Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails
Stefan Lippers-Hollmann
s.l-h at gmx.de
Sun Jul 19 23:16:12 UTC 2015
Hi
On 2015-07-19, Bastian Blank wrote:
> On Thu, Jul 09, 2015 at 05:16:57AM +0200, Stefan Lippers-Hollmann wrote:
> > Upgrading src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting due to
> > a new systemd unit dependency failures regarding lvmetad when mounting
> > non-rootfs logical volumes. Jumping to the emergency shell and invoking
> > "vgchange -ay" and "mount -a" allows booting to finish.
>
> Please provide all information from the system regarding the storage.
> This includes:
> - /etc/fstab
already provided in the original submission:
# cat /etc/fstab
# /etc/fstab: filesystem table.
#
# filesystem mountpoint type options dump pass
/dev/vg-redstone/debian64 / ext4 defaults,noatime,barrier=0 1 1
LABEL=UEFI /boot/efi vfat auto,user,exec,nodev,nosuid,noatime 1 2
/dev/vg-redstone/swap none swap sw 0 0
/dev/vg-redstone/var /var ext4 auto,user,exec,dev,noatime,barrier=0 1 2
/var/tmp /tmp none bind 0 0
/dev/vg-redstone/home /home ext4 auto,user,exec,nodev,nosuid,noatime,barrier=0 1 2
/dev/vg-redstone/storage /srv/storage ext4 auto,user,noexec,nodev,nosuid,noatime,barrier=0 1 2
LABEL=seagate /srv/seagate ext4 auto,user,noexec,nodev,nosuid,noatime 1 2
> - /etc/lvm/lvm.conf
/etc/lvm/lvm.conf is unchanged from the package default of lvm2
2.02.122-2, but I've attached it (gzipped) nevertheless.
$ md5sum -b /etc/lvm/lvm.conf
de7411c6a935b065dd7dcde6208c364f */etc/lvm/lvm.conf
> - pvs, vgs, lvs
# pvs
PV VG Fmt Attr PSize PFree
/dev/sdb2 vg-redstone lvm2 a-- 800,00g 446,00g
# vgs
VG #PV #LV #SN Attr VSize VFree
vg-redstone 1 5 0 wz--n- 800,00g 446,00g
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
debian64 vg-redstone -wi-ao---- 10,00g
home vg-redstone -wi-ao---- 30,00g
storage vg-redstone -wi-ao---- 300,00g
swap vg-redstone -wi-ao---- 4,00g
var vg-redstone -wi-ao---- 10,00g
> - lsblk
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 2,7T 0 disk
├─sda1 8:1 0 299M 0 part
└─sda2 8:2 0 2,7T 0 part /srv/seagate
sdb 8:16 0 931,5G 0 disk
├─sdb1 8:17 0 300M 0 part /boot/efi
└─sdb2 8:18 0 800G 0 part
├─vg--redstone-debian64 254:0 0 10G 0 lvm /
├─vg--redstone-var 254:1 0 10G 0 lvm /var
├─vg--redstone-home 254:2 0 30G 0 lvm /home
├─vg--redstone-swap 254:3 0 4G 0 lvm [SWAP]
└─vg--redstone-storage 254:4 0 300G 0 lvm /srv/storage
> - systemctl status in broken state
Taken, and stored in a temporary file, from within the emergency shell.
$ zcat systemctl-status.log.gz
● redstone
State: maintenance
Jobs: 0 queued
Failed: 1 units
Since: Mo 2015-07-20 00:04:38 CEST; 2min 18s ago
CGroup: /
├─1 /sbin/init
└─system.slice
├─lvm2-lvmetad.service
│ └─200 /sbin/lvmetad -f
├─emergency.service
│ ├─573 /bin/sh -c /sbin/sulogin; /bin/systemctl --job-mode=fail --no-block default
│ ├─576 bash
│ └─588 systemctl status
├─systemd-journald.service
│ └─199 /lib/systemd/systemd-journald
├─systemd-networkd.service
│ └─369 /lib/systemd/systemd-networkd
└─systemd-udevd.service
└─203 /lib/systemd/systemd-udevd
> > Kernel: Linux 4.1.0-1.slh.3-aptosid-amd64 (SMP w/2 CPU cores; PREEMPT)
>
> Ah, this is no Debian system at all.
It is a Debian system, I'm just usually running the kernel[1] I'm
developing and working on - but even though I picked the "wrong
one" when submitting the bug, the problem can be reproduced easily
using Debian's linux-image-4.0.0-2-amd64:
All logs above have been gathered using:
$ dpkg -l | grep -e linux-image-amd64 -e linux-image-4.0.0-2-amd64 -e 2.02.122-2 -e 2:1.02.99-2
ii dmeventd 2:1.02.99-2 amd64 Linux Kernel Device Mapper event daemon
ii dmsetup 2:1.02.99-2 amd64 Linux Kernel Device Mapper userspace library
ii libdevmapper-event1.02.1:amd64 2:1.02.99-2 amd64 Linux Kernel Device Mapper event support library
ii libdevmapper1.02.1:amd64 2:1.02.99-2 amd64 Linux Kernel Device Mapper userspace library
ii liblvm2app2.2:amd64 2.02.122-2 amd64 LVM2 application library
ii liblvm2cmd2.02:amd64 2.02.122-2 amd64 LVM2 command library
ii linux-image-4.0.0-2-amd64 4.0.8-1 amd64 Linux 4.0 for 64-bit PCs
ii linux-image-amd64 4.0+65 amd64 Linux for 64-bit PCs (meta-package)
ii lvm2 2.02.122-2 amd64 Linux Logical Volume Manager
$ cat /proc/version
Linux version 4.0.0-2-amd64 (debian-kernel at lists.debian.org) (gcc version 4.9.3 (Debian 4.9.3-1) ) #1 SMP Debian 4.0.8-1 (2015-07-11)
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.0.0-2-amd64 root=/dev/mapper/vg--redstone-debian64 ro quiet systemd.show_status=1
This particular system is running in UEFI mode, but I can reproduce it
just as well on other (older) systems in BIOS mode.
Starting with lvm2 2.02.122-2, it suddenly boots fine ~40% of the time,
while it fails booting the during the other attempts (with the logs
above). Interesting enough, systems using a SSD for the system
mountpoints usually succeed booting most of the time, while systems
with only spinning HDDs seem to be mouch more likely to be affected.
Using src:lvm2 2.02.122-1 it reliably failed all the time, while that
never happened with src:lvm2 <= 2.02.111-2.2.
I'm affected by this problem on more than 10, fairly different, systems.
After logging into the emergency shell, I can activate the volume group
manually using "vgchange -ay", mount the missing logical volumes with
"mount -a" and exit the emergency shell to continue the boot process.
Regards
Stefan Lippers-Hollmann
[1] Vcs-git: git://github.com/fullstory/linux-aptosid.git
Vcs-Browser: https://github.com/fullstory/linux-aptosid
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lvm.conf.gz
Type: application/gzip
Size: 19667 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20150720/1acda7a6/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20150720/1acda7a6/attachment-0001.sig>
More information about the pkg-lvm-maintainers
mailing list