How does MAAS pick which volume to boot from?

[Mark Shuttleworth]

Well, the digging you've done is plenty. Please file a bug for this,
though, and subscribe me.

Mark

On 12/06/2017 02:33 PM, Daniel K wrote:
> Mark,
>
> Thank you for the response.
>
> It indeed would seem that chain.c32 supports selecting a
> disk/partition to boot based on its MBR serial or GPT GUID, so the
> steps should be just to have the provisioningserver script pass that
> info to chain.c32. That would certainly ensure that the drive that
> grub is installed to is the drive that gets booted, which would
> eliminate any bios errors or indeterministic behavior (such as when
> the HPE bios randomly decides to reset the boot order). I've also had
> boot orders getting surprise re-arranged in some SuperMicro systems.
>
> It seems like a simple task and I would love to contribute by writing
> and submit a pull request for this -- except I am not a developer and
> anything I write would look like something MacGyver would create
> rather than professional code.
>
>
>
> Thanks,
>
>
> Daniel
>
>
> On Wed, Dec 6, 2017 at 7:30 AM, Mark Shuttleworth <mark at ubuntu.com
> <mailto:mark at ubuntu.com>> wrote:
>
>
>     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
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/maas-devel/attachments/20171206/d9960ca2/attachment.html>