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.
