Re: Maximum time for offline updates?

[Yvan Masson]

Le 23/12/2022 à 16:03, Stefan Monnier a écrit :

I find the idea of offline update rather odd: not only it's inconvenient
since the machine is unusable during this time, but on top of it, in
case of trouble, it can make it harder to fix the problem because you
may not be able to boot into a conveniently-usable system.

That was my feeling, too. Only very involved scenarios came to mind,
like "you have connectivity now, but are running on battery, and later
you'll have AC power but no connectivity" or something.

That scenario is already (arguably better) served by the distinction
between downloading the update(s) and installing them, which APT
supports already.  No need to reboot into a special mode to perform
the install.

Yes APT can do that. Offline update also ensures that :
- the computer is not used while applying updates
- the computer is rebooted just after applying updates

Offline update has disadvantages, but it makes sure that every programs are
restarted, thus avoiding strange issues or crashes due to conflicts in
libraries versions ([1] is a KDE article that very briefly explaining
this).  In an another article I could not find anymore, someone from KDE
explains that they receive many bug reports where issues comes from system
update without reboot (I would also be interested to know what is "many"
here).

Rebooting after the updates is different from the offline update you describe.

Yes.>

Indeed, in a perfect setup, system should make a snapshot before updates are
applied (see 6. in systemd.offline-updates manpage, note that I have not
heard it is done yet by any distribution by default), and revert the changes
if the update fails.

[ Agreed.  Ideally the updates should be performed in a "clone" of the current
   system, and only after it's done and sanity-checked should we switch to
   the new system.  We've known how to do that for many years (thanks to
   IBM's main frames, for example).  ]

Anyway, being able to fix a system that has been broken by *online*
updates is only relevant if the user has technical skills to do so.

But that is no different than for offline updates, is it?

I agree.

Windows, targeting both technical and non technical users, does exactly
this. I did not use an Apple system for years, but I think it was quite
similar for system updates. Please don't byte me ;-)

Indeed.  But they have different trade-offs.  They want to have as much
control as possible over the process so as to get as close as possible
to the "just works!" black box.  Basically they want their system
partition to be a binary blob that the end users can't even look at, so
updates merely require replacing one known binary blob with another, and
to minimize external factors they kick the users out before performing
the updates since for them users are fundamentally an annoyance (a
source of unpredictability).
And if something goes wrong along the way, their answer is "reinstall".

Debian's updates are hence quite different due to the basic
philosophical premise that user are here to help and that there isn't
just one "Debian version 10.1" but instead every Debian system is
different from the others.
So the upgrade scripts have to be a lot more careful to handle a much
wilder variety of situations, and they go through extra efforts to
interact correctly with a fully running system.

Indeed, for major upgrades, rebooting *some time* after the upgrade is
often a good idea, but that's different from the offline update
you describe.

I am not an expert, but I have seen many times that just after some "minor" *online* update, let's say LibreOffice and a few libraries, that a very strange bug appears (some application refuses to start, clicking on a button does nothing, and so on). And rebooting or re-opening the session fixed that.

Anyway, I am sorry but I have probably not the skills to discuss if offline updates are a good thing or not (I just think "it depends", I personally also prefer to update via command line and then reboot if necessary). But I really want to find why it did stop after ten minutes, because other non technical people might encounter this issue and won't be able to fix their system.

         Stefan "sorry for having hijacked your thread"

No worries, it is always interesting to know how other think :-)

OpenPGP_signature
Description: OpenPGP digital signature