Tobias Geerinckx-Rice writes:
>> My diff from linux-libre, which sure seems to tell a story:
>>
>> y -> not set CONFIG_UID16 (obsolete)
>
> As expected upthread, this and this alone was indeed the culprit. I
> don't see any evidence of interaction with other options though.
>
I tried working
Tobias Geerinckx-Rice via Bug reports for GNU Guix 写道：
My diff from linux-libre, which sure seems to tell a story:
y -> not set CONFIG_UID16 (obsolete)
As expected upthread, this and this alone was indeed the culprit.
I don't see any evidence of interaction with other options though.
Kind
Morning Guix,
I'm unable to ‘guix pull’ because of this bug. Log attached.
Here are my kernel options from kitzman's list:
not set CONFIG_UID16 (obsolete)
yCONFIG_EXPERT
yCONFIG_X86_64 (obvs)
yCONFIG_X86
not set CONFIG_X86_X32
not set CONFIG_X86_VSYSCALL_EMULATION
y
Please ignore the following. A function appearing there can still return ENOSYS.
kitzman writes:
> 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,
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
Hello,
a test in commencement.scm will be run by guixbuild user, no ?
$ ls -ld /
drwxr-xr-x 17 root root 4096 Feb 27 10:43 /
won't that always fail ?
--
Vincent Legoll
Hi,
Carl Dong skribis:
> New observation! On my Arch machine which has
>
> 5.10.11-arch1-1
>
> And
>
> # CONFIG_EXPERT is not set
> CONFIG_UID16=y
>
> (So according to my previous email it not trigger the bug)
>
> I’m getting the following strace:
>
> $ strace -v -e trace=file ~/sh -c "test
New observation! On my Arch machine which has
5.10.11-arch1-1
And
# CONFIG_EXPERT is not set
CONFIG_UID16=y
(So according to my previous email it not trigger the bug)
I’m getting the following strace:
$ strace -v -e trace=file ~/sh -c "test -w /home/dongcarl/.bash_profile”
execve() = 0
[
Regardless of how Kconfig options interact with each other, it seems that this
bug is only triggered when the effective kernel config (/proc/config.gz)
contains the following:
CONFIG_EXPERT=y
# CONFIG_UID16 is not set
Cheers,
Carl Dong
Hi all,
I was able to bisect this down to a few kernel configuration options, so
perhaps those with more kernel experience can help me track down what’s going
on.
The two Kconfig options which seem to influence the behavior are:
1. CONFIG_EXPERT
2. CONFIG_UID16
CONFIG_EXPERT=y, CONFIG_UID16=y
I also started to see this issue a few days ago. The host is currently
running a variant of Linux 5.9.14-arch1-1 and the docker image is
Alpine:3.12. I am not sure if this is helpful but if I remember
correctly, I rebooted my machine in between the times I was last able to
binutils-mesboot0
Hi!
Carl Dong skribis:
> This led me to look at ./configure’s shebang, which is:
> /gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh
>
> Then I did:
> /gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh
> -c "test -w config.cache”
>
> Which
More clues:
I ran the following one-liner:
for i in $(seq 0 65535); do sudo chown $i:$i
/tmp/guix-build-binutils-mesboot0-2.14.drv-0/binutils-2.14/config.cache &&
/gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05b/bin/sh -c "test
-w
Hi all,
I think I have a new lead!
Here’s what I did:
1. cd /tmp/guix-build-binutils-mesboot0-2.14.drv-0/binutils-2.14
2. env -i bash --rcfile environment-variables
3. Ran the configure command from the log, just to check:
./configure --disable-nls --disable-shared --disable-werror
Hi all,
Let me know if there’s anything at all I can do here to help debug :-)
Cheers,
Carl Dong
Hi Janneke!
Oh, that’s a very good find! I have no idea why config.cache is not writable…
This is most strange!
I checked that my mountpoints have enough free space… Not sure what else to
check?
Looking at `guix describe`, I’m on bf8dfe3df025e4ac80cccb87497b4f072ba10e2a
Cheers,
Carl Dong
>
Carl Dong writes:
Hello!
> Some more information from my debugging:
>
> 1. This error is reproducible even when I specify --cores=1, which is very
> strange
> 2. I have attached the full log to this email
Diffing this with the build log from
--8<---cut
Hi all,
I’m pulling from quite an old version of Guix here, and binutils-mesboot0 seems
to fail at configure. Here’s the tail of the log:
-
checking lex output file root... @ build-log 1955508 104
./configure: line 4505: lex: command not found
configure: error: cannot find output from lex;
18 matches
Mail list logo
