Transfered Grub can’t find /dev/md0 (Linux)

Please excuse, this pure Linux issue might not be very interesting for the indological audience of this blog. Pleased don’t be bored – this belongs to be on the net somewhere since others might face the same problem, too.

Problem (recent Debian testing, Kernel 2.6.30-1 – might not play a role, Grub 1.97~beta3-1): I’ve bought a new set of harddisks and assembled them to a brand new software raid1 chain from a Linux live system on CD  the usual way with Mdadm and formatted it with ext3. After that I’ve copied my filesystem to that which I tarballed before to an external harddisks from my old set of harddisks – no secret involved so far. I’ve executed chroot to reach the mounted filesystem and did update-grub and grub-install “(md0)” to reinstall the bootloader – it executed without errors. After reboot Grub started from the MBR of the first harddisk like planned but the raid chain wasn’t been found and so the boot precedure hung after Grub’s boot menu – not very amusing. On the net I’ve found several tips for people having the same problem, it was been told that Grub can’t handle all of the superblock versions which could have been created by different livesystems, a guy said that the problem typically occurs if the order of harddisks was manipulated on the bios level (both wasn’t the problem), and finally there were several suggestions concerning the fact that the Initramfs has to be updated regarding the new created filesystem, too. I did this (update-initramfs -u, before that the livesystem’s /dev and /proc have to be linked with mount -o bind /dev /mnt/dev and mount -t proc /proc /mnt/proc [or similar] before changing to the mounted filesystem with chroot, I don’t know if it’s critical but I’ve found an commented option raid1 in /etc/initramfs-tools/modules which I restored before) but without no response, still hung.

The solution (simple but hard to come to if you aren’t a Linux booting procedure insider): when the boot procedure hangs after several minutes it breaks and the Initramfs jumps into its shell (prompt: (initramfs) – I became very desperate to find out!). Just assemble the raid chain manually: mdadm –assemble /dev/md0 /dev/sda1 /dev/sdb1 (or similar) and jump back to the procedure tying exit. It boots. Then, after update-initramfs, update-grub and grub-install have been executed from their booted native system it works again! I haven’t found out what has been the problem up to the present day but I’ve seen that /boot/grub/grub.cfg contains the UUID of the raid where was just /dev/md0 when update-grub was executed in the chroot environment. But it seems that in general there is a  problem when you are using a live system with a different architecture.