[From nobody Tue Jun 16 15:09:09 2026 Received: (at 1140141-close) by bugs.debian.org; 16 Jun 2026 14:07:51 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-115.5 required=4.0 tests=ALL_TRUSTED,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, FOURLA,FROMDEVELOPER,HAS_BUG_NUMBER,PGPSIGNATURE,SPF_HELO_NONE, SPF_PASS,USER_IN_DKIM_WELCOMELIST autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 12; hammy, 125; neutral, 45; spammy, 0. spammytokens: hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin, 0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311, 0.000-+--H*RT:311, 0.000-+--H*RT:108 Return-path: <guilhem@debian.org> Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:48586) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <guilhem@debian.org>) id 1wZUSF-00FQBy-0P for 1140141-close@bugs.debian.org; Tue, 16 Jun 2026 14:07:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ZPJpCJpFE+S8mcEGkSmiZ/zlaowGbtQnAWez1dG5mpw=; b=aiEK0NsH4idZOYy+tZDnAFanoV V7UFQCvjCHWlA/UrNWL378eMF8JePmsQcul8yE1LxA6AnkKEH76Qwgaono2Dh5TxBTWQXPVNR6g6E 0MEiRcE6WOifrcO5H2K9wbf1PrSBwdQs/BvWM8HnUbvrI6Ync50HLf+2LXwPLtMcmMBQz3jpJxctG KFUL2Ec3KGRXw8q6ZXgTR7iMNOJAtMIGVzZhdZXZI6JEs/5ShY9GOpI4A5wtcaKd2seVHNpfDQ9pw 3MziOdq8AI90+T7ob560Nx2N7jCt87L6mBfnecIyQ8ukmdJw2BLvmh9BCM+3kOpy8dFwyU//JU8Eh El/XE+Dg==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <guilhem@debian.org>) id 1wZUSD-00DtxT-1L; Tue, 16 Jun 2026 14:07:49 +0000 Received: by localhost.localdomain (Postfix, from userid 1000) id 3B2DB420051; Tue, 16 Jun 2026 16:07:46 +0200 (CEST) Date: Tue, 16 Jun 2026 16:07:46 +0200 From: Guilhem Moulin <guilhem@debian.org> To: Alex <alex@alex.com> Cc: 1140141-close@bugs.debian.org Subject: Re: Bug#1140141: cryptsetup: Failure to boot fresh install via cryptroot-unlock with an encrypted home partition Message-ID: <ajFYstpxGt3GWVFq@debian.org> Mail-Followup-To: Guilhem Moulin <guilhem@debian.org>, Alex <alex@alex.com>, 1140141-close@bugs.debian.org References: <178161496707.2450742.2048347332975560589.reportbug@Oholtza.adimen.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="o105NPSbEen2pvZ1" Content-Disposition: inline In-Reply-To: <178161496707.2450742.2048347332975560589.reportbug@Oholtza.adimen.net> X-Debian-User: guilhem --o105NPSbEen2pvZ1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, 16 Jun 2026 at 08:02:47 -0500, Alex wrote: > I created a fresh install of Debian Trixie with the installation media. D= uring the installation, I created a separate partition for /home in a LUKS = encrypted device. > Upon booting for the first time, I could unlock these devices and boot no= rmally by interacting directly with the physical computer, but when attempt= ing to log in remotely via dropbear and unlock with cryptroot-unlock, I was= unable to do so successfully (I was not prompted to unlock the /home devic= e). > > I tested with only an encrypted /root separate from /boot. Using the same= procedure, I was able to successfully boot using dropbear and cryptroot-un= lock in this case. > > It appears that cryptroot-unlock does not properly prompt for all require= d boot devices even when booting can take place correctly via the normal te= rminal when interacting directly with the physical computer. cryptroot-unlock processes only devices that are configured for unlocking at initramfs stage there. Either because they are required (the device is holding the root file system, /usr, or the resume device), or because they have been manually configured with the `initramfs` crypttab(5) option. It appears your device is not configured to be unlocked at initramfs stage. When at the computer (not remotely), the unlocking happens by systemd later in the boot process. Use the `initramfs` crypttab(5) option and rebuild the initramfs if you want to unlock it at initramfs stage instead. --=20 Guilhem. --o105NPSbEen2pvZ1 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAmoxWLIACgkQ05pJnDwh pVIN0w/9F1/WIxl7HfflU8p2mH6kv5iO1aZ6+Z7tU9k7EMcd31pS36EcJuqflYck L2g41viZaa8M64iadzhsY2MdRAFIUDxGllV2VYulYVj9IDCWeiPYGLe/J/lIVnBU HA71mmHiy0onrkZJTXy0eZbCzOZStZRNjKG423MnYl9oi5nDG4J1f4rm4Jdzthlp lnyuU17b81HujGDuAupLcYiLH9gvZCjmzUvGqA7F77uyBYdbcaFitDMUlbo2xrzs coBBLO3RiIi5adGljacsaEf+HX7HOYfl0spAW+xpbLtXY58K5KbM2bQrone8S9FR M1ZKUyuzMLGmpAP+wQ5/3CL9NFg6hAQqvn5pQeolZ6/AN1mfnhE0rWA5yQnrzdxO VhZ4CVri8XZIZQO2ofrUAva6qcFRrcQuQkRXeXTHfRUrW6B1wjRCAkc6mHN07Q89 ofZ7kCIKCc9vvd4K+NFgwuAr5uUPyzAkE0zQ4zJMCLa+bZNPYJ+KDaXsDqiQfvTM T+oYYXE7vm0ZfZdK0NHgMALS+RHaM1sPB22n30Kcb88ibDHMJ1wShKSkc5fFD3z2 Az4829cLFCvD2SPmqp4Ba5EZvjIxZXuRzk65FcvvdASIdJB+1fNdrtIALScgkFfD yuzV4QKYF0mkKyaj44HQMHzhPriy1WLUSSskNDVaRAD6IxYQ1Jo= =S++A -----END PGP SIGNATURE----- --o105NPSbEen2pvZ1-- ]