G'day Tumblers, To be honest, I did not actually read the list before a dup. I often do, but this time I was doing other things and just never got time. I started with a normal dup, but I noticed it was big. So I pre-downloaded it because sometimes I get repo timeoutes. During the day, while I was working (using the laptop I was updating), I ran "zypper dup -l --download-only" I thought, wow, this is huge, maybe I should find out why.. but then it was getting late, so I just ran: zypper -n dup -l Then went to bed. I did it in konsole, with everything running normally. I have a few repos enabled... bh-lenlap:~ # zypper lr -E | wc -l 41 bh-lenlap:~ # Yeah, that is probably not great, but what can I say, I like to live dangerously. And.. It worked great. I did not notice anything. The next day I had to remove a snapshot or two because I was at 99.1% of storage on /, but other than that, nothing to report. If I knew this was what it was I may have run zypper in a VT or even in screen, but thanks to the excellence of the package maintainers, I was left with a working system. It was only *after* reading through the mailing list today I did an "ls -l /" and noticed the change. Wow. There is some real attention to detail there. You guys are absolutely awesome. I am not advocating for a complete lack of caution, but these days zypper seems to rarely crash out IMHO. -- Ben On 7/6/21 10:55 pm, Ludwig Nussel wrote:

Martin Wilck wrote:

...

On Mo, 2021-05-31 at 13:53 +0200, Ludwig Nussel wrote:

...

Due to the full rebuild and activation of gcc11 as default compiler the next snapshot will be a big one, so make sure to have sufficient disk space.

If you are not on btrfs with snapshots and are nervous to break the system you may want to make sure eg busybox-static is installed. So if thing unexpectedly go wrong you have the tools to complete the usrmerge manually. There is no way back.

Is it recommended e.g. to switch to text mode before dup'ing?

Not more than usual IMO. I'd always run zypper in screen or tmux though to make sure it continues in case the GUI dies.

cu Ludwig

-- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ https://protect-au.mimecast.com/s/QIpMCmO50pujzQPjIOMSr9?domain=suse.com SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

Updated on friday without problems. I suspect my issues were caused by ckb-next trying to pull in bash-legacybin as a dependency for some reason and as a moron I agreed without thinking. Without me agreeing to install bash-legacybin the update would've probably went with 0 problems.

* Niklas Haas [06-01-21 18:11]:

This change completely broke my system as well.

...

(1445/7248) Installing: filesystem-15.5-40.2.x86_64 ...................[error] Installation of filesystem-15.5-40.2.x86_64 failed: Error: Subprocess failed. Error: RPM failed: Make a copy of `/bin'. Merge the copy with `/usr/bin'. Clean up duplicates in `/usr/bin'. Make a copy of `/sbin'. Merge the copy with `/usr/sbin'. Clean up duplicates in `/usr/sbin'. Make a copy of `/lib'. Merge the copy with `/usr/lib'. Clean up duplicates in `/usr/lib'. Make a copy of `/lib64'. Merge the copy with `/usr/lib64'. Clean up duplicates in `/usr/lib64'. Switch to new `/usr/bin'. renameat2: Invalid argument Something failed, cleaning up error: lua script failed: [string "%pretrans(filesystem-15.5-40.2.x86_64)"]:37: exit error: filesystem-15.5-40.2.x86_64: install skipped error: filesystem-15.5-40.1.x86_64: erase skipped

Abort, retry, ignore? [a/r/i] (a):

I chose `retry`, which resulted in exactly the same output, followed by `abort`. After this, my system was unusable. Basic commands such as `/bin/ls` etc. did not work.

Luckily, I have zypper configured to make a zfs snapshot immediately prior to any operation, so recovery was as simple as booting into a dracut rescue shell and running `zfs rollback`. (An aside: Apparently the `bootfs.rollback` parameter does not work, I had to do it manually from a shell.)

I think that, quite frankly, such dangerous upgrades that have a high potential for total system destruction need to be communicated to users in a much more visible manner than some obscure mailing list nobody follows. Something like Gentoo's `eselect news` system would be a much better mechanism to communicate breaking changes well in advance. Let's be honest, nobody checks these mailing lists until *after* their system is a brick.

That aside, does anybody know what could be going on? The `renameat2: Invalid argument` command seems like the most obvious suspect. Is it possible that it's requiring some flag that zfs may or may not implement? Is there any work-around, or a way to perform this change manually? (The wiki does not really go into detail here, except elaborating on the existence of a magical-script-that-solves-everything. I would suggest adding some sort of step-by-step instruction for what this script is actually doing, so we can do it by hand, on systems affected by this bug.)

I too had problems and have rebooted to kernel 5.12.4-1-default. My nvidia G04 doesn't give me a full screen. Reinstalled the 4 nvidia packages, nvidia-computeG04 390.143-44.2 nvidia-gfxG04-kmp-default 390.143_k5.12.4_9-44.23 nvidia-glG04 390.143-44.2 x11-video-nvidiaG04 390.143-44.2 didn't help, reverted to 5.12.4-1-default kernel and most appears well. but I had no errors on the zypper dup -- (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 freenode

Some further digging confirms that zfs does not currently implement `renameat2`, it always returns `-EINVAL` if flags is nonzero. The best solution here seems to be to add a fallback path to the rpm script, in case that syscall fails.

I submitted https://build.opensuse.org/request/show/896791

On Tue, 01 Jun 2021 22:00:41 -0400 Neal Gompa wrote:

We don't support filesystems without RENAME_EXCHANGE

I'm not sure what this ambiguous usage of the word "support" means, but for at least one interpretation, accepting my request would make this cease being true. In either case, on systems you *do* support, my patch does not modify the behavior, so it shouldn't matter to you, right?

this code makes the change not atomic and frankly quite scary.

Non-atomic rename is better than unbootable unrecoverable broken system.

Shouldn't you bug the OpenZFS people to implement renameat(2) instead?

I did: https://github.com/openzfs/zfs/issues/2256 OpenZFS not supporting this yet isn't a good reason to brick users' systems, IMO.

On Wed 2021-06-02, Niklas Haas wrote:

Neal Gompa wrote:

...

this code makes the change not atomic and frankly quite scary. Non-atomic rename is better than unbootable unrecoverable broken system.

...

Shouldn't you bug the OpenZFS people to implement renameat(2) instead? I did: https://github.com/openzfs/zfs/issues/2256

OpenZFS not supporting this yet isn't a good reason to brick users' systems, IMO.

I'm a little puzzled by this exchange. Niklas' system got bricked, he debugged the issue, nudged upstream (ZFS in this case) about it *and* submitted a patch to work around the issue in openSUSE until hopefully fixed upstream. His patch does not appear to affect "supported" file systems in openSUSE; it adds a fall back that tries to avoid bricking. It looks to me Niklas has gone out of his way to help others and contribute. That, plus if this helps just one other user, isn't this good? Gerald

On 2021/06/01 19:00, Neal Gompa wrote:

On Tue, Jun 1, 2021 at 9:48 PM Niklas Haas wrote:

...

I submitted https://build.opensuse.org/request/show/896791

We don't support filesystems without RENAME_EXCHANGE, and this code makes the change not atomic and frankly quite scary. Shouldn't you bug the OpenZFS people to implement renameat(2) instead?

--- How would an average end-user have any clue about what file systems support what kernel calls?

On 2021-06-01, Neal Gompa wrote:

On Tue, Jun 1, 2021 at 9:48 PM Niklas Haas wrote:

...

I submitted https://build.opensuse.org/request/show/896791

We don't support filesystems without RENAME_EXCHANGE, and this code makes the change not atomic and frankly quite scary. Shouldn't you bug the OpenZFS people to implement renameat(2) instead?

I submitted a patch for this a while back, which was picked up by another contributor, though sadly the PR has stalled because the new author is busy with other things. I might try to revive the PR[1] again. [1]: https://github.com/openzfs/zfs/pull/9414 -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/

On Friday 2021-06-11 10:03, Aleksa Sarai wrote:

So I think it's fair to say that we *have to* support running on ZFS, or we must publicly state that our distribution cannot run inside containers on the default Ubuntu Server configuration.

"cannot run inside containers that themselves run on unsupported filesystems".

On Fri, Jun 11, 2021 at 4:03 AM Aleksa Sarai wrote:

On 2021-06-01, Neal Gompa wrote:

...

On Tue, Jun 1, 2021 at 9:48 PM Niklas Haas wrote:

...

I submitted https://build.opensuse.org/request/show/896791

We don't support filesystems without RENAME_EXCHANGE, and this code makes the change not atomic and frankly quite scary. Shouldn't you bug the OpenZFS people to implement renameat(2) instead?

I just ran into this bug today, and I realised that this bug actually also affects users who run containers on *different hosts* that have ZFS as the backing filesystem. For instance, running Tumbleweed on Ubuntu (which has ZFS as the default filesystem) will result in this error being triggered. (I personally run LXD containers on openSUSE with a ZFS storage driver, but this same thing would happen with Docker or LXD on Ubuntu or any other distribution with ZFS.)

ZFS is *not* the default on Ubuntu. You have to explicitly select this when setting up disks. I literally just did an Ubuntu installation a couple of days ago for work, and it didn't select ZFS when running through the default installation. And anyway, if you're doing containers, you can blow them away and start over, right? That's the point of containers... RIGHT?! -- 真実はいつも一つ！/ Always, there's only one truth!

On Fr, 2021-06-11 at 18:03 +1000, Aleksa Sarai wrote:

I just ran into this bug today, and I realised that this bug actually also affects users who run containers on *different hosts* that have ZFS as the backing filesystem. For instance, running Tumbleweed on Ubuntu (which has ZFS as the default filesystem) will result in this error being triggered. (I personally run LXD containers on openSUSE with a ZFS storage driver, but this same thing would happen with Docker or LXD on Ubuntu or any other distribution with ZFS.)

You run "zypper dup" in the container? Can't you just update your container image? Of course doing updates in containers ist just fine but "dup" is always kind of dangerous. In this specific case it should be tolerable to require an image update. That said, there's of course no guarantee that no other tools, applications, or scripts would expect RENAME_EXCHANGE to be supported on the root file system. TBH, I have no idea how Ubuntu gets away with it not being supported. It could lead to all kinds of subtle errors on Ubuntu, too. Regards Martin

On Fri, Jun 11, 2021 at 7:15 AM Jan Engelhardt wrote:

On Friday 2021-06-11 12:55, Martin Wilck wrote:

...

On Fr, 2021-06-11 at 18:03 +1000, Aleksa Sarai wrote:

...

I just ran into this bug today, and I realised that this bug actually also affects users who run containers on *different hosts* that have ZFS as the backing filesystem. For instance, running Tumbleweed on Ubuntu (which has ZFS as the default filesystem) will result in this error being triggered. (I personally run LXD containers on openSUSE with a ZFS storage driver, but this same thing would happen with Docker or LXD on Ubuntu or any other distribution with ZFS.)

You run "zypper dup" in the container? Can't you just update your container image?

Not everything runs on orchestration where you can rebuild from scratch. Think systemd-nspawn. There just is no image facility as far as that's concerned. It's just you and a directory tree.

LXD is image based, just like OCI container systems are. -- 真実はいつも一つ！/ Always, there's only one truth!

On 2021-06-11, Martin Wilck wrote:

On Fr, 2021-06-11 at 18:03 +1000, Aleksa Sarai wrote:

...

I just ran into this bug today, and I realised that this bug actually also affects users who run containers on *different hosts* that have ZFS as the backing filesystem. For instance, running Tumbleweed on Ubuntu (which has ZFS as the default filesystem) will result in this error being triggered. (I personally run LXD containers on openSUSE with a ZFS storage driver, but this same thing would happen with Docker or LXD on Ubuntu or any other distribution with ZFS.)

You run "zypper dup" in the container? Can't you just update your container image? Of course doing updates in containers ist just fine but "dup" is always kind of dangerous. In this specific case it should be tolerable to require an image update.

I'm not using Docker, I'm using LXD. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/

I had it written that way first, but as you pointed out, it can get weird when `mv` itself becomes unusable during the exchange. (`mv` is not a shell builtin on bash, unfortunately) I therefore think it's cleaner to have it in the binary, which is not a reusable utility but purpose-built for this script. The name "xmv" doesn't really imply atomicity to begin with, it's still doing what it says on the tin - exchanging two files. To avoid concerns about temp filenames and race conditions and whatnot, another way to handle this might be to unlink the file from the filesystem altogether and then relink that same inode into the FS somehow, but my POSIX-fu is not up to speed with how to accomplish that.

* Joe Salmeri [06-01-21 20:05]:

Hi Ludwig,

Ok, I fixed the problem on my system but it looks like I found something missed in the kernel source packages.

Here is the issue:

20210527 installs kernel 5.12.4-2 with

/usr/lib/modules/5.12.4-2-default/build as a symlink to ../../../usr/src/linux-5.12.4-2-obj/x86_64/default

That symlink is bad and should be to

./../../../usr/src/linux-5.12.4-2-obj/x86_64/default

Since it was a new kernel install, it seems to me that it would not be a UsrMerge bug and instead would be a bug in the kernel-source package.

After recreating the correct symlink using

cd /usr/lib/modules/5.12.4-2-default ln -s ../../../../usr/src/linux-5.12.4-2-obj/x86_64/default build

vmware player 16.1.1 was then able to recompile the vmware kernel modules successfully.

I checked the prior kernel source symlink in /usr/lib/modules/5.12.4-1-default/build and found that it too was wrong so that appears to be something that the UsrMerge migration missed.

Please let me know if you need any other information.

did not help me with G04 nvidia. -- (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 freenode

Hi Andrei, Here are the relevant entries from /var/log/zypp/history: # 2021-06-01 16:44:27 filesystem-15.5-40.2.x86_64.rpm installed ok # Additional rpm output: # Make a copy of `/bin'. # Merge the copy with `/usr/bin'. # Clean up duplicates in `/usr/bin'. # Make a copy of `/sbin'. # Merge the copy with `/usr/sbin'. # Clean up duplicates in `/usr/sbin'. # Make a copy of `/lib'. # Merge the copy with `/usr/lib'. # Clean up duplicates in `/usr/lib'. # Make a copy of `/lib64'. # Merge the copy with `/usr/lib64'. # Clean up duplicates in `/usr/lib64'. # Switch to new `/usr/bin'. # Switch to new `/usr/sbin'. # Switch to new `/usr/lib'. # Switch to new `/usr/lib64'. # Create `/bin' symlink. # Create `/sbin' symlink. # Create `/lib' symlink. # Create `/lib64' symlink. # Clean up backup files. # /usr/bin.usrmerge ... # //bin.usrmerge ... # /usr/sbin.usrmerge ... # //sbin.usrmerge ... # /usr/lib.usrmerge ... # //lib.usrmerge ... # /usr/lib64.usrmerge ... # //lib64.usrmerge ... # Run ldconfig. # 2021-06-01 16:44:27|install|filesystem|15.5-40.2|x86_64||download.opensuse.org-oss_2|e5341f4bdd83fc26d5c3277e4ab2801715e60cb8f59640abada994b6d0f79bfb| 2021-06-01 16:56:11|install|e2fsprogs-devel|1.46.2-3.3|x86_64||download.opensuse.org-oss_2|64af5aa2d3510bb11b53f66cbd846272efe3e0b940e8d666e4c4203fdb3ce78f| # 2021-06-01 16:56:13 kernel-default-devel-5.12.4-2.1.x86_64.rpm installed ok # Additional rpm output: # Changing symlink /usr/src/linux-obj/x86_64/default from ../../linux-5.12.4-1-obj/x86_64/default to ../../linux-5.12.4-2-obj/x86_64/default # 2021-06-01 16:56:13|install|kernel-default-devel|5.12.4-2.1|x86_64||download.opensuse.org-oss_2|14078112e692c1a39b5430527a684bdda4ba2e043f0a281d5f513618d4008baf| 2021-06-01 17:03:44|install|kernel-default|5.12.4-2.1|x86_64||download.opensuse.org-oss_2|518785460737a64940a0ac2f7c490fd356c584f72fc1c343e1e301caa5f71ab6| From that we can see that the filesystem package was installed first (@ 16:44:27), followed by the UsrMerge migration, and then the kernel-default-devel package was installed (@ 16:56). So the new kernel (5.12.4-2) was installed AFTER The UsrMerge migration had already occurred and therefore the link wasn't correct when it was created. It did update the symlink for linux-obj from the old kernel (5.12.4-1) to the new kernel, but the symlink that I reported as broken in the new kernel directory was: /usr/lib/modules/5.12.4-2-default/build and it was broken because it was missing the extra directory level and was fixed when I modified the symlink to add the extra ../ So it would appear that the kernel-default-devel package created the wrong symlink for /usr/lib/modules/5.12.4-2-default/build despite the new kernel being installed after the UsrMerge migration had already occurred. For the older kernel which was installed before UsrMerge I would have expected UsrMerge to fix in link that it broke in /usr/lib/modules/5.12.4-1-default/build Note that the "source" symlink in both /usr/lib/modules/5.12.4-1-default/source /usr/lib/modules/5.12.4-2-default/source also had the same issue in that they both needed the extra directory level added. Overall, I think that the UsrMerge migration went well but it looks like it missed some existing links and it looks like the kernel-default-devel package needs updating for the symlinks I mentioned which were wrong despite being installed after UsrMerge. Another possibility I could think of is that the kernel package did not know that UsrMerge was done because they occurred in the same zypper dup? Your original reply thought they had been installed out of order but we now know that they were installed in the correct order so the programmer in me was trying to come up with another way that the kernel package might create the wrong symlinks. You said to open a bug report if they were installed in the wrong order but since they were installed in the correct order should I still submit the bug report? Regarding this being the tip of the iceberg, is there are reason that those symlinks are created as relative instead of absolute? Also, I have been looking for other bad symlinks but so far no other significant issues have been found so overall I think the process went well. Joe

Thanks very much for your help!

munix9 wrote:

Am 02.06.21 um 02:05 schrieb Joe Salmeri:

...

Hi Ludwig,

Ok, I fixed the problem on my system but it looks like I found something missed in the kernel source packages.

Here is the issue:

20210527 installs kernel 5.12.4-2 with

/usr/lib/modules/5.12.4-2-default/build as a symlink to ../../../usr/src/linux-5.12.4-2-obj/x86_64/default

That symlink is bad and should be to

../../../../usr/src/linux-5.12.4-2-obj/x86_64/default

[...] I have a similar problem with kernel-default-devel-5.12.4-2.1.x86_64 https://bugzilla.opensuse.org/show_bug.cgi?id=1186710

Thanks for the report! A quick workaround is to either replace the stale symlink with an absolute one or "ln -s . /usr/usr" cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

all fine for me too just this i see in the logs... 1673 Jun 02 11:30:35 belial nscd[1848]: 1848 disabled inotify-based monitoring for file `/etc/services': No such file or directory 1674 Jun 02 11:30:35 belial nscd[1848]: 1848 stat failed for file `/etc/services'; will try again later: No such file or directory and few more later but can be from earlier times and I missed it. Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Wed, 2 Jun 2021 at 09:10, Thorsten Kukuk wrote:

On Wed, Jun 02, Bjoern Voigt wrote:

...

Ludwig Nussel wrote:

...

All packages in the distro have been fixed though. Is there a bug report for reporting all packages which are still not converted?

On my system rpcbind is affected (/bin and /sbin is still used):

There is no file in rpcbind according to your output which is in /bin and /usr/bin or /sbin and /usr/sbin. The package is fine.

It is still allowed to install files in /bin or /sbin, but it is not possible to install a file in /bin and have a symlink pointing to it in /usr/bin or the other way around.

Thorsten

...

rpm -qlv rpcbind-1.2.5-6.2.x86_64: -rwxr-xr-x 1 root root 35136 Mai 27 16:37 /bin/rpcinfo -rwxr-xr-x 1 root root 14464 Mai 27 16:37 /sbin/pmap_set2 -rwxr-xr-x 1 root root 55544 Mai 27 16:37 /sbin/rpcbind lrwxrwxrwx 1 root root 14 Mai 27 16:37 /sbin/rpcinfo -> ../bin/rpcinfo -rw-r--r-- 1 root root 498 Mai 27 16:37 /usr/lib/systemd/system/rpcbind.service -rw-r--r-- 1 root root 368 Mai 27 16:37 /usr/lib/systemd/system/rpcbind.socket -rw-r--r-- 1 root root 70 Mai 27 16:37 /usr/lib/sysusers.d/rpc-user.conf lrwxrwxrwx 1 root root 7 Mai 27 16:37 /usr/sbin/rcrpcbind -> service drwxr-xr-x 2 root root 0 Mai 27 16:37 /usr/share/doc/packages/rpcbind -rw-r--r-- 1 root root 106 Aug 15 2018 /usr/share/doc/packages/rpcbind/AUTHORS -rw-r--r-- 1 root root 112 Aug 15 2018 /usr/share/doc/packages/rpcbind/README -rw-r--r-- 1 root root 173 Mai 27 16:37 /usr/share/fillup-templates/sysconfig.rpcbind drwxr-xr-x 2 root root 0 Mai 27 16:37 /usr/share/licenses/rpcbind -rw-r--r-- 1 root root 1475 Aug 15 2018 /usr/share/licenses/rpcbind/COPYING -rw-r--r-- 1 root root 1523 Mai 27 16:37 /usr/share/man/man8/rpcbind.8.gz -rw-r--r-- 1 root root 2391 Mai 27 16:37 /usr/share/man/man8/rpcinfo.8.gz

Greetings, Björn

-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)

In data mercoledì 2 giugno 2021 17:58:32 CEST, Ludwig Nussel ha scritto:

I wonder how that happened. bash-legacybin requires "this-is-only-for-build-envs" ie cannot be installed outside OBS projects that specifically ignore that dependency via BuildIgnore.

To be frank, I had no idea myself. It only happened on one machine, the others were unaffected. For good measure though, I added a lock to the package. But can it, theoretically, be installed manually? -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B

Luca Beltrame wrote:

In data lunedì 31 maggio 2021 13:53:14 CEST, Ludwig Nussel ha scritto:

...

Therefore *your next dup will automatically and live migrate your installation* to UsrMerge. Make sure to actually use "dup" and not just "up".

A note to everyone: if you ever ended up with a package named "bash-legacybin" installed (ckb-next seems to require it for some weird reason, for example),

Looks like that's triggered by a script with "#!//bin/bash" as interpreter. That leads to ckb-next requiring //bin/bash instead of /bin/bash. I suppose the dependency resolver does not canonicalize file requires before looking them up in regular provides. So it ends up trying bash-legacybin which has /bin/bash as actual file. Anyway, I've submitted a fix for ckb-next. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

On Wednesday 2021-06-02 10:25, Dominique Leuenberger / DimStar wrote:

This was on a TW setup originally installed in November 2014 which has been zupper dup'ed ever since. My latest installed snapshot was 20210519, and duping to 20210527 resulted in:

( 116/3569) Installing: filesystem-15.5-40.2.x86_64 Create `/lib64' symlink. Clean up backup files. /usr/bin.usrmerge ... mv: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference Something failed, cleaning up rm: relocation error: /lib64/libc.so.6: symbol _dl_fatal_printf, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference error: lua script failed: [string "%pretrans(filesystem-15.5-40.2.x86_64)"]:37: exit error: filesystem-15.5-40.2.x86_64: install skipped error: filesystem-15.5-39.1.x86_64: erase skipped

Might be what fvogt alluded to in the Libera chat in the preceding night, 01/22:02 < fvogt> filesystem has a Requires(pre) on compat-usrmerge-tools, which requires glibc and rpm 01/22:02 < fvogt> Nope, compat-usrmerge-tools has AutoReq: 0 and relies on the already installed glibc

On Wed, 2021-06-02 at 10:39 +0200, Vojtěch Zeisek wrote:

Someone was here recently complaining about lack of praises and success reports. So, I successfully upgraded over 10800 packages, everything was smooth, after reboot everything works. Good job, thank You all. :-)

I second that (third maybe, since I have two installations I upgraded). Standard TW + NVidia + Packman + a couple of projects from my home repository. Thanks everyone! Robert

I had the ksh symlink pointing to /etc/alternatives/usr-bin-ksh issue too and reinstalling fixed the issue too.

Viele Grüße Axel -- Diese Nachricht wurde von meinem Android-Tablet mit K-9 Mail gesendet. Am 10. Juni 2021 01:38:35 MESZ schrieb Felix Miata :

On Pentium 4 32 bit with 1GB RAM and 2G swap partition I just did offline NET upgrade from tw20200824 to tw20210606. It all seemed to go well enough, though slow, typical of USA mirrors. It booted normally afterward. But, it removed virtually all of KDE3 and thus KDM3, even though I selected to keep enabled the existing KDE3 repo. :(

On my 32bit Intel Atom based eeePC (1G RAM, 18G HD) the update from a January TW version went smooth, including up-to-date DE Cinnamon and LXQt. Are you sure KDE3 still builds on TW? Viele Grüße Axel -- Diese Nachricht wurde von meinem Android-Tablet mit K-9 Mail gesendet

Thank you for your reply which brought me one step further but I still get stuck. Removing the early stop for overlayfs produces this ouput when calling convertfs: Make a copy of `/bin'. Merge the copy with `/usr/bin'. Clean up duplicates in `/usr/bin'. Make a copy of `/sbin'. Merge the copy with `/usr/sbin'. Clean up duplicates in `/usr/sbin'. Make a copy of `/lib'. Merge the copy with `/usr/lib'. Clean up duplicates in `/usr/lib'. Make a copy of `/lib64'. Merge the copy with `/usr/lib64'. Clean up duplicates in `/usr/lib64'. Switch to new `/usr/bin'. renameat2: Invalid cross-device link UsrMerge conversion failed, cleaning up !!! ATTENTION: Do NOT proceed if you see this message during !!! distribution upgrade. Chances are high that your system might !!! break beyond repair if you do. Seems that xmv does not like the overlayfs setup? regards, Christoph Am 2021-08-02 17:57, schrieb Ludwig Nussel:

Christoph Holtermann wrote:

...

I ran into problems during update. The problem is stated in this error message: UsrMerge conversion dos not work on overlayfs

I have two Tumbleweed installations from live systems that use overlayfs. Both are broken, at the second one I was more cautious and did not proceed update. So it's in a working broken state.

I'm not really sure which way to go. Is it possible to do the necessary steps manually on overlayfs? Could someone give me a hint what to do, is there a manual?

You could install compat-usrmerge-tools manually and remove the early exit for overlayfs from /usr/libexec/convertfs. Call that script to see whether the fallback to unsafe rename works there. No idea if that can work at all, so no promises. Not sure how sensible TW on overlayfs is anyway. Over time I suppose there's nothing left that's actually used from the lower layer.

cu Ludwig