Again, show
ls -l /etc/systemd/system/dup.service
I suspect you’ve created an empty dup.service unit file. You need to add the requisite content as Karl already posted.
@deano:
I would agree, clearly the file that nano makes is empty, as obviously the first thing that gets made is the “dup.service” file. The problem is that none of the rest of the commands that I ran after that, “worked” . . . which I did post also . . . . Either “file not found” or “masked” . . . so subsequent data that Karl posted did not actuate or “fill” the file . . . .
Is there one specific post in this lengthy thread that lists all of the correct commands to run, and in the correct order to create and then “populate” and then “start” the operation? Because, so far it seems like the data that has been posted is either “not working” due to info not entirely listed in the process, or is not listed in the correct ordering of the commands???
Like where in the process is Karl’s latest “daemon” hint to be run?? Before all of the nano-ing???
Of course not. Nano is an editor. Editors don’t invent content. Editor users create or insert content.
Oh man you’re making this difficult for yourself. Go back to post #58, open the dup.service file and enter the following…
# /etc/systemd/system/dup.service
[Unit]
Description=Dist Upgrade
[Service]
ExecStartPre=/usr/bin/sleep 11
ExecStart=/usr/bin/zypper dist-upgrade --no-confirm --download-only
Save when done.
Some reading
https://www.freedesktop.org/software/systemd/man/systemd.service.html
@et al:
Yes, in life, when it comes to choosing the hard way or the easy way, I always pick the hard way . . . because it’s more “interesting”? So, highly embarrassing, I have edited “sources.list” files using nano, and in PPC linux I had to create a config file for Xorg, but that was some years back and the posted data in the wiki was crystal clear . . . .
I’d have to say that although all of the data was “there” it wasn’t exactly explicitly explained . . . ??? All I can say is that I’ve been “stressed” for the last month and a half, having to take care of the better half, think and do everything just about for two, instead of just “my part” . . . has been tough. If you count cats that’s actually 4 that are being cared for by #1 . . . so, I had no extra brain power for figuring out how to get all four of my TW variations set up to run dup/dupa . . . .
But, I may have gotten the hint on it . . . I populated the dup.service file as per the last post from deano . . . which from the reading seems to supply the “download” function?? I then made another file for “dupa.service” which I populated via Karl’s post . . . and I started them both . . . . So, now, “stuff” is happening under the table???
# nano /etc/systemd/system/dup.service
1 # systemctl cat dup.service
# /etc/systemd/system/dup.service
# /etc/systemd/system/dup.service
[Unit]
Description=Dist Upgrade
[Service]
ExecStartPre=/usr/bin/sleep 11
ExecStart=/usr/bin/zypper dist-upgrade --no-confirm --download-only
# systemctl start dup
# ls -l /etc/systemd/system/dup.service
-rw-r--r-- 1 root root 180 Jun 3 17:43 /etc/systemd/system/dup.service
# journalctl -u dup -u dupa -g Consumed -q
Jun 03 17:47:57 1 systemd[1]: dup.service: Consumed 32.196s CPU time.
# nano /etc/systemd/system/dupa.service
# systemctl start dupa
Does that look like I’m now finally in the ball park on this service script invocation thing?? I’ll have to replicate this across the other three TW installs over the coming days, and see if that takes out the Balloon package upgrades . . . which, when they hit, hit me on 4 different installs. : - 0
Anyway, thanks for the perseverance on this, there was a lot of cross talk that perhaps made it a bit “harder” for those of us who pick that way . . . .
Great! Running “zypper dist-upgrade” as a service comes at low costs (for many users) and has big advantages over running the command in a terminal window on top of a graphical login.
I switched all machines to mirrorcache a month ago:
**erlangen:~ #** zypper lr -uE
# | Alias | Enabled | GPG Check | Priority | URI
---+---------------------+---------+-----------+----------+---------------------------------------------------------------------------------------
5 | Packman | Yes | (r ) Yes | 90 | https://ftp.fau.de/packman/suse/openSUSE_Tumbleweed/
14 | openSUSE-20191106-0 | Yes | (r ) Yes | 99 | https://**mirrorcache-eu.opensuse.org**/tumbleweed/repo/oss/
18 | repo-non-oss | Yes | (r ) Yes | 99 | https://**mirrorcache-eu.opensuse.org**/tumbleweed/repo/non-oss/
20 | repo-update | Yes | (r ) Yes | 99 | https://**mirrorcache-eu.opensuse.org**/update/tumbleweed/
1 | Application_Geo | Yes | (r ) Yes | 100 | https://**mirrorcache-eu.opensuse.org/**repositories/Application:/Geo/openSUSE_Tumbleweed/
3 | BellSoft | Yes | (r ) Yes | 100 | https://yum.bell-sw.com/
7 | chrome | Yes | (r ) Yes | 100 | https://dl.google.com/linux/chrome/rpm/stable/x86_64
11 | jalbum | Yes | ( ) No | 100 | https://jalbum.net/download/software/yumrepo/
**erlangen:~ #**
Downloading and installing 10,000++ packages on several machines since switching from download.opensuse.org a month ago resulted in a single glitch:
**erlangen:~ #** journalctl -u dupa -u dup -g ksh -o short-monotonic --quiet --no-full --no-pager
346.033457] erlangen zypper[3809]: 7zip aaa_base aaa_base-extras accountsservice accountsservice-lang acl acpi acpica adjtimex adobe-sourcecodepro-fonts adobe-sourcesans3-fonts adobe-sourcesanspro-fonts adobe-s…ndar-tools-lang akon
3390.558692] erlangen zypper[3809]: Paket ksh-93vu-5.8.x86_64 abrufen (2282/3575), 1,1 MiB ( 2,7 MiB entpackt)
3392.127312] erlangen zypper[3809]: Abrufen: ksh-93vu-5.8.x86_64.rpm ..fertig (803,2 KiB/s)]
6111.238574] erlangen zypper[11009]: Im Cache ksh-93vu-5.8.x86_64.rpm (2282/3575), 1,1 MiB ( 2,7 MiB entpackt)
6589.464042] erlangen [RPM][20636]: **erase ****ksh****-93vu-5.6.x86_64: success**
6589.510795] erlangen zypper[11009]: (2307/3611) Installieren: ksh-93vu-5.8.x86_64 .......
6589.510795] erlangen zypper[11009]: update-alternatives: error: /var/lib/alternatives/ksh corrupt: slave link same as main link /usr/bin/ksh
6589.511414] erlangen [RPM][20636]: **scriptlet %post(****ksh****-93vu-5.8.x86_64) failure: 2**
6589.511528] erlangen [RPM][20636]: **install ****ksh****-93vu-5.8.x86_64: success**
6589.511667] erlangen zypper[11009]: warning: %post(ksh-93vu-5.8.x86_64) scriptlet failed, exit status 2
6589.537850] erlangen [RPM][20636]: **erase ****ksh****-93vu-5.6.x86_64: success**
**erlangen:~ #**
Running “systemctl start dup” fixed the upgrade by removing a package which got erroneously installed on the first try.
BTW: kernel 5.18 arrived this morning. Consumed 35.393s CPU time (6 packages)
[FONT=monospace] [/FONT]
Thanks . . . obviously there was a “learning” curve involved . . . the “learning” hasn’t been fully absorbed to understand how and why two or three simple lines in a file can do what it does . . . . But, I’ll be adding that in to my other TW installs and maybe I’ll grow to understand it.
I have changed the repo address in Yast I believe previously when the Packman repo address was changed . . . so this “mirror-cache” adjustment would be to just pick up the closest/fastest mirror and therefore make the download and install process even snappier???
And. cool on the 5.18 kernel, one of the joys of TW is always being on the cutting edge of fresh kernels . . . newer is always better than old and stable in my “doing it the hard way” world . . . .
Alrighty . . . back in main channel TW this morning . . . I added in the local service files . . . and started them . . . and then “cat’d” them to see if they are there, which they are . . . . And, now . . .??? It’s all going on under the surface??
The little update applet shows 377 packages to upgrade . . . ??? Will that change when the packages have been downloaded and processed??
Seems like in Karl’s machines that would be happening lightening fast . . . a few seconds. In my Xenon cpu and HDD drive that will take minutes?? Or, we’ll never know? I only run the desktop for a couple of hours in the morning, then on to work . . . .
Is this done when the machine first boots the system, showing in the dmesg stuff?
nano /etc/systemd/system/dup.service
# nano /etc/systemd/system/dupa.service
# systemctl start dup.service
# systemctl start dupa.service
# systemctl cat dup.service dupa.service
# /etc/systemd/system/dup.service
# /etc/systemd/system/dup.service
[Unit]
Description=Dist Upgrade
[Service]
ExecStartPre=/usr/bin/sleep 11
ExecStart=/usr/bin/zypper dist-upgrade --no-confirm --download-only
# /etc/systemd/system/dupa.service
# /etc/systemd/system/dupa.service
[Unit]
Description=Dist Upgrade, apply download
[Service]
ExecStart=/usr/bin/zypper dist-upgrade --no-confirm
So I logged out for a few minutes and then on logging back in the update applet says, “system up to date” . . . ?? So, when does that “happen” and when does that “register” in the applet??
Like Karl mentioned there is a new 5.18 kernel that was in this last upgrade-ing . . . but that hasn’t switched over, but everything else is upgraded??
Hi
If you run the command zypper -vvv dup it will tell you what’s happening. Maybe you have the kernel locked? IMHO that is pointless, just keep more kernels (you can configure to keep versions as well), if have an issue, just boot to an old kernel from grub?
Your dup.service seems to have two different service configurations, one which is download only and the other with download/install without confirmation.
I don’t know enough about systemd configuration files to figure out what happens with this type of configuration, but it looks like the unconfirmed update was used.
I am not going to re-read this thread, but I thought your intention was to do a download only. I don’t think you should ever do an unconfirmed install.
In an case, you should clean up the service file to do what you want.
[Unit]
Description=Download Dist Upgrade
[Service]
ExecStart=/usr/bin/zypper dist-upgrade --no-confirm --download-only
Personally, I just open a terminal and do a zypper dup. You can keep using your computer until it finishes. But then, if I was only using TW for a couple of hours at at time every few days, I would just switch to Leap.
In the interest of “computer science” I shut the machine down. On cold boot TW is top listing in Grub and it showed “5.17” kernel . . . otherwise booted up cleanly.
The little update notifier applet now appears to be gone?? I checked uname -r and ran some of the journalctl commands offered by Karl. “Strangely” . . . while I am typing this post out a notification window opened saying, “You have 377 packages to upgrade”??? So perhaps the packages have not been installed?? :
uname -r
5.17.9-1-default
:~> sudo zypper ref
[sudo] password for root:
Repository 'Main Repository (NON-OSS)' is up to date.
Repository 'Main Repository (OSS)' is up to date.
Repository 'Main Update Repository' is up to date.
Repository 'libdvdcss' is up to date.
Repository 'Packman Repository' is up to date.
All repositories have been refreshed.
:~> sudo zypper clean --all
All repositories have been cleaned up.
:~> su
Password:
# journalctl -b -u dup.service -g download
-- No entries --
# journalctl -b -u dup.service -g packages
-- No entries --
# journalctl -b -u dup.service -g consumed
-- No entries --
Do I need to “start” the services each time I boot the system?
Hi
Likewise, but with -vvv and also run screen beforehand on those big ones… 
OK, thanks for the reply, I guess I missed this post between my other posts. Well, in my case it isn’t the download time that takes too much time, even for the “2321” packages that part isn’t the issue that started this thread. The issue was the “two hours in a tty” to get the packages installed that was the issue . . . .
So, that would mean for me the dupa.services is what I would want, not really the “download.”
Other folks have mentioned that “TW isn’t for you” . . . and indeed, with these huge package upgrades the thrill is almost gone. I have a Leap install in another machine and I have various TW installs across a couple of machines . . . .
I’m actually OK with “unconfirmed” upgrades in TW . . . if the / system blows itself up I know the Ultimate Solution for it. Until then I like the newest kernel aspect of TW . . . I just don’t like the comparatively large package hits . . . in comparison to other “rolling” and/or “unstable” systems that I also have installed and spend a few houyrs each day in . . . .
OK . . . a “hint” . . . that is a whisper. I wouldn’t know what “run screen” would mean or where -vvv would go . . . ???
Right now I’m just trying to figure out if the local services are “running” and/or if not, why not . . . .
I have used “zypper dup -l” for years in TW . . . it was only this recent series of large packages to process that had me look into this dup dupa thing . . . .
OK, so I checked the journal and 376 packages were downloaded, but the dupa “failed” . . . .
systemd[1]: Started Dist Upgrade, apply download.
Jun 06 07:32:30 zypper[12841]: System management is locked by the application with pid 12593 (/usr/bin/zypper).
Jun 06 07:32:30 zypper[12841]: Close this application before trying again.
Jun 06 07:32:30 systemd[1]: dupa.service: Main process exited, code=exited, status=7/NOTRUNNING
Jun 06 07:32:30 systemd[1]: dupa.service: Failed with result 'exit-code'.
OK, these posts are slipping by in the night:
zypper -vvv dup
Verbosity: 3
System management is locked by the application with pid 21604 (/usr/bin/zypper).
Close this application before trying again.
Does that mean I have to disable zypper?? to use dup dupa??
[edit:] OK, I started dupa again and ini checking the
journalctl -u dupa --since 09:00
It is now running through the 376 upgrades . . . reporting “success” with each line . . . so I guess it got around the zypper??? Seems like it is good to go . . . ???
Hi
That’s packagekit running (and probably downloading packages too…)
You run the command screen in a terminal session, then do your update.
OK, thanks for that clarification . . . .
So it looks like dupa did its thing . . . the journalctl dupa 9:00 showed somehting like “3886” lines to process the 376 upgrades . . . but it reports it completed, using “12 minutes” of cpu time . . . by the clock it was longer . . . jes sayin’.
Jun 06 10:01:58 zypper[21604]: Since the last system boot core libraries or services have been updated.
Jun 06 10:01:58 zypper[21604]: Reboot is suggested to ensure that your system benefits from these updates.
Jun 06 10:01:58 systemd[1]: dupa.service: Deactivated successfully.
Jun 06 10:01:58 systemd[1]: dupa.service: Consumed 12min 34.094s CPU time.
So, this brings it back to the “what is the best way to run TW for this intermittent user?” . . . and the issue of “not knowing” if and when dup/dupa is doing anything of consequence . . . . And, then, if I have to run and shut the machine down . . . would that be likely to break something? Or, would dup/dupa just auto-resume on the next boot of TW??
Possibly my “answer” to that is, now that I have dup/dupa set up . . . to “stop” the services for the “regular” 200 to 999 packages per week upgrades, and just use “zyper dup -l” . . . and then if another (and we know it will) huge package count shows up . . . start dup/dupa again and let the machine run for a longer time than it takes for Karl to upgrade his system???
I would have to scroll through the posts again to see if there is any “non-verbose” way to check that dupa has completed its mission, w/o scrolling down thru the 3886 lines for the 376 packages installed . . . . (Guy is never happy about messing with stuff) :\
You can’t run two instances of zypper simultaneously. Presumably Software Updates had started zypper when you started service dupa. Disable Software Updates in system tray.