Re: Maximum time for offline updates?
For those interested, I reported this upstream: https://github.com/PackageKit/PackageKit/issues/590 Yvan OpenPGP_signature Description: OpenPGP digital signature
Re: Maximum time for offline updates?
Yvan Masson wrote: [snip] > > 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. 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. > openSUSE does that by default, assuming you use their recommended filesystem of btrfs. The snapper program takes a snapshot before any update and again afterwards. [snip]
Re: Maximum time for offline updates?
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
Re: Maximum time for offline updates?
>>> 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. > 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. > 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? > 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. Stefan "sorry for having hijacked your thread"
Re: Maximum time for offline updates?
Le 23/12/2022 à 07:50, to...@tuxteam.de a écrit : On Thu, Dec 22, 2022 at 04:57:54PM -0500, Stefan Monnier wrote: [...] 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. Cheers 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). 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. 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. 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 ;-) I definitely won't use those OS either unless I have to, but I admit they do many things very well and have competent UI designers. But our favorite OS is still the best because at least we have the choice between online and offline. 1. https://blog.neon.kde.org/2021/03/01/offline-updates-are-coming/ Regards, Yvan OpenPGP_signature Description: OpenPGP digital signature
Re: Maximum time for offline updates?
On Thu, Dec 22, 2022 at 04:57:54PM -0500, Stefan Monnier wrote: [...] > 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. Cheers -- t signature.asc Description: PGP signature
Re: Maximum time for offline updates?
> I am using testing with KDE (but I suppose the desktop environnent does not > matter). I had a LOT of updates to apply today, so I used KDE Discover > (Gnome Software equivalent for KDE) to apply those in offline mode, ie > updates are dowloaded and then computer reboots in a special mode just to > update packages, and reboot normally when finished. Why? > Also, do you think I should report this issue? Yes. > Against which package? The package you used to do this "offline update" (hadn't heard of such a thing until now for Debian). 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. Stefan
Re: Maximum time for offline updates?
Hi Махно, No I had not read this manpage (by the way, maybe it should be mentioned in packagekit-offline-update.service?), thanks for the pointer. While very interesting, I could not find something related to my issue. Did I miss something? Regards, Yvan Le 22/12/2022 à 13:38, Махно a écrit : Hello. Did you read systemd.offline-updates man page? If not, here link: https://manpages.debian.org/testing/systemd/systemd.offline-updates.7.en.html 2022-12-22, kt, 09:43 Yvan Masson rašė: Le 21/12/2022 à 21:42, Georgi Naplatanov a écrit : On 12/21/22 19:59, Yvan Masson wrote: Hi list, I am using testing with KDE (but I suppose the desktop environnent does not matter). I had a LOT of updates to apply today, so I used KDE Discover (Gnome Software equivalent for KDE) to apply those in offline mode, ie updates are dowloaded and then computer reboots in a special mode just to update packages, and reboot normally when finished. However, update stopped before all packages where updated and computer rebooted with packages in a broken state. When I look journalctl, I see beginning of the update process: 17:44:41 pk-offline-update[742]: sent mode to plymouth 'updates' And exactly ten minutes later it stops brutally: 17:54:40 systemd[1]: packagekit-offline-update.service: Main process exited, code=killed, status=15/TERM 17:54:40 systemd[1]: packagekit-offline-update.service: Failed with result 'signal'. I suppose this maximum time comes somewhere from a systemd configuration or systemd unit, but could not find where. Any idea? Also, do you think I should report this issue? Against which package? Hi Yvan, I don't know what the problem is. Possible workarounds could be to try to upgrade the system from console: - option #1 # apt update # apt upgrade - option #2 # aptitude update # aptitude upgrade Kind regards Georgi Hi Georgi, Thanks for the suggestion, but I already know how to do that. I think offline updates are a good thing for "average user", so I would like either: - knowing how to configure Debian properly so that it works realiably - or reporting this issue somewhere so that it can be fixed in Debian/upstream Regards, Yvan OpenPGP_signature Description: OpenPGP digital signature
Re: Maximum time for offline updates?
Hello. Did you read systemd.offline-updates man page? If not, here link: https://manpages.debian.org/testing/systemd/systemd.offline-updates.7.en.html 2022-12-22, kt, 09:43 Yvan Masson rašė: > > Le 21/12/2022 à 21:42, Georgi Naplatanov a écrit : > > On 12/21/22 19:59, Yvan Masson wrote: > >> Hi list, > >> > >> I am using testing with KDE (but I suppose the desktop environnent > >> does not matter). I had a LOT of updates to apply today, so I used KDE > >> Discover (Gnome Software equivalent for KDE) to apply those in offline > >> mode, ie updates are dowloaded and then computer reboots in a special > >> mode just to update packages, and reboot normally when finished. > >> > >> However, update stopped before all packages where updated and computer > >> rebooted with packages in a broken state. > >> > >> When I look journalctl, I see beginning of the update process: > >> > >> 17:44:41 pk-offline-update[742]: sent mode to plymouth 'updates' > >> > >> And exactly ten minutes later it stops brutally: > >> > >> 17:54:40 systemd[1]: packagekit-offline-update.service: Main process > >> exited, code=killed, status=15/TERM > >> 17:54:40 systemd[1]: packagekit-offline-update.service: Failed with > >> result 'signal'. > >> > >> > >> I suppose this maximum time comes somewhere from a systemd > >> configuration or systemd unit, but could not find where. Any idea? > >> Also, do you think I should report this issue? Against which package? > >> > > > > Hi Yvan, > > > > I don't know what the problem is. Possible workarounds could be to try > > to upgrade the system from console: > > > > - option #1 > > # apt update > > # apt upgrade > > > > - option #2 > > # aptitude update > > # aptitude upgrade > > > > > > Kind regards > > Georgi > > > Hi Georgi, > > Thanks for the suggestion, but I already know how to do that. I think > offline updates are a good thing for "average user", so I would like either: > - knowing how to configure Debian properly so that it works realiably > - or reporting this issue somewhere so that it can be fixed in > Debian/upstream > > Regards, > Yvan
Re: Maximum time for offline updates?
Le 21/12/2022 à 21:42, Georgi Naplatanov a écrit : On 12/21/22 19:59, Yvan Masson wrote: Hi list, I am using testing with KDE (but I suppose the desktop environnent does not matter). I had a LOT of updates to apply today, so I used KDE Discover (Gnome Software equivalent for KDE) to apply those in offline mode, ie updates are dowloaded and then computer reboots in a special mode just to update packages, and reboot normally when finished. However, update stopped before all packages where updated and computer rebooted with packages in a broken state. When I look journalctl, I see beginning of the update process: 17:44:41 pk-offline-update[742]: sent mode to plymouth 'updates' And exactly ten minutes later it stops brutally: 17:54:40 systemd[1]: packagekit-offline-update.service: Main process exited, code=killed, status=15/TERM 17:54:40 systemd[1]: packagekit-offline-update.service: Failed with result 'signal'. I suppose this maximum time comes somewhere from a systemd configuration or systemd unit, but could not find where. Any idea? Also, do you think I should report this issue? Against which package? Hi Yvan, I don't know what the problem is. Possible workarounds could be to try to upgrade the system from console: - option #1 # apt update # apt upgrade - option #2 # aptitude update # aptitude upgrade Kind regards Georgi Hi Georgi, Thanks for the suggestion, but I already know how to do that. I think offline updates are a good thing for "average user", so I would like either: - knowing how to configure Debian properly so that it works realiably - or reporting this issue somewhere so that it can be fixed in Debian/upstream Regards, Yvan OpenPGP_signature Description: OpenPGP digital signature
Re: Maximum time for offline updates?
On 12/21/22 19:59, Yvan Masson wrote: Hi list, I am using testing with KDE (but I suppose the desktop environnent does not matter). I had a LOT of updates to apply today, so I used KDE Discover (Gnome Software equivalent for KDE) to apply those in offline mode, ie updates are dowloaded and then computer reboots in a special mode just to update packages, and reboot normally when finished. However, update stopped before all packages where updated and computer rebooted with packages in a broken state. When I look journalctl, I see beginning of the update process: 17:44:41 pk-offline-update[742]: sent mode to plymouth 'updates' And exactly ten minutes later it stops brutally: 17:54:40 systemd[1]: packagekit-offline-update.service: Main process exited, code=killed, status=15/TERM 17:54:40 systemd[1]: packagekit-offline-update.service: Failed with result 'signal'. I suppose this maximum time comes somewhere from a systemd configuration or systemd unit, but could not find where. Any idea? Also, do you think I should report this issue? Against which package? Hi Yvan, I don't know what the problem is. Possible workarounds could be to try to upgrade the system from console: - option #1 # apt update # apt upgrade - option #2 # aptitude update # aptitude upgrade Kind regards Georgi
Maximum time for offline updates?
Hi list, I am using testing with KDE (but I suppose the desktop environnent does not matter). I had a LOT of updates to apply today, so I used KDE Discover (Gnome Software equivalent for KDE) to apply those in offline mode, ie updates are dowloaded and then computer reboots in a special mode just to update packages, and reboot normally when finished. However, update stopped before all packages where updated and computer rebooted with packages in a broken state. When I look journalctl, I see beginning of the update process: 17:44:41 pk-offline-update[742]: sent mode to plymouth 'updates' And exactly ten minutes later it stops brutally: 17:54:40 systemd[1]: packagekit-offline-update.service: Main process exited, code=killed, status=15/TERM 17:54:40 systemd[1]: packagekit-offline-update.service: Failed with result 'signal'. I suppose this maximum time comes somewhere from a systemd configuration or systemd unit, but could not find where. Any idea? Also, do you think I should report this issue? Against which package? Regards, Yvan OpenPGP_signature Description: OpenPGP digital signature
