Dear all, I have ran into the exact same issue (I will assume it's the same source). I suppose this is only relevant for certain forks of the kernel, not the mainline one - I also assume that my train thought might prove useful... hopefully. * Syscalls * The stat syscall works - but then bash tries to getuid (so it knows if it's checking for the owner or for others), and returns -1 (not implemented). The returned mode by "stat" is checked in "test_eaccess", line 221, "test.c" of bash 2.05b. There, it checks the euid (to see if it either checks for o+w or u+w). The get[e]?[ug]id functions return -1 in my case - thus making bash believe it's not the same user, thus checking if others can write, and failing. Upon further inspection, the syscall happening to get the ids is actually a 32-bit one - which makes sense considering bash-mesboot0 is built only for i686. Take for example (taken from strace): - syscall 199 (getuid32) - syscall 102 (getuid, for x86_64) - syscall 24 (getuid for 32-bit) The first two work (for me). At the stage of gcc-mesboot1, these are the ones used. For binutils-mesboot0, the last one is used, and on my system, gives an error. Patching binutils-mesboot0, gawk-mesboot, gnu-make-mesboot was easy: test -w and test -x bash builtins were replaced by their coreutils-mesboot0 counterpart inside the build . Currently I have stumbled upon problems making gcc-mesboot1, which uses make-mesboot, which, when you do a "$(call ...)", internally it tries to do an "execve" syscall (weirdly enough, it does the right syscalls for getuid etc) - syscall 59 (execve) works (my normal make's syscall ALSO bash-mesboot's syscall at this point) - syscall 11 (execve) doesn't (the one used by make), gives ENOMEM Sure, if "test" commands were the only things to be patched I would be contempt with this upload: https://0x0.st/-_5w.scm . But I didn't manage to bootstrap my system only using my kernel. * Kernel * I'm not using a mainline kernel, let alone options. But the standard kernel supplied with my distro works. Referring to kernel's configuration: --- Mine Carl's Libre ✓ Arch ✓ Option not set not set y y CONFIG_UID16 (obsolete?) not set y y not set CONFIG_EXPERT y y y y CONFIG_X86_64 y y y y CONFIG_X86 (32 + 64, according to docs) not set not set y not set CONFIG_X86_X32 y y y y CONFIG_X86_VSYSCALL_EMULATION y not set y not set CONFIG_LEGACY_VSYSCALL_NONE y y y y CONFIG_IA32_EMULATION --- I'm not even a sub-mediocre when it comes to kernel code: Checking the kernel file arch/x86/entry/syscalls/syscall_32.tbl, that one contains the emulation functions - however, the kernel that I'm using -doesn't- have the IA32 functions defined in the table, but the mainline one does. A quick way to check this is to cat "/proc/kallsyms", look for "__ia32_sys_getuid", and see where (and if) it's mapped in memory. For me, it's not, ergo, the syscalls are not implemented, thus it returns -1. (or so I think) Might this be the issue? ** My solution: ** At this point, the chosen solution for me - build the packages in a VM, and wait for mesboot's x86_64 support. I don't think this is a problem with Guix - I find it normal if IA32 emulation is enabled, to have the syscalls. Kind regards, kitzman