Summary: | =sys-fs/lvm2-2.02.183 USE=udev leads to long delays in the initramfs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Herbert Wantesh <rauchwolke> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | agk, bkohler, cardoe, gentoo, polynomial-c, robbat2, slzoutendijk |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=684882 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
my complete /etc/init.d/assemble-raid script
dmesg.log |
Description
Herbert Wantesh
2019-04-05 11:00:55 UTC
I also see this error when trying to run grub-install and root on LVM etc. :-( Basically grub tries every device for 10s and fails, and again, and again... Workaround is to forward host lvm into chroot, see here https://bbs.archlinux.org/viewtopic.php?id=242594 I guess my last message was not very clear... I chroot into my new root partition that is one LVM on LUKS and try to grub-install into /dev/sda -> this fails unless /run/lvm from host is imported into the chroot. This seems to be fixed in the new upstream release 2.02.184 The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=53d8205ff9f4533c17a265a88e44363fd9fd66ed commit 53d8205ff9f4533c17a265a88e44363fd9fd66ed Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2019-04-08 18:34:13 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2019-04-08 18:34:27 +0000 sys-fs/lvm2: Bump to version 2.02.184 this should fix udev related issues as well as scan_lvs issues. Bug: https://bugs.gentoo.org/682578 Bug: https://bugs.gentoo.org/682380 Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> sys-fs/lvm2/Manifest | 1 + sys-fs/lvm2/lvm2-2.02.184.ebuild | 258 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 259 insertions(+) Please test =sys-fs/lvm2-2.02.184 and report back success/failure. i test =sys-fs/lvm2-2.02.184-r1 and it fixes the problem for me, thanks Tried again, unfortunately on another box and not totally identical setup, but the grub-install worked ok with 184-r1. Please change severity of this bug to critical or blocker. It rendered my system entirely unbootable and I had to do an hour and a half of rescue work to get it back. Perhaps I needed to wait several more minutes? Please mask or remove this ebuild ASAP!!! I can confirm that this is not about rather or not you have udev started. I start my raid via init script and it still happens. depend() { after sysfs devfs udev before checkfs fsck } assemble() { /sbin/fsck /dev/nvme0n1p1 || return 1 /bin/mount /mnt/nvme0 || return 1 /sbin/mdadm --assemble /dev/md0 /dev/sd{a,b,c,d}1 --bitmap /mnt/nvme0/md0-write-intent.dat || return 1 /sbin/vgchange -ay /dev/vg0 || return 1 } disassemble() { /sbin/vgchange -an /dev/vg0 || return 1 /sbin/mdadm --stop /dev/md0 || return 1 /bin/umount /mnt/nvme0 || return 1 } Please also share the dmesg output that shows the udev delays. It may be about non-started OR unresponsive udev. Also I'm wrong about it making my system unbootable. I tried again with a stopwatch and patience and it proceeded after 4 minutes and 40 seconds. It did loop through all block devices twice and left these love letters in my kernel log: [ 5.841247] EXT4-fs (nvme0n1p1): mounted filesystem with ordered data mode. Opts: (null) [ 5.853304] md: md0 stopped. [ 5.859397] md/raid:md0: device sda1 operational as raid disk 0 [ 5.859519] md/raid:md0: device sdd1 operational as raid disk 3 [ 5.859639] md/raid:md0: device sdc1 operational as raid disk 2 [ 5.859758] md/raid:md0: device sdb1 operational as raid disk 1 [ 5.861881] md/raid:md0: raid level 5 active with 4 out of 4 devices, algorithm 2 [ 5.864511] udevd[2067]: GOTO 'libsane_rules_end' has no matching label in: '/etc/udev/rules.d/S99-2000S1.rules' [ 5.866365] md0: detected capacity change from 0 to 8796106653696 [ 66.863157] udevd[2067]: worker [2105] /devices/virtual/block/md0 is taking a long time [ 186.965091] udevd[2105]: timeout 'udisks-lvm-pv-export d2uPGL-1XLV-VdAb-L05Y-KhdX-uTHk-QFspo3' [ 186.965345] udevd[2105]: slow: 'udisks-lvm-pv-export d2uPGL-1XLV-VdAb-L05Y-KhdX-uTHk-QFspo3' [2109] [ 186.999448] udevd[2067]: worker [2105] /devices/virtual/block/md0 timeout; kill it [ 186.999679] udevd[2067]: seq 1385 '/devices/virtual/block/md0' killed [ 187.000471] udevd[2067]: worker [2105] terminated by signal 9 (Killed) [ 187.000755] udevd[2067]: worker [2105] failed while handling '/devices/virtual/block/md0' [ 250.070660] udevd[2067]: worker [2106] /devices/virtual/block/md0 is taking a long time [ 288.846412] udevd[2426]: failed to execute '/lib/udev/pci-db' 'pci-db /devices/pci0000:00/0000:00:01.3/0000:03:00.1': No such file or directory <3 <3 <3 Created attachment 573910 [details]
my complete /etc/init.d/assemble-raid script
Created attachment 573912 [details]
dmesg.log
My full dmesg.log. I have some kernel hacking enabled and there's a driver that always gets flagged by the UB sanitizer (unrelated). Incidentally I also have a misbehaving wifi device I fixed with another init script hack, but this is also after starting udev and my assemble-raid, which is why my that wifi device goes away and comes back.
#!/sbin/openrc-run
name="iwlwifi-rescue"
description="wifi device, driver or firmware loading is screwed"
depend() {
after udev sysfs
before NetworkManager
}
start() {
ebegin "Attempting to ressurect Intel wifi device..."
set -x
echo 0000:27:00.0 > /sys/module/iwlwifi/drivers/pci:iwlwifi/unbind || return -1
sleep 0.25
echo 0000:27:00.0 > /sys/module/iwlwifi/drivers/pci:iwlwifi/bind || return -1
set +x
eend
}
how about stabilizing lvm2-2.02.184.*? |