Stan, Thanks for your response. You raise some VERY interesting questions. I have successfully upgraded from FC32 (Rawhide) to FC33 (Rawhide) on this host. No problems. blkid without operands hangs here though, hence the mentioned bug report on bugzilla.redhat.com. As we "speak" blkid on my host running as root is hung (STATE="D"). Lsof shows only one /dev/sda? partition... the swap partition. The same is true in the VM. Hmmmmm... VirtualBox runs as root. I would assume (I'm aware of what the letters stand for) that it would support privileged commands and/or instructions probably emulating some privileged commands/instructions in order to protect the host from errant guests. I can ask the VBox people if this is so if you would like me to do so. I do doubt that VBox is involved since this hang happens with or without VBox. I can get a "strace -xvf blkid" trace file if that would help. Thanks again for your response. George... (still wondering what to do) };-) On Monday, February 24, 2020, 1:38:25 PM PST, stan <upaitag@xxxxxxxx> wrote: On Mon, 24 Feb 2020 20:02:08 +0000 (UTC) George R Goffe via test <test@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > I have done "strace -xvfp <pid>" on all the processes listed. NONE > are running. ALL "say" they're waiting on a system call like wait or > read except for the blkid process which reports NOTHING. I tried > killing the blkid process but that just schedules, IIRC, a kill > signal against it's process but since that process doesn't seem to be > getting any cpu time, the kill will NEVER complete. > > I'm not sure what to do at this point. Write another bug report? You are upgrading in a virtual machine. Does the virtual process have direct access to the hardware? If blkid is looking for real disk ids and doesn't have access to them, it is probably going to hang. In top it should look like D I think, uninterruptible sleep. It is impossible to kill such tasks. Now this could be a bug in blkid, if it is supposed to be able to get block ids while running in virtual machines. But that seems like a pretty big if to me. _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
