From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 3F4F4139083 for ; Mon, 11 Dec 2017 20:06:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3053DE108A; Mon, 11 Dec 2017 20:06:27 +0000 (UTC) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CA956E1078 for ; Mon, 11 Dec 2017 20:06:26 +0000 (UTC) Received: by mail-yb0-x230.google.com with SMTP id z11so1766798ybm.1 for ; Mon, 11 Dec 2017 12:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=3JQKT8hd1HaVWRcwkxYWa6YHw1aTU0AJlM+7TJRadro=; b=hhwPkapjgegYihTEgIoI9Dn/pqZrZd8ZR6xdkAIRTiITXvXR2GacUfCvv0PeHYMEXH gRA+ZLnZvtkWYK/nlCrsKoBOkOi/jcIy6POigHveyxX214QwIg3WdyxPnT+yZ1rA78Gb rtxD7DcCu3sEfC7lClEyLMcfljwkO0DY3m5lE128xAYvI0HDgvNey9FB1CXhdDSU0WA5 6vwSYVfP1C+UkITfzLieYKd0mkdA2+w2wbPEuRzMzlFAKi0/M/+M1Pui3U3IgnvA2qkW iQT46ai6p/YLbPiXutMj6BkPL88zGBmFcw4iS3j+mIjl9YWVhzaPLpe3Kq11NLJkIn7K KoXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3JQKT8hd1HaVWRcwkxYWa6YHw1aTU0AJlM+7TJRadro=; b=ZkKUY/Bp97M8IpEYitGJEYTpaagmTtoSuP7IXtUjjYIIvU3FmOMpcNUvWgN4/O4lyj xFnOezKapbSOPRoAFRpyw1ZwdYUN0SzIJzhWSxvFwSPNrbZNYB9lu2KHHHdMFautlPLk 2sufTiWqbtVulYL5zAWqlVipSea+Tjf7f2BsjXY0qaATxE0zqdzqMbhO5Kt1LqJR2Yy7 vTDC/JUaaN9Xm1Jg2UXV7D7wHyrWTE9TnewaY862jOVpQYhGkRIvQE6kFuyBvr8ioMld VWc+demBHC+4bX11wR1GBI7dqOEZCeZwOTW1PM0HQrhJw9OKvisHnhCVq3dRZJ1U3sD2 /lnQ== X-Gm-Message-State: AKGB3mLcz8aMGDUiYcVGwBzIufLiP7bNJkxx5nkI7RCwnaYMIhmwL6Ti inOQqW5vl0Hz0psgRvJ70V4= X-Google-Smtp-Source: ACJfBosxoVWdwtBAvFBg1NAT6hvL4BqoRv4RVVnPEmpCjHDs+zglR/RkMXDJjwD/ZKAaWHT0MHnDZw== X-Received: by 10.37.108.4 with SMTP id h4mr1204833ybc.109.1513022785980; Mon, 11 Dec 2017 12:06:25 -0800 (PST) Received: from [192.168.2.5] (adsl-65-0-93-225.jan.bellsouth.net. [65.0.93.225]) by smtp.gmail.com with ESMTPSA id x134sm6846595ywg.15.2017.12.11.12.06.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Dec 2017 12:06:24 -0800 (PST) Subject: Re: [gentoo-user] How to repair a 'secondary Gentoo system' To: gentoo-user@lists.gentoo.org References: From: Dale Message-ID: Date: Mon, 11 Dec 2017 14:06:23 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: a104b75f-b57f-4dad-a2e5-18f22e6027f0 X-Archives-Hash: 3c86c84b24f3c85f40eea758c766a6d4 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 :-)  :-)