On Tue, Jan 8, 2019 at 8:38 AM Michael Biebl <bi...@debian.org> wrote: > > Am 08.01.19 um 16:43 schrieb Isaac Gelado: > > Adding sleep 1 does not work. I also check that the -v flag is only > > needed in one of the calls to udevadm. > > Urgh, this is getting really weird. > -v should not affect the behaviour of udevadm, but only generate > additional output which might slow it down a bit. > So I was suspecting a race between the startup of systemd-udevd and the > first "udevadm trigger" call and you avoided that race by slowing down > udevadm. > Apparently this doesn't seem to be the case if an explicit "sleep 1" > does not help. I assume increasing that from 1 to say 5 seconds doesn't > make a difference?
Definitively the `-v` option delays udevadm by less than one second, so I would assume a `sleep 5` is not going make any difference... Anyways, I can try that out later today (this only happens on my work desktop and every reboot requires saving quite a few screen sessions). Could the race be in the interaction between udevadm and the udev daemon? > (And I assume you made sure to rebuild the initramfs > after modifying /usr/share/initramfs-tools/scripts/init-top/udev) Yes, otherwise the system would have boot without errors and lots of output. As a side hint that might be helpful. I had two kernels 4.18 and 4.19 in my system. This problem started when I first boot 4.19, while I was able to boot 4.18 without problems. At some point I decided to do an `update-initramfs -k all -u` and the problem started to also happen when booting 4.18. I do not understand why when upgrading udev/systemd from 239-15 to 240-2 the trigger only updated the iniramfs for 4.19. > > > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? >
