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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55129b9d.5020...@1und1.de