Deployment fails due to missing EFI directory on system with no EFI support

[Jeff Lane ]

Attempting to deploy various versions of Ubuntu via MAAS 2.4.2 (7034-g2f5deb8b8-0ubuntu1). I've tried 16.04.5 and 18.04.1 and end up with messages in the logs like such:

Looking in the system settings, this system does not use EFI at all. It is purely BIOS mode, yet the installer is complaining about a missing efi directory when it fails.

The machine is successfully commissioned, and commissioning does not detect EFI and thus does not create a /boot/efi partition as it is not necessary. Watching the node boot via console, it clearly is doing a BIOS mode PXE boot from the NICs, it is not loading an EFI environment first.

A search and skimming of the manuals for this model (ProLiant SL230s) shows that it has no EFI options available as well:
https://support.hpe.com/hpsc/doc/public/display?docId=c03239129
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c03239183

Installation finished. No error reported.

Running command ['udevadm', 'settle'] with allowed return codes [0] (capture=False)

Running command ['umount', '/tmp/tmpmg3cwxp7/target/sys'] with allowed return codes [0] (capture=False)

Running command ['umount', '/tmp/tmpmg3cwxp7/target/proc'] with allowed return codes [0] (capture=False)

Running command ['umount', '/tmp/tmpmg3cwxp7/target/dev'] with allowed return codes [0] (capture=False)

finish: cmd-install/stage-curthooks/builtin/cmd-curthooks: SUCCESS: curtin command curthooks

start: cmd-install/stage-hook/builtin/cmd-hook: curtin command hook

Finalizing /tmp/tmpmg3cwxp7/target

finish: cmd-install/stage-hook/builtin/cmd-hook: SUCCESS: curtin command hook

curtin: Installation failed with exception: Unexpected error while running command.

Command: ['grep', 'efi', '/proc/mounts']

Exit code: 1

Reason: -

Stdout: ''

Stderr: ''

A full paste of the install lot from the MAAS web ui is here: https://pastebin.canonical.com/p/6SCncBtHGd/

And the node's config data from MAAS can be found here:
https://pastebin.canonical.com/p/dbV7PTVnYw/

[Andres Rodriguez (andreserl)]

Hi Jeff,

Could you please provide:

1. curtin config (maas <user> machine get-curtin-config <syustem-id>)
2. curtin version
3. Power settings of this machine (maas <user> machine power-parameters <system-id>). I'm interested in the power_boot_type.

Thanks!

[Andres Rodriguez (andreserl)]

Couple notes:

- Please set this back to 'New' once the information is provided.
- I invalidated cloud-init because it has nothing to do with this failing process.

[Jeff Lane  (bladernr)]

curtin config: https://pastebin.canonical.com/p/CqYxpMgzqg/
power settings:

bladernr@weavile:~$ maas bladernr machine power-parameters 7b4hgq
Success.
Machine-readable output follows:
{
    "power_address": "192.168.224.103",
    "power_boot_type": "auto",
    "power_driver": "LAN_2_0",
    "power_pass": "NKYG1RhbJI",
    "power_user": "maas",
    "mac_address": ""
}

It just uses IPMI for access and control, no special API, AMT or other magic. Though now that you've had me run that, why is the type "auto" when the web UI says "IPMI"??

and curtin version:
bladernr@weavile:~$ apt-cache policy curtin
curtin:
  Installed: 18.1-17-gae48e86f-0ubuntu1~18.04.1
  Candidate: 18.1-17-gae48e86f-0ubuntu1~18.04.1
  Version table:
 *** 18.1-17-gae48e86f-0ubuntu1~18.04.1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     18.1-5-g572ae5d6-0ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

[Andres Rodriguez (andreserl)]

Thanks for the quick response. So from the information provided above I can conclude that:

1. MAAS is *not* telling the machine to boot EFI.
2. The storage config reflects one for legacy systems (non-EFI).

This would either be an issue with curtin (although its quite strange it does what it does when in other legacy systems it doesn't). Or the firmware is buggy that's exposing something that doesn't exist and curtin is detecting it??

I'll let the curtin guys chip in. MArking invalid for MAAS.

[Ryan Harper (raharper)]

This is not a curtin bug. In your config, you're providing a late_commands which invoke grep and do not eat the return code, so if grep fails to find it's query, it returns 1 and this fails the install (one or more of the late_commands failed).

From config:

late_commands:
  01_efivars:
  - grep
  - efi
  - /proc/mounts
  02_efimnt:
  - mountpoint
  - /sys/firmware/efi/efivars
  03_hexdump:
  - curtin
  - in-target
  - --
  - sh
  - -c
  - 'grep efi /proc/mounts

From the install log we can see install was OK, but late_commands which run after install is complete failed:

Installation finished. No error reported.
Running command ['udevadm', 'settle'] with allowed return codes [0] (capture=False)
Running command ['umount', '/tmp/tmpmg3cwxp7/target/sys'] with allowed return codes [0] (capture=False)
Running command ['umount', '/tmp/tmpmg3cwxp7/target/proc'] with allowed return codes [0] (capture=False)
Running command ['umount', '/tmp/tmpmg3cwxp7/target/dev'] with allowed return codes [0] (capture=False)
finish: cmd-install/stage-curthooks/builtin/cmd-curthooks: SUCCESS: curtin command curthooks
start: cmd-install/stage-hook/builtin/cmd-hook: curtin command hook
Finalizing /tmp/tmpmg3cwxp7/target
finish: cmd-install/stage-hook/builtin/cmd-hook: SUCCESS: curtin command hook
curtin: Installation failed with exception: Unexpected error while running command.
Command: ['grep', 'efi', '/proc/mounts']
Exit code: 1

[Ryan Harper (raharper)]

Please reopen if you feel there's an issue with how curtin is handling the late_commands.

[Jeff Lane  (bladernr)]

Gah! thanks, I didn't even notice that before... thanks for pointing it out.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3297