|
Bugzilla – Full Text Bug Listing |
| Summary: | Failure during Tumbleweed update | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Neil Rickert <nwr10cst-oslnx> |
| Component: | libzypp | Assignee: | E-mail List <zypp-maintainers> |
| Status: | RESOLVED INVALID | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | paul.pgp-7 |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Transcript of update session -- the update was run under "screen -L". | ||
zypper requires libzypp which requires libyaml-cpp0_8. The installed libzypp used libyaml-cpp0_7. According to your screen dump the following was scheduled: Remove libyaml-cpp0_7-0.7.0-2.2.x86_64 Install libyaml-cpp0_8-0.8.0-1.1.x86_64 (openSUSE-Tumbleweed-Oss) Install libzypp-17.31.19-1.2.x86_64 (openSUSE-Tumbleweed-Oss) Install zypper-1.14.62-1.2.x86_64 (openSUSE-Tumbleweed-Oss) The installation was aborted after libyaml was updated, but before libzypp was updated. This is why neither the old nor the new libzypp are working. Aborting the transaction always bears the risk, that the system is not consistent afterwards. This here is one of the worse cases, where the inconsistency affects the installer itself. One of the reasons why we try to download all packages in advance into a _local_ disk cache is your scenario. And even if the transaction had so be aborted it's likely that the packages one needs to repair are already on the local disk then. AFAICS Tumbleweed removed libyaml-cpp0_7, but the package seems still to be present in https://download.opensuse.org/history/20230823/tumbleweed I'd try to call 'rpm -Uvh https://download.opensuse.org/history/20230823/tumbleweed/repo/oss/x86_64/libyaml-cpp0_7-0.7.0-2.3.x86_64.rpm'. In case the old libyaml is no longer installable because too many system libraries were already updated, one could try to do the same for the new libzypp. But this might be tedious because one had to manually resolve missing dependencies and add the packages to the rpm command line. In your case, if you actually want to keep the package cache on NFS, I'd try to do a: zypper up zypper zypper dup Updating zypper before the dup at least minimizes the risk that you lose the installer in case your NFS package cache vanishes during the update. I tend to close the bug as INVALID. There is no guarantee that every component of the system is up and working any time during an upadte. It looks like also the update of the network stack update (at least name resolution) was interrupted in the middle. Thanks for your feedback. I managed to recover the system. I have Tumbleweed installed on a USB drive. So I booted with that, and then mounted the broken system. I then used: zypper --installroot /mnt update zypper libzypp NOTE: this is using the "zypper" from the booted USB system rather than from the broken system This seems to have fixed the problem with "zypper". I was then able to boot into the broken system and run "zypper dup" to complete the update. Yes, there were some scripts that weren't run. I'm hoping those won't matter too much, and that any remaining problems will be fixed over time with future updates. Yes, feel free to close the bug. That's good news. Closing it. |
Created attachment 868999 [details] Transcript of update session -- the update was run under "screen -L". Today, I tried updating Tumbleweed: The following product is going to be upgraded: openSUSE Tumbleweed 20230809-0 -> 20230823-0 This failed about halfway through. I had to abort the update. I then tried again, but "zypper" would not load: zypper: error while loading shared libraries: libyaml-cpp.so.0.7: cannot open shared object file: No such file or directory I'm using "ext4" so I cannot rollback. As best I can tell, there was no network at this point. I'm not sure where that failed. For various reasons, I have configured the package cache to be on an NFS server, with the package cache mounted using "autofs". The major failure appears to be with the update of "autofs", which did not restart -- probably because of network issues. I will attach a transcript of the session. I did try rebooting the partially updated system, using the same kernel as before. This worked, but "zypper" still would not load. I mostly use Leap 15.5, also installed on the same system. So I can manage without Tumbleweed for a few days. I have not decided whether to attempt a rescue or do a clean install. In the meantime, I'm reporting this bug. Hmm, I have other Tumbleweed systems which might run into the same problem if I try to update them.