all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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




  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.