autoinstall mount options ignored

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

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

Reverting for now.

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.

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

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.

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.

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

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.

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.

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)