Preventing Boot Mode and Order Changes After MAAS Installation on a 2288v6 Server

Users
,
1

I’ve encountered a challenging issue during the installation of a 2288v6 server that I hope to get some insights on. After successfully completing the system installation, the server boots in legacy mode and attempts to PXE boot, but it halts at the booting screen. Here’s an image illustrating the issue:

image
image1003×411 53.8 KB

Despite ensuring UEFI boot during installation, it perplexingly switches to legacy boot afterward. My objective is to maintain the boot mode and order as configured before the MAAS installation, ideally booting directly from the disk rather than transitioning through PXE to the local disk.

Is there a way to prevent MAAS from altering my boot mode and order post-installation? Any guidance or suggestions to directly boot into the disk, bypassing PXE, would be greatly appreciated.

PS: I’m certain of initiating the installation in UEFI mode and am puzzled by the switch to legacy boot.
image

2

Can you try changing the power boot type of this machine’s power configuration to EFI boot on MAAS Web UI?

3

image
image920×352 15.9 KB

The power boot type is automatically recognized as efi.

4

Hi @maristelsksk

Any guidance or suggestions to directly boot into the disk, bypassing PXE, would be greatly appreciated.

MAAS needs your machine to PXE boot all the time first. This is because if the machine boots from the disk first after a deployment, you won’t be able to recommission/redeploy (for example) the machine. I.e. you can’t do it directly from MAAS, but you have to do it manually or use another script to interact with BMC if supported

5

In our env, server ports are shared between two VLANs (provisioning and management). After the deploy is complete, we actually don’t need MAAS to continue managing it through PXE. When we need to reinstall, there will be a separate API to move the port to the provisioning VLAN.
I’ve noticed that MAAS uses the reorder_uefi settings in curtin. I tried to disable it in the curtin configuration file, but it seems to have no effect.

I have tried to add the ipmitool command in curtin to manually point to disk boot, but it seems to be overridden by subsequent operations by MAAS.
like this

debconf_selections:
 maas: |
  {{for line in str(curtin_preseed).splitlines()}}
  {{line}}
  {{endfor}}
grub:
  update_nvram: false
  reorder_uefi: false
late_commands:
  100-maas: [wget, '--no-proxy', {{node_disable_pxe_url|escape.json}}, '--post-data', {{node_disable_pxe_data|escape.json}}, '-O', '/dev/null']
  101-maas_install_ipmitool_ubuntu:  [ apt, '-y',install,ipmitool ]
  102-maas_next_boot_disk_uefi: [ipmitool,chassis,bootdev,disk,options,'=','efiboot,persistent']

I look forward to your reply. THX！ :grinning:

6

According to the diagram here, the curtin preseeding happens prior to the cloud-init stage. Would you try to manually upload a script for changing the boot order on the deploy dialog.

7

Because curtin changes the boot order before the machine restarts during installation, I even suspect that this happens after the late_command , which is why my ipmitool command doesn’t take effect.
As for cloud-init, that’s something that comes into play after the system has booted up.

1 Like