[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45165: binutils-mesboot0 fails at configure, cannot find lex
From: |
kitzman |
Subject: |
bug#45165: binutils-mesboot0 fails at configure, cannot find lex |
Date: |
Wed, 09 Jun 2021 16:36:37 +0300 |
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
- bug#45165: binutils-mesboot0 fails at configure, cannot find lex,
kitzman <=