erlangen:~ # journalctl -b -1 -u dup -g 'Start|Consumed|following'
Mar 23 00:00:00 erlangen systemd[1]: Starting Distribution Upgrade...
Mar 23 00:00:00 erlangen systemd[1]: Started Distribution Upgrade.
Mar 23 00:00:50 erlangen zypper[17330]: The following 3354 packages are going to be upgraded:
Mar 23 00:00:50 erlangen zypper[17330]: The following 8 patterns are going to be upgraded:
Mar 23 00:00:50 erlangen zypper[17330]: The following product is going to be upgraded:
Mar 23 00:00:50 erlangen zypper[17330]: The following 7 packages are going to be downgraded:
Mar 23 00:00:50 erlangen zypper[17330]: The following 11 NEW packages are going to be installed:
Mar 23 00:00:50 erlangen zypper[17330]: The following NEW pattern is going to be installed:
Mar 23 00:00:50 erlangen zypper[17330]: The following 2 packages are going to be REMOVED:
Mar 23 00:00:50 erlangen zypper[17330]: The following package requires a system reboot:
Mar 23 03:44:46 erlangen systemd[1]: dup.service: Consumed 7min 18.557s CPU time.
erlangen:~ #
Download was slow due to some 80 curl errors. However zypper retried and finally succeeded without manual interaction. Upgrading was no big deal.
I switched manually to a local mirror in germany and the download speed was fast as everytime. The main download servers where maybe a little bit stressed due to the high amount of Tumbleweed installations and updates…
burgberg:~ # journalctl -b -3 -u dup -g 'Consumed|Start|folgende'
Mar 22 18:22:46 burgberg systemd[1]: Started Dist Upgrade Download.
Mar 22 18:23:42 burgberg zypper[1345]: Die folgenden 2423 Pakete werden aktualisiert:
Mar 22 18:23:42 burgberg zypper[1345]: Die folgenden 7 Schemata werden aktualisiert:
Mar 22 18:23:42 burgberg zypper[1345]: Das folgende Produkt wird aktualisiert:
Mar 22 18:23:42 burgberg zypper[1345]: Das folgende Paket wird durch eine ältere Version ausgetauscht:
Mar 22 18:23:42 burgberg zypper[1345]: Die folgenden 10 NEUEN Pakete werden installiert:
Mar 22 18:23:42 burgberg zypper[1345]: Das folgende NEUE Schema wird installiert:
Mar 22 18:23:42 burgberg zypper[1345]: Die folgenden 5 Pakete werden GELÖSCHT:
Mar 22 18:23:42 burgberg zypper[1345]: Das folgende Paket erfordert einen Systemneustart:
Mar 22 21:02:13 burgberg zypper[1345]: Es werden Programme ausgeführt, die immer noch die durch kürzliche Upgrades gelöschten oder aktualisierten Dateien oder Bibliotheken verwenden. Starten Sie die Programme neu, um die Aktualisierung>
Mar 22 21:02:13 burgberg systemd[1]: dup.service: Consumed 10min 40.220s CPU time.
burgberg:~ #
Host burgberg uses VDSL2 17a G.Vector with 71,27 Mbit/s download speed, while host erlangen uses FTTB with 27,5 Mbit/s. Nominal speed doesn’t matter here.
BTW: The user of burgberg was logged in half an hour only and pressed power off when done. As zypper dup runs in a systemd service shutting down was postponed some two hours until dup.service terminated successfully. The user wasn’t even aware of what had happened.
Yep. If in a hurry you always can try this. In the morning of March 23 I even did not notice that host erlangen had been successfully upgraded at midnight despite dozens of download errors.
@fudokai: host erlangen is configured to keep downloaded packages:
There where also the same complains for update to gcc12…
It’s always surprising that somebody gets surprised by an update of an rolling release distro…
And please take a seat and prepare yourself ahead: in some month the complete distribution will be rebuild to gcc14 and the same amount of packages will be updated!
I do not use Tumbleweed but Leap and thus do not experience these large upgrades. I am always amused to read these threads again and again, because they stiffen me in the idea that, at least for me, Leap is the better choice. Do I get the idea that for some others it also might be the better choice?
I used “stable” distros for over 2 decades and got finaly annoyed that they are always lacking behind the actual technical development. That’s why i switched my main computer (and two other machines) to Tumbleweed. And there was no surprise or anything else…because if you are using linux for such a long time you understand the background and the reasons why it is why it is. And then you don’t lament because of some 1000 packages that need an update…because for everybody with a base understanding of programming it is clear that you need to recompile all packages when you use a new compiler version of gcc.
Users of Leap don’t see this, because these several 1000 packages are hidden in the update process when they switch to the next release version. So they don’t notice that there was an update of gcc…
And i also don’t understand why some complain about 2000 or 3000 packages to update…starting a new forum thread and crying and lamenting takes more time then the upgrade process itself…
@fudokai Aside from a normal size update due to the gcc change/rebuild, it also put a strain on the mirroring infrastructure (which was having it’s own issues) hence seeing the connection issues, a cascade effect…
So the question is: why do admins who know that their infrastructure isn’t capable of supporting a rolling release, install it anyway and later start crying about…
…it’s over my head…
So the question is: why do users who know that their infrastructure isn’t capable of supporting a rolling release, install it anyway and later start crying about…
…it’s over my head…
Then the user didn’t do a basic research of the disadvantages of a rolling release distribution (simply google “rolling release vs fixed release”). This is common between all RR distributions, that the daily amount of packages to upgrade differs between a handfull and several thousands…
Every couple of weeks? If you are going to exaggerate, why not say every couple of days? Neither is true, but latter is much scarier and better suits your apparent purpose.
And if memory serves me correctly that was because of an error. Surely your not saying that the proper course of action would have been not to correct it?
Sure. However as already mentioned above upgrading several thousand packages is a non-issue. To my experience an upgrade failing due to high server load eventually succeeds when performed the day after.
Host erlangen gets a daily upgrade. Most of them are performed in less than one minute. Only some of them last longer:
erlangen:~ # journalctl -q -u dup -g Consumed|grep min
Jan 24 06:10:39 erlangen systemd[1]: dup.service: Consumed 1min 8.964s CPU time.
Feb 04 03:49:08 erlangen systemd[1]: dup.service: Consumed 1min 53.400s CPU time.
Feb 05 15:54:18 erlangen systemd[1]: dup.service: Consumed 1min 32.727s CPU time.
Feb 08 19:32:16 erlangen systemd[1]: dup.service: Consumed 1min 31.952s CPU time.
Feb 14 23:23:53 erlangen systemd[1]: dup.service: Consumed 1min 33.783s CPU time.
Feb 16 04:24:12 erlangen systemd[1]: dup.service: Consumed 1min 347ms CPU time.
Mar 07 18:23:11 erlangen systemd[1]: dup.service: Consumed 3min 16.117s CPU time.
Mar 17 03:23:04 erlangen systemd[1]: dup.service: Consumed 1min 16.042s CPU time.
Mar 19 14:24:48 erlangen systemd[1]: dup.service: Consumed 1min 4.490s CPU time.
Mar 23 03:44:46 erlangen systemd[1]: dup.service: Consumed 7min 18.557s CPU time.
erlangen:~ #
The best distro for one needs to take into account the context. In this case in particular an openSUSE rolling release performs better with a fast connection to internet. To mitigate that:
Run zypper dup less often, once every week / two weeks;
Notice if a big snapshot is incoming, and cancel zypper dup, try again next day;
Prefer MicroOS where a fewer number of OS packages is required, while apps are updated as flatpaks less frequently
Totally anecdotal, but I see fewer regular rebuilds than it used to be. Most package updates include package source updates.
