Re: setup-storage for raid5 + lvm
Hi, Nicolas Courtel wrote on 2009-04-30 11:11:46 +0200 [Re: setup-storage for raid5 + lvm]: # mdadm --zero-superblock /dev/sda2 # /lib/udev/vol_id -u /dev/sda2 6428a2d1-c30d-4916-ab6b-625117989651 [...] Ok, good to know, thanks for testing this. I wonder whether we should do something about this in setup-storage, but I believe that doing mdadm --zero-superblock on each and every non-RAID device is pure overkill. I agree. You may want to add a few words in the error message, something like Failed to obtain UUID [...], check that $device_name is not or has not been a RAID partition. sorry, I'm not familiar with the code in question, so I don't know if it's actually possible, but ideally, detecting this failure would trigger possible remedies to the problem (eg. zeroing the RAID superblock - unless this is potentially harmful for reasons not obvious to me right now) and then re-try. I can imagine that this might not be as simple to implement as it sounds. As an alternative, there could be a pedantic mode (triggered by some flag) which actually does zero each potential superblock (again, unless there is some reason this might be undesirable). Then, if you hit trouble with a particular installation, you could simply turn on this flag and see if it solves your problem without needing to go into any extensive debugging. Having something that just works even in awkward circumstances without manual intervention does not seem like a bad idea, does it? Thinking about the complexity of a modern Linux system, though, I tend to agree that something like that should be turned off by default ;-). Regards, Holger
Re: setup-storage for raid5 + lvm
# mdadm --zero-superblock /dev/sda2 # /lib/udev/vol_id -u /dev/sda2 6428a2d1-c30d-4916-ab6b-625117989651 # I wonder how this mdadm data was still there, though... Thanks for your help, Ok, good to know, thanks for testing this. I wonder whether we should do something about this in setup-storage, but I believe that doing mdadm --zero-superblock on each and every non-RAID device is pure overkill. I agree. You may want to add a few words in the error message, something like Failed to obtain UUID [...], check that $device_name is not or has not been a RAID partition. -- Nicolas
Re: setup-storage for raid5 + lvm
[...] The error message is the following (full log is at http://paste.debian.net/34215/) The uninitialized stuff warnings indicated some bugs that I need to look into, but that doesn't seem to be the showstopper. Executing: /lib/udev/vol_id -u /dev/sda2 Command /lib/udev/vol_id -u /dev/sda2 had exit code 4 Failed to obtain UUID for /dev/sda2 I originally wanted to have one swap slice on each disk, but in this case the error is on the sdb swap partition: Executing: /lib/udev/vol_id -u /dev/sdb2 Command /lib/udev/vol_id -u /dev/sdb2 had exit code 4 Failed to obtain UUID for /dev/sdb2 Any clue? That should only occur with some old mkswap versions that did not set up the UUID, but that doesn't seem to be the case here: Executing: udevsettle --timeout=10 mkswap /dev/sda2 (STDOUT) Setting up swapspace version 1, size = 1069281 kB (STDOUT) no label, UUID=3aa0ad8c-b7c9-428d-a2be-3511298c86af So, mysteriously, that information is lost afterwards. Hmm, looking at the code of vol_id it seems that parted might have overridden the volume id for /dev/sda2 (instead of /dev/sda1 or /dev/sda3). Could you re-run that failing installation and, once it aborts, do parted -s /dev/sda print Thanks, Michael pgps9Bjmqc7Be.pgp Description: PGP signature
Re: setup-storage for raid5 + lvm
Michael Tautschnig a écrit : Executing: /lib/udev/vol_id -u /dev/sda2 Command /lib/udev/vol_id -u /dev/sda2 had exit code 4 Failed to obtain UUID for /dev/sda2 I originally wanted to have one swap slice on each disk, but in this case the error is on the sdb swap partition: Executing: /lib/udev/vol_id -u /dev/sdb2 Command /lib/udev/vol_id -u /dev/sdb2 had exit code 4 Failed to obtain UUID for /dev/sdb2 Any clue? That should only occur with some old mkswap versions that did not set up the UUID, but that doesn't seem to be the case here: Executing: udevsettle --timeout=10 mkswap /dev/sda2 (STDOUT) Setting up swapspace version 1, size = 1069281 kB (STDOUT) no label, UUID=3aa0ad8c-b7c9-428d-a2be-3511298c86af So, mysteriously, that information is lost afterwards. Hmm, looking at the code of vol_id it seems that parted might have overridden the volume id for /dev/sda2 (instead of /dev/sda1 or /dev/sda3). Could you re-run that failing installation and, once it aborts, do parted -s /dev/sda print This looks ok: # parted -s /dev/sda print [...] Number Start End SizeType File system Flags 1 32.3kB 535MB 535MB primary ext2 raid 2 535MB 1604MB 1069MB primary linux-swap 3 1604MB 320GB 318GB primary raid No raid on sda2, but vol_id disagrees: # /lib/udev/vol_id --export /dev/sda2 ID_FS_USAGE=raid ID_FS_TYPE=linux_raid_member [...] So vol_id needs the --skip-raid option to return the uuid; a small patch of setup-storage makes the installation work much better: --- Fstab.pm.~1~2009-04-22 11:41:56.0 + +++ Fstab.pm2009-04-27 12:41:55.0 + @@ -94,7 +94,7 @@ # or labels, use these if available my @uuid = (); FAI::execute_ro_command( -/lib/udev/vol_id -u $device_name, \...@uuid, 0); +/lib/udev/vol_id --skip-raid -u $device_name, \...@uuid, 0); # every device must have a uuid, otherwise this is an error (unless we # are testing only) I don't know if this patch is a good idea, though, or if this behavior of vol_id should be considered as a feature or a bug. -- Nicolas
Re: setup-storage for raid5 + lvm
Michael Tautschnig a écrit : [...] So, mysteriously, that information is lost afterwards. Hmm, looking at the code of vol_id it seems that parted might have overridden the volume id for /dev/sda2 (instead of /dev/sda1 or /dev/sda3). Could you re-run that failing installation and, once it aborts, do parted -s /dev/sda print This looks ok: # parted -s /dev/sda print [...] Number Start End SizeType File system Flags 1 32.3kB 535MB 535MB primary ext2 raid 2 535MB 1604MB 1069MB primary linux-swap 3 1604MB 320GB 318GB primary raid No raid on sda2, but vol_id disagrees: # /lib/udev/vol_id --export /dev/sda2 ID_FS_USAGE=raid ID_FS_TYPE=linux_raid_member [...] Did /dev/sda2 ever belong to a RAID array? Could you please try - parted -s /dev/sda set 2 raid off - run vol_id - mkswap /dev/sda2 - run vol_id Nothing interesting happens... The disk has been in a raid 1 array a while ago, but the partitioning was different, and has been cleaned up by the new installation. -- Nicolas
Re: setup-storage for raid5 + lvm
Michael Tautschnig a écrit : [...] So, mysteriously, that information is lost afterwards. Hmm, looking at the code of vol_id it seems that parted might have overridden the volume id for /dev/sda2 (instead of /dev/sda1 or /dev/sda3). Could you re-run that failing installation and, once it aborts, do parted -s /dev/sda print This looks ok: # parted -s /dev/sda print [...] Number Start End SizeType File system Flags 1 32.3kB 535MB 535MB primary ext2 raid 2 535MB 1604MB 1069MB primary linux-swap 3 1604MB 320GB 318GB primary raid No raid on sda2, but vol_id disagrees: # /lib/udev/vol_id --export /dev/sda2 ID_FS_USAGE=raid ID_FS_TYPE=linux_raid_member [...] Did /dev/sda2 ever belong to a RAID array? Could you please try - parted -s /dev/sda set 2 raid off - run vol_id - mkswap /dev/sda2 - run vol_id Nothing interesting happens... The disk has been in a raid 1 array a while ago, but the partitioning was different, and has been cleaned up by the new installation. Ok, maybe mdadm helps, but I don't know for sure how to apply it: - Does mdadm --zero-superblock /dev/sda2 work? If not, you might need to run mdadm --zero-superblock /dev/sda. - Does running vol_id work afterwards? Thanks, Michael pgpdbig5dSMCL.pgp Description: PGP signature
