On 2018-12-24 7:09 a.m., Rafał Olejnik wrote:
> On Mon, 24 Dec 2018 13:34:40 +0800 John Wong wrote:
>> On 12/24/18 12:58 PM, John Wong wrote:
>> > Yes, udev 240-1 break my lvm2 system.
>> >
>> Hi, replace /lib/systemd/systemd-udevd with udev version 239's
>> (/lib/systemd/systemd-udevd), then update-initramfs -u.
>>
>> I can boot my system again.
>
> This works however errors about lvm are still shown:
>
> lvm2-activation-generator: lvmconfig failed
>
> lvm2-activation-generator: Activation generator failed.
I am also encountering this problem.
To prevent LVM-related errors, I have had to hold these packages at the
versions shown (output of apt-show-versions -u):
libudev1:amd64/sid 239-15 upgradeable to 240-1
lvm2:amd64/sid 2.02.176-4.1 upgradeable to 2.03.01-2
udev:amd64/sid 239-15 upgradeable to 240-1
If I allow lvm2 to upgrade to 2.03.01-2 (while holding udev/libudev1 at
the old version 239-15), I get the following in the log at bootup:
Dec 24 07:59:07 sid lvm2-activation-generator: lvmconfig failed
Dec 24 07:59:07 sid lvm2-activation-generator: Activation generator failed.
Dec 24 07:59:07 sid systemd[272]:
/lib/systemd/system-generators/lvm2-activation-generator failed with
exit status 1.
This seems harmless enough, as the boot still succeeds, and all my LVs
are mapped correctly (output from ls -l /dev/mapper/):
lrwxrwxrwx 1 root root 7 Dec 24 07:59 vg0-home -> ../dm-1
lrwxrwxrwx 1 root root 7 Dec 24 07:59 vg0-root -> ../dm-0
lrwxrwxrwx 1 root root 7 Dec 24 07:59 vg0-swap -> ../dm-2
If, instead, I allow udev and libudev1 to upgrade to 240-1 (while
holding lvm2 at the old version 2.02.176-4.1), then after a reboot, my
root LV goes "missing" (again, output from ls -l /dev/mapper/):
lrwxrwxrwx 1 root root 7 Dec 24 08:28 vg0-home -> ../dm-1
lrwxrwxrwx 1 root root 7 Dec 24 08:28 vg0-swap -> ../dm-2
Of course, the root LV is really still there (output of lvs):
LVVG Attr LSize
home vg0 -wi-ao <193.13g
root vg0 -wi-ao 18.62g
swap vg0 -wi-ao <7.64g
But this mapper glitch appears to cause problems for update-initramfs
and for update-grub, i.e.:
root@sid:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.19.0-1-amd64
Warning: couldn't identify filesystem type for fsck hook, ignoring.
root@sid:~# update-grub
/usr/sbin/grub-probe: error: failed to get canonical path of
`/dev/mapper/vg0-root'.
Additionally, during bootup, fsck fails on /dev/mapper/vg0-root,
complaining that the device is not found.
I hope my report can be of some help.
In summary, my workaround for the current problems with udev and lvm2
are to hold my udev and lvm2 packages to these versions:
libudev1:amd64/sid 239-15
lvm2:amd64/sid 2.02.176-4.1
udev:amd64/sid 239-15
/---
/-SM
/
