Bug#776409: —Bug#767832— not fixed in cryptsetup 2:1.6.6-4 nor 2:1.6.6-5
Hi,
we have most likely observed the same, or a very similar, bug when
upgrading two test systems from Wheezy to Jessie.
Important: We use LVM for everything but / and /boot.
The default fstab looks like this:
LABEL=boot /boot ext3
defaults,errors=remount-ro,noatime 0 2
LABEL=slash / ext3
defaults,errors=remount-ro,noatime 0 1
proc /proc proc
defaults 0 0
LABEL=tmp /tmp xfs
defaults,noatime,nosuid,nodev 0 0
LABEL=var /var xfs
defaults,noatime 0 0
LABEL=usr /usr xfs
defaults,noatime 0 0
LABEL=home /home xfs
defaults,noatime,nosuid,nodev 0 0
LABEL=swap none swap sw
blkid output like this:
/dev/sda1: LABEL="boot"
/dev/sda2: LABEL="slash"
/dev/sda3: TYPE="LVM2_member"...
/dev/mapper/vg00-usr: LABEL="usr"...
/dev/mapper/vg00-tmp: LABEL="tmp"...
/dev/mapper/vg00-var: LABEL="var"...
/dev/mapper/vg00-home: LABEL="home"...
/dev/mapper/vg00-swap: LABEL="swap"...
/dev/mapper/vg00-data: LABEL="data"...
The initramfs loops in "Begin: Running /scripts/local-block ... done."
until it gives up.
It seems, it did not recognize that /usr is on a logical volume and did
not attempt to activate it. Indeed, the device nodes are missing and
manually running "vgchange -ay" in the emergency shell allows the boot
to continue successfully.
Modifying fstab like this fixes things (all other filesystems continue
to use LABEL):
...
/dev/mapper/vg00-usr /usr xfs
defaults,noatime 0 0
...
So, I suspect this bug is triggered by the use of UUID or LABEL in fstab
for a split /usr when using any form of device-mapper (not only dm-crypt).
scripts/local-block/lvm2 has this code, that looks very suspect:
# Make sure that we have a d-m path
dev="${dev#/dev/mapper/}"
if [ "$dev" = "$1" ]; then
return 1
fi
No idea how to fix this except by doing an unconditional LVM activation.
Regards,
Marc
Reply to: