#918590 WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds

Package:
lvm2
Source:
lvm2
Description:
Linux Logical Volume Manager
Submitter:
Elimar Riesebieter
Date:
2021-08-24 13:15:07 UTC
Severity:
important
#918590#5
Date:
2019-01-07 17:21:52 UTC
From:
To:
Package: lvm2
Version: 2.03.02-1
Severity: important


At boottime I get:

WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds.

two times. System boots to maintenance stage. There I have to login
as root and run `vgchange -ay' and <ctrl-d> to get a running system.
/dev/md0 was assembled fine in the first boot stage.

I am running a custom 4.19.13 which ran fine on stable. Adding a
initramfs-tools/script/local-top/lvm which instructs to run
`vgchange -ay' let the system boot without intervention but pulls
out the 'WARNING' 4 times while booting

Thanks in advance

#918590#10
Date:
2019-01-07 17:34:36 UTC
From:
To:
* Elimar Riesebieter <riesebie@lxtec.de> [2019-01-07 18:21 +0100]:

The pv is running on top of /dev/md0 (RAID 1).

#918590#17
Date:
2019-01-10 04:57:44 UTC
From:
To:
Hi,

Elimar Riesebieter wrote:

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

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 10000000 microseconds.
  WARNING: Device /dev/dm-0 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/md1 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/md2 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-2 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-3 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-4 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-5 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-6 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-7 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-8 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-9 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-10 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-11 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-12 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-13 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-14 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-15 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-16 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-17 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-18 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-19 not initialized in udev database even after waiting 10000000 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 10000000 microseconds.
  WARNING: Device /dev/dm-0 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/md1 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/md2 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-2 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-3 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-4 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-5 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-6 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-7 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-8 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-9 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-12 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-13 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-14 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-15 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-16 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-17 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-18 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/dm-19 not initialized in udev database even after waiting 10000000 microseconds.
  LV       VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home     vgc6 -wi-ao---- <38.61g
  log      vgc6 -wi-ao----  <1.86g
  root     vgc6 -wi-ao----  53.00g
  var      vgc6 -wi-ao----   4.25g
  anx      vgwd -wi-ao---- 200.00g
  apt      vgwd -wi-ao----   1.00g
  bkup     vgwd -wi-ao---- 150.00g
  c3pio-sd vgwd -wi-a-----  65.00g
  crsh     vgwd -wi-ao----  20.00g
  dph      vgwd -wi-ao----  90.00g
  games    vgwd -wi-ao----   2.00g
  img      vgwd -wi-ao----  70.00g
  med      vgwd -wi-ao----   3.00g
  pbr      vgwd -wi-ao----   8.00g
  scr      vgwd -wi-ao----  60.00g
  swap     vgwd -wi-ao----  16.00g
  tmp      vgwd -wi-a-----  30.00g
  wdm-test vgwd -wi-a-----  10.00g
lvs  0.44s user 0.59s system 0% cpu 7:01.58 total
#                                   ^^^^^^^^^^^^^

Please also note the 7 minutes this command took to finish.

/dev/sde to /dev/sdi are the five different slots of an internal USB
3.0 multi-format card reader.

That's a clear difference to my case, probably because of using a
stock kernel: System boots more or less fine, but takes about 8.5
minutes minutes to boot of which likely 7 minutes are due to LVM.

vgc6 is a VG on two SSDs coupled to a RAID1 with md.
vgwd is a VG on two 3TB spinning disks coupled to a RAID1 with md.

There's also a third md-based RAID1 without LVM for /boot/.

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).

Oh, and JFTR: I'm using sysvinit-core as PID1 and it so far happened
with at least udev 240-2 and 240-3.

		Regards, Axel

#918590#22
Date:
2019-01-10 05:47:35 UTC
From:
To:
Hi,

about 20 minutes and two reboots later...

Axel Beckert wrote:

Same with 4.19.13-1 and 4.20-1~exp1.

		Regards, Axel

#918590#27
Date:
2019-01-10 16:45:40 UTC
From:
To:
Perhaps related to this, I've noticed horrific slowdowns with v2.03.02-1
when running stuff inside chroot unless I bind-mount /run from the host
environment. Yesterday I noticed that it can take hours to run update-grub,
and I get tons of this same error message for each device/partition

WARNING: Device /dev/loop0 not initialized in udev database even after


Problem goes away immediately when I mount /run. Something related to
missing /run/udev.

# apt policy lvm2

#918590#32
Date:
2019-01-16 21:08:43 UTC
From:
To:
* Axel Beckert <abe@debian.org> [2019-01-10 05:57 +0100]:

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

#918590#37
Date:
2019-01-16 22:07:07 UTC
From:
To:
* Elimar Riesebieter <riesebie@lxtec.de> [2019-01-16 22:08 +0100]:

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

#918590#42
Date:
2019-01-18 11:11:38 UTC
From:
To:
Hi,

* Ville Korhonen [Thu Jan 10, 2019 at 06:45:40PM +0200]:

I can confirm this problem, it seems to have appeared with the
upload of lvm 2.03.02-1.

STR (with `/dev/mapper/$VG-$LV` corresponding to a LV):

  mkfs.ext4 /dev/mapper/$VG-$LV
  mount /dev/mapper/$VG-$LV /mnt
  debootstrap buster /mnt
  chroot /mnt apt -y install lvm2
  mount --bind /proc /mnt/proc
  mount --bind /sys /mnt/sys
  mount --bind /dev /mnt/dev
  mount --bind /dev/pts /mnt/dev/pts
  chroot /mnt vgs

Then the vgs process is horribly slow and causing many messages like:

  WARNING: Device /dev/... not initialized in udev database even after waiting 10000000 microseconds

As soon as /run/udev is available inside the chroot, then lvm
behaves as expected:

  mount --bind /run/udev /mnt/run/udev

regards,
-mika-

#918590#47
Date:
2019-01-20 10:56:46 UTC
From:
To:
metoo

Sample (run on my laptop):

# pvdsplay
  WARNING: Device /dev/sda not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/vg00/root 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/vg00/swap not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/vg00/export not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/sdb not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/sdb1 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/sdb2 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/sdb3 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/vg00/root 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/vg00/swap not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/vg00/export not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/sdb1 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/sdb2 not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/sdb3 not initialized in udev database even after waiting 10000000 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

#918590#52
Date:
2019-02-18 22:28:08 UTC
From:
To:
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 10000000 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

#918590#57
Date:
2019-02-21 13:48:58 UTC
From:
To:
(answered in chat) the bug is apparently gone in latest sid.

@submitter can you confirm? XTaran?

bye,
//mirabilos

#918590#60
Date:
2019-02-21 13:48:58 UTC
From:
To:
(answered in chat) the bug is apparently gone in latest sid.

@submitter can you confirm? XTaran?

bye,
//mirabilos

#918590#65
Date:
2019-02-21 14:01:38 UTC
From:
To:
Thorsten Glaser wrote:

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

#918590#68
Date:
2019-02-21 14:01:38 UTC
From:
To:
Thorsten Glaser wrote:

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

#918590#73
Date:
2019-02-21 14:10:16 UTC
From:
To:
Ah. I normally put rootdelay=5 onto the kernel commandline for that.

OK.

Take care,
//mirabilos

#918590#76
Date:
2019-02-21 14:10:16 UTC
From:
To:
Ah. I normally put rootdelay=5 onto the kernel commandline for that.

OK.

Take care,
//mirabilos

#918590#81
Date:
2019-02-28 13:20:35 UTC
From:
To:
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

#918590#90
Date:
2019-06-02 04:41:29 UTC
From:
To:

#918590#95
Date:
2019-10-11 16:27:17 UTC
From:
To:
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

#918590#100
Date:
2021-08-24 13:04:29 UTC
From:
To:
Greetings, from The illuminati world elite empire. Bringing the poor, the needy and the talented to limelight of fame, riches, powers and security, get recognized in your business, political race, rise to the top in whatever you do, be protected spiritually and physically! All these you will achieve in a twinkle of an eye when you get initiated to the great Illuminati empire. Once you are initiated to the illuminati empire you will get numerous benefits and reward.
Note: that this email message was created solely for the purpose of our recruitment scheme which will end next month and this offer is for unique ones only, if you are not serious on joining the illuminati empire, then you are advise not to contact us at all. This is because disloyalty is highly not tolerated here in our organization. Do you agree to be a member of the illuminati new world order? If YES!. Then kindly reply us back on our direct recruitment email only at: joinilluminatin@hotmail.com
Please note, Kindly make sure all your response are send directly to the email stated above only at:> joinilluminatin@hotmail.com For more instructions on our membership process.
Note: Some email providers incorrectly place official Illuminati messages in their spam / junk folder or promotion folder. This can divert and exclude our responses to your emails.
The Illuminati.

#918590#105
Date:
2021-08-24 13:04:29 UTC
From:
To:
Greetings, from The illuminati world elite empire. Bringing the poor, the needy and the talented to limelight of fame, riches, powers and security, get recognized in your business, political race, rise to the top in whatever you do, be protected spiritually and physically! All these you will achieve in a twinkle of an eye when you get initiated to the great Illuminati empire. Once you are initiated to the illuminati empire you will get numerous benefits and reward.
Note: that this email message was created solely for the purpose of our recruitment scheme which will end next month and this offer is for unique ones only, if you are not serious on joining the illuminati empire, then you are advise not to contact us at all. This is because disloyalty is highly not tolerated here in our organization. Do you agree to be a member of the illuminati new world order? If YES!. Then kindly reply us back on our direct recruitment email only at: joinilluminatin@hotmail.com
Please note, Kindly make sure all your response are send directly to the email stated above only at:> joinilluminatin@hotmail.com For more instructions on our membership process.
Note: Some email providers incorrectly place official Illuminati messages in their spam / junk folder or promotion folder. This can divert and exclude our responses to your emails.
The Illuminati.

#918590#108
Date:
2021-08-24 13:04:29 UTC
From:
To:
Greetings, from The illuminati world elite empire. Bringing the poor, the needy and the talented to limelight of fame, riches, powers and security, get recognized in your business, political race, rise to the top in whatever you do, be protected spiritually and physically! All these you will achieve in a twinkle of an eye when you get initiated to the great Illuminati empire. Once you are initiated to the illuminati empire you will get numerous benefits and reward.
Note: that this email message was created solely for the purpose of our recruitment scheme which will end next month and this offer is for unique ones only, if you are not serious on joining the illuminati empire, then you are advise not to contact us at all. This is because disloyalty is highly not tolerated here in our organization. Do you agree to be a member of the illuminati new world order? If YES!. Then kindly reply us back on our direct recruitment email only at: joinilluminatin@hotmail.com
Please note, Kindly make sure all your response are send directly to the email stated above only at:> joinilluminatin@hotmail.com For more instructions on our membership process.
Note: Some email providers incorrectly place official Illuminati messages in their spam / junk folder or promotion folder. This can divert and exclude our responses to your emails.
The Illuminati.