Support defining mount and swap units via credentials #27260
Comments
|
We already support autodetection of swap and many other mount points automatically: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/. This doesn't cover all the cases you describe, but at least for swap it's reasonable to never define it in |
|
Though overall, the request is reasonable. I'm sure we'll various uses for such functionality. This should be implemented as a generator in systemd.
This syntax seems reasonable. We use |
|
so, this makes a ton of sense to me, and i would like to see this too. i'd suggest implementing this inside of systemd-fstab-generator, which already interprets root= and usr= as well as /etc/fstab. I'm not convinced escaping via :: is the way to go. We probably need a way to escape spaces too after all, hence something backslash-based sounds more appropriate, since it can cover all characters. It would probably be wise doing some reasearch how other components from us and the kernel actually do escaping in similar case, and then follow that. |
|
There's a line in TODO that asks for the same thing btw, and can be removed by any PR implementing this: |
|
Thanks. I'll take a look at the options for escaping. We have a similar need in libdevmapper where we store file system paths in the kernel aux_data word (which can not contain whitespace). Something that could be handled by |
|
This would also solve a problem for me when dealing with mounting multiple non-nested Btrfs subvolumes to boot up properly (which is how Fedora works right now). There's no standard for "discoverable subvolumes" like there are for "discoverable partitions", so we currently have no fstab-less way to bring up the whole system. |
|
Waiting in #27563. |
|
Wouldn't it be better to use credentials for this? This is not kernel configuration, it's purely userspace |
|
Given the existence of |
|
@bluca and @poettering How creds can be loaded from generators? |
…line Now, the following kernel command line options are supported: systemd.mount=what:where:fstype:options systemd.swap=what:options Closes systemd#27260.
…line Now, the following kernel command line options are supported: systemd.mount=what:where:fstype:options systemd.swap=what:options Closes systemd#27260.
|
We are picking them up from sd-stub and making them available in |
|
I think it's fine to also support credentials. But please keep the command line option too. This is much easier to use for people and familiar. |
|
Sure, adding that as well is fine. But I think we should emphasize more the credentials approach, especially for programmatic usage. |
…line Now, the following kernel command line options are supported: systemd.mount=what:where:fstype:options systemd.swap=what:options Closes systemd#27260.
…line Now, the following kernel command line options are supported: systemd.mount=what:where:fstype:options systemd.swap=what:options Closes systemd#27260.
|
@yuwata thanks! This looks like it will do exactly what we need. |
…line Now, the following kernel command line options are supported: systemd.mount=what:where:fstype:options systemd.swap=what:options Closes systemd#27260.
…line Now, the following kernel command line options are supported: systemd.mount=what:where:fstype:options systemd.swap=what:options Closes systemd#27260.
…line Now, the following kernel command line options are supported: systemd.mount=what:where:fstype:options systemd.swap=what:options Closes systemd#27260.
…line Now, the following kernel command line options are supported: systemd.mount=what:where:fstype:options systemd.swap=what:options Closes systemd#27260.
|
Continuing from #27260 (comment), once |
…line Now, the following kernel command line options are supported: systemd.mount-extra=what:where:fstype:options systemd.swap-extra=what:options Closes systemd#27260.
…line Now, the following kernel command line options are supported: systemd.mount-extra=what:where:fstype:options systemd.swap-extra=what:options Closes systemd#27260.
…line Now, the following kernel command line options are supported: systemd.mount-extra=what:where:fstype:options systemd.swap-extra=what:options Closes systemd#27260.
…line Now, the following kernel command line options are supported: systemd.mount-extra=what:where:fstype:options systemd.swap-extra=what:options Closes systemd#27260.
We should keep that, it's interpreted by different code and gets quite different handling. Moreover, there's usrhash and things too, for referencing /usr/ partitions by verity top-level hash, which really suggests we should leave that as is. |
bluca
changed the title
bluca
added
the
rc-blocker 🚧
reopening to track creds support |
keszybz
changed the title
|
I'm trying to test the new Firstly, when using command line mount units and The system boots normally and file systems are mounted as expected: Attempting to boot into a snapshot of the system state fails unpredictably: in some cases the system appears to boot normally but systemd attempts to unmount the command line mounts after switching root. In other cases the devices for the command line mount units time out. I'm struggling to debug this: the generated unit files seem sane and I can't figure out why the umounts and timeouts are occurring. The snapshot command line looks like this: In the case that file systems are unmounted the logs look like this: (the umount for /var fails since the target is busy but /home is unmounted at the end of booting). |
|
@bmr-cymru Filed as #28516. I will take a look. |
bluca
removed
the
rc-blocker 🚧
Component
other
Is your feature request related to a problem? Please describe
Linux today supports a variety of block and file system snapshot mechanisms (LVM2, btrfs, split mirrors etc.) and it is possible to boot a simple system with just a single (root) file system into a snapshot of the system state using the existing
root=androotflags=kernel command line options.Being able to boot into a snapshot has application for rolling back unsuccessful updates, system recovery and troubleshooting.
It is not currently directly possible to boot into a snapshot state for more complex file system layouts (for e.g. with separate
/var,/homeetc.) without first modifying the snapshot content to reference the appropriate block devices or subvolumes in/etc/fstab.Describe the solution you'd like
The ability to specify mount and swap units directly on the kernel command line. This would allow (in combination with
fstab=no) the overriding of the file system mount structure for a given boot of the operating system image.This allows a complete snapshot of the system state to be booted for e.g. in the case of a failed upgrade that renders the system unbootable.
The user can then roll back to the snapshot state minimizing down time and providing a valuable safety net around updates to the operating system.
The syntax would be something like:
Where a literal ':' in any of the fields is escaped as '::'.
This could be implemented as a new generator or by extending the existing fstab-generator.
Describe alternatives you've considered
It's possible to implement these options in a separate component that provides a new system generator to recognise and act on the unit syntax. This would require users to install additional packages to take advantage of the feature.
It's also possible to mount the snapshot of the root file system and directly modify /etc/fstab however this complicates rollback (since the changes to the fstab must either be reverted, or preserved in a separate block or file system snapshot).
The systemd version you checked that didn't have the feature you are asking for
253
The text was updated successfully, but these errors were encountered: