Description of problem: Each time laptop boots there is a delay of 2 min 59 seconds, where the boot process waits "for Complete Device Initialization". Nothing is shown to the user unless he uses "Esc", the messages in attach are shown. This is on a laptop with a dual boot setup with the Microsoft partitions encrypted with bitlocker.
Created attachment 8225 [details] picture of messages shown during delay of boot
It looks like you have either incorrect UUIDs in either /etc/fstab or on your kernel command line, or the UUIDs are correct, but for devices that are not present. This is a configuration issue you should be able to fix.
If reconfiguring doesn't help, then what are the /etc/fstab lines for the Microsoft partitions encrypted with bitlocker ?
CC: (none) => marja11, pterjan, tmbKeywords: (none) => NEEDINFO
oh, and in that case, please do also run, as root, journalctl -ab > journal.txt and attach journalctl.txt to this report. Or, if reconfiguring did fix the issue, please close this bug report.
Created attachment 8247 [details] Output of journalctl -ab > journal.txt
For info: The win_c and win_c2 were in that case (as a result of encrypting those partitions with bitlocker from within windows). After removing the from fstab the two lines related to these partitions only the "wait for Complet Device Installation" line remained. Since I did not know how to get rid of that and the installation was still completely fresh, I did a full Mageia reinstall (formatting the / partition, but not /home). The "wait for Complete Device Installation" line was still there with the 2 min 59 sec delay. Also, after the delay, the laptop boots into Mageia just fine, so access to / and /home work just fine. For the rest fstab only contains the entry for EFI and none. Since it was a potential configuration issue and not a bug, I asked for help on the forum, however up till now, without resulting to a fix: https://forums.mageia.org/en/viewtopic.php?f=8&t=11241
Comment on attachment 8247 [details] Output of journalctl -ab > journal.txt at 10:28:28 there are messages about systemd-udevd taking a long time, after that nothing happens for an entire minute. i don't manage to copy those lines to this comment on my phone
additionally, there are sddm segfaults, but those should no longer happen after last updates (and there's already a different bug report for that)
CC: (none) => mageiaSummary: 3 minutes delay in booting => 3 minutes delay in booting (systemd-udevd taking a long time)
Keywords: NEEDINFO => (none)
Could you run the following command: systemd-analyze plot > boot.svg and then attach the boot.svg file. This should show which service is actually delaying the boot process.
CC: (none) => mageia
Created attachment 8265 [details] systemd-analyze plot > boot.svg
(In reply to Sander Lepik from comment #9) > Could you run the following command: > > systemd-analyze plot > boot.svg > > and then attach the boot.svg file. This should show which service is > actually delaying the boot process. Thx, Sander, I didn't know that (In reply to Wim Coulier from comment #10) > Created attachment 8265 [details] > systemd-analyze plot > boot.svg And the winner is: systemd-udev-settle.service (2min 511ms) Assigning to Colin
Assignee: bugsquad => mageia
Problem is gone now. I assume that one of the recent updates solved it. I've set the status to resolved.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
The issue has been resolved. I'm guessing one of the latest upgrades fixed it. I changed the status to resolved. https://flappy-bird.co
CC: (none) => patrickknightpatrick8
(In reply to Marja Van Waes from comment #11) > (In reply to Sander Lepik from comment #9) > > Could you run the following command: > > > > systemd-analyze plot > boot.svg > > > > and then attach the boot.svg file. This should show which service is > > actually delaying the boot process. > > Thx, Sander, I didn't know that > > (In reply to Wim Coulier from comment #10) > > Created https://geometrydashworld.net attachment 8265 [details] > > systemd-analyze plot > boot.svg > > And the winner is: > > systemd-udev-settle.service (2min 511ms) > > Assigning to Colin The system actually has many useful applications.
CC: (none) => peanutsunless