I see there have been a few posts about “zypper dup -l” causing problems, today I ran that command in newish Sys76 Gazelle in TW . . . there was a four choice option involving packages that “couldn’t be upgraded” and a package that was going to “upgrade, except it needed the other package before it could upgrade” . . . I didn’t write anything down at the time because usually these problems resolve themselves . . . but one of the packages was “python3xxxxxxx”??? Also saw that a new kernel 5.9xxx was in the list of upgrades.
I usually select “go with package maintainers choice” rather than “stay with the old” . . . but out of the four options I didn’t see that, so I went with "1 . . . because it was first. I was “in a hurry” and didn’t have time to do research, etc. I ran it through and then shut down. When I returned home I booted the laptop , “welcome to grub” and TW is first up, unit usually boots quickly, but I looked over to a black screen with a “cursor is over link” looking cursor. I moved the mouse and it returned to default mouse and it moused around, but no GUI. Shut down, selected “advanced options” and rebooted into 5.9 “recovery” ran thru the dmesg . . . and back into black screen, this time the mouse cursor was there, but mousing the mouse did nothing. Since I have more time in ubuntu I tried to run “sudo zypper -f install” in a TTY, but that command wasn’t accepted, and I tried to install “synaptic” so I could "fix broken packages, but it didn’t allow that to happen . . . .
I rebooted again, this time picked the old kernel, 5.8xxxx and back into working GUI . . . so apparently the “package dependency” problems aren’t happening in the old kernel??? Question is “What happened?” Is this a “kernel not compatible with new machine issue?” Or, package dependency problem where the “wrong choice” resulted in busted video operation, providing black screen . . . in 5.9 kernel, but in 5.8 it’s fine?? Which is the Yast app that “fixes broken packages” as the olde synaptic will sometimes handle???
OK, maybe problem is solved . . . found YAst Software Management in the 5.8 kernel GUI, it found two packages to upgrade, “sof-firmware” and “ucode-intel” . . . ran those through. Shut down. Rebooted back into black screen!!!??? Got to a TTY to try to run zypper, “nothing to do” . . . exiting TTY went to black, then went to GUI log in . . . .
Checked “uname -r” and it shows 5.9.1.1??? kernel . . . so I guess we are back to “normal” . . . . Thanks for the bandwidth.
Following up on this post, I would be happy to hear what the command is to run to get zypper to “fix install” or “fix broken packages”??? Something that will get zypper to repair an upgrade that goes sideways???
Got another clue . . . ran another “dup -l” and restarted, get the “tumbleweed” splash . . . then back into black with the vert mouse cursor . . . which I think is the log in window showing that the password is to be typed in . . . . I typed my password into the black void . . . and that logged me in . . . to a GUI.
Or like going to TTY and then exiting via f7 key gets to the log in window . . . otherwise it’s black screen, not the what, the “plymouth” window???
Next time you boot to a black screen, wait 120 seconds before doing anything.
When a system boots up, it will arrieve at what will look like a text login screen and sometimes pause there for a time before continueing on. If that’s what’s happening in the background while you’re staring at a black screen, eventually your system will continue to the graphical login (which may be skipped if you have auto login enabled).
Either a bug ( then report it at bugzilla.opensuse.org ) or … you have been using YaST Software Manager or ‘zypper up’ instead of the documented ‘zypper dup’.
Thanks for the reply . . . I wasn’t in a hurry, and problem happened, seemed to be fixed, and then with the second zypper . . . returned again. Now that I know the “log in” is “there” . . . just buried visually by a bunch of blackness, it’s not as dramatic . . . but seems to be a problem. Autologin is not enabled.
Thanks also for the reply . . . I’m leaning with “bug” or the two packages interdependency issue that showed up in zypper dup -l (as mentioned) . . . . When I switched over to Yast it found the two other packages to upgrade, that was what seemed to fix the problem, but then runing “dup -l” again then found the new “12 packages” and then brought the problem back.
Asking again for what would be the zypper command to “fix install” via the TTY. Other question, generally I haven’t been running “dup -l” in a TTY, but is that something that is “required” or “recommended”??? In a little while I’m going to try to run dup -l in my MacPro edition of TW, we’ll see if the scenario repeats in an older machine . . . .
OK . . . running zypper over in the MacPro brings a similar error, but seems like the “options” are a tad bit different than in the Sys76 laptop . . . .
Problem: mate-menu-20.04.1-2.1.noarch requires python3-xdg, but this requirement cannot be provided
deleted providers: python3-pyxdg-0.26-6.2.noarch
not installable providers: python3-xdg-4.0.1-1.1.noarch[download.opensuse.org-oss]
Solution 1: Following actions will be done:
deinstallation of mate-menu-20.04.1-2.1.noarch
deinstallation of mate-panel-branding-openSUSE-42.1-4.44.noarch
deinstallation of mate-menu-lang-20.04.1-2.1.noarch
Solution 2: deinstallation of python3-pyxdg-0.26-6.2.noarch
Solution 3: keep obsolete python3-pyxdg-0.26-6.2.noarch
Solution 4: break mate-menu-20.04.1-2.1.noarch by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/4/c/d/?] (c):
Any sage advice on which would be the best path forward???
Perhaps this thread could be split out as it’s a different problem from the OP. I was getting this error as well, so I locked python3-pyxdg, then did the “sudo zypper dup” command and successfully updated. Now I see this:
A little package searching reveals there are two packages supplying python3-xdg, but only one can be installed at a time. On my system, mate was installed on 2020-05-06 and I see this:
It looks like mate installed python3-pyxdg, and it’s been updated twice since then. I think mate-menu needs to be rebuilt for the new version of python3-pyxdg, but I’m not sure how to make that happen.
Thanks for stopping by . . . it does seem like MATE has created some kind of conflict in its packaging . . . I think they do have a “forum” of a sort, but doesn’t seem to be over-active from my experience . . . . Might have to look around for that site again . . . been there before . . . .
I did try to run your “zypp-hist” command, but my console is rejecting that, saying “command not found” . . . but I do try to avoid “locking” packages if at all possible, because in my case I’m in “rolling” . . . so always a new series of packages coming down the tubes . . . .
Seems like maybe in my case, going with #3 option, “keep the obsolete pythonxxxxxx” package might match what you did, without locking . . . and then see if and when MATE gets around to repairing the situation???
Alrighty, well, this time I selected #3 option, “keep the obsolete python3-xxx package,” and that then showed the package is now “locked” . . . and the rest of the 265 packages passed through processing . . . and reboot . . . took a couple minutes maybe, but the log in window appears and we are back into an operational MATE gui . . . albeit with “an obsolete python3 package” . . . locked in . . . .
Thanks for that . . . I jumped back over to the original sufferer, the laptop . . . booted TW, same black screen . . . entered my password blindly, back into GUI . . . ran a zypper dup -l . . . had a bunch of “firmware” packages, rebooted, same problem, back in, went to Yast software management, searched “python3-xdg” and Yast showed it as “available” . . . so I installed it . . . shut down. On reboot, problem remains . . . .
But, over here I had different options than on the desktop, so I don’t recall how it got out of sorts . . . . I’ll try to add my name to your bugzilla report, but I think this is an “upstream” issue relating to MATE??? Don’t know if that is a fair assessment . . . .
I found this link to the obsolete RPM and used rpm to install it so zypper does not know about it. Click on the “python3-pyxdg-0.26-5.2 RPM for noarch” to download it.
It is one release back but seems to work for me.
OK, I’ll check into that . . . I’ve “taken the fork in the road” . . . with two different results . . . .
On the desktop I kept that “obsolete python3-xdg” . . . which “locked it” . . . but allowed upgrade to run through and rebooted into gui w/o issues . . . .
Over on the laptop, I still have the problem, but once logged in I ran zypper . . . then yast showed the newer python3 app that it wanted for the mate-menu upgrade . . . but installing that didn’t fix the problem . . . . But, now that I know to just type my password, maybe at some point an upgrade will come along and fix it??
Got a response from the mate-menu people on the report I made on their git-hub site:
This is a packaging issu with your distro, not an upstream issue. You need to file issues with OpenSUSE TW & Gecko TW instead, as only they can fix this. Looks like they have python updates out of synch with their build of mate-menus and need to rebuild that package from the same source
So over here in TW the “work around” is “keeping the obsolete python” package . . . .
I thought I had posted the response on the bubzilla bug report that larryr had filed, but I guess I didn’t . . . . Problem still remains in one or more of my TW installs . . . .
Actually, I believe only mate-menu depends on python3-pyxdg. When I test this by telling zypper to remove python3-pyxdg, I see this: