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.

Maybe. It depends on how rigorous the check is. Kernel memory, where I
believe the actual mount of a reiserfs partition would usually take place,
can never be swapped as far as I know. That leaves a userspace program that
deals with an rfs partition, like mkreiserfs. Since those programs would
never operate (with good results) on an in-use swap partition, the chances
that the data contained in the header would match the relevant data for a
swap partition is highly unlikely. Looking at the reiserfs header (
http://homes.cerias.purdue.edu/~florian/reiser/reiserfs.php) one could check
the partition two ways: by computing (# of blocks in partition) * (block
size), which is more likely to be inaccurate due to volume size not matching
partition size, or by just checking if the header points to a valid root
node (by checking the node height value). This pattern seems relatively
unlikely to be reproduced in a swap partition.

This is a rather rigorous check, I will admit, but the reason I flagged this
as vol_id's problem was because often the space left in the beginning of
volumes is used for bootloader-related stuff. I think that it is more
desirable that mkreiserfs touch only what is needed. This hasn't been a
problem with linux distros in the past, obviously because this value was not
computed, but I think backwards compatibility is always a plus if we can get
it.

I don't know the code at all for vol_id, but if those who do thing this
approach is useful, worthwhile, and doable, I'm wiling to research and
submit a patch to this effect.

On Wed, Mar 19, 2008 at 7:01 PM, Colin Watson <email address hidden>
wrote:

> 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.
>
> --
> vol_id reports swap instead of resierfs
> https://bugs.launchpad.net/bugs/203704
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Where there's no clear ordering between two potential inhabitants of a device, we do not consider vol_id's failure to correctly guess which it is a bug.

The problem is as Colin says, mkreiserfs should have wiped the device as it formatted it.

(If we had nice graphical tools like parted to do partitioning, we'd be fine, since they do wipe the device first)

Can you describe how to reproduce this?

Oh boy, it's been a while since this happened. I think, if I remember
right, format a partition as swap, then format it without clearing it as
reiserfs. Then run vol_id to try to identify the partition, it'll identify
as swap.

Andrew

On Mon, Jan 16, 2012 at 11:37 PM, Evan Peck <email address hidden>wrote:

> Can you describe how to reproduce this?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/203704
>
> Title:
> mkreiserfs does not clear metadata from previous device users
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/reiserfsprogs/+bug/203704/+subscriptions
>

@Andrew Thank you!

It appears this bug report meets the criteria for:
-Confirmation
This bug's status will be raised to "Confirmed"
Thank you.

Awesome! Thanks for following up!

On Tue, Jan 17, 2012 at 8:03 PM, Evan Peck <email address hidden>wrote:

> @Andrew Thank you!
>
> It appears this bug report meets the criteria for:
> -Confirmation
> This bug's status will be raised to "Confirmed"
> Thank you.
>
> ** Description changed:
>
> 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-9a86-4504-a4f0-1edc56bc30aa /home reiserfs defaults 0 2
>
> Unfortunately, upon boot, I get this (/var/log/fsck/checkfs):
> - Log of fsck -C -R -A -a
> + 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-9a86-4504-a4f0-1edc56bc30aa': No
> such file or directory
> -
>
> 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).
>
> - 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.
> -
> + 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-950c-4439-9ce8-e69b4795c5c3" TYPE="reiserfs"
>
> Running blkid reports the correct value; running vol_id reports a swap
> partition with UUID=ef5542e4-9a86-4504-a4f0-1edc56bc30aa
>
> -
> 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
>
> ** Changed in: reiserfsprogs (Ubuntu)
> Status: New => Confirmed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/203704
>
> Title:
> mkreiserfs does not clear metadata from previous device users
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/reiserfsprogs/+bug/203704/+subscriptions
>

You are quite welcome!
Thank you for taking the time to make Ubuntu better for everyone.