Heads up: UsrMerge impact imminent
Hi, As you may have noticed Factory activated the UsrMerge last week. Tumbleweed tests in openQA look good, only a non-usrmerge related bug prevents the release. I haven't received a lot of feedback from the call for testing so I hope that means the migration works really well :-) Therefore *your next dup will automatically and live migrate your installation* to UsrMerge. Make sure to actually use "dup" and not just "up". Means everything in /bin, /sbin, /lib and /lib64 will be merged into their counterparts in /usr, then replacing those directories with symlinks to /usr. After the migration packages that have compat symlinks like eg /bin/foo -> /usr/bin/foo will no longer be installable as they conflict with themselves. All packages in the distro have been fixed though. 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. 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 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? Thanks, Martin
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/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
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)
Hi, I'm on 20210524 and just ran zypper dup, the merge went badly. Every other package update started failing because it could not find /bin/sh or other binaries for the pre/post install scripts, I basically couldn't launch any program, only the terminal I had already open worked. Looking at the filesystem /bin was indeed linked to usr/bin and I could find /bin/sh, /bin/bash and others but for some reason no program could. After reboot the GUI wouldn't start, logging in also didn't work because the system couldn't find a shell. Luckily snapshots work great and I returned to a working system in a few minutes. Any thoughts? I could try running dup again tomorrow but if it messes up again I'd need some tips on what to look for to figure out why it happened.
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.
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.)
* Niklas Haas <lists.suse@haasn.dev> [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
* Patrick Shanahan <paka@opensuse.org> [06-01-21 18:21]: [...]
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
systemsettings5 has some difficulty, kf.service.sycoca: The menu spec file contains a Layout or DefaultLayout tag without the mandatory Merge tag inside. Please fix your file. and opening display config shows: No KScreen backend found. Please check your KScrenn installation. did another dup and installed additional ~50 updates. -- (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.
On 6/2/21 8:13 AM, Niklas Haas wrote:
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.
Thanks for the detailed debugging, would you mind creating a bugreport to track this? -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Tue, Jun 1, 2021 at 9:48 PM Niklas Haas <lists.suse@haasn.dev> 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? -- 真実はいつも一つ！/ Always, there's only one truth!
On Tue, 01 Jun 2021 22:00:41 -0400 Neal Gompa <ngompa13@gmail.com> 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 Tue, Jun 1, 2021 at 10:47 PM Niklas Haas <lists.suse@haasn.dev> wrote:
On Tue, 01 Jun 2021 22:00:41 -0400 Neal Gompa <ngompa13@gmail.com> 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.
We literally have no method where people can do ZFS on the root filesystem in the distribution, and basically nobody recommends ZFS on the root filesystem due to missing features like this. -- 真実はいつも一つ！/ Always, there's only one truth!
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 Wed, Jun 2, 2021 at 5:59 AM Gerald Pfeifer <gp@suse.com> wrote:
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?
Obviously my opinion doesn't matter since I'm not the maintainer, but I'd be worried about cases where this fallback code could be triggered, since the operation is not atomic, and that could make failures quite weird. Perhaps it doesn't matter in this case, but I'm always *extremely* wary of pretending that atomic ops aren't needed when code is written to assume atomic ops. OpenZFS might be fine because of other aspects of the filesystem, but what about network filesystems? If it's booted over NFS or Samba or some other network protocol, I'd be scared unless there was more hardening. -- 真実はいつも一つ！/ Always, there's only one truth!
On 2021/06/01 19:00, Neal Gompa wrote:
On Tue, Jun 1, 2021 at 9:48 PM Niklas Haas <lists.suse@haasn.dev> 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 04.06.2021 20:15, L A Walsh wrote:
On 2021/06/01 19:00, Neal Gompa wrote:
On Tue, Jun 1, 2021 at 9:48 PM Niklas Haas <lists.suse@haasn.dev> 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?
Average end-user will not use filesystem that is not even supported by standard kernel included in a distribution.
On 2021-06-01, Neal Gompa <ngompa13@gmail.com> wrote:
On Tue, Jun 1, 2021 at 9:48 PM Niklas Haas <lists.suse@haasn.dev> 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 2021-06-01, Neal Gompa <ngompa13@gmail.com> wrote:
On Tue, Jun 1, 2021 at 9:48 PM Niklas Haas <lists.suse@haasn.dev> 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.) 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. (As an aside, I have rebased and reworked the renameat2 PR for OpenZFS[1], but this is isn't going to be in a released version for a while even if it was merged quite soon.) [1]: https://github.com/openzfs/zfs/pull/12209 -- 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".
Aleksa Sarai wrote:
On 2021-06-01, Neal Gompa <ngompa13@gmail.com> wrote:
On Tue, Jun 1, 2021 at 9:48 PM Niklas Haas <lists.suse@haasn.dev> 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
The workaround to fall back to non-atomic double rename is now in Factory and will be available with the next snapshot. So the usrmerge will work on such systems, albeit not atomic. 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 Fri, Jun 11, 2021 at 4:03 AM Aleksa Sarai <asarai@suse.de> wrote:
On 2021-06-01, Neal Gompa <ngompa13@gmail.com> wrote:
On Tue, Jun 1, 2021 at 9:48 PM Niklas Haas <lists.suse@haasn.dev> 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 2021-06-11, Neal Gompa <ngompa13@gmail.com> wrote:
On Fri, Jun 11, 2021 at 4:03 AM Aleksa Sarai <asarai@suse.de> wrote:
On 2021-06-01, Neal Gompa <ngompa13@gmail.com> wrote:
On Tue, Jun 1, 2021 at 9:48 PM Niklas Haas <lists.suse@haasn.dev> 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.
Sorry, I'd heard that this was the case second-hand and didn't double-check before sending the mail (though it is still a supported configuration). In any case, the inatomic fallback was merged, so this problem was already solved (though it's not in a snapshot yet, which is why I just ran into it).
And anyway, if you're doing containers, you can blow them away and start over, right? That's the point of containers... RIGHT?!
I mean, depends on how you're running things. LXD containers aren't really like that, they're more akin to VMs in terms of how they're managed. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
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 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.
On Fri, Jun 11, 2021 at 7:15 AM Jan Engelhardt <jengelh@inai.de> 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, Neal Gompa <ngompa13@gmail.com> wrote:
On Fri, Jun 11, 2021 at 7:15 AM Jan Engelhardt <jengelh@inai.de> 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.
LXD does have images but they're not like OCI/Docker images and there isn't a "docker build"-like ecosystem. LXD images are basically just a tar-ified version of a distribution's root filesystem and there are no layers. LXD containers are managed more like VMs -- you can use other tools on top to get a more infrastructure-as-code-style model (such as OpenShift) but at its code LXD containers don't really have anything akin to Dockerfiles. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
On 2021-06-11, Martin Wilck <martin.wilck@suse.com> 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/>
Niklas Haas wrote:
I submitted https://build.opensuse.org/request/show/896791
Thanks for the effort doing that! The problem is that the fallback isn't atomic. How about making xmv exit with a different error code on EINVAL instead? That way the simplicity of xmv wouldn't be impacted and the unsafe path could be handled in the shell script. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
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.
On Wednesday 2021-06-02 00:43, Niklas Haas wrote:
Some further digging confirms that zfs does not currently implement `renameat2`, it always returns `-EINVAL` if flags is nonzero.
Filesystems do not implement "renameat2" in itself and you can still use sys_renameat2 - provided, as you mentioned, that flags==0.
The best solution here seems to be to add a fallback path to the rpm script, in case that syscall fails.
And do what? You can't replicate the guarantees of RENAME_EXCHANGE without renameat2.
Hi Ludwig, I just did the upgrade to 20210527 (from 20210524) with UsrMerge. Everything "appears" to have worked fine after rebooting and the merge looks like it was successful. Since this also updates the kernel to 5.12.4-2 that means vmware needs to recompile its modules (which it has done fine with all the previous kernel updates). I check to make sure that the following required patterns are still show to be installed (they do): Base Development C/C++ Development Linux Kernel Development And I verified that the new kernel source exists /usr/src/linux-5.12.4-2 /usr/src/linux-5.12.4-2-obj However, when vmware player (16.1.1) is started and it would normally compile its modules, instead it fails with: Kernel Headers 5.12.4-2-default were not found. Any idea what that problem is? Thanks! Joe
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. Thanks! Joe
* Joe Salmeri <jmscdba+tw@gmail.com> [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
On 02.06.2021 03:05, Joe Salmeri wrote:
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.
It is UsrMerge fallout. kernel-default-devel postinstall creates symlink to /usr/src/linux-$version-obj relative to /lib/modules. The link was correct at the time it was created. Then /lib/modules was moved into /usr which means either "/usr" is now redundant or one extra directory level is missing. kernel package will continue to create correct links on new install *after* UsrMerge but you apparently were unlucky to have kernel installed before it happened. UsrMerge is implemented in filesystem package. Check /var/log/zypp/history order in which kernel-default-devel and filesystem packages were installed.
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.
Again - link *was* correct when it has been first created. And yes, it must be adjusted during UsrMerge. I suspect it is just tip of iceberg. How many relative links are there?
Please let me know if you need any other information.
Open bug report, if you can confirm that kernel-default-devel was installed first before filesystem package it would be great.
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
On 02.06.2021 19:41, Joe Salmeri wrote:
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.
Yes, I was mistaken, link is packaged, not created at installation time.
It did update the symlink for linux-obj from the old kernel (5.12.4-1) to the new kernel,
Yes, this link is created at installation time.
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
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.
Thanks!
Joe
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
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)
On 5/31/21 4:53 AM, Ludwig Nussel wrote:
Hi,
As you may have noticed Factory activated the UsrMerge last week. Tumbleweed tests in openQA look good, only a non-usrmerge related bug prevents the release. I haven't received a lot of feedback from the call for testing so I hope that means the migration works really well :-)
Plain vanilla EXT4 system here. No problems, except for a few download timeouts. All of those downloaded fine with retry. 3000+ new files. Magic! Thank you Carl
Therefore *your next dup will automatically and live migrate your installation* to UsrMerge. Make sure to actually use "dup" and not just "up".
Means everything in /bin, /sbin, /lib and /lib64 will be merged into their counterparts in /usr, then replacing those directories with symlinks to /usr. After the migration packages that have compat symlinks like eg /bin/foo -> /usr/bin/foo will no longer be installable as they conflict with themselves. All packages in the distro have been fixed though.
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.
cu Ludwig
Am Montag, 31. Mai 2021, 13:53:14 CEST schrieb Ludwig Nussel:
Hi,
As you may have noticed Factory activated the UsrMerge last week. Tumbleweed tests in openQA look good, only a non-usrmerge related bug prevents the release. I haven't received a lot of feedback from the call for testing so I hope that means the migration works really well :-)
Therefore *your next dup will automatically and live migrate your installation* to UsrMerge. Make sure to actually use "dup" and not just "up".
Did that. System works normally, all seems to be well. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Am Mittwoch, 2. Juni 2021, 08:33:59 CEST schrieb Mathias Homann:
Am Montag, 31. Mai 2021, 13:53:14 CEST schrieb Ludwig Nussel:
Hi,
As you may have noticed Factory activated the UsrMerge last week. Tumbleweed tests in openQA look good, only a non-usrmerge related bug prevents the release. I haven't received a lot of feedback from the call for testing so I hope that means the migration works really well :-)
Therefore *your next dup will automatically and live migrate your installation* to UsrMerge. Make sure to actually use "dup" and not just "up".
Did that. System works normally, all seems to be well.
No issues here either. Everything works so far. Cheers Axel
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): 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
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)
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 <kukuk@suse.de> 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)
On Wed, 2021-06-02 at 12:15 +0100, Alin Marin Elena wrote:
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.
Those are not new at all - it's nscd that is still loudly complaining that it can't get a monitor on a file that moved to /usr/etc (yet, nscd basically needs to regularly check if the file appears, as otherwise an admin change to the file would have no effect) Cheers, Dominique
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), *uninstall* it prior to upgrading, because this one provides symlinks from / usr/bin/ to /bin for bash. When the merge occurs, bash will get replaced with a symlink to itself, potentially destroying your boot process (I had to download bash and install it manually so it would overwrite it). -- 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), *uninstall* it prior to upgrading, because this one provides symlinks from / usr/bin/ to /bin for bash. When the merge occurs, bash will get replaced with a symlink to itself, potentially destroying your boot process (I had to download bash and install it manually so it would overwrite it).
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. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer 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 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?
Yes but you'd have to very explicitly tell zypper to do so: # zypper in bash-legacybin Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides this-is-only-for-build-envs needed by bash-legacybin-5.1.4-2.3.x86_64 Solution 1: do not install bash-legacybin-5.1.4-2.3.x86_64 Solution 2: break bash-legacybin-5.1.4-2.3.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c/d/?] (c): cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
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 Mon, 2021-05-31 at 13:53 +0200, Ludwig Nussel wrote:
Hi,
As you may have noticed Factory activated the UsrMerge last week. Tumbleweed tests in openQA look good, only a non-usrmerge related bug prevents the release. I haven't received a lot of feedback from the call for testing so I hope that means the migration works really well :-)
Therefore *your next dup will automatically and live migrate your installation* to UsrMerge. Make sure to actually use "dup" and not just "up".
For completeness sake, and for people to hopefully get some info out, I'm also posting my upgrade issue encountered. 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 ....................................................................... ....................................................................... ..[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'. Warning: /lib/udev conflicts with directory /usr/lib/udev and will be removed 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 ... 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 At this point, I opted to 'retry' (unsurprisingly leading to the same error_, followed by abort. None of the commands were usable (ls, bash) and all responded with 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 To recover, I booted a TW Live image, mounted my root partition to /mnt and called zypper --root /mnt dup - which then went through without issues, rebooted and was ahappy camper again Cheers, Dominique
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
Dominique Leuenberger / DimStar wrote:
[...] At this point, I opted to 'retry' (unsurprisingly leading to the same error_, followed by abort. None of the commands were usable (ls, bash) and all responded with 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
A strange case indeed. Probably needs someone with deeper glibc knowledge to explain. From the log it looks like all usrmerge steps were executed successfully. So bin, sbin, lib and lib64 were merged into /usr. The last thing that happened before the mv was to replace /lib64 with a symlink to the merged /usr/lib64. It looks like /lib64/ld-linux-x86-64.so.2 is there. Otherwise starting mv would fail with file not found. AFAICT _dl_fatal_printf is an internal symbol that only ld uses. So ld probably wants to say something there. ld is statically linked though. In my experiments it does not seem to need glibc to print errors. Like so: # tree . ├── bin -> usr/bin ├── lib64 -> usr/lib64 └── usr ├── bin │ └── true └── lib64 ├── ld-2.33.so └── ld-linux-x86-64.so.2 -> ld-2.33.so 5 directories, 3 files # chroot $PWD /lib64/ld-2.33.so /bin/true /bin/true: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory Anyway if ld was merged successfully to /usr/lib64 why shouldn't libc work too? Maybe some corruption? Dominique filed https://bugzilla.opensuse.org/show_bug.cgi?id=1186730 Ideas how to explain that welcome. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Dne pondělí 31. května 2021 13:53:14 CEST, Ludwig Nussel napsal(a):
Hi, As you may have noticed Factory activated the UsrMerge last week. Tumbleweed tests in openQA look good, only a non-usrmerge related bug prevents the release. I haven't received a lot of feedback from the call for testing so I hope that means the migration works really well :-) Therefore *your next dup will automatically and live migrate your installation* to UsrMerge. Make sure to actually use "dup" and not just "up". Means everything in /bin, /sbin, /lib and /lib64 will be merged into their counterparts in /usr, then replacing those directories with symlinks to /usr. After the migration packages that have compat symlinks like eg /bin/foo -> /usr/bin/foo will no longer be installable as they conflict with themselves. All packages in the distro have been fixed though. 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. cu Ludwig
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. :-) -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
On Wed, Jun 02, 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. :-)
All of my machines (over a dozen) got automatcially updated in the night with only two problems, which were not usrMerge related: - packages got pulled in for new installation which requires a license - java got de-installed for no visible reason, re-installation of java worked fine. So many success stories :) Now only all my Raspberry PIs are waiting for their update ;) Thorsten -- 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)
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
On Mon, 2021-05-31 at 13:53 +0200, Ludwig Nussel wrote:
Hi,
As you may have noticed Factory activated the UsrMerge last week. Tumbleweed tests in openQA look good, only a non-usrmerge related bug prevents the release. I haven't received a lot of feedback from the call for testing so I hope that means the migration works really well :-)
Therefore *your next dup will automatically and live migrate your installation* to UsrMerge. Make sure to actually use "dup" and not just "up".
Means everything in /bin, /sbin, /lib and /lib64 will be merged into their counterparts in /usr, then replacing those directories with symlinks to /usr. After the migration packages that have compat symlinks like eg /bin/foo -> /usr/bin/foo will no longer be installable as they conflict with themselves. All packages in the distro have been fixed though.
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.
Hi Ludwig, Just wanting to report that my most problematic system (including NVIDIA GPU w. prop. drivers, and another 3rd-party out-of-tree kernel module) all updated fine Great work! --- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Hey, On Monday, 31 May 2021 13:53:14 CEST Ludwig Nussel wrote:
Hi,
As you may have noticed Factory activated the UsrMerge last week. Tumbleweed tests in openQA look good, only a non-usrmerge related bug prevents the release. I haven't received a lot of feedback from the call for testing so I hope that means the migration works really well :-)
Therefore *your next dup will automatically and live migrate your installation* to UsrMerge. Make sure to actually use "dup" and not just "up".
After the upgrade, `cd /usr; find . -xtype l` revealed a couple things. Most issues are unrelated to the migration: - There's no post-build check that verifies license or man pages symlinks are valid (SRs 896864 896863 896862 896854 896852 896848 for the ones I found) - glibc-32bit-debuginfo installs broken symlinks - A couple devel packages lacked requirements on libraries (SR 896875 & 896879) The only serious issue was with the ksh package. /usr/bin/ksh pointed to /etc/ alternatives/usr-bin-ksh which didn't exist. After reinstalling it again, the symlink is now valid and points to /etc/alternatives/ksh. The carla package also has broken symlinks. Christophe
On 6/2/21 9:19 PM, Christophe Giboudeaux wrote:
Hey,
On Monday, 31 May 2021 13:53:14 CEST Ludwig Nussel wrote:
Hi,
As you may have noticed Factory activated the UsrMerge last week. Tumbleweed tests in openQA look good, only a non-usrmerge related bug prevents the release. I haven't received a lot of feedback from the call for testing so I hope that means the migration works really well :-)
Therefore *your next dup will automatically and live migrate your installation* to UsrMerge. Make sure to actually use "dup" and not just "up".
After the upgrade, `cd /usr; find . -xtype l` revealed a couple things. Most issues are unrelated to the migration:
The carla package also has broken symlinks.
Carla hasn't succesfully rebuilt yet due to a gcc-11 issue, I made a few changes there yesterday that i'll submit to factory now, although from what I can see on my system carla only installs files into /usr -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
I had the ksh symlink pointing to /etc/alternatives/usr-bin-ksh issue too and reinstalling fixed the issue too.
Ludwig Nussel wrote:
As you may have noticed Factory activated the UsrMerge last week. Tumbleweed tests in openQA look good, only a non-usrmerge related bug prevents the release. I haven't received a lot of feedback from the call for testing so I hope that means the migration works really well :-)
So you can't make an omelette without breaking eggs after all... I've collected the issues reported so far and their workaround at https://en.opensuse.org/openSUSE:Usr_merge#State_in_openSUSE If you run into something new don't hesitate to file a bug and assign to me. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
I updated my ext4-root desktop (with proprietary Nvidia driver) this afternoon. It all went really well, no issues at all. I wasn't sure if it was needed by the update process, but I took the precaution of doing this step first: cd /usr ln -s . /usr/usr This did fix the previously mentioned kernel default/build symlinks which I can now see in the post-update system. The only other dead symlinks I can find in the post-merge root were already present in the backup that was made prior to the update. Good job. Cheers, Michael
On Mon, 31 May 2021 13:53:14 +0200 Ludwig Nussel wrote:
As you may have noticed Factory activated the UsrMerge last week. Tumbleweed tests in openQA look good, only a non-usrmerge related bug prevents the release. I haven't received a lot of feedback from the call for testing so I hope that means the migration works really well :-)
I updated a system I update only occasionally with tumbleweed-cli: factory:~ # tumbleweed update grep: /etc/zypp/repos.d/factory: Is a directory choosing latest version switching from 20210110 to 20210601? [y/n] (y): ... Everything went fine. Good work, thanks! Regards, Dieter
On 31/05/2021 13:53, Ludwig Nussel wrote:
Hi,
As you may have noticed Factory activated the UsrMerge last week. Tumbleweed tests in openQA look good, only a non-usrmerge related bug prevents the release. I haven't received a lot of feedback from the call for testing so I hope that means the migration works really well :-)
Therefore *your next dup will automatically and live migrate your installation* to UsrMerge. Make sure to actually use "dup" and not just "up".
Means everything in /bin, /sbin, /lib and /lib64 will be merged into their counterparts in /usr, then replacing those directories with symlinks to /usr. After the migration packages that have compat symlinks like eg /bin/foo -> /usr/bin/foo will no longer be installable as they conflict with themselves. All packages in the distro have been fixed though.
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.
cu Ludwig
I updated my system, and all went well. :) Except for the issue with the kernel's build and source dir symlinks, but thanks to the heads up https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/4... , I fixed them manually for now. Otherwise, good stuff. Good work, thanks o/ Have a good day. -- Ahmad Samir
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. :( /var/log/zypp/history includes dates all the way back to 2013-12-21, 3836862 bytes. -- 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
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 <mrmazda@earthlink.net>:
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
Axel Braun composed on 2021-06-10 09:24 (UTC+0200):
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?
KDE3 works fine after reinstalling the deleted packages. -- 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
Hello, 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? regards, Christoph Holtermann
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 -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
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
participants (33)
-
Ahmad Samir -
Aleksa Sarai -
Alin Marin Elena -
Andrei Borzenkov -
Axel Braun -
B -
Ben Holmes -
Bjoern Voigt -
Carl Symons -
Christoph Holtermann -
Christophe Giboudeaux -
dieter -
Dominique Leuenberger / DimStar -
Felix Miata -
Gerald Pfeifer -
Jan Engelhardt -
Joe Salmeri -
L A Walsh -
Luca Beltrame -
Ludwig Nussel -
Martin Wilck -
Martin Wilck -
Mathias Homann -
Michael Hamilton -
munix9 -
Neal Gompa -
Niklas Haas -
Patrick Shanahan -
Richard Brown -
Robert Munteanu -
Simon Lees -
Thorsten Kukuk -
Vojtěch Zeisek