On 03-28-2024 01:12AM, Felix Miata wrote:
-pj composed on 2024-03-27 23:29 (UTC-0500):
Felix Miata wrote:
-pj composed on 2024-03-26 23:27 (UTC-0500):
Felix Miata wrote:
-pj composed on 2024-03-26 18:56 (UTC-0500):
Hi, I have an HP-Mini-311 32 bit laptop with openSUSE Tumbleweed installed. The machine has not been started for over a year. Today I started the machine.
zypper --download-only
Results in many many problems.
Highly likely you didn't give a thought to updating your repo URLs. TW switched from a regular release to a port, so all its standard repos acquired a new root URL quite a while back:
You were right about the repositories. I changed them to the ports you suggested. I referenced the link you provided and then copied off of my current 32 bit laptop which is using the port repos. I should have tried sooner but I am not an advanced user and my mind spins easily.
zypper now broke somehow...
I changed /etc/zypp/zypp.conf line 351, from -> ## commit.downloadMode = to -> commit.downloadMode = DownloadAsNeeded
Likely a crippling idea for your situation. If you are able to boot but don't have network working,
Network is functional, at this time the machine is connected to the modem wireless; ping is functional. Was a huge mistake that I made then not passing the following? zypper -v in --download-in-advance rpm zypper libzypp libsolv-tools openSUSE-release coreutils filesystem zypper -v in --download-in-advance device-mapper glibc mdadm systemd udev aaa_base I removed "--download-in-advance" after the modification to zypp.conf . My thought was that the command was failing due to the snapshot being so dated, or stale a better word. how would be able to get back to doing anything useful? You'd
need another computer to download, then transfer files between computers without any network, to try to fix whatever needs fixing to enable proceeding.
Ok
I could not enter emergency mode or isolate graphical target so I passed zypper dup in Konsole.
Another crippler. If Plasma or X crashes, dup gets aborted, potentially in an unrecoverable state.
Nothing in this prior attempt concerning Plasma, or x appeared to have crashed. zypper just appeared to be stuck (couldn't fetch).
There were 2900 or so updates with 3 problems which had solutions....zypper started fetching and installing for a few minutes.....
I went to sleep because this machine is slow.....I returned to the machine to find zypper halted with options to retry, ignore etc..... I attempted to retry with no success about 4 times. I did not know what to do and then shut off the machine.
No one with a basic understanding of how package management has to work should give up so quickly. openSUSE is a multiuser operating system. If one login is hung, there are others to use to cope. You needed to determine which other selection to try instead, very likely ignore, to keep the dup process from getting terminated.
I did not ignore and instead canceled possibly creating a larger disaster. I did not know to try to attempt to proceed with the dup process and that it could potentially become fatal by canceling as such. I did create a Snapper snapshot prior to attempting this. systemctl --failed cups.path failed failed chronyd.service failed failed cups.service failed failed snapper-cleanup.service failed failed snapper-timeline.service failed failed cups.socket failed failed
I turned on the machine and logged into KDE. I opened Konsole. zypper lr -ua
zypper: error while loading shared libraries: librpm.so.9: cannot open shared object file: No such file or directory.
What happened here?
You probably painted yourself to the edge of a cliff. What seems likely is you failed to employ anything like the prequel provided in my first thread reply to get package management upgraded separately and first.
I have made a number of mistakes yes. I do acknowledge that I have made mistakes which I have no idea about also. The current version is
librpm.so.10.0.2 provided by rpm-4.19.1.1-3.1.i586.rpm. It looks like zypper has been upgraded but rpm not.
I expect you need to have these installed as an absolute minimum to be able to proceed: S | Name | Type | Version | Arch | Repository ---+---------------+---------+--------------+------+----------- i+ | libsolv-tools | package | 0.7.28-1.4 | i586 | OSS i+ | libzypp | package | 17.31.31-1.3 | i586 | OSS i+ | rpm | package | 4.19.1.1-3.1 | i586 | OSS i+ | zypper | package | 1.14.68-1.5 | i586 | OSS
rpm -qa | grep libsolv-tools libsolv-tools-0.7.28-1.4 rpm -qa | grep libzypp libzypp-17.30.0-1.5.i586 <- lower version rpm -qa | grep rpm rpm-4.19.1.1-3.1.i586 rpm -qa | grep zypper zypper-1.14.52-1.4.i586 <- lower version
That zypper was able to run at all seems a possibly good sign. If they're not all installed now, as that seems to be the case, I doubt there's any likelihood the installation can proceed, unless you can manage to get onto the system what all contain. IOW, the message suggests the new rpm package didn't get fully installed, if any of it at all. You can try upgrading rpm using rpm to fix it.
You mean manually installing the rpms asked for by zypper and/or the lower versions shown above? If it refuses
because of a stated dependency, then you'd need to try the dep and rpm in one rpm transaction, which in turn could require another, and another, and...., in one transaction doing 3 or 7 or 13 rpms at once. That might be impossible, in which case you could try manually extracting the required binary(s) from rpm and copying them into their target location(s). Failing that, fresh installation time.
Oh
It's possible that one or more might depend on i+ | filesystem | package | 84.87-15.2 | i586 | OSS having been installed first.
rpm -qa | grep filesystem filesystem-84.87-15.2.i586
If your last upgrade preceded usrmerge, around May 2021, I suggest going straight to fresh installation. If in / you have symlinks instead of directories for /bin/, /lib/ & /sbin/ then you should be past usrmerge.
The last upgrade was post usrmerge I believe in / has: bin -> usr/bin lib -> usr/lib sbin -> /usr/sbin -Best Regards