Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds
On Thu, 28 Feb 2019 14:20:35 +0100 Dejan Muhamedagic wrote: Package: lvm2 Version: 2.03.02-2 Followup-For: Bug #918590 As Ville Korhonen already reported, this bug affects all chroot based stuff (debootstick, multistrap, schroot) making them effectively unusable. There's some more info here: https://bbs.archlinux.org/viewtopic.php?id=242594 The Arch post mentioned above helpd me a lot but was not enough for me since all lvm tools where still stuck in the chroot env. My solution was to also bind mount /run/udev from the host to the chrooted system. My complete story and solution below: I faced this bug today while playing with LVM volumes on a new EFI machine. I was using a live Debian Buster and chrooted Debian Buster. In the chroot, I tried =strace /sbin/lvdisplay= and discovered attempts to open files in /run/udev/. I also warn you that for Debian Buster to be chrooted, your live CD must be equipped with same LVM2 version or so. This is the first time I face this issue (I have debug lots of situations in the past using, for example, quite old rescuecd w.r.t. chrooted system). # On the host: apt-get install lvm2 pvscan vgchange -a y mount /dev/vg/debian-amd64 /mnt/debian-amd64 # Prepare chroot: root=/mnt/debian-amd64 mkdir -p /mnt/debian-amd64/run/lvm mkdir -p /mnt/debian-amd64/run/udev mount --bind /dev $root/dev mount --bind /proc $root/proc mount --bind /sys $root/sys mount --bind /dev/pts $root/dev/pts mount --bind /run/lvm $root/run/lvm mount --bind /run/udev $root/run/udev # Do not forget EFI partition: mount /dev/sda1 $root/boot/efi # Run chroot: chroot $root /bin/bash # In the chroot: update-grub grub-install --efi-directory=/boot/efi Hope this helps. Nicolas
Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds
Package: lvm2 Version: 2.03.02-2 Followup-For: Bug #918590 As Ville Korhonen already reported, this bug affects all chroot based stuff (debootstick, multistrap, schroot) making them effectively unusable. There's some more info here: https://bbs.archlinux.org/viewtopic.php?id=242594
Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds
On Thu, 21 Feb 2019, Axel Beckert wrote: > Another thing I need to check before being able to answer is if I > still have that "sleep 5" workaround in the udev init script which > Michael Biebl suggested back then and which at least helped with some > recent udev/LVM issues on some, but not all machines. Ah. I normally put rootdelay=5 onto the kernel commandline for that. > So: Will tell as soon as will do the next reboot with at least that OK. Take care, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds
Thorsten Glaser wrote: > > Axel, do you still get it on your laptop after dist-upgrading > > to latest sid? > > (answered in chat) the bug is apparently gone in latest sid. > > @submitter can you confirm? XTaran? I can't remember having seen it recently, but for checking I need to reboot and I don't do that every few days. Another thing I need to check before being able to answer is if I still have that "sleep 5" workaround in the udev init script which Michael Biebl suggested back then and which at least helped with some recent udev/LVM issues on some, but not all machines. So: Will tell as soon as will do the next reboot with at least that machine where I remember having experienced this heavily. (There were others, too, where it was only about a minute of introduced lag and where I don't remember anymore which machines were affected. So I should probably remove that workaround from any such machine and check them all.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds
On Mon, 18 Feb 2019, Thorsten Glaser wrote: > Axel, do you still get it on your laptop after dist-upgrading > to latest sid? (answered in chat) the bug is apparently gone in latest sid. @submitter can you confirm? XTaran? bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * **!!! NEU !!!** Mit der **tarent Academy** bieten wir ab sofort auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf [www.tarent.de/academy](http://www.tarent.de/academy). Wir freuen uns auf Ihren Kontakt. *
Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds
Hi, we’re also hit by this (for a while already, but now on more systems). I discovered the following things: During boot, when the “even after waiting 1000 microseconds” message comes, hitting ^C allows the boot to continue, although several things (such as the framebugger console) are missing/not initialised. Logging in and doing sudo /etc/init.d/udev stop sudo /etc/init.d/udev start fixes it. Or, letting it boot, and getting the “sudo lvs” to hang. The same commands (udev stop/start) fix it, until the next reboot. All with sysvinit. On one system, I did not get it any more after today’s dist- upgrade (in sid), although that was the one on which I got it only late. On my own X61 work laptop, I don’t get it. Axel, do you still get it on your laptop after dist-upgrading to latest sid? bye, //mirabilos -- 21:12⎜ sogar bei opensolaris haben die von der community so ziemlich jeden mist eingebaut │ man sollte unices nich so machen das desktopuser zuviel intresse kriegen │ das macht die code base kaputt 21:13⎜ linux war früher auch mal besser :D
Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds
metoo Sample (run on my laptop): # pvdsplay WARNING: Device /dev/sda not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/vg00/root not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/sda1 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/vg00/swap not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/vg00/export not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/sdb not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/sdb1 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/sdb2 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/sdb3 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/vg00/root not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/sda1 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/vg00/swap not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/vg00/export not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/sdb1 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/sdb2 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/sdb3 not initialized in udev database even after waiting 1000 microseconds. --- Physical volume --- PV Name /dev/sda1 VG Name vg00 PV Size 107.13 GiB / not usable 3.16 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 27425 Free PE 0 Allocated PE 27425 PV UUID GKAL1e-CUkg-y3GD-y1WR-GcKl-xXkI-fI3Gik This breaks "dpkg-reconfigure linux-image-something" in a chroot. It takes hours to complete, while you are eager to get your server up and running again as fast as possible. Obviously pvdisplay worked without udev database entries, so I don't see a reason why it took so long. Moving back to lvm2 2.03.01-2 fixes the delay. Regards Harri
Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds.
* Elimar Riesebieter [2019-01-16 22:08 +0100]: > * Axel Beckert [2019-01-10 05:57 +0100]: > > > Hi, > > > > Elimar Riesebieter wrote: > > > At boottime I get: > > > > > > WARNING: Device /dev/md0 not initialized in udev database even after > > > waiting 1000 microseconds. > > > > I get the same warning, too, at boot time and so far also at any time > > I call a LVM command. In anycase the command (and hence the boot > > itself, too) takes about 7 minutes! (Which makes every reboot very > > annoying, and I had plenty of them recently due to #918764.) > > For my system this seems to be fixed. Can't reproduce which update > pulled the bug out: > > ii udev 240-4 > ii mdadm 4.1-1 > ii lvm2 2.03.02-1 > > Custom 4.19.15. > No custom lvm script. My /boot resides on a separated lv on a vg on top of a mdadm. I've installed grml-rescueboot. grub can't find vg0 and therefor doesn't boot a grml-image (2018-12). It did boot last in October with the very same layout Elimar -- Experience is something you don't get until just after you need it! signature.asc Description: PGP signature
Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds.
* Axel Beckert [2019-01-10 05:57 +0100]: > Hi, > > Elimar Riesebieter wrote: > > At boottime I get: > > > > WARNING: Device /dev/md0 not initialized in udev database even after > > waiting 1000 microseconds. > > I get the same warning, too, at boot time and so far also at any time > I call a LVM command. In anycase the command (and hence the boot > itself, too) takes about 7 minutes! (Which makes every reboot very > annoying, and I had plenty of them recently due to #918764.) For my system this seems to be fixed. Can't reproduce which update pulled the bug out: ii udev 240-4 ii mdadm 4.1-1 ii lvm2 2.03.02-1 Custom 4.19.15. No custom lvm script. Elimar -- Experience is something you don't get until just after you need it! signature.asc Description: PGP signature
Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds.
Hi, about 20 minutes and two reboots later... Axel Beckert wrote: > > I am running a custom 4.19.13 which ran fine on stable. > > I am running stock Debian unstable kernels. > > So far it happened with 4.18.20-2 (last 4.18 which was in sid/buster) > and 4.19.12-1 (current is 4.19.13-1). Same with 4.19.13-1 and 4.20-1~exp1. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds.
Hi, Elimar Riesebieter wrote: > At boottime I get: > > WARNING: Device /dev/md0 not initialized in udev database even after waiting > 1000 microseconds. I get the same warning, too, at boot time and so far also at any time I call a LVM command. In anycase the command (and hence the boot itself, too) takes about 7 minutes! (Which makes every reboot very annoying, and I had plenty of them recently due to #918764.) So far I've seen it in the following circumstances: * At boot, probably due to calls to vgchange or so. * Calling vgs * Calling lvs * Calling lvresize > two times. I get this type of warning 44 times per boot or LVM command: # time lvs WARNING: Device /dev/md0 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-0 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/md1 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/md2 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-2 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-3 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-4 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-5 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-6 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-7 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-8 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-9 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-10 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-11 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-12 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-13 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-14 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-15 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-16 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-17 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-18 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-19 not initialized in udev database even after waiting 1000 microseconds. /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdg: open failed: No medium found /dev/sdh: open failed: No medium found /dev/sdi: open failed: No medium found WARNING: Device /dev/md0 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-0 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/md1 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/md2 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-2 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-3 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-4 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-5 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-6 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-7 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-8 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-9 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-12 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-13 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-14 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-15 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-16 not initialized in udev database even after waiting 1000 microseconds. WARNING: Device /dev/dm-17 not initialized in udev database
