mkreiserfs does not clear metadata from previous device users
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
reiserfsprogs (Ubuntu) |
Confirmed
|
High
|
Unassigned |
Bug Description
Binary package hint: volumeid
Hi,
Here's the issue:
I'm running Feisty with the latest updates.
During the boot it will come up to "Checking local filesystems" at which point it will try and do a check on /dev/sda3, which has fstab entry as follows:
# Entry for /dev/sda3 :
UUID=ef5542e4-
Unfortunately, upon boot, I get this (/var/log/
Log of fsck -C -R -A -a
Tue Mar 18 13:38:16 2008
fsck 1.40-WIP (14-Nov-2006)
Failed to open the device 'UUID=ef5542e4-
fsck died with exit status 8
Tue Mar 18 13:38:16 2008
----------------
At this point, it drops to a maintenence shell with a very screwy path (just /bin or something useless like that).
The problem was that the partition used to be a swap partition, and mkreiserfs did not overwrite the first 64 KB of the partition. Hence, the swapspace header was left untouched, even though at offset 0x10000 a reiserfs header was found.
Running sudo blkid /dev/sda3 will report:
/dev/sda3: UUID="a1a4ee27-
Running blkid reports the correct value; running vol_id reports a swap partition with UUID=ef5542e4-
IMHO, vol_id should check for other filesystem headers first and they should override whatever swap signature found. If the swap partition was actually being used, wouldn't the use overwrite whatever filesystem header is there?
TO REPRODUCE:
-format a partition (as swap)
-format it (do not clear as reiserfs)
-run vol_id (to identify partition)
-it will return type swap
Thanks,
Andrew
description: | updated |
Changed in reiserfsprogs (Ubuntu): | |
importance: | Undecided → High |
summary: |
- mkreiserfs does not clear metadata from previous users of the device + mkreiserfs does not clear metadata from previous device users |
0x10000 is in the middle of swap data. If vol_id checked for that first, wouldn't it be quite possible (not even all that unlikely if a reiserfs superblock had been swapped out ...) for it to run into something that looked like reiserfs or any other filesystem in the middle of the swap data? The swap data could be anything.
I have to say that mkreiserfs seems like the buggy program here.