This is super interesting. It seems to me that MAAS commissioning should establish a unique way to identify each disk (unique MBR serial or GUID or label) and then we should use those on boot to be very precise.
I really don't like the arbitrary behaviour of GPT-when-over-2TB but I think that was studied extensively and proved the only sane approach because of old BIOS's. At some stage perhaps we can move to GPT-only but I suspect that's a loooong time away. Or perhaps we could move to a smarter approach, of using GPT everywhere when we know the BIOS will work with it, which should box the arbitrary behaviour to a shrinking group of older servers. Mark On 12/05/2017 11:40 PM, Daniel K wrote: > Digging into chain.c32, it looks like several options could be passed > for the boot drive. > > > Usage: > > chain.c32 hd<disk#> [<partition>] [options] > > chain.c32 fd<disk#> [options] > > chain.c32 mbr:<id> [<partition>] [options] > > chain.c32 boot [<partition>] [options] > > chain.c32 fs [options] > > chain.c32 label=<label> [options] > > chain.c32 guid=<label> [options] > > It would seem that label= or guid= would be the most sure-fire way to > boot the drive you want to boot, but that requires a GPT partition > instead of MBR. Fallback method for mbr could be use the mbr:<id> option: > > > The mbr: syntax means search all the hard disks until one with a > specific MBR serial number (bytes 440-443) is found. > > You can get the MBR serial number, by running the following command > (change /dev/sda to the correct device): > > $ hexdump -s 440 -n 4 -e '"0x%08x\n"' /dev/sda > > 0x0ec8694c > > Or by running: > > $ fdisk -l /dev/sda > > ... > > Disk identifier: 0x0ec8694c > > Example: > > LABEL mbr_serial > > COM32 chain.c32 > > APPEND mbr:0x0ec8694c -- Maas-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/maas-devel
