On 22/02/2012 11:44, Manuel Arostegui wrote:
Hey all, Whilst trying to upgrade one box from Debian Lenny to Debian Squeeze I have run into some problems with mdadm and the RAID labeling. Kernel: 2.6.32-41 mdadm version: v3.1.4 Disks: 4 RAID devices: /dev/md0 - boot - RAID1 - ext3 /dev/md1 swap /dev/md2 - "/" - RAID1 - ext3 /dev/md3 - "/var/lib/mysql" - RAID10 - xfs When doing the dist-upgrade and replacing the kernel + udev the system changes the RAID devices to md124, md125, md126 etc. As far as I have read, this makes sense - as mdadm is changing superblock and has to recalculate the whole RAID. This is big problem, if you have devices into /etc/fstab, like we do.
mdadm doesn't change superblocks in the manner you suggest - there isn't even an option yet to --update=metadata. I don't know Debian but it sounds like the dist-upgrade must be doing something odd. Your device names ought to be being preserved. Does doing a dist-upgrade involve a reboot part-way through? It ought to have your mdadm.conf in its initrd, or at the very least preserve your hostname, and maybe it doesn't.
The nearest I have seen is booting a system with a rescue CD when existing arrays get auto-assembled with high numbers (from 127 down) which can cause problems the next time you reboot back into the original system (because the on-disc metadata now thinks the array prefers to be e.g. md127 instead of md0). This is all to do with a missing mdadm.conf and/or the hostname not matching the arrays' homehost.
[...]
If we re-check the labels we can see all the devices got the same label (the one assigned to md0, md1 etc), so probably grub is trying to boot from single devices, and not from the md0 which is /boot
Grub always boots from single devices. This is why you have to use metadata 0.90 or 1.0 with RAID-1 for /boot. Generally the BIOS and therefore grub will boot from the first available drive, so if your normal first drive dies, the second drive becomes the first and you can still boot. Having said that, grub2 has real support for md RAID so you can boot off any metadata and RAID level with it, as long as the BIOS can read grub off the first drive.
This is blkid's output: /dev/sdb1: LABEL="boot" UUID="6d15111c-d2d9-4636-b2a5-7954ddcbcae2" SEC_TYPE="ext2" TYPE="ext3"
[...]
/dev/md0: LABEL="boot" UUID="6d15111c-d2d9-4636-b2a5-7954ddcbcae2" SEC_TYPE="ext2" TYPE="ext3"
[...]
As we have to migrate loads of machines, using labels is the fastest and cleanest way to do it. Just create the labels and change /etc/fstab across all the machines and voilá. But we cannot get it running. Is there any workaround to work with labels and avoid all the disks in the raid to get them as well?.
As you can see, it doesn't work. This will always happen with mdadm metadata version 0.90 and 1.0 with RAID-1 and is the only way grub can boot at all.
Using UUID doesn't seem like a good idea, as they may change with future dist-upgrades, mdadm upgrades etc.
Using UUID won't work anyway, for the same reasons as using the label doesn't work.
Has someone had same/similar problem with mdadm?
It's not really a mdadm problem, I think you need to find a way to fix whatever it is that's causing your arrays to be renamed/renumbered.
The only other thing that occurs to me is to check whether the upgrade process gives you a symlink like /dev/md/d0 which points to /dev/md127 (and similarly for your original md1-3), and if it does, fix up your Lenny systems to have those symlinks and use them in your fstab.
Sorry I can't give any more positive help. Cheers, John. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
