allowing "unsupported" changes to storage configuration

On Thu, 21 May 2020 at 07:30, ov2k <email address hidden> wrote:

> Specifically, to install to a custom btrfs
> subvolume and enable compression, I currently replace mount with a
> script that sets the proper options for each mount point.

Impressive creativity :)

> There are
> several improvements that would make it easier to implement such storage
> schemes.
>
> Wishlist
>
> There are several options that would suffice (for me).
>
> 1. Allow custom mount options in subiquity's manual storage
> configuration tool. One design is to add a text field for mount options
> when editing a partition. This is an integrated and visible approach,
> so a warning that incorrect or unsupported entries might break things
> would be warranted.
>

FWIW, curtin supports an options field on mounts. So you can do this with
an autoinstall config, if no other way. It probably makes sense to have a
suitably hidden way of adding options in the UI.

> 2. Pause to allow manual edits to the config file generated by
> subiquity. At least in some cases, there's already an "are you sure you
> want to continue" prompt that might suffice. However, I'm not sure
> whether a config file is written at that point or where it might be
> located. I don't think manual edits need to be officially supported,
> but the capability is useful.
>

Hm I don't think the config file is written when you are asked for
confirmation but that would be easy enough to change.

> 3. Pause after mounting /target but before writing anything. This would
> allow for configurations that aren't supported by curtin. However, I
> suspect this would require significant changes to subiquity and curtin,
> and I suspect the other options would cover most existing needs.
>

Yes, I think this would be pretty tricky.

This affects me as well - trying to do an autoinstall with mounting btrfs / with compression enabled before /target is written.

From what I can tell Subiquity does not parse storage:config:mount:options in filesystem.py:add_filesystem and there is no place for it to be stored in the filesytem model for it to be passed to curtin. The options are silently dropped.

This should be noted in the documentation.

https://ubuntu.com/server/docs/install/autoinstall-reference

```
action-based config
For full flexibility, the installer allows storage configuration to be done using a syntax which is a superset of that supported by curtin, described at https://curtin.readthedocs.io/en/latest/topics/storage.html.
```

It is not a superset if mount:options are not used.

We should just fix the bug instead really. Should be able to do this in the next release, after some plumbing changes.