Made a fresh install of build 20190527(dual boot 18908.1000)and not getting updates since then. Update manually tokernel-default-5.2.rc2-2.1.gcbe6c1c.x86_64.rpm.
Up & dup +discover has no effect. Software repositories are disabled because update manager starts on every boot and Chrome Dev generates an error. Re-enabling them does not help. Neverseen Kernel 5.1.5.x.
sudozypper up
Systemmanagement is locked by the application with pid 3634 (zypper).
Closethis application before trying again.
sudozypper dup
Systemmanagement is locked by the application with pid 5239(/usr/bin/ruby.ruby2.6).
Closethis application before trying again
Never seen such things before. How to Kill Ruby and pid 3634?
That sometimes happens here, when I login to Gnome. I usually wait it out. The update applet finishes its run after a while.
I will admit that I am puzzled as to why Gnome does this. I have it configured to never download updates. But it runs the updater anyway, to find out if there are updates. But it never tells me that there are updates. What’s the point of that?
In any case, if you don’t want to wait it out, there’s an easy alternative. Just login to Icewm to do your updating. Icewm doesn’t start any update applet, so it won’t get in the way. You can open a terminal and run “sudo zypper dup” from there.
Hmm.There was a big surprise today, a 2 coffees KDE upgrade.
Checkfor updates from the taskbar (Statusand Notifications) did work this morning with a huge amount of packages.
No errors, all green.
Thefollowing 33 NEW packages are going to be installed:
freecell-solver-presetskdegames-carddecks-default
kernel-default-devel-5.2.rc2-2.1.gcbe6c1ckernel-devel-5.1.4-1.2
kernel-devel-5.2.rc2-2.1.gcbe6c1ckernel-source-5.2.rc2-2.1.gcbe6c1c
kernel-syms-5.2.rc2-2.1.gcbe6c1ckmahjonggkmahjongg-langkmineskmines-langkpat
kpat-langkreversikreversi-langksudokuksudoku-langlibappindicator3-1
libdbusmenu-glib4libdbusmenu-gtk3-4libfreecell-solver0libindicator3-7libkdegames
libkdegames-langlibkf5kdegames6libKF5KMahjongglib5libkmahjongglibkmahjongg-lang
patterns-games-gamespatterns-kde-kde_gamespoppler-datapulseaudio-module-gconf
xf86-video-amdgpu
Thefollowing 2 NEW patterns are going to be installed:
gameskde_games
**Thefollowing 2302 packages are going to be upgraded:**
….
Thefollowing 30 patterns are going to be upgraded:
apparmorapparmor_optbasebasesystemdevel_basisdevel_kernelenhanced_base
enhanced_base_optfontsfonts_optkdekde_internetkde_multimediakde_officekde_pim
kde_plasmakde_utilitieskde_utilities_optkde_yastlaptopminimal_basemultimedia
multimedia_optofficesw_managementx11x11_enhancedx11_optx11_yastyast2_basis
Thefollowing product is going to be upgraded:
openSUSE Tumbleweed 20190527-0 ->20190529-0
Thefollowing 6 packages require a system reboot:
dbus-1glibclibopenssl1_0_0libopenssl1_1systemdudev
2302packages to upgrade, 33new.
Overall download size: 1.43 GiB. Alreadycached: 0 B. After the operation, additional
901.5 MiB will beused.
Note:System reboot required.
**Continue?[y/n/v/...? shows all options] (y): ****y**
Still don’t see Kernel 5.1.5.x, but Ok. Lost Kernel 5.1.4.x, not shown in the Grub menu.
Tumbleweed runs remarkably well on this Kernel 5.2 cycle.
You should not hang yoiur problem in anotherone’s thread, confusion about which answers is for which problem will occur and also your problem will not get the same attention then when it was advertised as a new thread with a good title.
When your installation is quite new, it is possible that there is nothing to do.
Your repo list is next to useless, because the real definition of the repos isn’t represented there. Only your local names and aliases. Please do a
The thread was “update manager is dead”; I’m on 5.1.3; attempts to update found nothing; Malcolm reported that 5.1.4 is current; so I inferred that my update manager might be dead. I wasn’t sure I have the right repositories identified, so I asked the question. I think I was on topic, but naive about what to be looking for.
So thanks for clarifying that I needed to provide more information. Here is is:
First, I do not realy know what the OP here means with an “update manager”. There isn’t such a thing in Tumbleweed, at least, when there is something in a GUI that looks like it, it should be ignored (or better switched off/removed).
The only way to bring TW up to date is:
zypper dup
Then I do not know what you should have on your architecture (again something that most probably does not fit with the OP.
Normaly, after an installation you should have
OSS repo;
non-OSS repo;
Update repo for OSS (almost never used in TW);
Update repo for non-OSS (almost never used in TW).
Then, normaly, there will be disabled repos in your list for Debug and Source.
Now you seem not to have the non-OSS ones. That may be special to your architecture.
The three you mention in your last list are again a OSS, a non-OSS and an Update. Probably not for your architecture. So better do not touch them.
zypper lr
Repository priorities are without effect. All enabled repositories share the same priority.
# | Alias | Name | Enabled | GPG Check | Refresh
--+------------------------+-----------------------------+---------+-----------+--------
1 | google-chrome-unstable | google-chrome-unstable | Yes | (r ) Yes | No
2 | kernel-repo | kernel-repo | Yes | (r ) Yes | No
3 | kernel-repo+ | kernel-repo+ | Yes | (r ) Yes | No
4 | repo-debug | openSUSE-Tumbleweed-Debug | Yes | (r ) Yes | No
5 | repo-non-oss | openSUSE-Tumbleweed-Non-Oss | Yes | (r ) Yes | No
6 | repo-oss | openSUSE-Tumbleweed-Oss | Yes | (r ) Yes | No
7 | repo-source | openSUSE-Tumbleweed-Source | Yes | (r ) Yes | No
8 | repo-update | openSUSE-Tumbleweed-Update | Yes | (r ) Yes | No
uname -r
5.2.0-rc2-2.gcbe6c1c-default
You can always get the default RPM package (65MB, not the debug one) and run the.rpm file in yast. In debian, the latest stable Kernel must be compiled manually, it looks the same for Tumbleweed. A new ISO file should give you the latest available, because it comes with a new Kernel. The update Manager does not seem to always follow that path.
Auto refresh is disabled to stop Update Manager from running, but this is not enough. Update Manager starts every time we boot and to kill it, we must disabled all repos too. This is what we did last week and it is not the first time we do so.
All types of notifications appear as an internal source of pollution here. KDE is not an exception.
This cmd line looks the same and opensuse dot org runs like a Swiss clock here:
Update manager does start at KDE login but generally does not lock thing up after it checks for updates which may tack a few minuets. The error message should give the PID of the process that has the update locked which you can then use to kill the process. **kill PID **where PID is the number given in the error message. Never needed to stop repos though???
erlangen:~ # journalctl -b -u packagekit.service
-- Logs begin at Wed 2019-04-10 09:08:16 CEST, end at Mon 2019-06-03 08:29:34 CEST. --
Jun 02 18:59:48 erlangen systemd[1]: Starting PackageKit Daemon...
Jun 02 18:59:48 erlangen PackageKit[2015]: daemon start
Jun 02 18:59:48 erlangen systemd[1]: Started PackageKit Daemon.
Jun 02 19:00:08 erlangen PackageKit[2015]: daemon quit
Jun 02 19:00:08 erlangen systemd[1]: packagekit.service: Main process exited, code=killed, status=15/TERM
Jun 02 19:00:08 erlangen systemd[1]: packagekit.service: Succeeded.
Jun 02 19:59:30 erlangen systemd[1]: Starting PackageKit Daemon...
Jun 02 19:59:30 erlangen PackageKit[4731]: daemon start
Jun 02 19:59:30 erlangen systemd[1]: Started PackageKit Daemon.
Jun 02 19:59:36 erlangen PackageKit[4731]: get-updates transaction /1_eebcdaab from uid 1000 finished with success after 6630ms
Jun 02 19:59:55 erlangen PackageKit[4731]: daemon quit
Jun 02 19:59:55 erlangen systemd[1]: packagekit.service: Main process exited, code=killed, status=15/TERM
Jun 02 19:59:55 erlangen systemd[1]: packagekit.service: Succeeded.
Jun 02 20:59:37 erlangen systemd[1]: Starting PackageKit Daemon...
Jun 02 20:59:37 erlangen PackageKit[6085]: daemon start
Jun 02 20:59:37 erlangen systemd[1]: Started PackageKit Daemon.
Jun 02 20:59:41 erlangen PackageKit[6085]: get-updates transaction /1_bcbeaaae from uid 1000 finished with success after 4359ms
Jun 02 21:00:02 erlangen PackageKit[6085]: daemon quit
Jun 02 21:00:02 erlangen systemd[1]: packagekit.service: Main process exited, code=killed, status=15/TERM
Jun 02 21:00:02 erlangen systemd[1]: packagekit.service: Succeeded.
Jun 03 05:51:19 erlangen systemd[1]: Starting PackageKit Daemon...
Jun 03 05:51:19 erlangen PackageKit[6905]: daemon start
Jun 03 05:51:19 erlangen systemd[1]: Started PackageKit Daemon.
Jun 03 05:51:23 erlangen PackageKit[6905]: get-updates transaction /1_eadebbae from uid 0 finished with success after 3610ms
Jun 03 05:51:39 erlangen PackageKit[6905]: daemon quit
Jun 03 05:51:39 erlangen systemd[1]: packagekit.service: Main process exited, code=killed, status=15/TERM
Jun 03 05:51:39 erlangen systemd[1]: packagekit.service: Succeeded.
Jun 03 06:36:44 erlangen systemd[1]: Starting PackageKit Daemon...
Jun 03 06:36:44 erlangen PackageKit[8103]: daemon start
Jun 03 06:36:44 erlangen systemd[1]: Started PackageKit Daemon.
Jun 03 06:36:48 erlangen PackageKit[8103]: get-updates transaction /1_eedcbbbd from uid 1000 finished with success after 3613ms
Jun 03 06:37:04 erlangen PackageKit[8103]: daemon quit
Jun 03 06:37:04 erlangen systemd[1]: packagekit.service: Main process exited, code=killed, status=15/TERM
Jun 03 06:37:04 erlangen systemd[1]: packagekit.service: Succeeded.
Jun 03 07:36:48 erlangen systemd[1]: Starting PackageKit Daemon...
Jun 03 07:36:48 erlangen PackageKit[9301]: daemon start
Jun 03 07:36:48 erlangen systemd[1]: Started PackageKit Daemon.
Jun 03 07:36:52 erlangen PackageKit[9301]: get-updates transaction /1_caebbddc from uid 1000 finished with success after 3636ms
Jun 03 07:37:08 erlangen PackageKit[9301]: daemon quit
Jun 03 07:37:08 erlangen systemd[1]: packagekit.service: Main process exited, code=killed, status=15/TERM
Jun 03 07:37:08 erlangen systemd[1]: packagekit.service: Succeeded.
Jun 03 08:15:22 erlangen systemd[1]: Starting PackageKit Daemon...
Jun 03 08:15:22 erlangen PackageKit[11268]: daemon start
Jun 03 08:15:22 erlangen systemd[1]: Started PackageKit Daemon.
Jun 03 08:15:42 erlangen PackageKit[11268]: daemon quit
Jun 03 08:15:42 erlangen systemd[1]: packagekit.service: Main process exited, code=killed, status=15/TERM
Jun 03 08:15:42 erlangen systemd[1]: packagekit.service: Succeeded.
Jun 03 08:18:22 erlangen systemd[1]: Starting PackageKit Daemon...
Jun 03 08:18:22 erlangen PackageKit[11844]: daemon start
Jun 03 08:18:23 erlangen systemd[1]: Started PackageKit Daemon.
Jun 03 08:18:23 erlangen PackageKit[11844]: uid 1001 is trying to obtain org.freedesktop.packagekit.system-sources-refresh auth (only_trusted:0)
Jun 03 08:18:23 erlangen PackageKit[11844]: uid 1001 failed to obtain auth
Jun 03 08:18:43 erlangen PackageKit[11844]: daemon quit
Jun 03 08:18:43 erlangen systemd[1]: packagekit.service: Main process exited, code=killed, status=15/TERM
Jun 03 08:18:43 erlangen systemd[1]: packagekit.service: Succeeded.
erlangen:~ #
packagekit is invoked at boot as well as every hour on behalf of users logged in. On a working system it locks zypper for a few seconds and silently terminates. You may verify your repos by running zypper dup in a root shell:
erlangen:~ # zypper dup
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...
Nothing to do.
erlangen:~ #
Thefollowing 5 NEW packages are going to be installed:
kernel-default-5.2.rc3-1.1.g038ee83kernel-default-devel-5.2.rc3-1.1.g038ee83kernel-devel-5.2.rc3-1.1.g038ee83kernel-source-5.2.rc3-1.1.g038ee83kernel-syms-5.2.rc3-1.1.g038e
Thefollowing package is going to be upgraded:
kernel-macros
Thefollowing package requires a system reboot:
kernel-default-5.2.rc3-1.1.g038ee83
1package to upgrade, 5new.
Overall download size: 184.9 MiB. Alreadycached: 0 B. After the operation, additional 1.1 GiB will be used.
Note:System reboot required.
**Continue?[y/n/v/...? shows all options] (y): **y
It is not systematic that repos are disabled, but 2400 packages are enough to keep it alive. Sometimes, we take a break of notifications and most of all, when DE stability is at high, we also take a break of data collection. Compare to what we do to kill them in Windows 10, this is a mellow approach.
Mainline Kernel has its own data collection pattern and this is our main contribution to Opensuse and the Linux edifice. A Kernel cycle usually last 10 weeks after what, the Kernel merges into Tumbleweed user’s machines.