Does TW offer "daily" snapshots for download?? Viable alternative to zyppering??

Folks:

Tomorrow will be TW day and based upon threads in the factory list-serve I’m anticipating that zypper will be showing a large number of packages that will be needed to upgrade the system???

Still running TW in what is a “newer” HDD SATA drive and historically that has taken “time” . . . I have already set up a script to run “dupa” as per Karl M’s suggestion, which might be one way of wending through the installing of large number . . . but which wouldn’t actually take less time for the machine . . . it would just be done “subliminally” so to speak . . . . I would have to guess when it’s all done, etc.

Based upon another poster in the list serve I’m considering downloading the TW install iso and running it as a “fresh install” into “/” but using the same /home partition, which may “take less machine time” . . . to do? The question is whether “packman” would have to be installed or set up again, or whether my prefs and such from /home would all be carried over and just the “/” would be freshened??

I searched “tumbleweed dailies” and that didn’t bring me to a page similar to . . . some other well known distro that offers “dailies” for the freshest horsies . . . each day. The Tumbleweed download page provided me with a snapshot for “Sept 1 '22” but today is the 3rd here in the states . . . . Is there a place where the freshest snapshot can be downloaded?? Or, it’s always going to be a day or so “behind”??And would that be a relatively “pain free” way to get through what might be another “2400” packages or possibly more???

Or, easiest, most “pain free” way to stay up to date is “**** the torpedoes, full zyppering through the wall of packages”???

Look in these forums in Other Forums > News & Announcements > Announcements.
There you see as last about TW snapshots: New Tumbleweed snapshot 20220901 released!
And the one before that: New Tumbleweed snapshot 20220831 released!
And the one before that: New Tumbleweed snapshot 20220829 released!

As far as I understand it (I am not running Tumbleweed), people simply update using

zypper dup

Some seem to do this every day (and then on some days nothing will happen), others do it when they see the Announcement, others may browse through the Announcement to see how important it is for them, and again others may do zyper dup once a week. Make your own plan.

If you keep your /home on a separat partition then you can avoid that a fresh installation will change it. However you should keep in mind that parts of your system configuration are kept in /etc and will be lost on a fresh installation.

Another thing to keep in mind when you “install” from the openSUSE Tumbleweed installation DVD is that the DVD provides only a limited set of packages (and no packages from Packman at all) but you probably have installed other packages (manual after installation) from the online repositories. Doing an update via online repositories with zypper dup will keep care of all your installed packages.

openSUSE Tumbleweed snapshots are provided “when they are done” i.e. there can be several on a day (so far I have seen two on a single day) or only one or two in a week (if I recall correctly there has been a week with no snapshot at all).

The latest Tumbleweed snapshots can be found here: https://download.opensuse.org/tumbleweed/iso/

From my point of few the best way to keep an openSUSE Tumbleweed installation up-to-date is to monitor the openSUSE factory mailling list and decide by the information provided on this list when to do a zypper dup.

Regards

susejunky

@hcvv:

Thanks for the “announcements” sub-forum suggestion . . . . Historically I have run “zypper dup -l” once a week, without issue . . . it’s only in the last year or so where the number of packages has increased exponentially and problems with “curl error” interrupting that have made regular maintenance of TW . . . a “chore” rather than easy-peasy.

@susejunky:

Thanks for that link to the iso downloads page . . . appreciate that . . . . Somewhat difficult to make the call, to ride along with the status quo and just zypper along as the system drops the data . . . or cut around the large number and run a fresh install. Since I have 8 distros on the desktop I don’t really customize the install of any one of them very much . . . but, in the case of TW dating back to '16 or so, stuff has been done in that time . . . .

When you make the choice between Leap and Tumbleweed. you should take the difference in resources required by keeping them up-to-date into account. It is weighing off between your arguments to have Tumbleweed and not Leap (something only you can decide) against the hassle the much larger download and install volume gives you (which depends of course very much on your connection speed, the down-time you can allow, etc.).

@hcvv:

Yes. That is the “new reality” for TW . . . but historically TW didn’t have these “balloon” downloads . . . just regular upgrades every few days. I also have a Leap 15.4 install on an older Mac laptop . . . which I’m “OK” with . . . “beta” or so edition, doesn’t require constant attention . . . .

I like “new” . . . but the new “balloon” paradigm is taxing the '12 hardware’s ability to process in a reasonable amount of time, etc.

I download daily:

erlangen:~ # systemctl cat dup.timer 
# /etc/systemd/system/dup.timer
[Unit] 
Description=Systemd timer to update the system daily with Zypper 

[Timer] 
OnCalendar=daily 
Persistent=true 

[Install] 
WantedBy=timers.target 
erlangen:~ # systemctl cat dup.service  
# /etc/systemd/system/dup.service
[Unit] 
Description=Dist Upgrade 

[Service] 
Restart=on-failure
ExecStartPre=/usr/bin/sleep 11 
ExecStart=/usr/bin/zypper dist-upgrade --no-confirm --download-only 
erlangen:~ #
erlangen:~ # journalctl -b -2 -u dup -g 'Pakete|Consumed'
Sep 02 16:19:46 erlangen zypper[2303]:   Diese zusätzlichen Schlüssel werden normalerweise zum Signieren von Paketen verwendet, die vom
Sep 02 16:19:46 erlangen zypper[2303]:   Repository versendet werden. Um diese Pakete beim Download und der Installation zu validieren,
Sep 02 16:20:05 erlangen zypper[2303]: Installierte Pakete werden gelesen...
Sep 02 16:20:06 erlangen zypper[2303]: Die folgenden 3394 Pakete werden aktualisiert:
Sep 02 16:20:06 erlangen zypper[2303]: Die folgenden 2 NEUEN Pakete werden installiert:
Sep 02 16:20:06 erlangen zypper[2303]: 3394 Pakete werden aktualisiert, 1 wird zurückgestuft, 2 neue, 1 zu entfernen, 1 Anbieterwechsel.
Sep 02 16:51:54 erlangen systemd[1]: dup.service: **Consumed 1min 1.935s CPU time**.
erlangen:~ # 

I install manually by running the following service:

erlangen:~ # systemctl cat dupa.service  
# /etc/systemd/system/dupa.service
[Unit] 
Description=Dist Upgrade, apply download 

[Service] 
ExecStart=/usr/bin/zypper dist-upgrade --no-confirm 
erlangen:~ #
erlangen:~ # journalctl -b -2 -u dupa -g 'Pakete|Consumed'
Sep 02 16:53:49 erlangen zypper[9977]: Installierte Pakete werden gelesen...
Sep 02 16:53:51 erlangen zypper[9977]: Die folgenden 3394 Pakete werden aktualisiert:
Sep 02 16:53:51 erlangen zypper[9977]: Die folgenden 2 NEUEN Pakete werden installiert:
Sep 02 16:53:51 erlangen zypper[9977]: 3394 Pakete werden aktualisiert, 1 wird zurückgestuft, 2 neue, 1 zu entfernen, 1 Anbieterwechsel.
Sep 02 17:04:09 erlangen systemd[1]: dupa.service: **Consumed 6min 41.112s CPU time**.
erlangen:~ # 

Benefits with regard to running ‘zypper dist-upgrade’ in a console:

  • Service runs in the system slice; it won’t die in case of trouble
  • Comprehensive, persistent logging with journal
  • Automatic restarting of download (in case of timeouts due to high server load)

@karlmistelberger:

Thanks for the data repost. We did go into this quite thoroughly back in May and I did set up your script and I ran it . . . . My issue is that I’m not running TW every day or all of the time, I boot it once a week and run “zypper dup -l” . . . and for the most part that keeps the system up to date and the package numbers are relatively “mild.”

But, now again, four months later, and today’s “zypper dup” shows “2567” packages . . . to keep TW “current” . . . unfortunately, as part of our 22 page thread in May, we got into the potential issues with my '12 Xeon Quad-core cpu as an area of “weakness” in regards to processing these large numbers, and TW is still installed in an HDD . . . and that is where your time & cpu time consumed numbers are “different” than mine . . . .

Other than TW, my other linux distros aren’t requesting the time and attention to maintain them that TW is . . . Sid is modest, Manjaro . . . modest numbers, so I don’t need a faster cpu, except for processing the TW upgrades.

To give a comparo . . . a couple days back I zyppered a Gecko rolling upgrade of “1656” some packages, on my '20 Sys76 laptop, for the 9/1 upgrade . . . on a 500 MB FIOS connection, it still took roughly 30 minutes to simply download the packages from the SUSE??? server, with a “curl error” 3/4 of the way through . . . and then on a 10th gen i7 cpu installing into an NVMe SSD . . . another roughly 20 minutes to install the 1656 packages . . . .

I don’t believe my desktop will get these “2567” packages handled in less time than that . . . ???

I’ll be firing your dupa script in a few minutes . . . if I can get the “time” thing going, we’ll see how much time it will take . . . ???

Been too busy to take the time to run a fresh install of TW into another disk in the machine, SATA SSD . . . might be the next step to try to solve this obsession that TW has with massive package revamping . . . . . : - 0

@karlmistelberger:

So, following up . . . by the computer clock I ran

#systemctl start dupa.service

to install the 2568 ± packages at 9:20 am PST checking at intervals with

# systemctl status dupa.service

which would only show something “20 lines” from the activity at a time . . . .

At approx. 10:13 am it showed in was installing package 1563/2569 . . . . And then around 10:50 am it seemed to be going through the grub listing stuff???

Not knowing exactly when dupa.service is finished the current round of installs, I checked again with

# journalctl -b -u dupa.service -g consumed

and it reported at 10:54 am PST:

# journalctl -b -u dupa.service -g consumed
Sep 05 10:49:51 linux-xxxx systemd[1]: dupa.service: Consumed 23min 41.438s CPU time.

So, by the real time clock roughly 90 some minutes passed . . . but using “23 mins” of cpu time . . . more or less “painless” . . . I could see that stuff in the browser was “influenced” by the installation activities of the script . . . . Ordinarily I would have probably shut down out of my gas guzzling Xeon cpu by 10 am or so . . . in that sense TW used that much more energy to upgrade itself . . . .

With the dupa.service script I just don’t have to watch the console while it goes on . . . up side, it didn’t seem to “quit” the download the way zypper did in my laptop the other day . . . it just kept on with it???