<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><br>
Well, the digging you've done is plenty. Please file a bug for
this, though, and subscribe me.<br>
<br>
Mark<br>
<br>
On 12/06/2017 02:33 PM, Daniel K wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMsMBN3RxPCMefmox0m0VHEkiFz0MFE2NW_gOb3B26NWkPRVeQ@mail.gmail.com">
<div dir="ltr">Mark,
<div><br>
</div>
<div>Thank you for the response.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div><br>
</div>
<div>Daniel</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Dec 6, 2017 at 7:30 AM, Mark
Shuttleworth <span dir="ltr"><<a
href="mailto:mark@ubuntu.com" target="_blank"
moz-do-not-send="true">mark@ubuntu.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
This is super interesting. It seems to me that MAAS
commissioning should<br>
establish a unique way to identify each disk (unique MBR
serial or GUID<br>
or label) and then we should use those on boot to be very
precise.<br>
<br>
I really don't like the arbitrary behaviour of
GPT-when-over-2TB but I<br>
think that was studied extensively and proved the only sane
approach<br>
because of old BIOS's. At some stage perhaps we can move to
GPT-only but<br>
I suspect that's a loooong time away. Or perhaps we could
move to a<br>
smarter approach, of using GPT everywhere when we know the
BIOS will<br>
work with it, which should box the arbitrary behaviour to a
shrinking<br>
group of older servers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Mark<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
On 12/05/2017 11:40 PM, Daniel K wrote:<br>
> Digging into chain.c32, it looks like several
options could be passed<br>
> for the boot drive.<br>
><br>
> > Usage:<br>
> > chain.c32 hd<disk#> [<partition>]
[options]<br>
> > chain.c32 fd<disk#> [options]<br>
> > chain.c32 mbr:<id> [<partition>]
[options]<br>
> > chain.c32 boot [<partition>] [options]<br>
> > chain.c32 fs [options]<br>
> > chain.c32 label=<label> [options]<br>
> > chain.c32 guid=<label> [options]<br>
><br>
> It would seem that label= or guid= would be the
most sure-fire way to<br>
> boot the drive you want to boot, but that requires
a GPT partition<br>
> instead of MBR. Fallback method for mbr could be
use the mbr:<id> option:<br>
><br>
> > The mbr: syntax means search all the hard
disks until one with a<br>
> specific MBR serial number (bytes 440-443) is
found.<br>
> > You can get the MBR serial number, by running
the following command<br>
> (change /dev/sda to the correct device):<br>
> > $ hexdump -s 440 -n 4 -e '"0x%08x\n"' /dev/sda<br>
> > 0x0ec8694c<br>
> > Or by running:<br>
> > $ fdisk -l /dev/sda<br>
> > ...<br>
> > Disk identifier: 0x0ec8694c<br>
> > Example:<br>
> > LABEL mbr_serial<br>
> > COM32 chain.c32<br>
> > APPEND mbr:0x0ec8694c<br>
<br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>