How does MAAS pick which volume to boot from?

Wed Dec 6 04:40:10 UTC 2017

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

So for a MBR boot it would seem to make sense that if during commissioning,
grub is installed on /dev/sdc then it should pass hd2 instead of hd0 to
chain.c32, or pass mbr:<serial>. That way regardless of the bios
configuration, the correct drive would always boot. Looks like there are
some options to use variables in the pxe template files, but I doubt a guid
or mbr serial number would be availble.

Looks like I may be able to sidestep this by hardcoding something like
"label=boot" instead of hd0 in the template file, then forcing curtin to
use a gpt table instead of mbr, and ensuring the disk/partition with grub
is labeled "boot" and no others are labeled as such. Still not quite
familiar enough with MAAS to know where to make that adjustment.

This of course would also not be a problem if HPE would put the drives in
the right order. Or UEFI, which is not supported by these servers that I
can tell.

On Tue, Dec 5, 2017 at 11:06 PM, Daniel K <sathackr at gmail.com> wrote:

> Looks like the hd0 may be hardcoded :-/
>
> > root at maas1:~# cat /usr/lib/python3/dist-packages/provisioningserver/
> templates/pxe/config.local.amd64.template
> > DEFAULT local
> >
> > LABEL local
> >   SAY Booting local disk ...
> >   KERNEL chain.c32
> >   APPEND hd0
>
>
>
> On Tue, Dec 5, 2017 at 10:38 PM, Daniel K <sathackr at gmail.com> wrote:
>
>> So attacking this from the angle I'm most familiar with I've captured the
>> traffic between the maas server and a booting node to see if I can catch
>> the data in flight.
>>
>> PXE first downloads a file called pxelinux.0 - I see this file in
>> /var/lib/maas/boot-resources.
>> Then requests(and receives) a file called ldlinux.c32.
>>
>> Then requests a non existent file: pxelinux.cfg/<some sort of uuid/guid?>
>> > # Packet 344 from C:\Users\user\asdf.pcap
>> > - 345
>> > - 166.825599
>> > - 10.20.128.111
>> > - 10.20.4.30
>> > - TFTP
>> > - 121
>> > - Read Request, File: pxelinux.cfg/36383031-3839-3255-5831-353130303732,
>> Transfer type: octet, tsize=0, blksize=1408
>> > - # Packet 345 from C:\Users\user\asdf.pcap
>> > - 346
>> > - 166.836864
>> > - 10.20.4.30
>> > - 10.20.128.111
>> > - TFTP
>> > - 61
>> > - Error Code, Code: File not found, Message: File not found
>>
>> Then requests and receives a file called pxelinux.cfg/01-<mac address>
>> > # Packet 346 from C:\Users\user\asdf.pcap
>> > - 347
>> > - 166.837008
>> > - 10.20.128.111
>> > - 10.20.4.30
>> > - TFTP
>> > - 105
>> > - Read Request, File: pxelinux.cfg/01-e8-39-35-2b-c9-5c, Transfer
>> type: octet, tsize=0, blksize=1408
>>
>> which contains the following printable text:
>> > 95+\W1ExL@@T
>> > oad*DEFAULT local
>> > LABEL local
>> >   SAY Booting local disk ...
>> >   KERNEL chain.c32
>> >   APPEND hd0
>>
>> which I can correlate to log entries:
>> > 2017-12-05 22:17:49 provisioningserver.rackdservices.tftp: [info]
>> ldlinux.c32 requested by e8:39:35:2b:c9:5c
>> > 2017-12-05 22:17:49 provisioningserver.rackdservices.tftp: [info]
>> pxelinux.cfg/36383031-3839-3255-5831-353130303732 requested by
>> e8:39:35:2b:c9:5c
>> > 2017-12-05 22:17:49 provisioningserver.rackdservices.tftp: [info]
>> pxelinux.cfg/01-e8-39-35-2b-c9-5c requested by e8:39:35:2b:c9:5c
>>
>> I assume the "APPEND hd0" is what is telling the pxelinux loader which
>> disk to boot.
>> I searched but I cannot find a directory called pxelinux.cfg anywhere on
>> the maas servers, nor a file with any part of the mac address in it's name.
>> I'll assume then that some piece of maas is responding to that request
>> after fetching the config from some sort of database for that MAC
>> address/node.
>>
>> So then there must be a knob somewhere in MAAS that I can tweak to cause
>> a different disk to be sent in the APPEND hd0 command.
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Dec 5, 2017 at 5:24 PM, Lloyd Parkes <
>> lloyd+lp at must-have-coffee.gen.nz> wrote:
>>
>>> I originally sent this from the wrong email address and so it got hung
>>> up on list moderation.
>>>
>>>
>>> On 5 December 2017 at 10:45, Daniel K <sathackr at gmail.com> wrote:
>>> >
>>> > There must be something that tells the PXE loader which physical disk
>>> to try
>>> > to boot
>>>
>>> This is almost certainly hard coded in the PXELinux boot script to
>>> default to BIOS disk 0x80. Have a look at
>>> http://www.syslinux.org/wiki/index.php?title=SYSLINUX#LOCALBOOT_type
>>> and see if it helps.
>>>
>>> I would dig into this myself because I want to make my HPE servers
>>> boot as well, but I'm 3265km and two months away from my MAAS servers.
>>>
>>> Cheers,
>>> Lloyd
>>>
>>> --
>>> Maas-devel mailing list
>>> Maas-devel at lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/maas-devel
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/maas-devel/attachments/20171205/4a8d3803/attachment.html>