In my experience this probably won't happen until about 5.22.3 or 5.22.4, and it's probably best to wait until then anyway as they'll have the bugs ironed out.
Rawhide kernel nodebug should never be overwritten by a debug kernel. I create that repository by hand, it isn't scripted at all. Perhaps you do not have an excludepkgs entry for kernel* in your rawhide config?
Probably not, since I didn't know I was meant to set such a value. I am guessing this is supposed to go in /etc/yum.repos.d/fedora-rawhide.repo but which section?
As to the shutdown, if vbox locks up, and the service definition has no timeout, systemd will wait forever until it is properly shut down. If it is locked up, obviously it won't shut down. This is entirely in how they wrote the entry for the service. They could have included a timeout for say 1:30 or 5 minutes or whatever, and then systemd would just ignore a lack of response and shut the system down, but if there is no timeout, it will wait until the service tells it that it has exited cleanly. In their case, I am sure they wish to ensure guests have shutdown cleanly.
It appears to have a timeout of 1:30 mins, but it will stay running for about 10 mins plus.
While virtualbox is "open source" it has not ever been upstream for the host services. I don't even recall an attempt being made in earnest over the past decade. If they don't care to do so, upstream isn't going to bother to make sure that it works. Sometimes they have to play catch up, and they have chosen to shoulder that burden themselves. There is nothing I can do about it.
Fair enough, I though there was some mention of VirtualBox drivers being mainlined, I might have read that wrong. My bad.
I actually use the Rawhide Kernel No Debug, but that gets overwritten by the debug kernel. The debug kernel works in general, albeit slighlty slower performance, but only seems to have this issue.
I'm not sure it's a virtualbox problem because what happens is, the VBox locks up, but then attempting to shut down the host system results in some deadlock (Waiting for a job... for several minutes) and I have to forcefully power the system off.
So that tells me there's something in the kernel that's not working right. There may well be another issue hat hand.
VirtualBox no longer starts VMs or restores saved VMs without getting stuck. This is a continuous problem with these "202XXXXXgit123abcdef.fcXX" kernels, and rarely happens with the non-debug or "123.fcXX" kernels.
Same issue as thunderbirdtr above.
qtcreator: error while loading shared libraries: libExtensionSystem.so.4: cannot open shared object file: No such file or directory
Will not start. When opened in terminal this error occurs:
qtcreator: error while loading shared libraries: libExtensionSystem.so.4: cannot open shared object file: No such file or directory
VirtualBox 6.1.18 will not load a VM - gets stuck with no progress. Also cannot shut down the system afterwards without forcing a shutdown
VirtualBox 6.1.18 VM gets stuck in an endless loop.
So far so good. Panasonic CF-31 Mk III, Intel HD Graphics. Firefox Wayland 82.0.3 flickers a lot to the point where it's unusable, but it also happened on 5.19.5. Using kernel 5.8 at the moment.
With the Wayland session, I found since updating, the panel freezes up after some time (could be 3 minutes, could be 30 minutes). The buttons are still responsive if the application is still running, but if the application was closed after the freeze, the button remains and does nothing.