FAIL: installing grub to target devices

Users
1

Today deployment is constantly failing with MAAS 2.6.2. I’ve tried recommissioning and went through a live DVD of Gparted and wiped the storages to be sure. Still, I can’t get past this:

start: cmd-install/stage-curthooks/builtin/cmd-curthooks/install-grub: installing grub to target devices
setup grub on target /tmp/tmplwfmv7xv/target
Found primary UEFI ESP: sda-part1
finish: cmd-install/stage-curthooks/builtin/cmd-curthooks/install-grub: FAIL: installing grub to target devices
finish: cmd-install/stage-curthooks/builtin/cmd-curthooks/configuring-bootloader: FAIL: configuring target system bootloader
finish: cmd-install/stage-curthooks/builtin/cmd-curthooks: FAIL: curtin command curthooks
Traceback (most recent call last):
File “/curtin/curtin/commands/main.py”, line 202, in main
ret = args.func(args)
File “/curtin/curtin/commands/curthooks.py”, line 1770, in curthooks
builtin_curthooks(cfg, target, state)
File “/curtin/curtin/commands/curthooks.py”, line 1736, in builtin_curthooks
setup_grub(cfg, target, osfamily=osfamily)
File “/curtin/curtin/commands/curthooks.py”, line 623, in setup_grub
for dev_id in uefi_find_grub_device_ids(storage_cfg_odict)])
File “/curtin/curtin/commands/curthooks.py”, line 560, in uefi_find_grub_device_ids
if item[‘type’] == ‘mount’ and item[‘path’] == ‘/boot/efi’:
KeyError: ‘path’
‘path’
Stderr: ‘’

Previous deployment that worked used: curtin: Installation started. (19.3-26-g82f23e3d-0ubuntu1~18.04.1)
This failing one uses: curtin: Installation started. (20.1-2-g42a9667f-0ubuntu1~18.04.1)

The production is still running on ~30 hosts, but 2 that needed a redeployment are now uncapable of coming back online due to this.

2

I actually repeated this with 2.8.2 just now, so I began investigating. I tried 3 different storage layouts, all of which were lacking a swap partition on lvm, and what do you know… they all deployed. So just removing SWAP seems to cure the situation. Not the ideal situation, but I’ll go with that for now. We surely need the swap there just in case RAM runs out.

3

This is due curtin by default create a swap file. If you create a swap partition, curtin try to mount the two and trough the error.

The curtin docs says:

Curtin will use a heuristic to configure the swapfile size if the size parameter is not set to a specific value. The maxsize sets the upper bound of the heuristic calculation.

To solve, create/edit the curtin_userdata_xxx and set size: 0 to swap. This is an example:

#cloud-config
debconf_selections:
 maas: |
  {{for line in str(curtin_preseed).splitlines()}}
  {{line}}
  {{endfor}}

swap:
  size: 0

late_commands:
  maas: [wget, '--no-proxy', '{{node_disable_pxe_url}}', '--post-data', '{{node_disable_pxe_data}}', '-O', '/dev/null']
4

Thank you! I think I can live with the swap file and skip the swap partition :slight_smile:
Do you know if there’s any intent to change the behaviour somehow here? As in curtin not doing a swap file if we have a swap partition? Or us able to modify the size of the swap file from within MAAS or something?

5

I have not found the way. It’s a characteristic of curtin, for me it doesn’t make sense. If I need a swap partition I configure one.

You have more information about curtin user_scripts at https://maas.io/docs/custom-machine-setup