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 <[email protected]> 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 <[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/mailm >> an/listinfo/maas-devel >> >> >
-- Maas-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/maas-devel
