8-18-23 dup left sytem unable to boot

Greetings, I’ve not updated ,dup, my system in a while …since like march and today’s dup seemed to go fine but after a reboot the system locked up after it tried to reboot. It appeared it was going to boot, it appeared kde was getting ready start as I saw the screen I generally see right before the spinning wheels but it never got to that. It just dumped to a black screen and that was it…I couldn’t F2 etc to even get a terminal, even num lock did nothing so it was completely frozen. I’ve never had this happen, even if a driver broke I’ve generally been able to get a terminal to check logs. I’ve rolled back successfully. I also have the kernel and nvidia drivers locked as I generally update them independently so it should have been the old running kernel.

The one thing that may or may not be the problem is this, I don’t think it is but it’s worth mentioning. I removed some python stuff as dup was complaining about it. I removed these two apps before dup to get the error to go away per this forum input. Python310-notebook-6.5.3-3.1.noarch - #5 by suse_rasputin

jupyter-jupyter-client python310-jupyter-client

I removed them via zypper, then ran a dup and then rebooted to a locked up system. Here is the error now that I’ve rolled back. Could this be the issue, i’d figure id at least get a terminal if it was a python library issue. I’m not sure what more I can provide since I was unable to get logs.

Problem: the to be installed python310-ipyparallel-8.6.1-1.4.noarch requires ‘python310-jupyter-client < 8’, but this requirement cannot be provided
deleted providers: python310-jupyter-client-7.4.9-1.1.noarch
not installable providers: python310-jupyter-client7-7.4.9-2.3.noarch[download.opensuse.org-oss_1]
Solution 1: deinstallation of python310-ipyparallel-8.4.1-2.2.noarch
Solution 2: deinstallation of python310-jupyter-client-7.4.9-1.1.noarch
Solution 3: keep obsolete python310-ipyparallel-8.4.1-2.2.noarch
Solution 4: keep obsolete python310-jupyter-client-7.4.9-1.1.noarch
Solution 5: break python310-ipyparallel-8.6.1-1.4.noarch by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/4/5/c/d/?] (c):

Should be possible to see previous boot log(s) with
sudo journalctl -b -1
(-0 is current, -1 previous and so on)

The only thing I can see as a maybe is the following…nothing else stands out. But even a kde segfault should allow me to hit F2 etc to get a terminal I’d think. Regarding the dup error …did I handle that correctly by using zypper to remove those two apps and then running dup or should I have handled this another way?

2103:Aug 18 13:00:52 localhost.localdomain kernel: xdg-desktop-por[2617]: segfault at 0 ip 0000000000000000 sp 00007ffeaabe3f98 error 14 in xdg-desktop-portal-gtk[555d84084000+13000] likely on CPU 3 (core 3, socket 0)
2119:Aug 18 13:00:52 localhost.localdomain dbus-daemon[2519]: [session uid=1000 pid=2519] Activating via systemd: service name=‘org.kde.kglobalaccel’ unit=‘plasma-kglobalaccel.service’ requested by ‘:1.9’ (uid=1000 pid=2630 comm=“/usr/bin/kded5”)

Here’s the last kernel from the last boot that didn’t work if that helps…per the journalctl -b -1.

@Neal Hi, python 3.10 is not the default anymore… are you using jupyter items, if so they should update to 3.11 versions… else let them be gone…

I got rid of all the python 3.10 items… there is also a thread on the Factory ML https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/WIORVWUEIGKG3KYQUTTTOO5IE3NWANEE/

Right, like I was saying in the op I ran dup and got the message posted. I researched it and it seemed like just removing these two apps was the answer so I did then I ran dup without installing them again. I’m not sure it’s even the issue but thought I should put it in there as who knows.


  1. First I used zypper to remove “jupyter-jupyter-client and python310-jupyter-client”
  2. Then I ran dup and it did it’s think without any errors.

reboot and then after what appears to be a successful kernel boot and the beginnings of kde trying to start I’m dumped into a black screen and no system response…not even numlock.

Was I suppose to reinstall a new version of those files before dup?

That link you posted, they said they lost internet access…so did I. On reboot and the kernel logs it looks like it could not bring up my wifi interface. I’m on a laptop and use wifi. I see wicked on my laptop but not sure if it’s using it…I thought I was using network manger to list the wifi resources and connect to them via the kde networks icon. But, I’m still not sure that this would cause the issues of not booting and just locking up with a black screen.

@Neal do you think you were using it, I know I was at some point , but got rid of it all and everything 3.10 related :wink:

I’m using wired network here with NM and no issues (I’m on GNOME, Aeon and Hyprland)… wicked is deprecated in Tumbleweed, AFAIK you should be using NM.

A black screen usually indicates gpu issues…

I have the wicked binary installed because I looked but it appears I’m using NM. I install TW about four years ago …not sure if it was used then or not. It shouldn’t be the gpu and if it is I don’t know why as I have all things kernel and nvidia locked in zypper to avoid this crap, I got tired of duping and pulling in a new kernel and the nvidia patches were not here so I just locked both them. This seems to have been working for a while…I release the locks and update them after a confirmed patch and relock. So, not sure why the gpu would be having issues.

My current running setup that I’m trying to update.

uname -a && zypper ll
Linux localhost.localdomain 6.1.8-1-default #1 SMP PREEMPT_DYNAMIC Tue Jan 24 06:29:25 UTC 2023 (baebfe0) x86_64 x86_64 x86_64 GNU/Linux

| Name | Type | Repository | Comment

1 | kernel-de* | package | (any) |
2 | nvidia* | package | (any) |
3 | x11-video-nvidiaG04* | package | (any) |

@Neal Oh wow… way out of date for the kernel and likely the nvidia supporting bits…

I suspect unlocking and getting to the latest of everything may help, especially with the glibc update…

If python310 is still an obstacle you may wish to try my partially scripted python310 eradication workaround:

# cat py310rm.sh
rpm -e --nodeps libpython3_10-1_0 \
python310 \
python310-base \
python310-certifi \
python310-cffi \
python310-chardet \
python310-cryptography \
python310-curses \
python310-gobject \
python310-gobject-cairo \
python310-gobject-Gdk \
python310-idna \
python310-M2Crypto \
python310-pycairo \
python310-pycparser \
python310-pyOpenSSL \
python310-rpm \
python310-six \
zypper al python310*

Adjust the above to match whatever python310 packages you currently have installed, then run it. Once you’re sure you’ve successfully purged all of python310, proceed with a zypper zup, which will install any absent python311 packages required to fulfill requirements previously provided by python310 packages. I’ve done this on 11 TW installations here so far, plus a few that only had a few python310 that I just typed rpm -e --nodeps for removing at a shell prompt instead of adapting a previously used script.

1 Like

@mrmazda I just used zypper remove --dry-run python310* to see, then ran without the dry-run :wink:

1 Like

What do you mean by this? The kernel and corresponding nvidia drivers are compiled in relation to each other and since they are both locked neither the kernel or any nvidia drivers should be changed in any way. What this should accomplish and has in the past …is running a dup updates everything else and leaves the kernel and nvidia drivers alone. I don’t find the kernel outdated honestly…I mean it works fine and isn’t really old at all. Is there something else you’re referring to here that I’m not understanding you about?

On an installation that hadn’t been dup’d in several months?

@mrmazda sure it’s a dry run, but ideally let the system get to the latest snapshot, then clean out afterwards. You shouldn’t have to worry about locks…?

@Neal yes, all the updated glibc packages that just came out, your kernel and nvidia drivers are not compiled against that, whether it’s an issue or not… your system, your call :wink:

1 Like

So, not sure if you have a nvidia card or not but the problem with not locking the kernel and the nvidia drivers is you end up with a broken system way too often when a new kernel is pulled in and the nvidia drivers haven’t been patched. I understand what your saying, and highly appreciate the input, but I fail to see how not installing the newest kernel and nvidia drivers would cause a issue. From a technical point am I missing something, I mean there shouldn’t be any updates including glibc that are depending on a specific kernel. Having a known working kernel and nvidia driver locked should help eliminate them as a culprit. I guess I can try…I mean what snapper for right? Generally I’d see something in the kernel logs about the gpu not booting if it was a issue with the kernel and nvidia drivers and it’s never left me hanging with a frozen system…I’ve always at least had a terminal. I posted the kernel logs above on the failed boot. My hunch was if that python junk was somehow used by kde or something and it locked things up since I deleted it?

Ahh, I see what your saying.

So, is there a way to recompile the current kernel and nvidia drivers against the new glibc…I really don’t want to try a new kernel and nvidia drivers right now and if I release the locks I loose them and can’t get them back as the older packages are removed. If the new kernel it pulls in and the nvidia drivers are broken I’m out on a limb.


Running an old kernel shouldn’t cause a black screen:

# inxi -S
  Host: gx620 Kernel: 6.3.4-1-default arch: x86_64 bits: 64 Console: pty pts/1
    Distro: openSUSE Tumbleweed 20230817

Old kernels needn’t be automatically removed. You can configure how many you keep via /etc/zypp/zypp.conf, or simply disable the purge-kernels.service, and remove or not at will:

# systemctl status purge-kernels.service
○ purge-kernels.service
     Loaded: masked (Reason: Unit purge-kernels.service is masked.)
     Active: inactive (dead)
# rpm -qa | grep kernel-de
1 Like