Dmitrii, Thanks for the response -- I'm only working with a 32GB micro-sd card, nowhere near the 2TB for auto-gpt.
I tried setting the partition table type to GPT for a node in the "Ready" state and the request was ignored -- not sure how to force GPT without just changing it after install(which causes problems with automation) What I would expect to work: > maas maasadmin block-device update 753 partition_table_type=GPT gives me a "success" message but the type remains "MBR" On Wed, Dec 6, 2017 at 2:56 AM, Dmitrii Shcherbakov < [email protected]> 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/ > 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 <[email protected]> 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 <[email protected]> wrote: >> >>> Looks like the hd0 may be hardcoded :-/ >>> >>> > root@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 <[email protected]> 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 < >>>> [email protected]> 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 <[email protected]> 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 >>>>> [email protected] >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>> an/listinfo/maas-devel >>>>> >>>> >>>> >>> >> >> -- >> Maas-devel mailing list >> [email protected] >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/maas-devel >> >> >
-- Maas-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/maas-devel
