Mount BOTTLEROCKET-PRIVATE before BOTTLEROCKET-DATA

[mikn]

What I'd like: Mount BOTTLEROCKET-PRIVATE to a path that does not require BOTTLEROCKET-DATA to first be mounted.

Currently, the BOTTLEROCKET-PRIVATE partition is inexplicably mounted after BOTTLEROCKET-DATA because of its position in the mount tree (/var/lib/bottlerocket for -PRIVATE and /local and /local/var bind mounted to /var for -DATA) - this means that the -DATA partition (which is required relatively late) must be mounted before -PRIVATE. This limits what type of data you could feed to the early boot to mount -DATA (only the kernel command line).

We would like to be able to store configuration for mounts in the private partition, specifically for cryptsetup and device mapper tables in our case.

We are currently carrying the release package in our own variant to make this possible. We do it by mounting the -PRIVATE partition under /run/bottlerocket_private (still read only) and then bind-mounting it to /var/lib/bottlerocket once the rest of the mount tree is in place.

This opens up some exciting possibilities wrt bootstrap configuration also.

Any alternatives you've considered:

• Injecting kernel command line arguments (not feasible for device mapper tables)
• Temporary mount of private partition in our own units (uglier and more brittle)

[bcressey]

the BOTTLEROCKET-PRIVATE partition is inexplicably mounted after BOTTLEROCKET-DATA

The drawbacks of this weren't apparent at the outset, back when there were just the aws-* AMIs and the initial settings all came from IMDS, which required the network to be up, which when we were using wicked meant that local storage should be available in order to persist DHCP leases.

Effectively none of that applies now and I agree that decoupling the two is useful. For boot time optimization we're at the point where the pipelining of local storage -> network -> API server -> settings is one of the next areas to tune, and I'd already started to ponder this change.

We would like to be able to store configuration for mounts in the private partition

But the private partition itself is not a cryptsetup mount? Long-term I'd like to get to the point where that data is encrypted also, since various sensitive data may come in through user settings (e.g. registry credentials).

[mikn]

Currently we don't encrypt the -PRIVATE partition, no. We use systemd-creds to encrypt individual credentials using the TPM into a credstore.encrypted/ folder under the root of the -PRIVATE file system. We do not consider the information in the -PRIVATE partition to be sensitive in general in the way that would require the entire partition to be encrypted for now.

I am not sure how to enable safety-adding encryption of the -PRIVATE partition in a way that would work across the environments you support, but mounting it before -DATA would allow for bespoke, user-driven solutions per environment for the -DATA volume, which in itself would be very valuable. :)