Re: First Atomic Workstation/WorkstationOstree update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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.

> 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

> - 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).

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?

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.

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




[Index of Archives]     [Fedora Users]     [Fedora KDE]     [Fedora Announce]     [Fedora Docs]     [Fedora Config]     [PAM]     [Red Hat Development]     [Red Hat 9]     [Gimp]     [Yosemite News]

  Powered by Linux