APPEND hd0 in config.local.amd64.template for legacy boot in not valid

[Jack Storm]

on 64bit systems that only support legacy boot. I believe this will apply to all systems that are legacy boot. as APPEND hd0 is not a valid boot option for PXELINUX for local boot.

see https://wiki.syslinux.org/wiki/index.php?title=SYSLINUX#LOCALBOOT_type
and ./src/provisioningserver/templates/pxe/config.local.i386.template
as it already uses LOCALBOOT -1

With out this patch, when deploying, the system will sit at a boot: prompt during final boot from local media

[Lee Trager (ltrager)]

There is actually a note in our tests[1] that using LOCALBOOT is unreliable on i386 and AMD64. LOCALBOOT 0 is used on other architectures. I don't have any information as to why it was considered unreliable nor if -1 was attempted.

Is the current config not working on your machine?

[1] https://git.launchpad.net/maas/tree/src/provisioningserver/boot/tests/test_pxe.py#n511

[Jack Storm (jstorm)]

Correct, the current config of using APPEND hd0 does not work, as that would append, hd0 to the kernel command line options, Attached, is a console image of the system with APPEND hd0, attempting to boot, it just sits there for ever.

The config for i386 uses LOCALBOOT -1, and that works for me on my system.

For some reason git.launchpad.net is not pulling up for me this morning, so I'm about to either state what that link says, or something crazy.

From [https://wiki.syslinux.org/wiki/index.php?title=SYSLINUX#LOCALBOOT_type]
type -1 (minus one) : Cause the boot loader to report failure to the BIOS, which, on recent BIOSes, should mean that the next boot device in the boot sequence should be activated.

I'm guessing, -1 was not considered, is because of the phrase 'on recent BIOSes, should mean'

My Machine is an HP DL380E.

[Lee Trager (ltrager)]

I think I see why LOCALBOOT -1 isn't being used. -1 causes the the BIOS to try whatever is next in the boot order. This has two problems.

1. Existing machines may not have local boot configured to be next. This will cause deployment failures.
2. Network booting on many machines means try IPv4 then try IPv6. Some even try both TFTP and HTTP.

I recently evaluated using the boot next method on UEFI GRUB and found it significantly increased boot time because of 2.

This is a bit difficult because I understand this is broken for you but we also don't want to break other users. I'll ask the rest of the team for feedback.

[Adam Collard (adam-collard)]

Modern servers will all do UEFI booting, for the subset that don't only some of them will hit this issue. We are focussing on improving the boot experience for UEFI based servers.