<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hmm. As far as the installer goes, having the debian-installer
mark the device with <span class="term"><code class="option">x-initrd.attach</code></span>
which appears to have similar functionality (systemd fomat) but
not <span class="term"><code class="option">initramfs</code></span> seems
like an oversight or a bug in itself. The installer should leave
the computer in a bootable state. I suppose the installer should
either also add the <span class="term"><code class="option">initramfs</code></span> option,
or else the <span class="term"><code class="option">x-initrd.attach </code></span>flag
it already adds should produce similar behaviour for the purposes
of determining drives required at initramfs time.</p>
<p><br>
</p>
<p>On Tue, 16 Jun 2026 16:07:46 +0200 Guilhem Moulin
<a class="moz-txt-link-rfc2396E" href="mailto:guilhem@debian.org"><guilhem@debian.org></a> wrote:</p>
> Hi,<br>
> <br>
> On Tue, 16 Jun 2026 at 08:02:47 -0500, Alex wrote:<br>
> > I created a fresh install of Debian Trixie with the
installation media. During the installation, I created a separate
partition for /home in a LUKS encrypted device.<br>
> > Upon booting for the first time, I could unlock these
devices and boot normally by interacting directly with the physical
computer, but when attempting 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 device).<br>
> ><br>
> > I tested with only an encrypted /root separate from /boot.
Using the same procedure, I was able to successfully boot using
dropbear and cryptroot-unlock in this case.<br>
> ><br>
> > It appears that cryptroot-unlock does not properly prompt
for all required boot devices even when booting can take place
correctly via the normal terminal when interacting directly with the
physical computer.<br>
> <br>
> cryptroot-unlock processes only devices that are configured for<br>
> unlocking at initramfs stage there. Either because they are
required<br>
> (the device is holding the root file system, /usr, or the
resume<br>
> device), or because they have been manually configured with the<br>
> `initramfs` crypttab(5) option.<br>
> <br>
> It appears your device is not configured to be unlocked at
initramfs<br>
> stage. When at the computer (not remotely), the unlocking
happens by<br>
> systemd later in the boot process. Use the `initramfs`
crypttab(5)<br>
> option and rebuild the initramfs if you want to unlock it at
initramfs<br>
> stage instead.<br>
> <br>
> -- <br>
> Guilhem.<br>
<br>
</body>
</html>