You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe
Currently, importctl pull-raw, pull-tar, import-raw, import-tar and import-fs operations can only place images under /var/lib. As I understand it, images placed under /var/lib are kept activated even after system reboots.
Myself, along with other members of the GNOME community (CC @alatiera), are currently exploring ways of using multiple pieces of systemd, including importctl, to provide a better and safer experience to develop and test system components on immutable systems.
We would like to simplify as much as possible the steps required to recover from potentially system-breaking changes.
Describe the solution you'd like
To achieve this in a safer way, I am wondering if we would be open to extend importctl to allow placing images under /run as well, e.g., and be just a simple system reboot back to safety.
e.g., importctl import-raw --class=sysext --runtime component.sysext.raw component, would result in /run/extensions/component.raw
Describe alternatives you've considered
Writing some wrapper on top of importctl that would hack this behavior.
The systemd version you checked that didn't have the feature you are asking for
256~rc1
The text was updated successfully, but these errors were encountered:
Component
other
Is your feature request related to a problem? Please describe
Currently, importctl pull-raw, pull-tar, import-raw, import-tar and import-fs operations can only place images under
/var/lib
. As I understand it, images placed under/var/lib
are kept activated even after system reboots.Myself, along with other members of the GNOME community (CC @alatiera), are currently exploring ways of using multiple pieces of systemd, including importctl, to provide a better and safer experience to develop and test system components on immutable systems.
We would like to simplify as much as possible the steps required to recover from potentially system-breaking changes.
Describe the solution you'd like
To achieve this in a safer way, I am wondering if we would be open to extend importctl to allow placing images under
/run
as well, e.g., and be just a simple system reboot back to safety.e.g., importctl import-raw --class=sysext --runtime component.sysext.raw component, would result in
/run/extensions/component.raw
Describe alternatives you've considered
Writing some wrapper on top of importctl that would hack this behavior.
The systemd version you checked that didn't have the feature you are asking for
256~rc1
The text was updated successfully, but these errors were encountered: