boot fails: mdadm not looking for UUIDs but hostname in superblocks

The installer seems to work around the issue of an unset hostname in initramfs by putting an ARRAY line into the mdadm.conf file, or by having an unset hostname when creating the md device. Whichever, this error does not appear after raid installations.

I can confirm this issue. Hostname is none in initrd context. Thus mdadm fails when auto scan of md arrays. One workaround is to manually set HOMEHOST (to the hostname which was used while initially creating the array) and rebuild the initial ramdisk with mkinitramfs.

I can confirm this bug as described by the reporter on the latest jaunty system.

:-Dustin

I'm marking this 'confirmed' and priority 'low'. This is something that should be fixed obviously, but it's not happening on raid installs from cd.

:-Dustin

Okay, I've spent a little more time on this, and I think there is a lot more involved from a configuration perspective to manually take a non-RAID system to a root-on-RAID1 system.

Here are the steps I was able to use in a Jaunty KVM to get this to work.

Install Jaunty into a KVM, and boot it with a single disk:
 HOST# qemu-img create -f qcow2 disk1.img 4G
 HOST# kvm -hda disk1.img -cdrom jaunty-server-amd64.iso

Ensure that system is happy, hunkey, and dorey.

Create a new disk.
 HOST# qemu-img create -f qcow2 disk2.img 4G

Launch the guest with both disks now:
 HOST# kvm -hda disk1.img -hdb disk2.img

The rest of these commands are to be run in the guest....

Partition:
 # fdisk /dev/sdb
n
p
(enter)
(enter)
t
fd
w

Create /dev/md0:
 # mdadm --create /dev/md0 --level=raid1 --raid-devices=2 missing /dev/sdb1

Append your raid configuration file:
 # mdadm --detail --scan >> /etc/mdadm/mdadm.conf

Configure your raid. Note that this will update your initramfs with the new mdadm.conf file!!!
 # dpkg-reconfigure mdadm

Fix /etc/fstab, which is configured for /dev/sda1 to provide /. Update this to /dev/md0 (or the UUID of /dev/md0).
 # vi /etc/fstab
...

Add the new disk to your bootloader device map:
 # echo "(hd1) /dev/sdb" >> /boot/grub/device.map

Format the filesystem:
 # mkfs.ext3 /dev/md0

Mount it:
 # mount /dev/md0 /mnt

Copy the data over from the first dist to the second. Make sure you exclude the dynamically created kernel filesystems.
 # rsync -aP --exclude /dev/ --exclude /mnt/ --exclude --/proc/ --exclude /sys / /mnt
 # mkdir /mnt/dev /mnt/mnt /mnt/proc /mnt/sys

Install the bootloader on the raid device.
 # grub-install /dev/md0

Reboot.

Hit (esc) to enter the grub menu. Hit (e) to edit your kernel line. Replace root=(*) with root=/dev/md0.

:-Dustin

This issue is really a matter of process and configuration.

I'm converting it from a bug, to a question/answer.

Cheers,
:-Dustin

for your information :
grub-install /dev/md0 just crashed my installation...... seems it's really NOT a good idea.
server keeps on doing bios -> loading grub -> bios -> ....

This is a bug with mdadm --incremental not doing hotplug, because it looks for permission to do so in mdadm.conf.

On hotplug systems mdadm.conf should not have contain any specific references, maybe it should explicity mention "any" like this:?

DEVICE <any>
HOMEHOST <any>
ARRAY <any>

This whole bussiness of locking down array assembly (homehost,ARRAY) may just be due to the historical (suboptimal) mdadm design to assamble raids going by major/minor numbers saved in the superblocks. Those should always be considered being dynamic(depreciated). Using --assemble --uuid mdadm takes a UUID and match this unique but same UUID on all member devices.

Of course we should refrain from running arrays that are not complete (avoid leading them to desync by subsequent writes), unless we are required to recover data from a specific failed array and --run it manually or by a startup script.