How does MAAS pick which volume to boot from?
Dmitrii Shcherbakov
dmitrii.shcherbakov at canonical.com
Wed Dec 6 07:56:15 UTC 2017
For non-UEFI systems it appears to be that MAAS 2.3.0 only generates a
curtin operation with "gpt" when storage devices are larger than 2 TiB:
https://github.com/maas/maas/blob/2.3.0/src/maasserver/preseed_storage.py#L224-L237
def _generate_disk_operation(self, block_device):
...
if bios_boot_method in [
"uefi", "powernv", "powerkvm"]:
disk_operation["ptable"] = "gpt"
if node_arch == "ppc64el":
add_prep_partition = True
elif (block_device.size >= GPT_REQUIRED_SIZE and # <---- this
node_arch == "amd64"):
disk_operation["ptable"] = "gpt"
add_bios_grub_partition = True
else: # <---- and this
disk_operation["ptable"] = "msdos"
class CurtinStorageGenerator:
... def generate(self):
...
# Generate each YAML operation in the storage_config.
self._generate_disk_operations()
...
def _generate_disk_operations(self):
"""Generate all disk operations."""
for block_device in self.operations["disk"]:
self._generate_disk_operation(block_device)
https://github.com/maas/maas/blob/2.3.0/src/maasserver/models/partitiontable.py#L51-L53
GPT_REQUIRED_SIZE = 2 * 1024 * 1024 * 1024 * 1024
Best Regards,
Dmitrii Shcherbakov
Field Software Engineer
IRC (freenode): Dmitrii-Sh
On Wed, Dec 6, 2017 at 7:40 AM, Daniel K <sathackr at gmail.com> 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
>
> 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
>>>>
>>>
>>>
>>
>
> --
> Maas-devel mailing list
> Maas-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/maas-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/maas-devel/attachments/20171206/7875e95c/attachment-0001.html>
More information about the Maas-devel
mailing list