Hi, sorry for the bad formatting. This should be better.
I'm preparing Debian Buster for use with fai, and I'm getting a very long delay for the installation when using LVM partition layout. The following process takes a long time(the vgs command is ren multiple times) ps ax --forest \_ /bin/sh /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg \_ /bin/sh /etc/grub.d/00_header \_ /usr/sbin/grub-probe --device /dev/mapper/vg_sys-root --target=compatibility_hint \_ vgs --options vg_uuid,pv_name --noheadings --separator : | So the prozess vgs --options ... ist stuck. When I'm executing the vgs command manually it's stuck too. Using verbosity and debug switches, I get this output: time vgs -vvvddd --options vg_uuid,pv_name --noheadings --separator : Parsing: vgs -vvvddd --options vg_uuid,pv_name --noheadings --separator: ... Device /dev/vg_sys/swap not initialized in udev database (1/100, 100000 microseconds). Device /dev/vg_sys/swap not initialized in udev database (2/100, 100000 microseconds). ... Device /dev/vg_sys/swap not initialized in udev database (100/100, 9900000 microseconds). WARNING: Device /dev/vg_sys/swap not initialized in udev database even after waiting 10000000 microseconds. filter md deferred /dev/vg_sys/swap filter cache deferred /dev/vg_sys/swap ... Device /dev/vg_sys/root not initialized in udev database (1/100, 0 microseconds). Device /dev/vg_sys/root not initialized in udev database (2/100, 100000 microseconds). ... Device /dev/vg_sys/root not initialized in udev database (100/100, 9900000 microseconds). WARNING: Device /dev/vg_sys/root not initialized in udev database even after waiting 10000000 microseconds. ... rAGmpb-AnKr-Iemp-2WPv-I37a-N7C8-aUcJ2F:/dev/xvdb2 Completed: vgs -vvvddd --options vg_uuid,pv_name --noheadings --separator : real 1m30,375s user 0m0,064s sys 0m0,132s I also checked what's going on with strace. I see a lot of Errors like this: openat(AT_FDCWD, "/run/udev/data/b254:1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden) openat(AT_FDCWD, "/run/udev/data/b254:1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden) openat(AT_FDCWD, "/run/udev/data/b254:1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden) openat(AT_FDCWD, "/run/udev/data/b254:1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden) openat(AT_FDCWD,"/run/udev/data/b254:1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden) After checking the documentation I wondered if using the lvm options "use_lvmetad = 0" or "obtain_device_list_from_udev = 0" might help. After setting them and make sure they are active(via lvm dumpconifg) I saw that this was not the case. On the internet there are advices to make /run/lvm available within chroot via mount --bind. Since there is no /run/lvm on the installation system and since the path causing the error is /run/udev, I tried to bind-mount /run/udev. It seems to fix the problem. The command runs fast again. I'm not sure if this is the best way to go or if this is just a usable workaround. These are the installed packages on the fai server: fai-client 5.3.6 fai-quickstart 5.3.6 fai-server 5.3.6 Regards, Tobias
