----- Original Message -----
On Tue, Nov 28, 2017, at 09:37 AM, Bastien Nocera wrote:
I had a chat with Owen shortly after the Fedora 27 release, and I'm guessing the status hasn't changed for folks like myself that need to be able to make changes to the lower OS layers and have them persist across reboots, correct?
I'd like to refer things like this to docs; there's https://github.com/projectatomic/atomic-host-docs/pull/84 which unfortunately is stalled a bit, see https://github.com/projectatomic/atomic-host-docs/issues/95
Will try to pick that back up.
Subbed.
I need to be able to, amongst other things:
- be able to switch kernels independently of the OS installation
This one is https://github.com/projectatomic/rpm-ostree/issues/946
Subbed as well.
- be able to install external kernel modules for particular kernel
revisions and have them persist across reboots
- be able to modify daemons, be it startup scripts, udev/hwdb rules, or
binaries and have them persist across reboots
We actually do support this today with `ostree admin unlock --hotfix`. I tend to discourage people from using it because changes will be silently discarded if you upgrade (or make any other changes via rpm-ostree).
Does it come back if you rollback, or is it dropped to the floor?
That said we totally could support a model where we capture changes from `sudo make install` and the like in a layer and have it re-apply on top of everything else. A lot like combining `rpm-ostree install /path/to/local.rpm` with `rpm-ostree ex livefs`. Would that cover what you wanted?
That would be useful.
Can you flesh this out slightly more and we can write up an upstream issue? For example are you using `sudo make install` or are you building local RPMs or something else? Is jhbuild involved, etc.
Usually, it's either: - install locally built or scratch RPM(s), of kernels, or system daemons. This is also useful for testing changes in user-sessions outside interactive user's grasp, like gdm and its session, or things that are hard to use without breaking the development env, like gnome-session or a Wayland gnome-shell - data files such as as udev rules/hwdb quirks, modprobe configuration changes to allow the installation of out-of-tree modules. This is an example of testing an out-of-tree driver: https://github.com/hadess/retrode/blob/master/README.md Mistakes will require a reboot, obviously - Sometimes, it would be "make install" of custom built software
I think that a single overlay for hacks and tests would be fine. Something like: - unlock the overlay - throw stuff in the overlay - reboot, it uses the overlay by default, test - reboot and pass a command-line option to reset the overlay
You would probably also want a configuration option that makes it impossible to use that overlay.
Do we have any tracking bugs to collect requirements for that sort of usage, or is it outside the scope of Atomic Workstation?
It's completely in scope; generally rpm-ostree issues upstream are the best place to track this. The big picture vision is that we support all types of development/testing scenarios, the same as one would with a traditional package manager. Because in production, one often needs the ability to e.g. install a patched iptables RPM to add some debug printfs.
But all host system mutation runs through rpm-ostree which means it has the opportunity to make all changes transactional, and avoids the hysteresis of traditional package management - we make it easy to reset back to the "gold master" state which is always there.
And that'd very useful indeed, to allow starting from a blank slate.
Cheers