Same UUID on sda1, sdb1, sdc1, etc,... identical /boot

[GTBecker]

I have a 5-drive RAID10 (2x2+1 on sda2, sdb2, sdc2, sdd2, sde2) with identical boot partitions on sda1, sdb1, sdc1, sdd1, sde1 - even identical boot UUIDs. grub uses, and fstab mounts, /boot by UUID and both currently choose sde1 among the identical available partitions. My rationale is that, in the event mdadm fails a drive and it is subsequently physically removed, the system will still boot and run. It seems to work.

Despite the apparent success with the scheme, I've become a little uncomfortable with the notion and did some searching; I can't find any documentation that discusses the UUID selection processes of grub and fstab.

Is this method valid?

[Mute Ant]

If you need this sort of detail and the man pages don't actually say, a fail-safe position is that the search order will change on every boot, every different machine, every version upgrade. In a normal desktop PC, boot happens without reference to file systems and UUID; just the CPU, the BIOS, devices with BIOS numbers and sectors loaded into memory. That is, the boot sector, boot code lumps, vmlinuz and initrd.img must all be readable by the BIOS, not inside a software raid.

[GTBecker]

... the boot sector, boot code lumps, vmlinuz and initrd.img must all be readable by the BIOS, not inside a software raid.

Yes; that is the case. The BIOS runs the MBR of the available /boot partition it chooses, and it doesn't matter which drive it selects since each has an identical /boot partition. RAID doesn't start until the kernel loads; the BIOS can't and doesn't see anything in RAID.

I believe my concern for the selection process is immaterial; whichever drive the BIOS chooses, and however, makes no difference in the outcome if the /boot partitions are identical. If a drive has been failed and removed it simply chooses another to boot.

That raises one issue. Any changes to grub.cfg (manually or by update_grub) are normally made only to the currently mounted /boot partition. To maintain identical partitions grub.cfg must be propagated to the other /boot copies after any grub.cfg change.

Thanks for your thoughts.

[Mute Ant]

A normal grub-install fits 440 bytes of MBR code in sector 0 and embeds the next stage between sector 0 and the first partition. Usually no one notices, but you might. Is that code in all of your bootable drives? I think it's the GRUB script interpreter.

Code: Select all

/usr/sbin/grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding won't be possible!.

Code: Select all

xxd -l 32768 /dev/sda

...shows you the first 64 sectors of a drive.

[GTBecker]

Is that code in all of your bootable drives?

Apparently, yes. There are a few bytes in those 32k that differ from drive to drive, but each drive runs fine.

[Mute Ant]

Excelente. You are now Mint #1 at booting RAID [that is, the first person who made it work instead of whinging that it didn't]. I shall be sure to tell people it is possible. How, of course, is your privilege.