GNOME Bugzilla – Bug 705597
So gparted got the File System wrong
Last modified: 2013-08-15 16:52:40 UTC
So gparted got the File System wrong, gfdisk and lfdisk get it right, but gparted gets it wrong. Obviously gparted is getting it's information from somewhere other than the other two. So gparted is wrong. Apparently there is a swaplabel somewhere that is fooling gparted. # fdisk.distrib -l /dev/sda|grep sda10 /dev/sda10 52859583 68538959 7839688+ 83 Linux # parted /dev/sda10 print Model: Unknown (unknown) Disk /dev/sda10: 8028MB Sector size (logical/physical): 512B/512B Partition Table: loop Number Start End Size File system Flags 1 0.00B 8028MB 8028MB linux-swap(v1) # gfdisk -l /dev/sda|grep sda10 /dev/sda10 3497 4533 7832160 83 Linux So gparted's File System is not related to "82" or "83". So how do I correct this wrong idea that gparted is reporting??!!
See, it is ext3! # fsck.ext3 -v /dev/sda10 e2fsck 1.42.8 (20-Jun-2013) /dev/sda10: clean, 2232/490560 files, 1834365/1959922 blocks # mount|grep /dev/sda10 /dev/sda10 on /music type ext3 (rw,nosuid,nodev,noexec,noatime,errors=continue,commit=222,barrier=1,data=ordered) So STOP saying it is swap!
# disktype /dev/sda10 --- /dev/sda10 Block device, size 7.477 GiB (8027841024 bytes) Ext3 file system UUID 4FF328E3-A3A7-44F7-A998-6C0404616E15 (DCE, v4) Volume size 7.477 GiB (8027840512 bytes, 1959922 blocks of 4 KiB) Linux swap, version 2, illegal subversion, 4 KiB pages So disktype gives BOTH... wonderful.
10:44 tmp# blkid -c /dev/null /dev/sda10 /dev/sda10: UUID="4ff328e3-a3a7-44f7-a998-6c0404616e15" TYPE="ext3" 10:44 tmp# blkid /dev/sda10 /dev/sda10: UUID="4ff328e3-a3a7-44f7-a998-6c0404616e15" SEC_TYPE="ext2" TYPE="ext3"
p# wipefs /dev/sda10 offset type ---------------------------------------------------------------- 0x438 ext3 [filesystem] UUID: 4ff328e3-a3a7-44f7-a998-6c0404616e15
Created attachment 251015 [details] stop giving me this error!
GParted uses external libraries and programs to determine the file system. In comment #1, parted (libparted) reports that the partition contains "linux-swap(v1)" signatures. As such this appears to be a problem with the libparted library. What version of parted are you using? You can use "parted -v" to display the version.
Can you also explain the steps you did to produce this issue. Include any partitioning, file system creations, etc that you performed before and while GParted was running, both using GParted and using other methods.
Yes I bet it is because of the word SWAPSPACE2 # dd if=/dev/sda10|strings -t x|head -n 2 ff6 SWAPSPACE2 3e1020 lost+found left sitting there after I did: 1. used mkswap on the wrong partition. 2. used fsck to recover that partition. Package: gparted Version: 0.16.1-1 Kernel: Linux 3.9-1-486 Versions of packages gparted depends on: ii libatkmm-1.6-1 2.22.7-2 ii libc6 2.17-92 ii libgcc1 1:4.8.1-8 ii libglib2.0-0 2.37.5-1 ii libglibmm-2.4-1c2a 2.36.2-1 ii libgtk2.0-0 2.24.20-1 ii libgtkmm-2.4-1c2a 1:2.24.4-1 ii libpangomm-1.4-1 2.34.0-1 ii libparted0debian1 2.3-13 ii libsigc++-2.0-0c2a 2.2.10-0.2 ii libstdc++6 4.8.1-8 ii libuuid1 2.20.1-5.5 gparted recommends no packages. Versions of packages gparted suggests: pn dmraid <none> ii dmsetup 2:1.02.77-4 ii dosfstools 3.0.22-1 pn gpart <none> pn jfsutils <none> pn kpartx <none> pn ntfsprogs <none> pn reiser4progs <none> pn reiserfsprogs <none> pn xfsprogs <none> ii yelp 3.8.1-2 -- no debconf information
So sda10 has both swap and ext3 file system signatures. Parted and GParted (via libparted) report sda10 as containing swap, blkid and wipefs (via libblkid) report it containing ext3. Possible fixes: 1) If sda10 doesn't contain any files you want you can re-format the partition to ext3 again using GParted. It erases old file system signatures before creating the new file system. 2) Otherwise you can manual clear the swap signature in sda10. There may be a Kernel caching consistency issue between sda and sda10 which means parted and GParted don't see the change. Either: 2.1) Use GParted to create a temporary "cleared" partition, or 2.2) Reboot.
There are files there. Yes I have rebooted many times. Apparently all I need to do is just say overwrite even one letter of SWAPSPACE2. Are you saying I should chose "Format to"->"cleared" and promise this will not touch any of the files on my disk even though it is under the Format to menu? Isn't there some better documented way of zapping one byte? There is no room to make a copy of this partition. So { dd .. ; echo X; dd ...;} > /dev/copy_of_partition isn't acceptable.
(In reply to comment #10) > Are you saying I should chose "Format to"->"cleared" and promise this will not > touch any of the files on my disk even though it is under the Format to menu? No. Format to -> Cleared will erase the contents of a partition. > Isn't there some better documented way of zapping one byte? > > There is no room to make a copy of this partition. So { dd .. ; echo X; dd > ...;} > /dev/copy_of_partition isn't acceptable. 1) Unmount /dev/sda10 2) Backup the first 8K dd if=/dev/sda10 of=sda10-8K-backup bs=1K count=8 3) Erase the "SWAPSPACE2" signature dd if=/dev/zero of=/dev/sda10 bs=1 seek=4086 count=10
OK... but wait a second, that would zap my data! $ cp /etc/motd /tmp/motd $ dd if=/dev/zero bs=1 seek=10 count=1 of=/tmp/motd 1+0 records in 1+0 records out 1 byte (1 B) copied, 0.000132424 s, 7.6 kB/s $ ls -l /etc/motd /tmp/motd -rw-r--r-- 1 root root 286 2006-03-17 /etc/motd -rw-r--r-- 1 jidanni jidanni 11 08-09 12:55 /tmp/motd I'll ask the fsck guy... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719195
Oh I see, I need dd conv=notrunc ...
But still dd should be the last resort. Who knows, me tinkering in there could upset some checksum somewhere else! No documentation on if it is safe to tamper there either.
If you do not wish to use "dd" to erase the swap signature, then you might consider the following: 1) Ensure that you have a backup of your data. 2) Locate the offset in the partition where the signature occurs 3) Use hexedit to visually edit the partition at this offset and alter the signature. The man page for hexedit contains details on how to use this tool.
(In reply to comment #14) > Who knows, me tinkering in there could upset some checksum somewhere else! > No documentation on if it is safe to tamper there either. Ext3 file system doesn't have any checksums. Continuing steps from comment #11 ... 4) Check the file system afterwards fsck.ext3 -f /dev/sda10
OK, according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719195 it seems that 1. yes it is my job to fix it myself. 2. maybe the tests that (current too?) (g)parted uses need to be smarter. The .debs are too old for me to say, but I did ask for new ones... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719275
Thank you for responding with these links. After reading the reports I agree that it is the responsibility of the user to fix. In this case the problem was created by reformatting an ext3 file system to linux-swap, and then running e2fsck to try to restore the original ext3 file system. This is an abnormal situation. If a partition is reformatted then one should not expect to be able to recover all data without any problems. Also as pointed out in the first link for comment #17, there are inherent problems in relying on either the msdos partition type code, or determining the file system type from the partition contents. There is no _one_ right choice. Closing this report as NOTGNOME since the base detection of file systems is in the libparted library, and not in the GParted code.