* Re: [gentoo-user] How to repair a 'secondary Gentoo system'
2017-12-11 19:12 ` Helmut Jarausch
@ 2017-12-11 19:45 ` David Haller
2017-12-11 20:56 ` Rich Freeman
2017-12-11 20:06 ` Dale
2017-12-12 1:45 ` [gentoo-user] " Kai Krakow
2 siblings, 1 reply; 7+ messages in thread
From: David Haller @ 2017-12-11 19:45 UTC (permalink / raw
To: gentoo-user
Hello,
On Mon, 11 Dec 2017, Helmut Jarausch wrote:
>My procedure is quite similar, I only use
>
>mount --rbind /dev/ "${root}/dev"
Ah, that's nice for /dev/{pts,shm,usb}/ ;)
>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
>
>although I'm not using system but openrc on both system
It seems to me though, that that systemd-coredump thingy is running
though ...
$ ps a -eo pid,cmd | awk '$1 == 25375 { print;}'
If you're not using systemd as init and that thing still runs, that
could be the cause of you not getting usable info.
HTH,
-dnh
--
"N race conditions on the wall, N race conditionsa You take one down,
pass it around, and wait. And wait some more." -- Bytor in #tribes
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [gentoo-user] How to repair a 'secondary Gentoo system'
2017-12-11 19:45 ` David Haller
@ 2017-12-11 20:56 ` Rich Freeman
0 siblings, 0 replies; 7+ messages in thread
From: Rich Freeman @ 2017-12-11 20:56 UTC (permalink / raw
To: gentoo-user
On Mon, Dec 11, 2017 at 2:45 PM, David Haller <gentoo@dhaller.de> wrote:
>
> On Mon, 11 Dec 2017, Helmut Jarausch wrote:
>>Strangely enough, dmesg shows
>>
>>systemd-coredump[25375]: Failed to connect to coredump service: No such file
> ^^^^^^
>>or directory
>>
>>although I'm not using system but openrc on both system
>
> It seems to me though, that that systemd-coredump thingy is running
> though ...
>
> $ ps a -eo pid,cmd | awk '$1 == 25375 { print;}'
>
That won't show anything, because systemd-coredump isn't a daemon. If
configured to do so, the kernel runs it when a core file is generated,
pipes the core into it, and it in turns passes it along to a
socket-activated service which logs it. Then all those processes
terminate. You wouldn't see them running except for a brief moment
when a process dumps core.
In your case the problem is that the socket doesn't exist, probably
because you aren't actually running systemd. So, systemd-coredump is
being run by the kernel, but it can't pass the core file along to the
service that logs it.
Most likely you have systemd installed but aren't actually running it.
It isn't particularly easy to accidentally install systemd under
Gentoo (I can't imagine that bug going unreported for long around
here...). Presumably you're using a systemd profile, or otherwise
have installed it.
If systemd is installed, then chances are you have this file
installed: /usr/lib/sysctl.d/50-coredump.conf
If that file exists, then I suspect openrc will parse it and set:
kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e
And that will cause the issue you're seeing.
Just move that file someplace else and reboot. Or run sysctl
kernel.core_pattern=/tmp/core.%p or something like that. Then core
files will be dumped to disk and not piped into systemd-coredump.
Long-term you should sort out which service manager you want to run
and configure the entire system accordingly. You might run into
subtle bugs like this one if you have systemd installed and don't use
it. There is nothing wrong with switching back and forth, but it
isn't a well-tested config.
--
Rich
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-user] How to repair a 'secondary Gentoo system'
2017-12-11 19:12 ` Helmut Jarausch
2017-12-11 19:45 ` David Haller
@ 2017-12-11 20:06 ` Dale
2017-12-12 1:45 ` [gentoo-user] " Kai Krakow
2 siblings, 0 replies; 7+ messages in thread
From: Dale @ 2017-12-11 20:06 UTC (permalink / raw
To: gentoo-user
Helmut Jarausch wrote:
> 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?
>>
>> 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
>
> although I'm not using system but openrc on both system
>
> Thanks,
> Helmut
Just a thought. Have you recompiled the package chroot belongs too?
Maybe somehow the chroot file got corrupted or something and just fails
to run.
I would also cd to your backup install and just poke around and see if
everything looks normal. Like maybe /sbin is missing or something.
Maybe look for some files that you know are used to chroot in, like bash
for example.
Dale
:-) :-)
^ permalink raw reply [flat|nested] 7+ messages in thread* [gentoo-user] Re: How to repair a 'secondary Gentoo system'
2017-12-11 19:12 ` Helmut Jarausch
2017-12-11 19:45 ` David Haller
2017-12-11 20:06 ` Dale
@ 2017-12-12 1:45 ` Kai Krakow
2 siblings, 0 replies; 7+ messages in thread
From: Kai Krakow @ 2017-12-12 1:45 UTC (permalink / raw
To: gentoo-user
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.
^ permalink raw reply [flat|nested] 7+ messages in thread