[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] Add Nvidia GPU to Centos Atomic Node
- From: Colin Walters <walters verbum org>
- To: atomic-devel projectatomic io
- Subject: Re: [atomic-devel] Add Nvidia GPU to Centos Atomic Node
- Date: Wed, 08 Nov 2017 13:33:17 -0500
On Wed, Nov 8, 2017, at 12:36 PM, Dusty Mabe wrote:
>
>
> On 11/08/2017 12:06 PM, Colin Walters wrote:
> > On Wed, Nov 8, 2017, at 11:33 AM, Dusty Mabe wrote:
> >>
> >> - ostree admin unlock --hotfix
> >> - alias yum='/usr/share/yum-cli/yummain.py'
> >
> > Let's please not mention `--hotfix`?
>
> So the more official answer is: use traditional CentOS
IMO, yep! This type of thing is a lot of the reason
why we need two models for a while.
But just diving into this a bit - while we haven't yet plumbed through
automatic updates into rpm-ostree by default yet,
we finally added `rpm-ostree upgrade --download-only`
which does a *lot* of this.
And I'd really like to flesh out the background/automatic
updates story more and get to where we can turn it
on by default.
Yet things like dkms have a lot of hooks into system
updates. I just looked at the implementation slightly
more closely and it actually forks off a daemon helper
right in the middle of a traditional yum update.
One of the promises we'd make once we enable
background host updates by default is that they *don't touch*
your running OS; we wouldn't try to reload kernel modules
for example if we picked up a newer nvidia driver RPM.
This conflicts directly with the traditional yum/apt
model of trying to apply updates live, and I think things
get really interesting here with dkms as of course the
kernel isn't updated live, but other bits of userspace
like the "kernel-devel" is.
Oh, and another big thing is that our upgrades are
*cancellable*, you can Ctrl-C them at any time. This
ties in with the "background" story - if we have automatic
updates enabled, you still want `rpm-ostree install`
to preempt that. If DKMS is going off and starting its
own systemd service making changes that's going to be way harder.
How hard would it be to make dkms play nicely with
this? I don't honestly know.
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]