Zypper freezes at %posttrans after dup(then somehow finishes on next boot?)

English Install/Boot/Login
1

Last night I did a zypper dup installing snapshot 20241009 which included the new kernel 6.11.2-1, the updated 550 Nvidia drivers, and 600+ other packages. Upon reaching the various posttrans results, zypper locked up. After attempting a control+c, I got the ‘zypper is cleaning up’ will exit gracefully as soon as possible message. It would remain in that state for the next 24 hours with no change. I was unsuccessful at finding which process was holding zypper after some searching. After giving up and fearing the fact that I might now have a broken system upon restart, I resided to that fact and rebooted.

Upon the reboot, I was surprised to find that everything was working as normal, and when launching

journalctl -f

I was greeted by this:

Oct 11 23:43:23 TheNexus zypper[2322]: dracut[I]: Module ‘systemd-networkd’ will not be installed, because command ‘/usr/lib/systemd/systemd-networkd-wait-online’ could not be found!
Oct 11 23:43:23 TheNexus zypper[2322]: dracut[I]: Module ‘systemd-pcrphase’ will not be installed, because command ‘/usr/lib/systemd/systemd-pcrextend’ could not be found!
Oct 11 23:43:23 TheNexus zypper[2322]: dracut[I]: Module ‘systemd-portabled’ will not be installed, because command ‘portablectl’ could not be found!
Oct 11 23:43:23 TheNexus zypper[2322]: dracut[I]: Module ‘systemd-portabled’ will not be installed, because command ‘/usr/lib/systemd/systemd-portabled’ could not be found!
Oct 11 23:43:23 TheNexus zypper[2322]: dracut[I]: Module ‘systemd-resolved’ will not be installed, because command ‘resolvectl’ could not be found!
Oct 11 23:43:23 TheNexus zypper[2322]: dracut[I]: Module ‘systemd-resolved’ will not be installed, because command ‘/usr/lib/systemd/systemd-resolved’ could not be found!
Oct 11 23:43:23 TheNexus zypper[2322]: dracut[I]: Module ‘rngd’ will not be installed, because command ‘rngd’ could not be found!
Oct 11 23:43:23 TheNexus zypper[2322]: dracut[I]: Module ‘connman’ will not be installed, because command ‘connmand’ could not be found!
Oct 11 23:43:23 TheNexus zypper[2322]: dracut[I]: Module ‘connman’ will not be installed, because command ‘connmanctl’ could not be found!
Oct 11 23:43:23 TheNexus zypper[2322]: dracut[I]: Module ‘connman’ will not be installed, because command ‘connmand-wait-online’ could not be found!
Oct 11 23:43:24 TheNexus zypper[2322]: dracut[I]: Module ‘tpm2-tss’ will not be installed, because command ‘tpm2’ could not be found!
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: Module ‘biosdevname’ will not be installed, because command ‘biosdevname’ could not be found!
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: Module ‘memstrack’ will not be installed, because command ‘memstrack’ could not be found!
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: memstrack is not available
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: If you need to use rd.memdebug>=4, please install memstrack and procps-ng
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: Module ‘systemd-pcrphase’ will not be installed, because command ‘/usr/lib/systemd/systemd-pcrextend’ could not be found!
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: Module ‘systemd-portabled’ will not be installed, because command ‘portablectl’ could not be found!
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: Module ‘systemd-portabled’ will not be installed, because command ‘/usr/lib/systemd/systemd-portabled’ could not be found!
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: Module ‘systemd-resolved’ will not be installed, because command ‘resolvectl’ could not be found!
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: Module ‘systemd-resolved’ will not be installed, because command ‘/usr/lib/systemd/systemd-resolved’ could not be found!
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: Module ‘rngd’ will not be installed, because command ‘rngd’ could not be found!
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: Module ‘connman’ will not be installed, because command ‘connmand’ could not be found!
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: Module ‘connman’ will not be installed, because command ‘connmanctl’ could not be found!
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: Module ‘connman’ will not be installed, because command ‘connmand-wait-online’ could not be found!
Oct 11 23:43:26 TheNexus zypper[2322]: dracut[I]: Module ‘tpm2-tss’ will not be installed, because command ‘tpm2’ could not be found!
Oct 11 23:43:28 TheNexus zypper[2322]: dracut[I]: Module ‘memstrack’ will not be installed, because command ‘memstrack’ could not be found!
Oct 11 23:43:28 TheNexus zypper[2322]: dracut[I]: memstrack is not available
Oct 11 23:43:28 TheNexus zypper[2322]: dracut[I]: If you need to use rd.memdebug>=4, please install memstrack and procps-ng
Oct 11 23:43:29 TheNexus zypper[2322]: dracut[I]: *** Including module: systemd ***
Oct 11 23:43:29 TheNexus zypper[2322]: dracut[I]: *** Including module: systemd-initrd ***
Oct 11 23:43:29 TheNexus zypper[2322]: dracut[I]: *** Including module: i18n ***
Oct 11 23:43:29 TheNexus zypper[2322]: dracut[I]: *** Including module: drm ***
Oct 11 23:43:31 TheNexus zypper[2322]: dracut[I]: *** Including module: plymouth ***
Oct 11 23:43:32 TheNexus zypper[2322]: dracut[I]: *** Including module: btrfs ***
Oct 11 23:43:32 TheNexus zypper[2322]: dracut[I]: *** Including module: crypt ***
Oct 11 23:43:32 TheNexus zypper[2322]: dracut[I]: *** Including module: dm ***
Oct 11 23:43:32 TheNexus zypper[2322]: dracut[I]: *** Including module: kernel-modules ***
Oct 11 23:43:35 TheNexus zypper[2322]: dracut[I]: *** Including module: kernel-modules-extra ***
Oct 11 23:43:35 TheNexus zypper[2322]: dracut[I]: *** Including module: lvm ***
Oct 11 23:43:35 TheNexus zypper[2322]: dracut[I]: *** Including module: resume ***
Oct 11 23:43:35 TheNexus zypper[2322]: dracut[I]: *** Including module: rootfs-block ***
Oct 11 23:43:35 TheNexus zypper[2322]: dracut[I]: *** Including module: suse-btrfs ***
Oct 11 23:43:35 TheNexus zypper[2322]: dracut[I]: *** Including module: suse-xfs ***
Oct 11 23:43:35 TheNexus zypper[2322]: dracut[I]: *** Including module: terminfo ***
Oct 11 23:43:35 TheNexus zypper[2322]: dracut[I]: *** Including module: udev-rules ***
Oct 11 23:43:36 TheNexus zypper[2322]: dracut[I]: *** Including module: dracut-systemd ***
Oct 11 23:43:36 TheNexus zypper[2322]: dracut[I]: *** Including module: ostree ***
Oct 11 23:43:36 TheNexus zypper[2322]: dracut[I]: *** Including module: usrmount ***
Oct 11 23:43:36 TheNexus zypper[2322]: dracut[I]: *** Including module: base ***
Oct 11 23:43:36 TheNexus zypper[2322]: dracut[I]: *** Including module: fs-lib ***
Oct 11 23:43:36 TheNexus zypper[2322]: dracut[I]: *** Including module: shutdown ***
Oct 11 23:43:36 TheNexus zypper[2322]: dracut[I]: *** Including module: suse ***
Oct 11 23:43:36 TheNexus zypper[2322]: dracut[I]: *** Including module: suse-initrd ***
Oct 11 23:43:36 TheNexus zypper[2322]: dracut[I]: *** Including modules done ***
Oct 11 23:43:36 TheNexus zypper[2322]: dracut[I]: *** Installing kernel module dependencies ***
Oct 11 23:43:36 TheNexus zypper[2322]: dracut[I]: *** Installing kernel module dependencies done ***
Oct 11 23:43:36 TheNexus zypper[2322]: dracut[I]: *** Resolving executable dependencies ***
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: *** Resolving executable dependencies done ***
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: *** Hardlinking files ***
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: *** Hardlinking files done ***
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: *** Generating early-microcode cpio image ***
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: *** Constructing AuthenticAMD.bin ***
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: *** Store current command line parameters ***
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: Stored kernel commandline:
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: rd.driver.pre=btrfs
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: rd.luks.uuid=luks-bb9c6198-4cba-4ebd-96c0-7bbb335069a8
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: rd.lvm.lv=system/root rd.lvm.lv=system/swap
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: resume=UUID=a4fca568-fef8-4beb-b7b3-3809eac765ac
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: root=UUID=358c5f61-4abe-4f03-a742-a057d284e2b5 rootfstype=btrfs rootflags=rw,relatime,ssd,space_cache=v2,subvolid=1101,subvol=/@/.snapshots/801/snapshot,subvol=@/.snapshots/801/snapshot
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: *** Stripping files ***
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: *** Stripping files done ***
Oct 11 23:43:37 TheNexus zypper[2322]: dracut[I]: *** Creating image file ‘/boot/initrd-6.10.11-1-default’ ***
Oct 11 23:43:38 TheNexus zypper[2322]: dracut[I]: *** Creating initramfs image file ‘/boot/initrd-6.10.11-1-default’ done ***
Oct 11 23:43:38 TheNexus [RPM][18722]: erase virtualbox-kmp-default-7.0.20_k6.10.8_1-1.6.x86_64: success
Oct 11 23:43:38 TheNexus [RPM][18722]: Transaction ID 6709f056 finished: 0
Oct 11 23:43:38 TheNexus zypper[2322]: .done]
Oct 11 23:43:38 TheNexus [RPM][25560]: Transaction ID 6709f06a started
Oct 11 23:43:38 TheNexus [RPM][25560]: erase kernel-devel-6.10.11-1.1.noarch: success
Oct 11 23:43:39 TheNexus [RPM][25560]: erase kernel-devel-6.10.11-1.1.noarch: success
Oct 11 23:43:39 TheNexus [RPM][25560]: Transaction ID 6709f06a finished: 0
Oct 11 23:43:39 TheNexus zypper[2322]: (8/9) Removing: kernel-devel-6.10.11-1.1.noarch […done]
Oct 11 23:43:39 TheNexus [RPM][25561]: Transaction ID 6709f06b started
Oct 11 23:43:39 TheNexus [RPM][25561]: erase kernel-default-6.10.11-1.1.x86_64: success
Oct 11 23:43:47 TheNexus macosx-prober[26543]: debug: /dev/nvme1n1p1 is not an HFS+ partition: exiting
Oct 11 23:43:48 TheNexus [RPM][25561]: erase kernel-default-6.10.11-1.1.x86_64: success
Oct 11 23:43:48 TheNexus [RPM][25561]: Transaction ID 6709f06b finished: 0
Oct 11 23:43:48 TheNexus zypper[2322]: (9/9) Removing: kernel-default-6.10.11-1.1.x86_64 […done]
Oct 11 23:43:48 TheNexus zypper[2322]: Running post-transaction scripts […done]

So, there doesn’t seem to be a problem, but am I right in interpreting that zypper finished the remaining transactions after the restart? Because that’s what it looks like, and I was unaware that zypper could do this. There doesn’t seem to be any breakage that I have seen, and I tested zypper to make sure it is still working and all appears well.

While there is not really a problem here, I would like to know the cause of the freeze, and was wondering if the ability to finish post upgrade like this is something zypper is capable of? If so, great, but I’ve never read about anybody else having a similar experience.

Would love some feedback.

2

I wonder what would have happened if you had opened another tab in konsole, bash terminal and zypper -vvv dup before powercycling.

3

Nothing unfortunately, as trying to invoke zypper in another terminal/tab will only yield:

System management is locked by the application with pid ****** (zypper).
Close this application before trying again.

It would have been nice if I ran the original dup verbose, but alas, I generally don’t most times.

4

Glad your machine is without issue from this. A safer approach when using zypper is zypper -vvv dup --download-only (I haven’t been doing this often myself).

DownloadAsNeeded    Alternating download and install. Packages are
##                      cached just to avid CD/DVD hopping. This is the
##                      traditional behaviour.

An advanced user explained their technique on the mailing list as follows:

‘quote’
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 rpm, 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.

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
‘end quote’

5

You know what this command is doing? It only downloads packages but does not install them. So it is not a “safer approach”. The standard setting of zypper dup is to download all packages before starting the installation. You only increase the complexity with your approach, as you now need to issue two zypper dups to install package updates/upgrades…one for downloading and one for installation.

So how does this help the TO with a postinstall/posttrans script which hangs forever? It is completely unrelated…

6

:cold_face:

7

:cold_face:

quoi???

8

Apologies, > [quote=“hui, post:5, topic:179338”]
So it is not a “safer approach”.
[/quote]

It is a safer approach (you have your opinion). The packages are then on the machine and can be installed with a zypper -v dup. Also the quote provide’s an even safer configuration option by adding the commit.downloadMode = DownloadAsNeeded to /etc/zypp/zypp.conf

I was taking the time to read the post and responded with information I thought was helpful.

-Good Luck!

9

It shows you the current messages. How exactly does it help to diagnose what happened before reboot?

No. Zypper was told to purge unused kernels and did it. It apparently resulted in removal of KMPs which depended on the deleted kernels. But it has nothing to do with whatever issues you had before reboot.

Check logs before reboot, at the time your system hung.

10

It is not only a opinion. It is not safer. Read up on the documentation and try to understand what the various zypper options and settings are doing. --download-only only downloads packages (as the command suggests when you read it…). zypper dup downloads all packages before starting the installation. When the download fails, the installation process doesn’t start. So there is no additional safety by only downloading the packages. Only additional work and complexity.

And i also recommend to you to read the complete background and information which is provided within zypp.conf and zypper.conf

DownloadAsNeeded
Alternating download and install. Packages are
cached just to avid CD/DVD hopping. This is the
traditional behaviour.

If you read Felix’s ML post you would see that he uses two contradicting settings. In zypp conf he set the standard to DownloadAsNeeded but overides it with each zypper dup as he uses DownloadOnly

1 Like
11

Umm…thanks? I think you may have been responding to two different people, as I did nothing to invoke the ‘cold’ emoji.

12

Small correction: the last command he uses is DownloadInAdvance
But nevertheless, severall contradicting and unrelated zypper options where mixed here in this thread.

They don‘t help the TO.

@Android_Gynous Doing zypper dup in a terminal session (text only) will decrease the risk of interfering of a running GUI session or process which can cause hangs or even crashes. This is also mentioned in the Tumbleweed SDB. And forcefully ending an upgrade process via ctrl+c asks for trouble. This should be avoided.

13

I’m sure if I tried to find that particular post I wouldn’t succeed until after doing so became unequivocally moot. I suspect I didn’t report the whole story about how my process came about. URPMI on Mandrake/Mandriva/Mageia automatically updates package management packages before any others, to it runs, then restarts itself. I very much like that process, but have no idea how to do the same with zypper programmatically. Thus I script package management upgrades, and a little extra, before running an otherwise “normal” up or dup. I’ve since acquired other reasons to continue, but have modified my behavior in part via package caching on my LAN server. For my 40+ TWs and 19 SRs, I bind mount the applicable cache, so downloading from mirrors is drastically reduced. Several months ago, libzypp and/or zypper had a broken dependency caused by a failed dev attempt to improve them (since abandoned) that allowed my script to cause failure of zypper to run again until I manually identified and installed the offender, or reverted one and/or the other of zypper/libzypp. Anyway, the LAN caching avoids the / filesystem fillup, avoids inducing fragmentation, and speeds the dup process. I continue to prefer DownloadAsNeeded conceptually, so normally still do so with Leap, even though it’s an overall slower process. I’ve gone back to using the package management upgrade first script in part because I like to see what changes it contains, or not, rather than having it scroll away too fast to see on the VTs where I do most package management, and from which direct kernel framebuffer scrollback was eliminated over four years ago (kernel 5.7.11 or so was the last having it).

14

When we were using TW, we experienced this, more than once or twice. (BTW - we have since moved all our machines to Leap 15.6).

Here was our process when this event happened.

We would see the hang during “posttrans”, so would do a CTRL-C. Then we’d see the “cleaning up, and exit gracefully…” response.

Our first experience with this, it never exited gracefully … would just sit there with no other response. (no way we’d wait 24 hours :slight_smile: ). You can jump to another CLI and check the process list - nothing was happening.

So, after 30 minutes (more than enough time to exit gracefully, we’d do another CTRL-C … that’s when we’d see the command prompt. It’s that second CTRL-C (sometimes 3rd) that convinces the process to quit.

Next, we would once again execute, “zypper -vvvv dup” and it would continue where it left off previously and finish up with no issues (including the posttrans). No reboots, simply execute zypper again.

So, after that first experience, whenever we saw the hang, we would do a CTRL-C … wait about 30 seconds - no graceful exit? Then do another CTRL-C and start the zypper again.

Haven’t ever experienced this using Leap.

15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.