When I got the initramfs shell I also typed udevadm trigger --type=subsystems --action=add udevadm trigger --type=devices --action=add
and tried to continue the boot process, but it failed. Then I typed udevadm trigger --type=devices --action=add -v and it booted nicely. Somehow, the `-v` flag is trigger some additional logic (maybe required to get what to print?) that makes the difference. Cheers! On Mon, Jan 14, 2019 at 10:41 AM Isaac Gelado <igel...@gelado.cat> wrote: > > Sorry for the late reply. I could not reboot my machine until today. > > I added a sleep 5 and it didn’t work. > > On Tue, Jan 8, 2019 at 9:15 AM Michael Biebl <bi...@debian.org> wrote: >> >> Am 08.01.19 um 18:11 schrieb Isaac Gelado: >> > 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. >> >> This is expected. udev's postinst runs "update-initramfs -u" which only >> updates the initramfs of the currently active kernel, not for all of them. >> For that, as you already mentioned, you need to pass "-k all" >> >> Regards, >> Michael >> >> -- >> Why is it that all of the instruments seeking intelligent life in the >> universe are pointed away from Earth? >>
