From: kitzman via Bug reports for GNU Guix <bug-guix@gnu.org>
To: 45165@debbugs.gnu.org
Subject: bug#45165: binutils-mesboot0 fails at configure, cannot find lex
Date: Wed, 09 Jun 2021 16:36:37 +0300 [thread overview]
Message-ID: <87bl8fkvmi.fsf@disroot.org> (raw)
In-Reply-To: <1C1332EB-3389-416F-A8A7-0CF6A469AE29@carldong.me>
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
next prev parent reply other threads:[~2021-06-09 19:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-10 20:01 bug#45165: binutils-mesboot0 fails at configure, cannot find lex Carl Dong
2020-12-10 22:28 ` Carl Dong
2020-12-11 6:33 ` Jan Nieuwenhuizen
2020-12-11 16:37 ` Carl Dong
2020-12-15 18:50 ` Carl Dong
2020-12-16 0:46 ` Carl Dong
2020-12-16 17:49 ` Carl Dong
2020-12-22 14:33 ` Ludovic Courtès
2020-12-22 16:42 ` Carl Dong
2021-01-18 22:48 ` Carl Dong
2021-01-19 23:03 ` Carl Dong
2021-02-03 19:18 ` Carl Dong
2021-02-06 21:04 ` Ludovic Courtès
2020-12-25 15:57 ` Tom Hiller
2021-02-27 10:33 ` Vincent Legoll
2021-06-09 13:36 ` kitzman via Bug reports for GNU Guix [this message]
2021-06-09 15:12 ` kitzman via Bug reports for GNU Guix
2021-12-24 5:58 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2021-12-24 8:11 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2022-02-24 13:09 ` kitzman via Bug reports for GNU Guix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bl8fkvmi.fsf@disroot.org \
--to=bug-guix@gnu.org \
--cc=45165@debbugs.gnu.org \
--cc=kitzman@disroot.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.