autoinstall mount options ignored

[ov2k]

In general, subiquity doesn't (yet) bother with mount options. This has been mentioned a few times already:

https://bugs.launchpad.net/subiquity/+bug/1752602
https://bugs.launchpad.net/subiquity/+bug/1840702
https://bugs.launchpad.net/subiquity/+bug/1879779

Those reports include feature requests for the interactive interface to grow fields for mount options. This report is more narrowly focused on autoinstalls.

Regarding autoinstalls, the subiquity documentation states, "For full flexibility, the installer allows storage configuration to be done using a syntax which is a superset of that supported by curtin." curtin supports mount options. However, mount options provided as part of an autoinstall storage config are ignored.

Regardless of whether this is a bug or a feature request, would adding mount option support to subiquity autoinstalls involve any more than recognizing the options key and passing it to curtin?

And for anybody looking for a hackish workaround, a user-data file is attached demonstrating one approach with a trivial example.

[Michael Hudson-Doyle (mwhudson)]

Ah yes, good point. https://github.com/CanonicalLtd/subiquity/pull/795 should fix this.

[Dimitri John Ledkov (xnox)]

Fix for this causes regression https://bugs.launchpad.net/subiquity/+bug/1889749

Reverting for now.

[Dimitri John Ledkov (xnox)]

I'm not sure how to fix things, such that we support this, and don't regress. As if adding things to the model, need to be marked optional or something, cause something breaks detecting things as usable disks with this pull request applied.

[Oukaci (moukaci)]

It doesn't seem fixed with version Ubuntu 20.04.1 posted the 2020-07-31 at 17:35.

https://askubuntu.com/questions/1274335/autoinstall-ubuntu-20-04-mount-with-options-nodev-noexec

[ov2k (ov2k)]

I finally took a closer look at the reverted PR, and it includes a lot of unrelated things. From comments in the referenced zFCP/SCSI multipath issue, adding the multipath field to partitions seems to have been the problem. From my testing with the attached user-data, only one line from the PR is required to support mount options. Either a PR with just the one options line or a PR without the multipath line. The former is less likely to cause problems elsewhere. The latter might address a bunch of other things that subiquity autoinstalls are supposed to support but don't yet.

[sedlund (scott-edlund)]

I think the underlying multipath issue in curtin was fixed in https://github.com/canonical/curtin/commit/e113b0557775d7c1d9505b291f41e9e06308e896

so maybe this patch can make it back in sometime soon.

[Michael Hudson-Doyle (mwhudson)]

https://github.com/canonical/subiquity/pull/925

[ov2k (ov2k)]

This might be better filed as a new bug, but I think something broke https://github.com/canonical/subiquity/pull/925. Snap currently reports subiquity 2280.

Right now, I seem to only get default options. The customized options keys exist in /autoinstall.yaml during subiquity's early commands, but they are missing from /var/log/installer/subiquity-curtin-install.conf during subiquity's late commands.

I think the test in the PR passes because errors=remount-ro is part of defaults for vfat filesystems. noatime might make for a better test.

I do believe https://github.com/canonical/subiquity/pull/925 is not at fault. After https://github.com/canonical/subiquity/pull/808 reverted https://github.com/canonical/subiquity/pull/795, I clipped the bit relevant to mount options, and have been monkey patching subiquity with it. With the one extra line, mount options were working, at least last I looked.

[ov2k (ov2k)]

After some more digging, I think the problem I'm having is spurious. subiquity 2280 is the version bundled with the installer. For some reason, snap in the installer is reporting 2280 is up to date, so it doesn't download the subiquity version that supports mount options.

The problem with using errors=remount-ro in the test might still be valid, though.

[Michael Hudson-Doyle (mwhudson)]

Yes we're not offering the update to users of 20.04.2 because bugs in the version of subiquity in the ISO make the upgrade exceedingly bumpy :( But if you're autoinstalling, you can set the installer to refresh from stable with:

refresh-installer:
  channel: stable
  update: true

Or you can just use an ISO from http://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/current/ if you don't mind using an ISO based on the state of the archive on a random day vs release day (in practice it's not going to make a lot of difference)