Your message dated Fri, 31 May 2019 14:55:04 +0200
with message-id <[email protected]>
and subject line Re: Bug#929782: cryptsetup-initramfs: Detects rootfs
incorrectly
has caused the Debian Bug report #929782,
regarding cryptsetup-initramfs: autodetection should use /etc/fstab not
/proc/mounts
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 [email protected]
immediately.)
--
929782: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929782
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: cryptsetup-initramfs
Version: 2:2.1.0-3
Severity: important
Dear Maintainer,
Usually, all my systems use "encrypted_root" as a name for rootfs.
fstab looks like this:
/dev/mapper/encrypted_root / ext4 errors=remount-ro 0
1
crypttab looks like this:
encrypted_root UUID=whatever none luks
However, when installing new system from a live system I can't mount new
rootfs as "encrypted_root" because it is already used by live rootfs, so
I mount it as "new_root". Remember that fstab and crypttab of all
systems have "encrypted_root" as the name of rootfs in them.
Now when I chroot into new system and do "update-initramfs -u" I get
"target 'new_root' is not found in /etc/crypttab".
This is very wrong. Somehow the update script gets the name of rootfs as
it is currently mounted (which doesn't matter) and uses it down the line.
The algorithm should be:
* Look in fstab and see the name of rootfs.
* Look in crypttab and see if the name exists there.
* If it exists, add crypt modules, if it doesn't, display warning as usual.
The script should never care how rootfs is mounted at the time of
running because it may be chroot in live system or rescue system or
whatever.
-- Package-specific info:
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.0.0-trunk-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cryptsetup-initramfs depends on:
ii busybox 1:1.30.1-4
ii cryptsetup-run 2:2.1.0-3
ii initramfs-tools [linux-initramfs-tool] 0.133
Versions of packages cryptsetup-initramfs recommends:
ii console-setup 1.191
ii kbd 2.0.4-4
cryptsetup-initramfs suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi,
On Fri, 31 May 2019 at 06:47:00 +0000, Lyberta wrote:
> This is very wrong. Somehow the update script gets the name of rootfs as
> it is currently mounted (which doesn't matter) and uses it down the line.
This is documented in NEWS.Debian. Using /proc/mounts instead of
/etc/fstab is deliberate and in line with initramfs-tools/hooks/resume
(which uses /proc/swaps for autodetection). And is arguably more
robust, in case the source block device uses non-persistent names such
as /dev/sda1. Also not all filesystems use /etc/fstab — I heard zfs for
one normally doesn't — and we don't want to parse /proc/cmdline with
special cases for each of such file system. Using /proc/mounts and
sysfs(5) is the common denominator here.
> The algorithm should be:
>
> * Look in fstab and see the name of rootfs.
> * Look in crypttab and see if the name exists there.
In fstab(5) the source device can be specified as a UUID not a mapped
device name, so we can't rely on fstab(5) and crypttab(5) alone. And
your proposed logic won't work well with detached headers, which might
be long gone by the time the initramfs image is created.
Moreover your algorithm only works for simpler device stacks. We
support more complex ones, such as / in an LV spanning over multiple
encrypted PVs; or / in an MD over multiple encrypted drives; or / in a
multiple btrfs filesystem; etc. We traverse the sysfs(5) hierarchy to
discover the underlying stack, as we can't rely on fstab(5) (or
/proc/mounts) and crypttab(5) alone.
> The script should never care how rootfs is mounted at the time of
> running because it may be chroot in live system or rescue system or
> whatever.
update-initramfs(8) does require the root device to be mounted to /, so
I guess you mean “the script should never care *about the mapped device
names*” here? That's a valid point (although not ‘Severity: important’,
perhaps ‘wishlist’), but naively replacing /proc/mounts with /etc/fstab
would break other use-cases and invariants.
Thus closing this as wontfix, sorry. In your live system you can run
`dmsetup rename encrypted_root encrypted_liveroot` so you can map the
new root device as ‘encrypted_root’ before creating the initramfs image
from the chroot.
Cheers,
--
Guilhem.
signature.asc
Description: PGP signature
--- End Message ---
