GNOME Bugzilla – Bug 582497
detects reiserfs root partition as linux-swap
Last modified: 2010-03-09 23:36:30 UTC
Please describe the problem: gparted detects my root partition /dev/sda3 as linux-swap instead of reiserfs. it then tries to swapon it and blocks me trying to resize the partition. Steps to reproduce: 1. take my disk 2. start gparted 3. Actual results: Expected results: it should detect it as reiserfs Does this happen every time? yes Other information: fau-stud-033-054 mnt # parted -l Model: ATA ST9100821AS (scsi) Disk /dev/sda: 100GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 32.9MB 32.9MB primary ntfs boot 2 32.9MB 2007MB 1974MB primary linux-swap 3 2007MB 32.0GB 30.0GB primary linux-swap system: fau-stud-033-054 mnt # uname -a Linux fau-stud-033-054 2.6.29-gentoo #4 SMP PREEMPT Tue May 5 01:49:18 CEST 2009 i686 Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz GenuineIntel GNU/Linux
Thank you including the output from parted with this bug report. The GParted applicatoin will only mount a partition if you instruct it to do so. Are you using a live CD? If so which one and which version? It would appear that the problem lies with parted/libparted. Which version is in use?
I'm using gentoo, as seen in uname above. No live CD. The partition gets swapon'd immediately and can't be swapoff'd since it's not a swap partition. * sys-apps/parted Latest version available: 1.8.8 Latest version installed: 1.8.8 * sys-block/gparted Latest version available: 0.4.4 Latest version installed: 0.4.4
GParted uses libparted to detect many file systems including ReiserFS. Would you be able to open a bug with the Parted project? The mailing list address for parted bugs is: bug-parted@gnu.org You can find the parted bug reporting system at: http://www.gnu.org/software/parted/bugs.shtml I think the parted mailing list is monitored more frequently than the bug tracker.
Link to bug reported to bug-parted mailing list: http://lists.gnu.org/archive/html/bug-parted/2009-05/msg00006.html
Many enhancements have been made to parted since this bug report was opened. Would you be able to test the problem with the latest GParted Live 0.5.1-1 which includes parted-2.2?
The above should have read GParted Live 0.5.2-1. :)
Hi Curtis, thansk for your effort. I updated libparted to 2.2 and tried the command above on my gentoo box: parted -l Model: ATA ST9100821AS (scsi) Disk /dev/sda: 100GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 106MB 105MB primary ntfs boot 2 2007MB 32.0GB 30.0GB primary linux-swap(v1) 3 32.0GB 100GB 68.0GB extended lba 5 32.0GB 35.1GB 3126MB logical linux-swap(v1) 6 35.1GB 61.6GB 26.4GB logical jfs 7 61.6GB 82.0GB 20.5GB logical ntfs 8 82.0GB 98.7GB 16.7GB logical ntfs hidden 9 98.7GB 100GB 1324MB logical ext2 The partition layout has changed a bit, but the important partition (#2) is still shown as linux-swap instead of reiser fs tough it is still my root partition and perfectly mountable.
I just took a look at the first 10kb and saw a supicious "SWAPSPACE2" at position 4086 of the partition. Unfortunately I have no idea how the partition header should look like, but I guess this could confuse parted. At pos 65588 after a huge load of zeroes there is a "ReIsEr2Fs". I'll try to remove the "SWAPSPACE2" (replace it with zeroes) and see if that helps. Maybe I'll do a sys backup first ;)
I think you have just discovered the source of the problem. :) When I create a new partition formatted with ReiserFS, The first non-zero byte starts at position 0x10000 (65,536 decimal). All of the preceding bytes are zero. It would appear that somehow a linux-swap file system signature was left in your ReiserFS partition. I tried to recreate the problem by taking a linux-swap partition and reformatting it as ReiserFS, but the problem did not occur for me. Perhaps there was a problem with an older version of ReiserFS not overwriting the previous file system signatures?
Created attachment 155675 [details] first 65536 bytes of invalid partition dd if=/dev/sda2 of=dump bs=65536 count=1 compressed to tar.7zip
The "SWAPSPACE2" entry is most certainly the cause of the confusion as to the file system type. To fix this problem you should be able to set the bytes for "SWAPSPACE2" at offset 0x0FF6 to 0x00. I would suggest a hexadecimal editor such as hexedit to perform the editing while the partition is unmounted. Would you be able to try this and report back with your findings?
I'm currently doing a backup of the partition just in case, since my actual worries with this partition is that I want to resize it. Then I will use a little c++ app I created quickly to erase the bytes while mounted (it's such a hastle to unmount the root partition... I'll risk it ^^). Hopefully it will resolve this problem.
Having a backup is always a good idea when editing partitions and file systems. :) It is possible that the bytes from 0x0400 up to 0x041B inclusive will need to be zeroed as well, though I expect that zeroing out "SWAPSPACE2" will be sufficient.
It worked! Zeroing out the SWAPSPACE2 was sufficent. :)
That is good news. Since we are unsure of how the linux-swap file system signature came to live in the ReiserFS partition, and since I was unable to recreate this problem by reformatting a linux-swap partition to ReiserFS, I would like to close this bug as RESOLVED - FIXED. Do you agree that we should now close this bug?
Hm it was a pretty annoying bug, and I wouldn't let the usual user write directly to the partition. So it would be nice to change this in libparted. On the other hand, this probably is a very rare case, maybe caused by another bug which is already resolved. So I think we can mark it as resolved until someone else comes along with the same issue. Thanks for Your help!
GParted and Parted determine the file system type by looking for a recognized file system signature at known locations in the partition. The case you experienced is likely very rare because you actually had two file system signatures in a single partition. When GParted parses these known locations it stops at the first recognized signature. If/when a set of steps are discovered that cause this problem to occur, then please feel free to re-open this bug and provide this additional information. At the moment I am at a loss as to how it occurred in the first place. Closing this bug.