Re: [systemd-devel] Using systemd.offline-updates from an ostree based system

2019-05-02 Thread Richard Hughes
On Mon, 29 Apr 2019 at 10:16, Lennart Poettering wrote: > Please rewrite this as `FOREACH_STRING(fn, "/system-update/, > "/etc/system-update") …` and then exit fatally with an error if > laccess() fails with any error != ENOENT. In the above failures to > laccess() /system-update are handled diffe

Re: [systemd-devel] Using systemd.offline-updates from an ostree based system

2019-04-29 Thread Lennart Poettering
On Fr, 26.04.19 15:34, Richard Hughes ([email protected]) wrote: > On Fri, 26 Apr 2019 at 14:47, Dan Nicholson wrote: > > I think /etc is the only guaranteed to be writable location that's > > generic to all ostree systems. If possible, I'd get systemd to honor > > /etc/system-update. > > Lenna

Re: [systemd-devel] Using systemd.offline-updates from an ostree based system

2019-04-26 Thread Colin Walters
On Fri, Apr 26, 2019, at 3:47 PM, Dan Nicholson wrote: > > I think /etc is the only guaranteed to be writable location that's > generic to all ostree systems. If possible, I'd get systemd to honor > /etc/system-update. I think /etc seems sane for this but the other option that Lennart raised al

Re: [systemd-devel] Using systemd.offline-updates from an ostree based system

2019-04-26 Thread Richard Hughes
On Fri, 26 Apr 2019 at 14:47, Dan Nicholson wrote: > I think /etc is the only guaranteed to be writable location that's > generic to all ostree systems. If possible, I'd get systemd to honor > /etc/system-update. Lennart, is the attached going to be acceptable to you (of course as a PR with docs.

Re: [systemd-devel] Using systemd.offline-updates from an ostree based system

2019-04-26 Thread Dan Nicholson
On Fri, Apr 26, 2019 at 3:54 AM Lennart Poettering wrote: > > On Do, 25.04.19 17:10, Richard Hughes ([email protected]) wrote: > > > Hi all, > > > > I use the offline updates feature > > https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html > > in fwupd to install some k

Re: [systemd-devel] Using systemd.offline-updates from an ostree based system

2019-04-26 Thread Lennart Poettering
On Fr, 26.04.19 13:49, Richard Hughes ([email protected]) wrote: > > I'd not make dynamic changes to ESP or /boot I must say (i.e. 2. + > > 3. from the list above). It should contain static data only I am sure, > > only updated at system updates. > > I guess /boot works from a logical and mutabl

Re: [systemd-devel] Using systemd.offline-updates from an ostree based system

2019-04-26 Thread Richard Hughes
On Fri, 26 Apr 2019 at 09:54, Lennart Poettering wrote: > Hmm, the assumption was always that / was mutable if offline updates > are used to update /... Right, I don't know if I'm misusing the offline updates feature to update firmware. If there's something else I should be using I'm open for ide

Re: [systemd-devel] Using systemd.offline-updates from an ostree based system

2019-04-26 Thread Lennart Poettering
On Do, 25.04.19 17:10, Richard Hughes ([email protected]) wrote: > Hi all, > > I use the offline updates feature > https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html > in fwupd to install some kinds of firmware. I've just found out this > doesn't work on Fedora Silver

Re: [systemd-devel] Using systemd.offline-updates from an ostree based system

2019-04-25 Thread Ryan Gonzalez
Hmm not sure exactly when the offline updates generator runs, but maybe the symlink could be made in /sysroot? Then depending on how early the generator runs, it might even still be on / if it's before the switchroot. -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> ever

[systemd-devel] Using systemd.offline-updates from an ostree based system

2019-04-25 Thread Richard Hughes
Hi all, I use the offline updates feature https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html in fwupd to install some kinds of firmware. I've just found out this doesn't work on Fedora SilverBlue as / is immutable and of course creating the /system-update symlink fails.