You are not logged in.
I am installing Arch Linux on SDD with UEFI. At the end I install grub2
pacman -S grub efibootmgr os-prober intel-ucode
mkdir /boot/EFI
mount /dev/sda1 /boot/EFI
grub-install --target=x86_64-efi --bootloader-id=grub_uefi --recheck
and
grub-mkconfig -o /boot/grub/grub.cfg
I have error
WARNING: Device /dev/sda1 not initialized in udev database even after waiting 10000000 microseconds.
Last edited by thommen (2018-12-16 18:07:43)
Offline
https://bbs.archlinux.org/viewtopic.php?id=242594
This thread should solve your problem, it solved mine.
Offline
This topic does not concern my case
Offline
I am installing Arch Linux on SDD with UEFI. At the end I install grub2
pacman -S grub efibootmgr os-prober intel-ucode mkdir /boot/EFI mount /dev/sda1 /boot/EFI grub-install --target=x86_64-efi --bootloader-id=grub_uefi --recheck
and
grub-mkconfig -o /boot/grub/grub.cfg
I have error
WARNING: Device /dev/sda1 not initialized in udev database even after waiting 10000000 microseconds.
You did not specify the 'efi-directory'. So in your case:
grub-install -–target=x86_64-efi –-efi-directory=/boot/EFI --bootloader-id=grub_uefi --recheck
If it still doesn't work, maybe you should mount the ESP mountpoint BEFORE chroot during your installation process.
As a side note, it's more common to use '/boot/efi' as ESP mountpoint instead of '/boot/EFI'.
Also if you follow the WIKI, it should've been mounted at '/efi'
More info: https://wiki.archlinux.org/index.php/EF … _partition
Failure is success in progress.
A.E.
Offline
The choice of the catalog is optional. Providing the catalog does not change the situation. I am waiting for the whole process to end. Preview → https://imgur.com/a/G1QQ5J2
Offline
The choice of the catalog is optional. Providing the catalog does not change the situation. I am waiting for the whole process to end. Preview → https://imgur.com/a/G1QQ5J2
According to the Wiki, there's no need to worry:
https://wiki.archlinux.org/index.php/GR … _in_chroot
Failure is success in progress.
A.E.
Offline
I not writing about error
WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.
Offline
I get the same error cycling across several devices on a fresh uefi install. As mentioned above, these appear to be benign warning messages (though can burn up several minutes until the process terminates after the reported devices are probed repeatedly).
For me at least, everything boots up proper afterwards.
Offline
I'm getting this trying to install with a 201812 install image currently, and can't get a usable, bootable config to work with grub-mkconfig. This is efi booting, nvme disk, original dell windows install on nvme0n1p1-4, p5 /boot, p6 luks+lvm2 atop it with root/var/home lv's.
First, I get the "hang" using grub-mkconfig in any way. Removing the redirect to dev/null, I see the same errors posted here. In the install, I found that lvmetad isn't started at all to generate the socket inside /run/lvm, so binding it into the chroot did nothing to help. Attempting to start via systemctl says it can't start in run level 1. Starting lvmetad seemed to fork the process and generate the socket now, so seemed money ahead... Attempting to generate the grub.cfg with grub-mkconfig still hangs in the same ugly way with timeouts, stating it still can't connect to lvmetad, and devices uninitialized in udev. Just simply starting lvmetad doesn't seem to help here, but I don't know how to fix beyond this. I'm sure on a working system in full run state, this wouldn't be an issue, but during install it is a chicken and egg problem.
This system worked fine running dual boot and ubuntu, trying to add arch now blew up grub and can't get a workable boot config. At recommendation for my xps15, I even tried bootldr as part of systemd booting, but it doesn't seem to want to unlock my encrypted disk. I'm back to trying to make grub work.
This seems a major problem/bug for the install process, this is being reported in many ways all over, and a lack of output, just hang by grub-mkconfig doesn't help anyone either. Is there a good way to get lvmetad working with grub-mkconfig during install? Or replace it with something more workable during install?
Offline
I too get the timeout issues with lvmetad on grub-mkconfig. This is an old install that I had problems with 4.20 so I chrooted and downgraded and messed up my mounts, so I had to go back and run grub-mkconfig to fix the images correctly. It eventually gets done after cycling through the devices as reported above.
Offline
Had same problem with GPT disk under BIOS today. I was restoring grub with December arch usb stick.
Last edited by plasmikHI (2019-01-06 21:48:00)
Offline
I too get the timeout issues with lvmetad on grub-mkconfig. This is an old install that I had problems with 4.20 so I chrooted and downgraded and messed up my mounts, so I had to go back and run grub-mkconfig to fix the images correctly. It eventually gets done after cycling through the devices as reported above.
So does it ever actually complete successfully? How many times does it loop? I haven't let it run past 2-3 loops, as it just seems to go nowhere slowly, but I'm willing to let it sit however long as long as it might actually work, eventually...
Last edited by mikebutash (2019-01-06 22:07:52)
Offline
opps, wrong posting here.
Last edited by mikebutash (2019-01-06 22:24:15)
Offline
You can try to temporarily disable lvmetad ( set use_lvmetad = 0 in /etc/lvm/lvm.conf , remove executable flag on lvmetad binary or mask the lvmetad unit, stop/kill lvmetad ).
Just note this does not work with ArchLinux in general, i.e. it must be enabled if you are using the lvm hook in initcpio as it's kind of baked into there and won't work at all without it. (You'd have to do a custom lvm hook otherwise.)
Any issue related to lvmetad probably won't be fixed anymore. In lvm-2.03.x, there is no more lvmetad at all, it got axed. Only question is, when does that find its way into ArchLinux too (still on 2.02.xxx). It'll happen eventually I guess, just needs some work as there are references to lvmetad in many places.
Last edited by frostschutz (2019-01-13 16:28:04)
Offline
Luckily it doesn't matter how you use lvm, since you don't need to use grub-mkconfig in the first place. See archwiki: User:Eschwartz/Grub#Write_the_configuration_from_scratch (this is in the process of being merged into the main wiki article).
Last edited by eschwartz (2019-01-13 16:35:34)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Just wanted to state that I also ran into this bug today while trying to install on an Acer Nitro 5 Ryzen/Radeon laptop, and it was extremely annoying. I would up simply using an older install image/older packages, but was ultimately defeated for other reasons anyway.
Offline
There is more wrong with the kernel I think than just some of the grub-mkconfig routines being poorly dependent on lvmetad.
I got around to screwing wth the laptop again after a month or more of hateful disgust, and went about manually building grub to get it booting. No matter how I build the kernel, with whatever hooks, it refuses to bootstrap my luks+lvm2 config. I manually pieced together a (theoretically) booting grub config from ubuntu, to get back into my ubuntu lv's. and windoze10 on the original dell partitions. Arch, with a duplicated build, simply refuses to boot off the config, not initiating the luksOpen to unlock crypto volume, or finding subsequent root to pivot off of.
Apparently a minority of folks go to this extreme to notice, but glad I'm not alone. I had to go back to ubuntu or windoze meantime on the lappy, which works with an exactly same config as arch, just without a bunk kernel build.
Considering chromebook more these days if they can run my linux apps...
Last edited by mikebutash (2019-02-13 23:03:43)
Offline
I have been having troubles with this issue on my luks lvm setup on Gentoo. Strange was that in my case this occurred only on latest kernels:
Not working
linux-4.19.72-gentoo and some other in that line..
Working
linux-4.14.65-gentoo
linux-4.18.11-gentoo
I was under impression I did something dirty with kernel, I also emerged eudev (Gentoo udev for OpenRC) and lvm2 packages from unstable tree, but that didn't help, I found some bug at redhat about this, but finally I found a page: https://wiki.gentoo.org/wiki/Custom_Initramfs#LVM
And after applying following changes to /etc/lvm/lvm.conf file, I am able to boot 4.19.72 kernel finally.
devices {
# Disable scanning udev for md/multipath components.
# This is required with recent versions of lvm2, even if you use another solution for
# your LV device nodes; without it lvm commands will stall for minutes waiting for udev.
multipath_component_detection = 0
md_component_detection = 0
}
activation {
# Set to 0 to disable udev synchronisation (if compiled into the binaries).
udev_sync = 0
# Set to 0 to disable the udev rules installed by LVM2
udev_rules = 0
}
Last edited by archenroot (2019-10-06 22:55:50)
Offline