Richard Biener wrote:
On Wed, 22 Mar 2017, Andrei Borzenkov wrote:
On Wed, Mar 22, 2017 at 11:45 AM, Richard Biener
wrote: Not sure why you need to reboot twice - you'd apply a kernel update online in a non-transactional way (we have working ways of "rolling" back to the old kernel). So the reboot updates the kernel, from the initrd you apply the update and simply continue booting?
Some services may be taken over from initrd. In this case initrd had been generated using old versions and they will continue to be used even if you update root to new version until next reboot. This may lead to rather hard to debug issues because everything after boot will indicate you have new versions installed.
Well, apply the update from init (systemd) then before it spawns anything else. init can reload itself.
Yes, there are implementation difficulties but it can work. You still do have to wait for those updates to be applied of course.
That way already exists. It's called "offline system updates". A description is online¹. In short packagekit has a mode to just download rpms and notify the system of their presence. On next reboot systemd boots into a special target, installs the downloaded files and reboots again. This mode is not just for small updates. This is what you'd use for updating e.g. whole desktop environments with hundreds of packages. So applying updates this way does take time. I'm sure it will take even more time just in the moment one needs the system to be back ASAP :-) The "transactional update" mechanism on the other hand would download and install packages while the user can still use the system. Since the installation goes to a separate snapshot of the file system, the running system is not impacted. After successful installation a reboot would boot into the newly created snapshot just as quick (or slow :-)) as usual. Both methods obviously need safeguards. If the installation step of the offline updates is too dumb (like rpm -U --force --nodeps *) it has the potential to bring the system to a inconsistent state, in case packages got installed or removed after the updates were downloaded. transactional updates would always lead to a consistent system at least. However, if safeguards are not in place to handle or disallow package installations/removals after creating the new snapshot, one would miss those modifications after reboot. I guess a better integration with zypper and rpm itself is needed to prevent that. However, both approaches are unsuitable for small updates IMO. On a traditional server it would be crazy to require a reboot just to apply e.g. a security update on apache or even systemd when both services can handle inline replacement just fine. We have to be better than that. That also applies to the desktop. Who wants to reboot to update Firefox after all? So IMO the perfect solution would allow both, installing small updates like today, plus having a way to apply "disruptive" changes without impacting the running system. For the latter the offline updates approach is a cheap solution that can be used immediately and on any file system. It's not really the best way for users though. Transactional updates are more effort on engineering side. The changes required to packages and the system are the right thing to do anyways though (like sorting out the /srv mess or separating data/config migrations from installation). So it's worthwhile to fix the packages independent of the discussion about the right update mechanism. cu Ludwig [1] https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.htm... -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org