From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fredrik Salomonsson Subject: Re: btrfs and subvolumes for root, take 2 Date: Sun, 02 Dec 2018 17:56:07 -0800 Message-ID: <87lg57tlu0.fsf@gmail.com> References: <877eh1otpy.fsf@gmail.com> <87lg5d15qq.fsf@gnu.org> <87mupoedkr.fsf@gmail.com> <87efb0ngoy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gTdT3-0000S9-3P for help-guix@gnu.org; Sun, 02 Dec 2018 20:56:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gTdT2-0000A5-39 for help-guix@gnu.org; Sun, 02 Dec 2018 20:56:13 -0500 In-Reply-To: <87efb0ngoy.fsf@gnu.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: help-guix Hi, Ludovic Court=C3=A8s writes: > Fredrik Salomonsson skribis: > >> Ludovic Court=C3=A8s writes: >> >>> The Guile backtrace you sent shows that /etc/ssl already existed when >>> your system booted and was not a symlink. This led the =E2=80=9Cactiva= tion >>> code=E2=80=9D of GuixSD to fail: >>> >>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/activation.= scm#n320 >>> >>> The solution is to remove /etc/ssl (is it coming from another distro >>> previously installed on this device?). You can boot a separate medium,= =20 >>> mount the root partition, and =E2=80=9Crm -rf /etc/ssl=E2=80=9D from th= ere. Or you can, >>> at the boot REPL that you get after the backtrace, type something like: >>> >>> ,use (guix build utils) >>> (delete-file-recursively "/etc/ssl") >>> ,q >>> >>> Note that you might have similar issues with /etc/pam.d, for instance, >>> if there=E2=80=99s such a stale directory. >> >> Thanks for the reply. That pointed me in the right direction. Although >> the solution you suggested wasn't an option for me. As it turned out, it >> was actually mounting my Arch Linux root (__current/arch-root). Which I >> had set to be the default subvolume if no ~subvol=3D~ option is given wh= en >> mounting the disk. > > Clearly / or /etc cannot be shared between GuixSD and another distro; > each distro needs to have full control over these. My suggestion would > be to share nothing but /home (and /gnu, /var/guix, and /etc/guix if you > want to able to use Guix on the other distro). > > I can=E2=80=99t really advise more than this since the specifics are then= a > matter of taste. :-) I think you misunderstood what I meant. I'm not sharing / or /etc between GuixSD and Arch linux. Both have their own / (and /etc), in their own subvolume (think partitions for ext4). See this thread for a full explanation of my disk layout: https://lists.gnu.org/archive/html/help-guix/2017-08/msg00011.html But in short, only /home, /gnu, /var/guix and /boot/grub are shared between the two. The issue I had was that for some reason when booting GuixSD. It ignore the rootflags for mounting GuixSD's /, instead it mounted the / for Arch, as that was the default. Which causes the error. Clearly I do not want it to share /etc between the two, that would be madness. :) I worked around that by changing the default to GuixSD's /. So now it's mounting the correct subvolumes. Sorry about the confusion. --=20 s/Fred[re]+i[ck]+/Fredrik/g