----- 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 _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
