64 bit Gentoo on Raspberry Pi3 Broken

[NeddySeagoon]

Team,

I did an update the other day. glibc ended badly with sandbox messages about signals already having handers, bad file descriptors and so on.
I still have the log. Now the poor wee thing won't boot. The boot messages on the console just stop.
My main install is on a USB HDD. That's the one that hangs at boot.

I also have an older less complete install on an SDCard. Its slow but it better than not booting. The plan was to boot that, mount everything at /mnt/gentoo in the traditional manner, then fix it ... but the chroot doesn't work.

Code: Select all

Pi3 64bit ~ # chroot /mnt/gentoo/ /bin/bash
Pi3 64bit / # env-update
>>> Regenerating /etc/ld.so.cache...

[1]+  Stopped                 chroot /mnt/gentoo/ /bin/bash
Pi3 64bit ~ # 

So its dropped out of the chroot.

Code: Select all

Pi3 64bit ~ # jobs -l 
[1]+  2525 Stopped (tty output)    chroot /mnt/gentoo/ /bin/bash
Pi3 64bit ~ # 

Any hints would be most welcome.


-- edit --
This happens on the console, over ssh and in srceen.

-- edit --
Further testing has shown that its the chroot process and any process in the chroot fighting over the console.
One stops the other every time it wants to do output.

[krinn]

from your output the chroot works, it's when you env-update that it gets stops, and i could see a relationship between env-update frozen and "glibc ended badly".

I would give a shot at env-update --no-ldconfig
did get plague by https://bugs.gentoo.org/show_bug.cgi?id=575232 ?
i'm pretty sure you will like this one also : https://forums.gentoo.org/viewtopic-t-8 ... ight-.html

[NeddySeagoon]

krinn,

Its a terminal setting thing.

If I do

Code: Select all

stty -tostop

begore I do the chroot, the chroot steps work.
Anything useful in the chroot gets me

Code: Select all

 [1]+  Stopped                 chroot /mnt/gentoo /bin/bash

which I can fix by typing fg.
By keeping that up, the job I want to run in chroot actually runs in the chroot.

It looks like this

Code: Select all

[1]+  Stopped                 chroot /mnt/gentoo /bin/bash
Pi3 64bit log # fg
chroot /mnt/gentoo /bin/bash

[1]+  Stopped                 emerge -K1 =sys-libs/glibc-2.23-r2
(chroot) Pi3 64bit / # fg
emerge -K1 =sys-libs/glibc-2.23-r2

 * IMPORTANT: 6 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.

Calculating dependencies... done!
>>> Running pre-merge checks for sys-libs/glibc-2.23-r2
 * glibc-2.23-r2.tbz2 MD5 SHA1 size ;-) ...                              [ ok ]
<builtin>: recipe for target 'glibc-test' failed
<builtin>: recipe for target 'glibc-test' failed

 * Messages for package sys-libs/glibc-2.23-r2:

 * Package:    sys-libs/glibc-2.23-r2
 * Repository: gentoo
 * USE:        multilib kernel_linux rpc elibc_glibc arm64 userland_GNU
 * FEATURES:   distcc distcc-pump preserve-libs sandbox userpriv usersandbox
Traceback (most recent call last):
  File "/usr/lib/python-exec/python2.7/emerge", line 50, in <module>
    retval = emerge_main()
  File "/usr/lib64/python2.7/site-packages/_emerge/main.py", line 1185, in emerge_main
    return run_action(emerge_config)
  File "/usr/lib64/python2.7/site-packages/_emerge/actions.py", line 3236, in run_action
    emerge_config.args, spinner)
  File "/usr/lib64/python2.7/site-packages/_emerge/actions.py", line 505, in action_build
    retval = mergetask.merge()
  File "/usr/lib64/python2.7/site-packages/_emerge/Scheduler.py", line 1029, in merge
    signal.siginterrupt(signal.SIGCONT, False)
RuntimeError: (9, 'Bad file descriptor')

[1]+  Stopped                 chroot /mnt/gentoo /bin/bash

That's another feature :)
I've tried python2.7 and python3.4. That just changes the python version in the error message.

[krinn]

don't know then, did you mount /dev in your new root? (only explains i have in mind for your file descriptors trouble)

[NeddySeagoon]

krinn,

Its there. [snip] to spare you the 'guff'.

Code: Select all

[snip]
/dev/sda1       76765216 7637588  65205044  11% /mnt/gentoo
/dev/sda3       17170840 1901804  14373756  12% /mnt/gentoo/var/tmp/portage
/dev/sda4              -       -         -    - /mnt/gentoo/usr/portage
/dev/sda5       38448788 1377368  35101912   4% /mnt/gentoo/var/cache/distfiles
/dev/sda6       51775076   53404  49068540   1% /mnt/gentoo/home
proc                   0       0         0    - /mnt/gentoo/proc
sysfs                  0       0         0    - /mnt/gentoo/sys
[snip]
devtmpfs           10240       0     10240   0% /mnt/gentoo/dev
mqueue                 0       0         0    - /mnt/gentoo/dev/mqueue
devpts                 0       0         0    - /mnt/gentoo/dev/pts
shm               437032       0    437032   0% /mnt/gentoo/dev/shm
/dev/mmcblk0p6   1463128  523087    838461  39% /mnt/gentoo/usr/portage

It has to be the console I'm using that breaks the chroot. It stops non foreground jobs when they want to do terminal output.

The bad file descriptor issue started at the end of the glibc build but that's not the cause as the system I chroot in from has the same glibc.

[krinn]

your shm is toast, how you manage to fill it like that?

[Ant P.]

er... those columns are total/used/free, in that order.

[krinn]

oh, it answer who is toasted then

[NeddySeagoon]

Just to post a follow up. The short answer is its fixed but I don't really know why.

Circumstantial evedence says that something broke at build time and installed in is broken state.
glibc is excluded, since a rebuild did not fix it.

Code: Select all

emerge -K @system

changed nothing, hence the conclusion it was a build time issue.

The eventual fix was to boot a different (older) install, mount the broken install at /mnt/gentoo, Tell the booted install ROOT=/mnt/gentoo and allow it to run

Code: Select all

emerge -e @system

so that the system set was rebuilt.