Not sure if this is the sub-forum for this question, but I’m asking in anticipation of a recurrence of the “large number of packages to upgrade that error out several times” in the zypper processing of rolling SUSE distros.
This morning I happen to be in Gecko rolling as I pass through my various multi-boot installs and I ran a zypper dup -l and it showed “1642 packages to upgrade” from last weeks upgrade . . . . It was early here, so I just clicked “y” and zypper started retrieving packages. I walked away for a few minutes and when I came back it appeared that the cursor had “returned”??? So soon?? O, no, looking at it more closely the download had errored out on “curl” or some sound package . . . “we tried five times and it failed.” I picked “i” to ignore and immediately the download resumed from package 1300 . . . .
I walked away again for breakfast and when I came back . . . cursor was back after downloading all of the packages and a “installation failed to complete” error was showing?? So the packages were “downloaded” but zypper “didn’t know what to do with all of them” so it errored out???
So, that is the question, how to “repair” a zypper upgrade that has gone horribly wrong? I know what ubuntu uses to do that, but not in SUSE so I ran “zypper dup -l” via sudo and it started the review process again, found the 1643 (now) packages to install and began the process that is still running as I type . . . .
I’m assuming that in a day or so when I get to my Tumbleweed edition that these same “1643 packages” will be waiting there as well . . . which, as I’ve posted before, is “too many packages for a rolling distribution” . . . but it doesn’t seem like the devs can help themselves . . . ???
My question is, "how to run a command is SUSE that will “repair broken upgrade”??? And, is there any way to prevent these zypper mishandlings of the large number of packages that are seeming to show up every couple of months in the rolling SUSE-land???
When that happens here, I usually pick “retry”, and the update usually resumes where it left off.
However, if you abort at that stage, it is probably harmless. Normally it has only been downloading packages and has not installed anything yet. So just restart. It will recognize that the already downloaded packages are in the package cache, so it won’t need to download them again.
I walked away again for breakfast and when I came back . . . cursor was back after downloading all of the packages and a “installation failed to complete” error was showing?? So the packages were “downloaded” but zypper “didn’t know what to do with all of them” so it errored out???
That’s because you did the ignore instead of retry. I think, at that stage, it probably has still only downloaded and not installed anything. And, in that case, you can just restart the upgrade. It should find the downloaded packages in cache, download only the one that is missing, and then install.
OK, thanks for the reply . . . . I think a few months back “we” were hitting some kind of problems like this, in today’s case I think that because it said, “We tried 5 times and failed” I didn’t think that doing a 6th “retry” would make any difference, because in the past it didn’t. There was some problem with “repo”?? sources???
Anyway, when you say, “restart” the process, are you meaning something other than running “zypper dup -l” again, as you say, the downloads were in cache, but zypper couldn’t find them to start the process???
I’m now in TW install, and I’m about to run another zypper for what I believe will be the same deal on a large number of packages. Not only did zypper “stumble” and error out a couple of times but then it stalled on a package installation for over 5 mins . . . AFTER it had “100%” posted . . . before writing it as “done.”
Overall very slow and cumbersome error prone upgrade in the Gecko rolling edition. I’ll see if the TW zypper is any different in a few minutes . . . .
O, just got a notification in TW that I have 2265 packages to upgrade from last weeks zyppering . . . cool, so cool.
That’s a reasonable way of looking at it. However, when I do “retry” it usually works.
I think it has been retrying with an already open socket. But when I say “retry” it starts afresh with a new socket.
I did get through yesterday’s update without any retry needed.
They updated “glibc”, and that meant that just about everything had to be recompiled. That’s why the update was so large.
Anyway, when you say, “restart” the process, are you meaning something other than running “zypper dup -l” again, as you say, the downloads were in cache, but zypper couldn’t find them to start the process???
I just meant to run the same “zypper dup” command again.
I’m now in TW install, and I’m about to run another zypper for what I believe will be the same deal on a large number of packages. Not only did zypper “stumble” and error out a couple of times but then it stalled on a package installation for over 5 mins . . . AFTER it had “100%” posted . . . before writing it as “done.”
Which package?
After it installs a package, it still has to run any special scripts for that package. I noticed that the “rpcbind” was especially slow. I’m not sure why, but it probably had to reinstate cached information about rpc connections.
The package it stalled on for over 5 minutes was a “nvidia-gfxG05 . . . x86” package . . . I have nvidia card, but I’m not using nvidia proprietary drivers . . . .
Over in TW still wending through the install of the now 2270 packages . . . the download process errored out 4 times at interval “curl error 55 . . . connection died.” 4 times, louie, four times. As soon as I hit “r” it immediately re-fired and continued to the next “death” . . . .
But, only difference is that perhaps because of “r” . . . after the download completed it started the installation, and so far that is proceeding . . . with some alacrity.
That package does a compile after install. That’s what would take a while.
If you do not want the proprietary drivers, then remove that package and disable to nvidia repo so that it won’t be reinstalled on the next update.
But, only difference is that perhaps because of “r” . . . after the download completed it started the installation, and so far that is proceeding . . . with some alacrity.
That’s a lot of packages. It does take a while. It took a while, here.
OK, on the remove the package . . . pretty sure that I did disable the repo . . . . My problem is that I have perhaps now 4 different SUSE installs on that one computer, “more, is more better” type of thing . . . so I’m not digging down under the hood too much in any of them. But I do know from numerous incidents that the nvidia drivers don’t seem to keep pace with rolling distro upgrades . . . . So in TW I’m in default video, but in Gecko I believe it is “nouveau” . . . so I don’t know why an “nvidia” package would be in there.
And, yes on the “it takes a long time” . . . I think on the TW w/ the 2268 packahes to upgrade it took over an hour to download and then install . . . with the 4 “death spirals” on the download phase . . . . “curl 55 error” etc.
Ah, that might explain that package issue . . . but both Gecko & TW weren’t “smooth” on the zypper-ing process on the '12 MacPro. But over on my new Sys76 laptop I have a Gecko partition and that ran a 1557 package upgrade in less than a half n hour . . . no “deaths” or errors . . . except a “we couldn’t create an i/o slave” . . . for you??? What? I wanted a slave to follow my commands . . . . Haven’t rebooted on it to see if that has any real meaning . . . .
A read of the first post of this primer thread may help understanding the graphics driver situation. Gecko may not demand you accept license terms of the old technology, reverse-engineered nouveau X display driver (xf86-video-nouveau, normally installed via the meta-package xorg-x11-driver-video), as does openSUSE. Without nouveau DDX driver installed, NVidia GPUs run on the newer technology modesetting DIX driver. Both must be tried if you wish to know if either seems to work better than the other. I’ve standardized on the modesetting for all GPUs that it supports (anything not bleeding edge made since around 2008 or so for which a suitable kernel device driver exists).
Thanks for the link and the insights . . . I’ll take a look at it in a bit. I have three computers of varying age that have nvidia cards, but as mentioned, since I have a fair number of installs on them I’m generally not rifling around under the hood. The main squeeze for the multi-drive/multi-boot platform is the '12 Mac Pro . . . overall still plenty fast for my needs, but it seemed to have difficulty processing the large downloads and upgrades of so many packages yesterday??? don’t know if that was server-side stuff during the day here in SoCal, and then late afternoon it went fast and smooth on the '20 Gazelle 15 . . . etc.
We used to have to do “modesetting” to get linux to run on PPC Macs ten or so years back, configure our own Xorg.config file and so forth . . . mess with the video params, just to get “out of the blackness” . . . thankfully haven’t had to mess with that in some years . . . things generally run fine in the Intel based cpu linux editions.
LOL . . . back in TW this morning to run os-prober to get grub listings current . . . and after yesterday’s 2200+ package upgrade, today, another 115 packages to install . . . going slow on the download, etc.
Today another 447 packages to upgrade in TW . . . so somewhere over 2500 packages for a minor update???
And, after running the upgrade . . . video goes to black screen and would not revive with mouse or shift clicking . . . thought the zyppering had gotten messed up again. Shut down with the power button and on cold boot logged back in and ran a zypper . . . “nothing to do” ???