Conversation
…lock symlinks and not magic links The from-nothing build (run 35496552035, 9329c91) stopped in stage 04 at util-linux: libmount/src/hook_idmap.c:335, 'RESOLVE_NO_SYMLINKS' undeclared. Everything before it had passed on the new toolchain, the compiler check included. It is upstream's, and visible only where the C library's <fcntl.h> does not bring <linux/openat2.h> in, which is glibc before 2.43. hook_idmap.c uses the constant and includes nothing that defines it. Looking for where the other files get it found the worse half: include/fileutils.h defines a fallback of 0x02, and in the kernel's ABI 0x02 is RESOLVE_NO_MAGICLINKS; RESOLVE_NO_SYMLINKS is 0x04. context.c preprocesses to `mnt_context_is_restricted(cxt) ? 0x02 : 0` on such a libc, so the restricted-mount hardening 2.42 added blocks the wrong thing. Kryptik's mount is not setuid, so that mode is not reachable here; it is fixed anyway, because a carried patch should not leave a known-wrong constant beside the line it touches. build/patches/util-linux-2.42.3 holds one patch: fileutils.h includes the kernel header where configure found it and its fallback is 0x04, and hook_idmap.c includes fileutils.h as context.c and hook_mount.c do. The row becomes s_util_linux, which applies the set through apply_repo_patches with the same configure flags as before. Reproduced and checked on a glibc 2.39 host: the released tarball fails at the identical line; the patch applies to it with no fuzz through the project's own function, which refuses a tampered copy; the whole package then builds; and context.c preprocesses to 0x04 where it had 0x02.
This was referenced Sep 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the stage 04 failure on main (run 35496552035):
libmount/src/hook_idmap.c:335: 'RESOLVE_NO_SYMLINKS' undeclared.Two upstream defects, both visible only on a glibc older than 2.43, whose
<fcntl.h>does not bring<linux/openat2.h>in:hook_idmap.cuses the constant and includes nothing that defines it. This is what stopped the build.include/fileutils.hdefines a fallback of0x02. In the kernel's ABI that isRESOLVE_NO_MAGICLINKS;RESOLVE_NO_SYMLINKSis0x04.context.ccompiled with it, so the restricted-mount hardening asked the kernel to block the wrong thing. Kryptik'smountis not setuid, so that mode is not reachable here.Fix. A one-patch set in
build/patches/util-linux-2.42.3(withSHA256SUMSand a README), applied by a news_util_linuxwith the same configure flags as before.Checked on a glibc 2.39 host: the released tarball fails at the identical line; the patch applies with no fuzz through
apply_repo_patches, which refuses a tampered copy; the package builds;context.cpreprocesses to0x04where it had0x02.Held until a local smoke build of the other 18 bumped packages finishes, so that one build round covers everything it finds.