[gentoo-user] Re: How to repair a 'secondary Gentoo system'

[Kai Krakow]

Am Mon, 11 Dec 2017 20:12:49 +0100 schrieb Helmut Jarausch:

> On 12/11/2017 05:58:42 PM, David Haller wrote:
>> Hello,
>>
>> On Mon, 11 Dec 2017, Helmut Jarausch wrote:
>> >But now, don't ask me why,
>> >chroot  /OtherGentoo   /bin/bash
>> >dies of a segment fault.
>> >
>> >Is there any means to repair such a Gentoo system short of
>> rebuilding it
>> >(nearly) from scratch?

You could try to start emerge with chroot directly instead of dropping 
into a shell, then rebuild whatever causes the segfault:

$ chroot /OtherGentoo emerge -1a bash

But keep in mind that chroot doesn't do a very good isolation against the 
host system. You may want to use a wrapper script to setup the needed 
mounts, and maybe some more stuff.

You could also try running busybox instead of bash.


>> How about a bit of debugging first?
>>
>> # catchsegv chroot  /OtherGentoo   /bin/bash
>> # cd /OtherGentoo/ && chroot  /OtherGentoo/ /bin/bash
>>
>> (ISTR, there was/is a reason for first cd-ing into the chroot and then
>> chrooting with the full-path...)
>>
>> Have you (bind) mounted /sys, /dev, /proc into the chroot?
>>
>> I use this as the top and bottom of a little bit longer
>> chroot-wrapper-script:
>>
>> ==== /root/bin/chrooter ====
>> #!/bin/bash
>> root="$1"
>> shift
>>
>> test -e "${root}/proc/kcore" || mount --bind /proc/ "${root}/proc"
>> test -e "${root}/sys/block"  || mount --bind /sys/ "${root}/sys"
>> test -e "${root}/dev/root"   || mount --bind /dev/ "${root}/dev"
>> test -e "${root}/dev/pts/0"  || mount --bind /dev/pts/
>> "${root}/dev/pts"
>> [..]
>> cd "$root"
>> chroot "$root" /bin/bash -l
>> ====
>
> My procedure is quite similar, I only use
>
> mount --rbind /dev/ "${root}/dev"
>
> and
>
> mount --rbind /run  /${NROOT}/run
>
> ---
>
> I've tried
> catchsegv chroot  /OtherGentoo   /bin/bash
>
> as well as
>
> chroot  /OtherGentoo   catchsegv /bin/bash
>
> In both cases, I don't get any error messages BUT I don't get chrooted.
>
> Strangely enough, dmesg shows
>
> systemd-coredump[25375]: Failed to connect to coredump service: No
such  
> file or directory

It seems that at least systemd is installed and dropped some sysctl files 
in the directory structure. This would then set kernel.core_pattern to 
systemd-coredump.

OTOH, you may want to try to enter other Gentoo system with systemd-nspawn 
instead of chroot. It would also setup most of your bind mounts correctly:

$ cd /OtherGentoo && sudo systemd-nspawn

Similar to your use-case, I'm using such a OS tree to manage a rescue 
system in case my main system would not boot. A simple script is used as 
a wrapper to enter the system:

$ cat /mnt/rescue/enter.sh
#!/bin/bash
cd $(dirname $0) && \
exec sudo systemd-nspawn --bind=/usr/portage --bind=/boot $@


> although I'm not using system but openrc on both system

systemd-nspawn should be able to enter non-openrc systems but the host OS 
needs a running systemd instance to build the namespace scope.

I can even simulate a full rescue system boot that way:

$ /mnt/rescue/enter.sh -nb

and the container boots, dropping me at a console login.


Both provides much better isolation and simulation of the root 
environment than chroot.


-- 
Regards,
Kai

Replies to list-only preferred.