Curtin doesn't handle type:mount entries without 'path' element

Thank you for filing a bug.

> The following line fails on swap partitions, because their type is mount, but their path is not defined

Right, it doesn;t have to be swap, but rather any type: mount which does not include a 'path' element.

The schema for type:mount does not require path so the line you mentioned needs fixing.

Thanks!

This bug is fixed with commit 1304d3ea to curtin on branch master.
To view that commit see the following URL:
https://git.launchpad.net/curtin/commit/?id=1304d3ea

@ryan,

Are you planning to SRU it ?

This bug was fixed in the package curtin - 20.1-20-g1304d3ea-0ubuntu1

---------------
curtin (20.1-20-g1304d3ea-0ubuntu1) groovy; urgency=medium

  * New upstream snapshot.
    - curthooks: uefi_find_grub_device_ids handle type:mount without path
      (LP: #1892242)
    - netplan openvswitch yaml changed (LP: #1891608)
    - tools/curtainer: do not wait for snapd.seeded.service
    - tools/curtainer: enable using ubuntu-minimal images
    - vmtests: add Groovy [Paride Legovini]
    - Drop the Eoan vmtests (EOL) [Paride Legovini]
    - tools: rename remove-vmtest-release to vmtest-remove-release
    - Snooze the tests failing because of LP: #1861941 for two more months
      [Paride Legovini]
    - LP: #1671951 is Fix Released => Drop the PPA [Paride Legovini]
    - swaps: handle swapfiles on btrfs (LP: #1884161)
    - curtainer: fail is masking of zfs-mount or zfs-share fails
      [Paride Legovini]
    - multipath: handle multipath nvme name fields correctly (LP: #1878041)
    - curtainer: mask the zfs-mount and zfs-share services [Paride Legovini]
    - tools/jenkins-runner: shuffle test-cases to randomize load
      [Paride Legovini]
    - Add Trusty/UEFI/HWE-X vmtest, drop realpath add, drop shell code
    - LP: #1881977 - Install realpath on Trusty UEFI. [Lee Trager]
    - vmtests: fix PreservePartitionWipeVg storage config
    - Fix mdraid name creates broken configuration
      [James Falcon] (LP: #1803933)
    - vmtests: update skiptests
    - vmtest: allow installed centos images to reboot (LP: #1881011)

 -- Ryan Harper <email address hidden> Thu, 20 Aug 2020 09:10:33 -0500

We will SRU at some point but we don't have a current timeline.

Tomorrows Curtin daily:ppa should have this (and as you can see, other fixes)

https://launchpad.net/~curtin-dev/+archive/ubuntu/daily

@Richard @Ryan,

Thanks, much appreciated.

It has been brought to my attention by an impacted user, the following:

"
Thank you for your update. I added this new version of ppa curtin into maas and restart regiond and now we successfully deployed servers with swap partition created in maas. It is working as expected.

Maybe one question when we can expect this patched version of curtin inside standard package repo?
"

- Eric on behalf of an impacted user.

Hello. On behalf of an impacted user:

"We have now been blocked for month not being able to provision new machines without dirty hacks.

There has also not been any activity on that page since we started the issue.

Any help to push this harder is welcome, this is urgent for us."

Unfortunately, Canonical don't SRU Curtin anymore as it is moving toward a SNAP installation where Curtin changes will be released and then consumed by MAAS (installed as a snap).

Does your customer have MAAS installed as DEB or as SNAP ?

If it's DEB, the procedure changes, meaning that you would need to take curtin from the its stable PPA[0].

The fix for this particular bug has been introduced in release:

1304d3ea curthooks: uefi_find_grub_device_ids handle type:mount without path

$ git describe --contains 1304d3ea
ubuntu/20.1-29-g81144052-0ubuntu1

https://github.com/canonical/curtin/releases/tag/ubuntu%2F20.1-29-g81144052-0ubuntu1

Hoping it answers your questions.

[0] https://launchpad.net/~curtin-dev/+archive/ubuntu/stable/+packages

So, where have clients (especially MaaS clients) been informed of this change to Curtin? I can imagine a few would want to add the Curtin PPA to their list of repos...

What I wrote on comment#12 is what I've been told by the Canonical's server team.

As far as I can tell, I don't think support sent any official communication in the field nor documented it. This way to work is also fairly new to my knowledge.

Let's talk about this internally on how we want to present this to UA customer (if need be).

- Eric

Another of our customers hit this bug again on bionic when their cloud was redeployed. I understand it will be curtin snap going forward, but why can't we have at least have a working version in deb repo so that whoever is still using this will have a better experience?

In terms of understanding when this was fixed for what users/versions. Assuming that MAAS is copying the curtin version from the server, to the deployed client, which I think is the case, you need to get an updated Curtin to the MAAS server.

The bug was fix released into curtin 20.1-20-g1304d3ea-0ubuntu1 in August 2020.

Curtin has not been updated in bionic itself since May 2020 (20.1-2-g42a9667f-0ubuntu1~18.04.1). So no fix there.

MAAS 2.7 PPA (https://launchpad.net/~maas/+archive/ubuntu/2.7) - No fix

MAAS 2.8 PPA (https://launchpad.net/~maas/+archive/ubuntu/2.8) - Fixed in 21.2-0ubuntu1~18.04.1 uploaded 1st March 2021 - first and only curtin upload

MAAS 2.9 PPA (https://launchpad.net/~maas/+archive/ubuntu/2.9) - FIxed in 21.2-0ubuntu1~20.04.1 uploaded 16th February 2021 - first and only curtin upload

MAAS 2.8 was released 24 June 2020
MAAS 2.9 was released December 2020
MAAS 3.0 was released 6 July 2021 [Note: only supports 20.04]

So seems like there was a gap from August 2020 to December 2020 where the fix possibly wasn't available to MAAS users at all? And then until March 2021 it wasn't available to MAAS 2.8 users.

However I don't know what version of MAAS, if any, is consuming curtin as a snap. And whether that applies to both DEB and SNAP installations of those given versions.