After update to sys-fs/udev-240 from 239, the computer could not go beyond the initialization of lvm and kept displaying messages like: WARNING: Device /dev/sdXXX not initialized in udev database even after waiting 10000000 microseconds. Downgrading to version sys-fs/udev-239 fixed the problem. I tried udev-240 on another computer which does not use lvm. The computer completed the boot process but all devices the keyboard, mouse, ethernet, ... were not responsive. Again the computer worked after downgrade to version 239. These two computers are the latest ~amd64 and kernel 4.20.0.
Same here. Saw that error with grub2-mkconfig. I noticed with udev-240 a lot of modules (amdgpu,network) are not loaded.
This is rather a bug un systemd/udev.
I've encountered this problem too, but have stuck with OpenRC rather than systemd which is confusing because I have the following runlevels in sysinit # rc-update show | grep udev udev | sysinit udev-trigger | sysinit # rc-update show | grep devfs devfs | sysinit ...and yet udev is running from a systemd path... # ps -Alf | grep udev 5 S root 3199 1 0 80 0 - 4874 - 09:14 ? 00:00:00 /lib/systemd/systemd-udevd --daemon 0 S root 6223 5978 0 80 0 - 2530 - 09:47 pts/0 00:00:00 grep --colour=auto udev Going to downgrade to =sys-fs/udev-239 (after upgrading kernel as currently no /usr/src/linux/Makefile ), hopefully it will work for me too.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=766a97cd1fc61e3a924951b4bed63f8b45d847e6 commit 766a97cd1fc61e3a924951b4bed63f8b45d847e6 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2018-12-28 16:47:08 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2018-12-28 16:47:08 +0000 sys-fs/udev: backport patches Closes: https://bugs.gentoo.org/673796 Package-Manager: Portage-2.3.52_p18, Repoman-2.3.12_p30 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-fs/udev/Manifest | 1 + sys-fs/udev/{udev-240.ebuild => udev-240-r1.ebuild} | 5 ++++- 2 files changed, 5 insertions(+), 1 deletion(-)
Im still experiencing this. 2 different fresh installs. ~amd64 keyworded. Using openrc. Happens only with sys-fs/udev-240-r1. 239 is fine. System will eventually finish booting but then im left with no working keyboard. Again this doesn't happen with 239.
I take that back it's also happening with sys-fs/udev-239 if sys-fs/udisks-1.0.5-r2 is installed. Removing that udisks version removes the error. Udev-240-r1 did it even without udisks installed. Building sys-fs/lvm2 without udev support USE="-udev" also solves this. Not sure if using lvm with out udev support will cause any issues later or if im missing out on any features but it resolves the error so far. Hope this is at least slightly helpful.
(In reply to jeremy mills from comment #6) > I take that back it's also happening with sys-fs/udev-239 if > sys-fs/udisks-1.0.5-r2 is installed. Removing that udisks version removes > the error. Udev-240-r1 did it even without udisks installed. Building > sys-fs/lvm2 without udev support USE="-udev" also solves this. Not sure if > using lvm with out udev support will cause any issues later or if im missing > out on any features but it resolves the error so far. Hope this is at least > slightly helpful. Yup I can confirm some of the combinations as well udev-240-r[23], WITH udisks:0 => 'not initialized in udev' udev-240-r[23], WITHOUT udisks:0 => 'not initialized in udev' udev-239, WITHOUT => works will retest udev-239 + udisks:0 later tonight.
Please test udev-241_rc2, or whatever the newest version is at the time. Version 240 will never be stablized.
As an alternative to having sys-fs/udev, I am using sys-fs/eudev now. Works lika a charm
*** Bug 678164 has been marked as a duplicate of this bug. ***
As another workaround please test lvm2-2.02.184-r1.
(In reply to jannis from comment #9) > As an alternative to having sys-fs/udev, I am using sys-fs/eudev now. Works > lika a charm We got sys-fs/eudev-3.2.5 and got the problem anyway. Using sys-fs/lvm2-2.02.183
(In reply to Joakim Tjernlund from comment #12) > (In reply to jannis from comment #9) > > As an alternative to having sys-fs/udev, I am using sys-fs/eudev now. Works > > lika a charm > > We got sys-fs/eudev-3.2.5 and got the problem anyway. > Using sys-fs/lvm2-2.02.183 sys-fs/udisks 1.0.5-r2 and 2.8.1
(In reply to Robin Johnson from comment #11) > As another workaround please test lvm2-2.02.184-r1. That did not work. Now I also got an extra /dev/sda: No medium found I got sda is a removable disk: sd 0:0:0:0: [sda] Attached SCSI removable disk
Uninstalling sys-fs/udisks-1.0.5-r2 fixed the problem for me.
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: [url]https://wiki.gentoo.org/wiki/Custom_Initramfs#LVM[/url] And after applying following changes to /etc/lvm/lvm.conf file, I am able to boot 4.19.72 kernel finally. [code] 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 } [/code]
Please tell us used LVM/(e)udev package version. The problem should be fixed in latest LVM/udev... well, it was only a problem in udev/systemd.
The latest version sys-fs/udev-243 does not cause the lvm problem. You can close this bug report.
The bad old ebuilds are gone. Please close.