From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id MJFZIdltQmbt6AAAe85BDQ:P1 (envelope-from ) for ; Mon, 13 May 2024 21:45:29 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id MJFZIdltQmbt6AAAe85BDQ (envelope-from ) for ; Mon, 13 May 2024 21:45:29 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=protonmail.com header.s=protonmail3 header.b=jpzQEBD5; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1715629529; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=mdFbcsKV0tQiK1X1LFAu/JcWYVT1k3Ad3fXHFtG4PHc=; b=IlztAuVyJ/5r5kUTFHckRvV1T6cMRUdhjoVAxYpIA4mwcW3nZi03uQGamIBnFCm+Lg6No3 16McRhX2M8E4xD9qOACXFC0uqdlTggacmiI9ZqlTG1I1gWCX+frVVXsbafQFoX/K9/gOC5 X7ZvEx7LVnLK+Mexv9Stf5sfV8SOChFO8+hdenGl+gKuwknB4l6glsrp8FWM2Ok0JJseiD 3EyBZnNUJqONly6KUPFP5ueQliXVrCyzzbxhjKCk6tdrmbYH/NSJ8KEeAydTS7c38uhnzQ F4cHZ2SqjvadFy/CTcLJpNKx2yr2b8w2oT5XajS2EA04Ds+7GfCfKlRz3WFg+g== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1715629529; a=rsa-sha256; cv=none; b=bGcLBt7Pp86JlwByAR6nuEP3IZY2akg016/P0YuwyNfmDPEVrKn7VYaqdkb6zS4MVI3c9a XMRJCLox/bz1nw+uHPz/YjIWRlg9qbFGgmFzvH8zkzhCitOesePMBmmeUFPSSEbGctqThT FWl1dJoEfPkXhVer90ZGjSna2kj6QSJz3VR8q3Due3FQwpOj/1i0sug7MWtcC4XqbUnSP9 H8PzEH6mHWB977uuBXij2vZlnG4iPR/+YNuRtzagAgu/BBGgGluBFPk/PoxD8HVVF/+AJs +1m0LtiT3qCrxiB5RgD04M+OfaCL3xud3oUx3t6H1m+R1JieNg9MZqedu8m3Bw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=protonmail.com header.s=protonmail3 header.b=jpzQEBD5; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0AA8C1CA0 for ; Mon, 13 May 2024 21:45:29 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s6bbk-000792-SK; Mon, 13 May 2024 15:45:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s6bba-00075u-Tn for bug-guix@gnu.org; Mon, 13 May 2024 15:45:09 -0400 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s6bba-0003R5-44 for bug-guix@gnu.org; Mon, 13 May 2024 15:45:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s6bba-0008S0-G8 for bug-guix@gnu.org; Mon, 13 May 2024 15:45:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#70897: Guix system hangs on boot with LUKS root partition Resent-From: Kaelyn Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 13 May 2024 19:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70897 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 70897@debbugs.gnu.org Received: via spool by 70897-submit@debbugs.gnu.org id=B70897.171562949932461 (code B ref 70897); Mon, 13 May 2024 19:45:02 +0000 Received: (at 70897) by debbugs.gnu.org; 13 May 2024 19:44:59 +0000 Received: from localhost ([127.0.0.1]:34470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s6bbW-0008RV-Sp for submit@debbugs.gnu.org; Mon, 13 May 2024 15:44:59 -0400 Received: from mail-4322.protonmail.ch ([185.70.43.22]:60845) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s6bbS-0008RL-MI for 70897@debbugs.gnu.org; Mon, 13 May 2024 15:44:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1715629487; x=1715888687; bh=mdFbcsKV0tQiK1X1LFAu/JcWYVT1k3Ad3fXHFtG4PHc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=jpzQEBD5kwmfxgSEsXpECUAD2HO368qijFGZbSrSAzP7YMOmhoNhpbsk75TA1hrHn blQ8HGQ+w4uklBGWsAncZAoyezI81M3j9JuAl4s0dhvtORFx+62yWJJiSa9mtOXrij aZNiZe6AAEuB5Fm/m62Thfj7d7aC2upPeh8g+Ey2SWMTaFrozyjzr0LZmCfVITAWQN o6cBJpWcWHGqCmOGsxBIDmcwkcbKtFtbD4RBC7MKzUeBcB1PJb/LIndmtsZps5CrKq HDR7loocvHMXEF07AmvNn5OiuWtUKns0QiB7it3byEUa+N9Y+i4qv+5Mbw98LMIdOu BBhbaHjOBV/0g== Date: Mon, 13 May 2024 19:44:41 +0000 Message-ID: In-Reply-To: <87ikzic92t.fsf@gnu.org> References: <87ikzic92t.fsf@gnu.org> Feedback-ID: 34709329:user:proton X-Pm-Message-ID: 1f6c7213668183e748092f6f3804384c52fa4ab6 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Kaelyn From: Kaelyn via Bug reports for GNU Guix Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: bug-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -3.87 X-Spam-Score: -3.87 X-Migadu-Queue-Id: 0AA8C1CA0 X-Migadu-Scanner: mx11.migadu.com X-TUID: Mrwy8aEGuAeM Hi Ludo', On Monday, May 13th, 2024 at 3:14 AM, Ludovic Court=C3=A8s w= rote: >=20 >=20 > Hi Kaelyn, >=20 > Kaelyn kaelyn.alexi@protonmail.com skribis: >=20 > > I recently updated my systems after finally finding https://issues.guix= .gnu.org/70051 and seeing the issue I was having with booting with a non-ro= ot LUKS partition configured had been fixed. After updating to a commit pas= t these two: > >=20 > > 49f82fca41 mapped-devices: luks: Specify modules needed at the top-leve= l. > > 6062339156 mapped-devices: can specify modules to = import. > >=20 > > I am now seeing a different error, which I am pretty sure is related > > to the module import changes in 49f82fca41. The error I get is about > > an unknown symbol "system*/tty" when the initramfs tries to prompt for > > a password to unlock the LUKS partition containing the root > > filesystem. >=20 >=20 > To be clear, you have both a LUKS-encrypted root and a non-root > LUKS-encrypted partition? >=20 > (FWIW I tested (1) with a LUKS-encrypted root, and (2) with a cleartext > root and LUKS-encrypted /home. The bug you mention affected #2.) More accurately, I have one system that has a mirrored btrfs root with two = LUKS-encrypted partitions (and a few quirks in the setup that make rebootin= g a bit tedious, such as grub slowly unlocking two drives, and a ZFS pool t= hat has to be unlocked manually after boot), and one with a single LUKS-enc= rypted btrfs partition. I hit (2) on the first system about a month ago whe= n I updated both, with the second system booting fine. I hit (1) on the sec= ond system when updating much more recently after seeing (2) was fixed, and= hadn't tried rebooting the first system with the new generation. > Could you share your OS config or a relevant subset thereof? My full OS config is decidedly non-trivial, with parts (e.g. common service= s and user accounts) shared between host configurations. The mapped-devices= and file-systems fragments for the two systems are below. For the first system, with the mirrored btrfs root: (mapped-devices (list (mapped-device (source (uuid "7bcca55e-8a41-44a8-beab-2047eed0af41")) (target "cryptroot1") (type luks-device-mapping)) (mapped-device (source (uuid "9472b8ae-c90c-4712-b90d-ca07602514d7")) (target "cryptroot2") (type luks-device-mapping)) )) (file-systems (let ((rootfs (file-system (mount-point "/") (device "/dev/mapper/cryptroot1") (type "btrfs") (check? #f) (options "compress=3Dzstd,subvol=3D@guix") (dependencies mapped-devices)))) (cons* rootfs (file-system (mount-point "/boot/efi") (device (file-system-label "EFI")) (type "vfat") (mount-may-fail? #t) (dependencies mapped-devices)) (file-system (mount-point "/gnu") (device "/dev/mapper/cryptroot1") (type "btrfs") (check? #f) (options "compress=3Dzstd,subvol=3D@gnu_store") (dependencies (cons rootfs mapped-devices))) %base-file-systems)))) The second system, with the single-drive encrypted btrfs root: (mapped-devices (list (mapped-device (source (uuid "e6aaafc5-49cb-477b-a665-daf065611195")) (target "cryptroot1") (type luks-device-mapping)) )) (file-systems (let ((rootfs (file-system (mount-point "/") (device "/dev/mapper/cryptroot1") (type "btrfs") (check? #f) (options "compress=3Dzstd,subvol=3D@guix") (dependencies mapped-devices)))) (cons* rootfs (file-system (mount-point "/boot/efi") (device (file-system-label "EFI")) (type "vfat") (mount-may-fail? #t) (dependencies mapped-devices)) (file-system (mount-point "/gnu") (device "/dev/mapper/cryptroot1") (type "btrfs") (check? #f) (options "compress=3Dzstd,subvol=3D@gnu_store") (dependencies (cons rootfs mapped-devices))) %common-file-systems)))) (Note the %common-file-systems is simply %base-file-systems plus a couple o= f NFS mounts from the first system, which are shared with several computers= .) For both computers, I make use of the 6.1 or 6.6 LTS kernels since I also u= se ZFS. When I hit (1), I eventually figured out where the hang during boot= was happening by removing "quiet" from the kernel command line, which also= caused shepherd to be more verbose (something I hadn't realized). When I h= it (2), the boot process was still in the initrd due to failing to unlock a= nd mount the root filesystem. If there is any further information I can provide, please let me know. Cheers, Kaelyn >=20 > > I don't know how the module plumbing of Shepherd and the generated > > initramfs work, but I suspect the fix for Shepherd opening LUKS > > partition broke the import of system*/tty in the initramfs (for > > example, at the early REPL that booting my latest system generation > > ends up at, system*/tty is undefined initially, but after evaluating > > "(use-modules (gnu build file-systems))" system*/tty resolves to a > > procedure as exected--so the module is at least present in the > > initramfs). I have encountered this error with two different systems, > > and I believe the reproduction is simply trying to open a LUKS device > > without a keyfile so that a password prompt is necessary. >=20 >=20 > Hmm. Thanks for investigating! >=20 > Ludo=E2=80=99.