Please mask sys-apps/util-linux-2.39* immediately, we may end up with lots of broken systems (tho only ones running ~ because 2.39 is not stable yet). I will update with more details ASAP, but so far I know: sys-apps/util-linux-2.39 on kernel 5.10.x results in portage being unable to merge anything: >>> Running pre-merge checks for dev-java/openjdk-bin-17.0.6_p10 mount: /proc: mount(2) system call failed: Function not implemented. dmesg(1) may have more information after failed mount system call. Unable to mark /proc slave: 32 * The ebuild phase 'pretend' has exited unexpectedly. This type of ... dmesg did not in fact say anything useful. I found this was easy to reproduce with: mount -o remount,... mount: /boot: mount(2) system call failed: Function not implemented. dmesg(1) may have more information after failed mount system call. umount worked fine mount of a not-yet-mounted filesystem worked fine This was on a box with 5.10.144 and: # equery l glibc gcc binutils portage pax-utils * Searching for glibc ... [IP-] [ ] sys-libs/glibc-2.37-r3:2.2 * Searching for gcc ... [I-O] [ ] sys-devel/gcc-12.3.1_p20230512-r1:12 * Searching for binutils ... [IP-] [ ] sys-devel/binutils-2.40-r5:2.40 * Searching for portage ... [IP-] [ ] sys-apps/portage-3.0.47:0 * Searching for pax-utils ... [IP-] [ ] app-misc/pax-utils-1.3.7:0 I had a similar enough box that still had util-linux-2.38.1-r2 so I could quickpkg over there and untar (emerge --usepkg... failed the same way). I never tried rebooting to find out what that resulted in. I will test on a box with a 5.15.x kernel and one with 6.3.x just in case this turns out to be a kernel/syscall compatibility thing, and also get some straces of 2.38.1 vs 2.39
I've just had a report of this as well with 5.10. Apparently 5.15.x is OK. For now, FEATURES="-pid-sandbox" is supposed to help.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e900d7a779b844a2bf134840214c78eb1f668df0 commit e900d7a779b844a2bf134840214c78eb1f668df0 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-05-19 22:52:18 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-19 22:52:18 +0000 profiles: mask =sys-apps/util-linux-2.39 This breaks Portage's pid-sandbox at least w/ Linux 5.10. Bug: https://bugs.gentoo.org/906797 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 6 ++++++ 1 file changed, 6 insertions(+)
By stracing the small reproducer of 'mount -o remount...', I can see that mount from util-linux-2.39 unconditionally calls the mount_setattr syscall. That syscall was added in ~5.12.x kernels. -### util-linux-2.38.1-r2_kernel-5.10.147_remount-ro.strace -NNN execve("/bin/mount", ["mount", "-o", "remount,rw", "/boot"], 0xHHHH /* 42 vars */) = 0 +### util-linux-2.39_kernel-5.10.147_remount-ro.strace +NNN execve("/bin/mount", ["mount", "-o", "remount,ro", "/boot"], 0xHHHH /* 42 vars */) = 0 ... -NNN mount("/dev/sda1", "/boot", 0xHHHH, MS_REMOUNT, NULL) = 0 +NNN fspick(3, "", FSPICK_NO_AUTOMOUNT|FSPICK_EMPTY_PATH) = 4 +NNN fsconfig(4, FSCONFIG_SET_FLAG, "ro", NULL, 0) = 0 +NNN fsconfig(4, FSCONFIG_CMD_RECONFIGURE, NULL, NULL, 0) = 0 +NNN mount_setattr(3, "", AT_EMPTY_PATH, {attr_set=MOUNT_ATTR_RDONLY, attr_clr=MOUNT_ATTR_NOSUID|MOUNT_ATTR_NODEV|MOUNT_ATTR_NOEXEC|MOUNT_ATTR_NOSYMFOLLOW, propagation=0 /* MS_??? */, userns_fd=0}, 32) = -1 ENOSYS (Function not implemented) +NNN close(4) = 0 ... util-linux attempts to check at compile-time if mount_setattr is supported: /usr/local/src/github-forks/util-linux $ egrep -1 mount_setattr configure.ac move_mount \ mount_setattr \ nanosleep \ -- UL_CHECK_SYSCALL([fspick]) UL_CHECK_SYSCALL([mount_setattr]) UL_CHECK_SYSCALL([move_mount]) -- test "x$ul_cv_syscall_fspick" = xno || test "x$ul_cv_syscall_mount_setattr" = xno || test "x$ul_cv_syscall_move_mount" = xno || So: 1) is that UL_CHECK_SYSCALL doing an actual compile-test, or is it only, say, going by what kernel headers say? An affected box has sys-kernel/linux-headers-6.2 but only running a 5.10.x kernel; are the newer headers fooling it? 2) being a compile-time check with no runtime check or fallback, makes me think mount(8) would fail in mysterious ways on any system that got downgraded >=5.12 -> <5.12 and rebooted. That's not great.
Note also, with 2.39, fstab mount options "user,exec" is newly broken, failing incorrectly with "must be superuser to use mount.". "users,exec" still works, but is not semantically identical ("user" confines permission-to-unmount to the mounting user, whereas "users" allows any user with parent directory read access to unmount it, even if no access to the rootdir of the mount, confirmed experimentally with 2.39). The code around option evaluation was extensively reworked between 2.38 and 2.39, and this shows what's breaking in 2.39 with "user,exec": 45519: libmount: OPTLIST: merging L 328 outer: exec (0x5625c3ac82d0) L 334 inner: exec (0x5625c3ac7f50) L 342 remove duplicate exec 45519: libmount: OPTLIST: remove exec L 334 inner: noauto (0x5625c3ac7fb0) L 334 inner: user (0x5625c3ac8010) L 352 remove due to MNT_INVERT exec 45519: libmount: OPTLIST: remove user i.e. the exec flag is clearing the user flag. With "exec,users" this doesn't happen. And that's as far as I went root-causing this mess.
(In reply to Daniel Pouzzner from comment #4) That sounds like an entirely separate issue. Please create an issue upstream.
It *is* an entirely separate issue, but supports the decision to mask the version, which is why I mentioned it here.
Created https://bugs.gentoo.org/906859 (and found an upstream open issue about it).
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ca46cab3e9d658ced95d386616f0b2c3abda5400 commit ca46cab3e9d658ced95d386616f0b2c3abda5400 Author: Hank Leininger <hlein@korelogic.com> AuthorDate: 2023-05-20 19:38:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-23 03:09:25 +0000 sys-apps/util-linux: Fix for mount_setattr use on <5.12 kernels Backported pending upstream fix from https://github.com/util-linux/util-linux/pull/2248 Note that there's at least one other breaking bug in util-linux-2.39 so the mask probably shouldn't be removed yet. Bug: https://bugs.gentoo.org/906859 Closes: https://bugs.gentoo.org/906797 Closes: https://github.com/gentoo/gentoo/pull/31108 Signed-off-by: Hank Leininger <hlein@korelogic.com> Signed-off-by: Sam James <sam@gentoo.org> .../util-linux-2.39-check-for-mount_setattr.patch | 94 +++++ .../util-linux-2.39-tests-for-mount_setattr.patch | 13 + sys-apps/util-linux/util-linux-2.39-r2.ebuild | 398 +++++++++++++++++++++ 3 files changed, 505 insertions(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=981f36533f7d0930bcb794d305e392678e83da5b commit 981f36533f7d0930bcb794d305e392678e83da5b Author: Sam James <sam@gentoo.org> AuthorDate: 2023-05-23 04:20:10 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-23 04:20:16 +0000 sys-apps/util-linux: update mount_setattr patch to new upstream version The PR got updated slightly. Closes: https://bugs.gentoo.org/906797 Signed-off-by: Sam James <sam@gentoo.org> .../files/util-linux-2.39-check-for-mount_setattr.patch | 14 +++++++++----- ...util-linux-2.39-r2.ebuild => util-linux-2.39-r3.ebuild} | 0 2 files changed, 9 insertions(+), 5 deletions(-)
Given the bug is now marked as fixed, do we also want to remove the entry from package.mask that blocks all sys-apps/util-linux-2.39, including -r3? # Sam James <sam@gentoo.org> (2023-05-19) # Breaks Portage's pid-sandbox at least with 5.10 kernels. Pending investigation. # If you're hitting this, try: FEATURES="-pid-sandbox" emerge -v1 sys-apps/util-linux # as a workaround. bug #906797. ~sys-apps/util-linux-2.39
(In reply to Krzysztof Olędzki from comment #10) > Given the bug is now marked as fixed, do we also want to remove the entry > from package.mask that blocks all sys-apps/util-linux-2.39, including -r3? > > # Sam James <sam@gentoo.org> (2023-05-19) > # Breaks Portage's pid-sandbox at least with 5.10 kernels. Pending > investigation. > # If you're hitting this, try: FEATURES="-pid-sandbox" emerge -v1 > sys-apps/util-linux > # as a workaround. bug #906797. > ~sys-apps/util-linux-2.39 No. See the commit message at https://bugs.gentoo.org/906797#c8. Yes, we backported fixes (just for convenience/testing purposes) but I don't really want to unmask util-linux-2.39, given they substantially rewrote the mount handling and there's been several regressions, and 2.39.1 will be on its way soon.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d89394c9345cc488d5ed7b7c40aac61c6a86dcd4 commit d89394c9345cc488d5ed7b7c40aac61c6a86dcd4 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-05-26 07:24:26 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-26 07:24:41 +0000 sys-apps/util-linux: backport another mount regression fix (still masked) util-linux-2.39.1 is coming next week. Bug: https://bugs.gentoo.org/906797 Signed-off-by: Sam James <sam@gentoo.org> .../util-linux-2.39-mount-dont-call-hooks.patch | 79 +++++ sys-apps/util-linux/util-linux-2.39-r1.ebuild | 393 --------------------- ...ux-2.39-r3.ebuild => util-linux-2.39-r4.ebuild} | 7 +- 3 files changed, 83 insertions(+), 396 deletions(-)
