Split snap-bootstrap

[valentindavid]

Todo:

• Add locking of sealed keys
• recovery/factory reset

To be used with snapcore/snapd#12570

[xnox]

I think this will break cloudimg-rootfs mode.

Also this backtracks on using snapd-bootstrap for everything. And goes back to a shell script the tool.

I would rather there be snapd-bootstrap as a generator, or some snapd-bootstrap-snap-mounts-generator binary.

Can you make snapd-bootstrap be able to run in a generator mode, when called under a different name, and symlink it into system-generators path? such that we have just one go binary and it is used in a generators mode?

See for example that netplan does that.

[valentindavid]

I think this will break cloudimg-rootfs mode.

Modes that are not handled by the split snap-bootstrap are still handled through the monolitic snap-bootstrap. Though I would like to split them all at some point.

Also this backtracks on using snapd-bootstrap for everything. And goes back to a shell script the tool.

Here there is only one script. A generator called snap-mounts. But it could be part of the generator part of snap-bootstrap. I was just lazy and this branch is still experimental. The rest of this PR is just systemd units.

snap-bootstrap is still used. It is just split in several sub commands so it integrates better with systemd.

Can you make snapd-bootstrap be able to run in a generator mode, when called under a different name, and symlink it into system-generators path? such that we have just one go binary and it is used in a generators mode?

This is what this PR does. This is what generates the mount units of the snaps from the modeenv. And the script snap-mounts that I mentioned before generates the mounts of the disk. But that could be the same generator.

However, we cannot (or at least should not) put everything in the generator. The generator should only read configuration or kernel parameters and generate units, or eventually other configuration files for systemd. (And looking quickly at what netplan does, this is the same).

There are things, like opening the cryptsetup disk, that cannot be done in the generator. And we cannot use systemd's cryptsetup integration, at least not yet. So for that reason, I have split snap-bootstrap to have multiple smaller commands.

Maybe this branch is not very clear, because it is still experimental. But let me sum up what happens in the boot (this is topologically sorted, things might happen in a slightly different order or in parallel).

• snap-mounts generator generates the right mount units for the corresponding boot mode
• epoch (of secboot) is measured with snap-bootstrap measure-epoch
• udev calls snap-bootstrap scan-disk when disks appear. And snap-bootstrap scan-disk tags disk and partitions
• mount units that were generated by snap-mounts (the non encrypted ones)
• measure the model when available with snap-bootstrap measure-model
• for encrypted disks, snap-bootstrap unlock-{data,save} is called.
• udev tags opened encrypted disks
• mount the encrypted mount units that were generated by snap-mounts
• when the modeenv is available, we do a daemon-reload
• during reload, generators are re-run, including snap-bootstrap as a generator. It finds the required snaps, and generates the mount units for them.
• the generated mount units for the snaps are mounted
• there other subcommands run, see the PR for details
• after that, the normal boot process continues like if we had run snap-bootstrap initramfs-mounts

[valentindavid]

This is what the run mode looks like:

[xnox]

Do we still want this?