[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#902123: marked as done (finish-install: `update-initramfs -u` needs proc(5) and sysfs(5) resp. mounted to /proc and /sys for the cryptsetup hook)

Your message dated Sat, 8 Jun 2019 22:20:45 +0200
with message-id <20190608202045.GA16783@debian.org>
and subject line Re: Bug#902123: finish-install: `update-initramfs -u` needs proc(5) and sysfs(5) resp. mounted to /proc and /sys for the cryptsetup hook
has caused the Debian Bug report #902123,
regarding finish-install: `update-initramfs -u` needs proc(5) and sysfs(5) resp. mounted to /proc and /sys for the cryptsetup hook
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
902123: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902123
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: finish-install
Version: 2.94
Severity: important

Hi there,

Upgrading to cryptsetup ≥2:2.0.3-2 from d-i might yield an unbootable system
if the initramfs image is updated at finish-install stage.

That's because the cryptroot hook script is now relying on pseudo-filesystems
proc(5) (for /proc/{mounts,cpuinfo,cmdline}) and sysfs(5) (to generate the
block device hierarchy and determine which devices need to be unlocked at
initramfs stage).  These pseudo-filesystems are respectively mounted to
/target/proc and /target/sys during the installation of the base system, but
unmounted before finish-install's postinst script runs /usr/lib/finish-install.d/*.

So if the target system's root FS is on an encrypted system, and console-setup
is installed, then /usr/lib/finish-install.d/10update-initramfs triggers
`in-target update-initramfs -u -k all` without mountpoints /proc and /sys,
hence the cryptsetup(8) binaries and crypto modules aren't included in the
generated initramfs image, and the new system can't boot.  (I assume most
users won't see the big warning in the log file.)

A dirty fix would be to make the cryptsetup hook file mount /proc and /sys if
needed, but I'm quite reluctant to do that :-P  Is there a reason why proc(5)
and sysfs(5) are unmounted before finish-install stage?  Adding
`mount`/`umount` to /usr/lib/finish-install.d/10update-initramfs would not be
enough since other udebs might want to update the initramfs as well at
finish-install stage; for instance /usr/lib/finish-install.d/10open-iscsi from
open-iscsi-udeb.

Another thing, since the cryptsetup package split (≥2:2.0.3-1),
/usr/lib/finish-install.d/10update-initramfs should `dpkg-query -s
cryptsetup-initramfs` not cryptsetup.  If the target system has no encrypted
devices that need to be unlocked at initramfs stage (for instance, if only the
FS holding /home is on an encrypted device) then there is no need to deploy
cryptsetup's initramfs integration, but the cryptsetup scripts and binaries
might be installed regardless.

Cheers,
-- 
Guilhem.

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message --- 
On Fri, 22 Jun 2018 at 17:30:43 +0200, Guilhem Moulin wrote:
> Upgrading to cryptsetup ≥2:2.0.3-2 from d-i might yield an unbootable system
> if the initramfs image is updated at finish-install stage.
> 
> That's because the cryptroot hook script is now relying on pseudo-filesystems
> proc(5) (for /proc/{mounts,cpuinfo,cmdline}) and sysfs(5) (to generate the
> block device hierarchy and determine which devices need to be unlocked at
> initramfs stage).  These pseudo-filesystems are respectively mounted to
> /target/proc and /target/sys during the installation of the base system, but
> unmounted before finish-install's postinst script runs /usr/lib/finish-install.d/*.

Not sure what I did wrong at the time, but I'm no longer (nor anyone else)
able to reproduce this, and `in-target` does ensure (via chroot_setup())
that /target/proc and /target/sys are mounted before chroot()'ing.  Was
likely only a cryptsetup bug and 8ea400db fixed it :-)

> Another thing, since the cryptsetup package split (≥2:2.0.3-1),
> /usr/lib/finish-install.d/10update-initramfs should `dpkg-query -s
> cryptsetup-initramfs` not cryptsetup.  If the target system has no encrypted
> devices that need to be unlocked at initramfs stage (for instance, if only the
> FS holding /home is on an encrypted device) then there is no need to deploy
> cryptsetup's initramfs integration, but the cryptsetup scripts and binaries
> might be installed regardless.

Just filed #930228 and #930229 for this.

-- 
Guilhem.

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: