FS#61040 - [arch-install-scripts] [lvm2] LVM need access to /run/lvm under new root

Attached to Project: Arch Linux
Opened by Xiao (leonshaw) - Wednesday, 12 December 2018, 09:02 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 05 January 2019, 16:27 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

LVM utilities need access the sockets in /run/lvm, otherwise it falls back to device scan.
It was not be a problem before. But recently due to some upsteam changes, they will try udev and wait for 10 seconds for each device. This can make grub-mkconfig stuck for tens of minutes.

Despite upstream, it seems easier and more elegant to fix this in arch-chroot script by providing /run/lvm access to chroot environment. Like bind-mounting into the new root, and add a symbolic link at /run/lvm.

Additional info:

[root@archiso /]# time vgs
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
WARNING: Device /dev/loop0 not initialized in udev database even after waiting 10000000 microseconds.
WARNING: Device /dev/sda not initialized in udev database even after waiting 10000000 microseconds.
WARNING: Device /dev/vg0/swap not initialized in udev database even after waiting 10000000 microseconds.
WARNING: Device /dev/sda1 not initialized in udev database even after waiting 10000000 microseconds.
WARNING: Device /dev/vg0/root not initialized in udev database even after waiting 10000000 microseconds.
WARNING: Device /dev/sda2 not initialized in udev database even after waiting 10000000 microseconds.
WARNING: Device /dev/loop0 not initialized in udev database even after waiting 10000000 microseconds.
WARNING: Device /dev/vg0/swap not initialized in udev database even after waiting 10000000 microseconds.
WARNING: Device /dev/sda1 not initialized in udev database even after waiting 10000000 microseconds.
WARNING: Device /dev/vg0/root not initialized in udev database even after waiting 10000000 microseconds.
WARNING: Device /dev/sda2 not initialized in udev database even after waiting 10000000 microseconds.
VG #PV #LV #SN Attr VSize VFree
vg0 1 2 0 wz--n- 15.53g 0

real 1m50.289s
user 0m0.047s
sys 0m0.081s


Steps to reproduce:
Follow installation wiki, setup root using lvm, install grub and run grub-mkconfig.
Or just run LVM utils after chroot.
This task depends upon

Closed by  Dave Reisner (falconindy)
Saturday, 05 January 2019, 16:27 GMT
Reason for closing:  Fixed
Additional comments about closing:  testing/arch-install-scripts 21-1
Comment by nl6720 (nl6720) - Wednesday, 12 December 2018, 09:24 GMT
The issue appeared with lvm2 2.02.183-1. It doesn't occur with lvm2 2.02.182-1 in chroot.
Comment by Eli Schwartz (eschwartz) - Wednesday, 12 December 2018, 19:44 GMT
Of course the "real" solution for grub is to not rely on automagic detection scripts. :D

Honestly, does it make sense for lvm2 to hang like this though?

Also forum discussion about the issue: https://bbs.archlinux.org/viewtopic.php?pid=1820949#p1820949
Comment by Dave Reisner (falconindy) - Wednesday, 12 December 2018, 21:25 GMT
> Despite upstream, it seems easier and more elegant
There's nothing elegant about hacking around upstream bugs.

What exactly changed? Why did this work previously?
Comment by Xiao (leonshaw) - Thursday, 13 December 2018, 00:08 GMT
I don't think it's kind of hacking. Setting up a proper /run is just like /dev, /proc, etc. There may be other installation scripts relying on it.
Comment by Xiao (leonshaw) - Thursday, 13 December 2018, 02:19 GMT
Previously lvm uses device scanning if lvmetad is not available. After the upstream change, during the scanning it waits 10s for the dev to be available in udev to get information, but fails.
Comment by Matt Heinmuller (opensoul) - Friday, 14 December 2018, 02:10 GMT
I ended up installing downgrade from AUR (in the chroot) and downgrading lvm2. After install, did full system upgrade. LVM took a while to do it's thing on next reboot. It is working now, tho at boot I get a start job is running for Create Volatile Files and Directories.. takes 5 to 10 sec, then boots.

Loading...