How does MAAS pick which volume to boot from?

Wed Dec 6 19:20:26 UTC 2017

Lee,

Removing the argument prevents it from booting.

I get a repeating error:
> ERR: When syslinux is not booted from physical disk (or its emulation),
> 'boot' and 'fs' are meaningless.
> boot:

On Wed, Dec 6, 2017 at 3:28 AM, Lee Trager <lee.trager at canonical.com> wrote:

> What happens if you remove the argument(the append line) completely? On a
> test host it automatically selects the right drive.
>
> Lee
>
> On Tue, Dec 5, 2017 at 11:56 PM, Dmitrii Shcherbakov <dmitrii.shcherbakov@
> canonical.com> wrote:
>
>> 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/prese
>> ed_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/model
>> s/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/mailm
>>> an/listinfo/maas-devel
>>>
>>>
>>
>> --
>> 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/20171206/616a2285/attachment-0001.html>