----- 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
> the status hasn't changed for folks like myself that need to be able to
> changes to the lower OS layers and have them persist across reboots,
I'd like to refer things like this to docs; there's
which unfortunately is stalled a bit, see
Will try to pick that back up.
> 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
> revisions and
> have them persist across reboots
> - be able to modify daemons, be it startup scripts, udev/hwdb rules, or
> and have them persist across reboots
We actually do support this today with `ostree admin unlock --hotfix`. I
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
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
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:
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
> 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.