Updating openSUSE Tumbleweed:
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. hostnamectl The snapshot is :> 20220612 Can I get your insight on what you recommend in doing? The goal for me is to get the machine back up to date if possible. -Thanks
-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.
More or less expected, if you have any repos enabled that do not auto-refresh.
hostnamectl
The snapshot is :> 20220612
Can I get your insight on what you recommend in doing? The goal for me is to get the machine back up to date if possible.
I don't recall if I ever let one go quite that long without a dup, but I have quite some experience with lengths of more than 6 months. This, and experience with urpm, lead me to beginning each dup process with this prequel: zypper ref 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 The idea here is to ensure the package management system and the filesystem are prepared for the task at hand by fully updating them first, trusting that anything in my install list they depend on will come along with them. Once this prequel is done, and all the rest of the packages have been downloaded in advance, any hiccups should nevertheless be able to be somehow dealt with some combination of zypper, rpm, yast and/or logical thought processes. What you might want to consider for something so old is an offline upgrade. It can be as simple as fetching https://download.opensuse.org/tumbleweed/repo/oss/boot/x86_64/loader/initrd https://download.opensuse.org/tumbleweed/repo/oss/boot/x86_64/loader/linux and putting them on a local filesystem, then creating a bootloader stanza to load them. This enables NET installation as long as nothing destroys the existing Grub or their filesystem first. Were live dup to fail hopelessly, a NET upgrade might be able to pick it back up, and if worse came to worse, initialize a fresh installation, without need to download or burn or find something to burn to. I use --download-in-advance explicitly here because my zypp.conf files all contain "commit.downloadMode = DownloadAsNeeded". I don't much care for the concept of filling a filesystem with rpms before performing their installations. That can lead to inability to complete the upgrade, or install a particularly large package, on a / filesystem lacking ample freespace, in addition to increasing filesystem fragmentation. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 03-26-2024 08:12PM, 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.
More or less expected, if you have any repos enabled that do not auto-refresh.
hostnamectl
The snapshot is :> 20220612
Can I get your insight on what you recommend in doing? The goal for me is to get the machine back up to date if possible.
I don't recall if I ever let one go quite that long without a dup, but I have quite some experience with lengths of more than 6 months. This, and experience with urpm, lead me to beginning each dup process with this prequel:
zypper ref 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
Hi, coreutils, rpm, zypper, openSUSE-release, filesystem, libzypp, libsolv-tools all return -> is not available in your repositories. Cannot reinstall, upgrade, or downgrade...... Same..... glibc, mdadm, systemd, udev, aaa_base -> is not available in your repositories..................
The idea here is to ensure the package management system and the filesystem are prepared for the task at hand by fully updating them first, trusting that anything in my install list they depend on will come along with them. Once this prequel is done, and all the rest of the packages have been downloaded in advance, any hiccups should nevertheless be able to be somehow dealt with some combination of zypper, rpm, yast and/or logical thought processes.
Ok great advice on this.
What you might want to consider for something so old is an offline upgrade. It can be as simple as fetching https://download.opensuse.org/tumbleweed/repo/oss/boot/x86_64/loader/initrd https://download.opensuse.org/tumbleweed/repo/oss/boot/x86_64/loader/linux
I would like to try this for 32 bit though if possible.
and putting them on a local filesystem, then creating a bootloader stanza to load them.
Ok I like your idea can you enlighten me a bit more? This enables NET installation as long as nothing destroys the
existing Grub or their filesystem first. Were live dup to fail hopelessly, a NET upgrade might be able to pick it back up, and if worse came to worse, initialize a fresh installation, without need to download or burn or find something to burn to.
The 32 bit NET installation is here -> https://en.opensuse.org/openSUSE:Tumbleweed_installation#LegacyX86_(i586)
I use --download-in-advance explicitly here because my zypp.conf files all contain "commit.downloadMode = DownloadAsNeeded". I don't much care for the concept of filling a filesystem with rpms before performing their installations.
Ok, I was not aware of this before. So when you pass: zypper dup on your machine one updated rpm package at a time gets pulled in and immediately installed (I'll try it out)? The default zypper behavior seems to be to download the updated rpm/rpms and then install them. That can lead to inability to complete the upgrade, or install
a particularly large package, on a / filesystem lacking ample freespace, in addition to increasing filesystem fragmentation.
Well this is very good advice. Please feel free to touch on anything you may have missed here also.
-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: http://download.opensuse.org/ports/i586/tumbleweed/
What you might want to consider for something so old is an offline upgrade. It can be as simple as fetching https://download.opensuse.org/tumbleweed/repo/oss/boot/x86_64/loader/initrd https://download.opensuse.org/tumbleweed/repo/oss/boot/x86_64/loader/linux
I would like to try this for 32 bit though if possible.
and putting them on a local filesystem, then creating a bootloader stanza to load them.
Ok I like your idea can you enlighten me a bit more?
This is a redacted stanza for use with Grub Legacy: title Install openSUSE TW download.opensuse.org kernel (hd0,2)/stw/linux showopts install=http://download.opensuse.org/distribution/tumbleweed/repo/oss hostname=myhost ifcfg=*="hostIP/24,gatewayIP,8.8.8.8 8.8.4.4,mylocal.net" net.ifnames=0 ipv6.disable=1 noresume vga=791 video=1440x900@60 3 nomodeset kexec_reboot=0 BrokenModules=floppy lang=en keytable=us Upgrade=1 textmode=1 initrd (hd0,2)/stw/initrd For 32bit, linux and initrd come from: http://download.opensuse.org/ports/i586/tumbleweed/repo/oss/boot/i386/loader... I save them on a native filesystem on /dev/sda3.
The 32 bit NET installation is here -> https://en.opensuse.org/openSUSE:Tumbleweed_installation#LegacyX86_(i586)
Whenever possible, I download from mirrors, not web pages: http://download.opensuse.org/ports/i586/tumbleweed/iso/ -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 03-27-2024 12:09AM, 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 I could not enter emergency mode or isolate graphical target so I passed zypper dup in Konsole. 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. 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?
What you might want to consider for something so old is an offline upgrade. It can be as simple as fetching https://download.opensuse.org/tumbleweed/repo/oss/boot/x86_64/loader/initrd https://download.opensuse.org/tumbleweed/repo/oss/boot/x86_64/loader/linux
I would like to try this for 32 bit though if possible.
and putting them on a local filesystem, then creating a bootloader stanza to load them.
Ok I like your idea can you enlighten me a bit more?
This is a redacted stanza for use with Grub Legacy:
title Install openSUSE TW download.opensuse.org kernel (hd0,2)/stw/linux showopts install=http://download.opensuse.org/distribution/tumbleweed/repo/oss hostname=myhost ifcfg=*="hostIP/24,gatewayIP,8.8.8.8 8.8.4.4,mylocal.net" net.ifnames=0 ipv6.disable=1 noresume vga=791 video=1440x900@60 3 nomodeset kexec_reboot=0 BrokenModules=floppy lang=en keytable=us Upgrade=1 textmode=1 initrd (hd0,2)/stw/initrd
For 32bit, linux and initrd come from: http://download.opensuse.org/ports/i586/tumbleweed/repo/oss/boot/i386/loader...
I save them on a native filesystem on /dev/sda3.
This is very good but perhaps to advanced for me.
The 32 bit NET installation is here -> https://en.opensuse.org/openSUSE:Tumbleweed_installation#LegacyX86_(i586)
Whenever possible, I download from mirrors, not web pages: http://download.opensuse.org/ports/i586/tumbleweed/iso/
Thank you for this information about mirrors.
-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, 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.
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.
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 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. 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 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. 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. It's possible that one or more might depend on i+ | filesystem | package | 84.87-15.2 | i586 | OSS having been installed first. 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. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
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
-pj composed on 2024-03-28 02:41 (UTC-0500):
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? ...
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
Given working network, putting the following all on one line at a shell prompt may be all that's needed to get zypper dup to run again: rpm -Uvh http://download.opensuse.org/ports/i586/tumbleweed/repo/oss/i586/libzypp-17.... http://download.opensuse.org/ports/i586/tumbleweed/repo/oss/i586/zypper-1.14... rpm -Uvh --nodeps http:... may be required due to other packages depending on them not yet upgraded. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 03-28-2024 06:39AM, Felix Miata wrote:
-pj composed on 2024-03-28 02:41 (UTC-0500):
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? ...
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
Given working network, putting the following all on one line at a shell prompt may be all that's needed to get zypper dup to run again:
rpm -Uvh http://download.opensuse.org/ports/i586/tumbleweed/repo/oss/i586/libzypp-17.... http://download.opensuse.org/ports/i586/tumbleweed/repo/oss/i586/zypper-1.14...
rpm -Uvh --nodeps http:... may be required due to other packages depending on them not yet upgraded.
Your suggestion seems to have worked correctly here for the machine in question. Current repos and kernel are below. :~> zypper lr -ua Repository priorities in effect: (See 'zypper lr -P' for details) 90 (raised priority) : 1 repository 99 (default priority) : 5 repositories # | Alias | Name | Enabled | GPG Check | Refresh | URI --+----------------------------------+----------------------------------------+---------+-----------+---------+------------------------------------------------------------------------------- 1 | download.opensuse.org-non-oss | Main Repository (NON-OSS) | Yes | (r ) Yes | Yes | http://download.opensuse.org/ports/i586/tumbleweed/repo/non-oss/ 2 | download.opensuse.org-oss | Main Repository (OSS) | Yes | (r ) Yes | Yes | http://download.opensuse.org/ports/i586/tumbleweed/repo/oss/ 3 | download.opensuse.org-tumbleweed | Main Update Repository | Yes | (r ) Yes | Yes | http://download.opensuse.org/ports/i586/update/tumbleweed/ 4 | libdvdcss | libdvdcss | Yes | (r ) Yes | Yes | http://opensuse-guide.org/repo/openSUSE_Tumbleweed/ 5 | openSUSE-20210307-0 | openSUSE-20210307-0 | No | ---- | ---- | http://download.opensuse.org/tumbleweed/repo/oss 6 | openSUSE_Tumbleweed | Open H.264 Codec (openSUSE Tumbleweed) | Yes | (r ) Yes | Yes | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed 7 | packman-essentials | packman-essentials | Yes | (r ) Yes | Yes | https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentia... 8 | repo-debug | openSUSE-Tumbleweed-Debug | No | ---- | ---- | http://download.opensuse.org/debug/tumbleweed/repo/oss/ 9 | repo-source | openSUSE-Tumbleweed-Source | No | ---- | ---- | http://download.opensuse.org/source/tumbleweed/repo/oss/ paul@paul-HP-Mini-311-1000:~> sudo zypper dup Retrieving repository 'packman-essentials' metadata ......................................................................................................................................[done] Building repository 'packman-essentials' cache ...........................................................................................................................................[done] Loading repository data... Reading installed packages... Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Computing distribution upgrade... The following item is locked and will not be changed by any action: Available: Mesa-dri-nouveau Nothing to do. HP-Mini-311-1000:~> uname -r 6.7.7-1-pae HP-Mini-311-1000:~> Thank you for your advanced help with this situation. Are you aware of other issues that I have possibly overlooked since upgrading the packages? -Best Regards
-pj composed on 2024-03-30 10:35 (UTC-0500):
Felix Miata wrote:
Given working network, putting the following all on one line at a shell prompt may be all that's needed to get zypper dup to run again:
rpm -Uvh http://download.opensuse.org/ports/i586/tumbleweed/repo/oss/i586/libzypp-17.... http://download.opensuse.org/ports/i586/tumbleweed/repo/oss/i586/zypper-1.14...
rpm -Uvh --nodeps http:... may be required due to other packages depending on them not yet upgraded.
Your suggestion seems to have worked correctly here for the machine in question.
Nice to hear! :D ...
The following item is locked and will not be changed by any action: Available: Mesa-dri-nouveau
I don't recall the history of why this was locked for you. If the package is installed, keeping it locked could eventually prevent upgrades of other Mesa* packages.
Nothing to do. HP-Mini-311-1000:~> uname -r 6.7.7-1-pae HP-Mini-311-1000:~>
Thank you for your advanced help with this situation. Are you aware of other issues that I have possibly overlooked since upgrading the packages?
Be sure the following are installed: liblzma5-5.6.1.revertto5.4-3.2.i586.rpm xz-5.6.1.revertto5.4-3.2.i586.rpm If they aren't, you need to do another zypper dup. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
* Felix Miata <mrmazda@earthlink.net> [01-01-70 12:34]: ...
Be sure the following are installed:
liblzma5-5.6.1.revertto5.4-3.2.i586.rpm xz-5.6.1.revertto5.4-3.2.i586.rpm
If they aren't, you need to do another zypper dup.
*only* x86_64 was affected. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
* -pj via openSUSE Users <users@lists.opensuse.org> [03-28-24 00:31]:
zypper now broke somehow...
I changed /etc/zypp/zypp.conf line 351, from -> ## commit.downloadMode = to -> commit.downloadMode = DownloadAsNeeded
I could not enter emergency mode or isolate graphical target so I passed zypper dup in Konsole. 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.
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.
you were advised to "download in advance" to preclude this type of problem. zypper -v ref ; zypper -v dup -d -l && zypper -v dup -l then if zypper or one of it's dependencies changes, it does not hang your system. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Op woensdag 27 maart 2024 02:12:40 CET schreef Felix Miata:
-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.
More or less expected, if you have any repos enabled that do not auto-refresh.
hostnamectl
The snapshot is :> 20220612
Can I get your insight on what you recommend in doing? The goal for me is to get the machine back up to date if possible.
I don't recall if I ever let one go quite that long without a dup, but I have quite some experience with lengths of more than 6 months. This, and experience with urpm, lead me to beginning each dup process with this prequel:
zypper ref 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
The idea here is to ensure the package management system and the filesystem are prepared for the task at hand by fully updating them first, trusting that anything in my install list they depend on will come along with them. Once this prequel is done, and all the rest of the packages have been downloaded in advance, any hiccups should nevertheless be able to be somehow dealt with some combination of zypper, rpm, yast and/or logical thought processes.
What you might want to consider for something so old is an offline upgrade. It can be as simple as fetching https://download.opensuse.org/tumbleweed/repo/oss/boot/x86_64/loader/initrd https://download.opensuse.org/tumbleweed/repo/oss/boot/x86_64/loader/linux and putting them on a local filesystem, then creating a bootloader stanza to load them. This enables NET installation as long as nothing destroys the existing Grub or their filesystem first. Were live dup to fail hopelessly, a NET upgrade might be able to pick it back up, and if worse came to worse, initialize a fresh installation, without need to download or burn or find something to burn to.
I use --download-in-advance explicitly here because my zypp.conf files all contain "commit.downloadMode = DownloadAsNeeded". I don't much care for the concept of filling a filesystem with rpms before performing their installations. That can lead to inability to complete the upgrade, or install a particularly large package, on a / filesystem lacking ample freespace, in addition to increasing filesystem fragmentation. This is definitely not the way to deal with TW. Unless you have an unlimited amount of spare time.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board openSUSE Forums Team
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.
hostnamectl
The snapshot is :> 20220612
Can I get your insight on what you recommend in doing? The goal for me is to get the machine back up to date if possible.
-Thanks Can you please be more clear and support your statement with output on
Op woensdag 27 maart 2024 00:56:09 CET schreef -pj via openSUSE Users: paste.opensuse.org then put the link here? This for: zypper lr -d sudo zypper ref && sudo zypper dup -- Gertjan Lettink a.k.a. Knurpht openSUSE Board openSUSE Forums Team
* Knurpht-openSUSE <knurpht@opensuse.org> [03-26-24 21:32]:
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.
hostnamectl
The snapshot is :> 20220612
Can I get your insight on what you recommend in doing? The goal for me is to get the machine back up to date if possible.
-Thanks Can you please be more clear and support your statement with output on
Op woensdag 27 maart 2024 00:56:09 CET schreef -pj via openSUSE Users: paste.opensuse.org then put the link here? This for: zypper lr -d sudo zypper ref && sudo zypper dup
perhaps better and safer: zypper -v ref ; zypper -v dup -d -l && zypper -v dup -l -y especially after being so remiss in updating no problems with zypper changing versions mid update, etc, etc -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 03-26-2024 08:30PM, Knurpht-openSUSE wrote:
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.
hostnamectl
The snapshot is :> 20220612
Can I get your insight on what you recommend in doing? The goal for me is to get the machine back up to date if possible.
-Thanks Can you please be more clear and support your statement with output on
Op woensdag 27 maart 2024 00:56:09 CET schreef -pj via openSUSE Users: paste.opensuse.org then put the link here? This for: zypper lr -d sudo zypper ref && sudo zypper dup
Ok, here is the information requested: https://paste.opensuse.org/pastes/00cb1dd5f698
Ok, here is the information requested:
https://paste.opensuse.org/pastes/00cb1dd5f698 Was this ever updated? It has an install image from 20210307 which is 4 years
Op woensdag 27 maart 2024 03:53:25 CET schreef -pj via openSUSE Users: old. I suggest you download a new image and do a fresh install. A dup is not going to work, too many changes since the last dup. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board openSUSE Forums Team
On 03-26-2024 09:59PM, Knurpht-openSUSE wrote:
Ok, here is the information requested:
https://paste.opensuse.org/pastes/00cb1dd5f698 Was this ever updated? It has an install image from 20210307 which is 4 years
Op woensdag 27 maart 2024 03:53:25 CET schreef -pj via openSUSE Users: old. I suggest you download a new image and do a fresh install. A dup is not going to work, too many changes since the last dup.
Yes, this machine was updated but stored for perhaps 1.5 or so years. I do not have alot of configuration modifications from default on this machine so perhaps it is best to fresh install.
participants (4)
-
-pj -
Felix Miata -
Knurpht-openSUSE -
Patrick Shanahan