Recently, the boot time of my Ubuntu VM increased to over 2 minutes from circa 10 seconds. This was in Parallels 16 but also occurs in Parallels 17. I have traced the issue to a combination of the following: Ubuntu 20.04 kernel 5.11.0-34-generic VM configuration CD-ROM = disconnected. With the VM configured to have a disconnected CD-ROM and booting to an older kernel version, there is no problem. With CD-ROM disconnected and this specific kernel version there is a 2 minute delay in boot whilst the kernel searches for a presented CD-ROM that is, essentially, empty! Note that a knock on to this is that a systemd-udevd process connected to the CD-ROM is constantly generating CHANGE events and causing the process to ramp to 100%. If I boot the VM and during the delay, change the CD/DVD configuration to an available ISO image the boot continues immediately. Note that I've had mixed results with selecting an ISO image that doesn't exist anymore because I deleted it (Parallels still remembers it in the presented list for that config option.) If I configure the VM to use an ISO image the boot delay disappears as does the runaway systemd-udevd process. I don't know if this is a Parallels or kernel issue. It's tempting to blame a kernel bug but it could be a fix to an outstanding bug that that used to hide a bug in Parallels. My understanding/comprehension of the configuration value 'disconnect' for the CD/DVD is that no CD/DVD is presented to the kernel, but clearly that is happening because I can see the mapped SATA drive in the boot messages (captured in dmesg.) However, it's also happening in V16 which has been around for ages. Be interested in Technical's view on this. Please see this thread for additional/related information: https://forum.parallels.com/threads/parallels-17-ubuntu-20-crashing-every-time.354593/
Looks like it is already fixed in Linux kernel Workaround for slow VM boot: boot with some image connected And possible workaround for image connection after VM boot is to run: sudo systemctl stop systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket
Could you explain a little more - perhaps there is something in that thread that is related to this issue? That problem seems to be related to the cd-tray being ejected at boot time when a CD was expected but had been removed post hibernation and before resume. I don't see how it relates to this problem; I don't hibernate the VM and the VM did not have an attached ISO image when it was running, so the OS shouldn't have been expecting any thing to be there. It also mentions nothing about slow boot times. I can confirm that ejecting the disk in Ubuntu, sets the cd-rom to disconnect and then rebooting the VM brings back the delay in boot and the runaway systemd-udevd process so the issue isn't related to there being a cd missing that was there when the VM was powered down. The workarounds you give aren't in that fix thread either, but are ones I mentioned in the linked thread when I responded to that one. With an attached ISO image, the systemctl workaround isn't needed (and, indeed, if the systemd-udevd services are stopped, they need to be started again.) I raised this new thread because the title that the OP of the linked thread gave was about a crashing VM so they may have a different issue.
That bug in linux kernel about incorrect handling introduced by particular commit. The effect of this commit is different on different platforms. It was fixed, but I believe it will be changed one more time. Applying this patch and rebuilding kernel makes VM functional again.
Sorry, I'm still not clear. Are you saying that you've found references to that bug that cause different effects on different platforms, including the one I describe above - can you link? Have you patched and recompiled the 5.11.0.34 kernel to prove that it fixes the slow boot? If not, then how do you know? I ask not because I disbelieve you, but because that bug does not seem in anyway related so I don't see how it does fix it.
Yes, I have patched, recompiled and checked the 5.11.22 kernel. This kernel sources came with Ubuntu 21.04 as: linux-source-5.11.0/hirsute-updates,hirsute-security,now 5.11.0-34.36 all [installed] Linux kernel source for version 5.11.0 with Ubuntu patches The problem is gone.
That's great to know, thanks. I'm not that familiar with Linux so I'll await a fix released through the normal software update but it's good to know it's fixed.
