Chris, Thanks for responding to this situation I'm having. I have not tried a fresh FC33 install. I could try this though. I have not tried qemu-kvm, I will have to learn a little about this but can do if needed. VBox comes with it's own LKMs which are compiled during the installation. I haven't seen anything from Fedora for VBox except for guest-additions... yet. I use /dev/sda3 as a swap partition on all my systems (host and guest) and that configuration has been working very nicely for me for some time now. To get started with the VM I did a "swapoff -av" which went into the Uninterruptible sleep state.... and had to power cycle 'cause the "reboot" command was waiting for swap operations to end. Sigh... "swapoff -av /dev/sda3" fails too... same way. This problem with "swapoff" appears in the host system as well. NOT GOOD. So, in the VM I had done a fresh install of FC32 a few weeks ago. I may still have the .iso file laying around if needed. This was the first time I have done any "dnf upgrade" commands which shows the problem. I just now power cycled the VM and that new kernel didn't have an initramfs so it wouldn't boot. Apparently "dracut" didn't complete due to "blkid" doing it's Uninterruptible sleep routine. I rebooted to the previous kernel and tried "dnf reinstall 'kernel*'. It failed the same exact way AND in the same place too. Before attempting the reinstall I removed the swap partition (or tried to remove it... "swapoff" hang) from the running configuration and, just for fun, put an xfs filesystem on it so the system wouldn't think of it as swap. The "dnf reinstall kernel*" command worked! Here's the "ps -efadlc | grep blkid" output before the first power cycle: (D=Uninterruptible sleep). Sigh... F S UID PID PPID CLS PRI ADDR SZ WCHAN STIME TTY TIME CMD 0 D root 2174 2173 TS 19 - 697 - 23:48 pts/0 00:00:00 blkid -u filesystem -o export -- /dev/sda3 Currently the VM is up and running on the new kernel without a swap partition. Where to go from here? Best regards, George... On Monday, February 24, 2020, 3:45:55 PM PST, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: On Mon, Feb 24, 2020, 1:02 PM George R Goffe via test <test@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > Hi, > > A few weeks ago I wrote a bug against the blkid command, https://bugzilla.redhat.com/show_bug.cgi. > > I am still having trouble with blkid, this time it's in a VM (VirtualBox) while upgrading from FC32 to FC33. > > blkid is at the util-linux-2.35.1-4.fc32.x86_64 level running on kernel 5.6.0-0.rc1.git0.1.fc32.x86_64. > > The install has been running for 16+ hours now and appears to be hung in the kernel upgrade: > > Running scriptlet: libreoffice-data-1:6.4.0.3-2.fc32.noarch 881/881 > Running scriptlet: pulseaudio-13.99.1-1.fc33.x86_64 881/881 > Running scriptlet: libwbclient-2:4.12.0-0.2.rc3.fc33.1.x86_64 881/881 > Running scriptlet: kernel-core-5.6.0-0.rc2.git3.1.fc33.x86_64 881/881 > > Here's what pstree says about the dnf process: > > dnf,5606 /bin/dnf --nogpgcheck upgrade > └─sh,8400 /var/tmp/rpm-tmp.wMjFt5 2 > └─kernel-install,8401 /bin/kernel-install add 5.6.0-0.rc2.git3.1.fc33.x86_64 /lib/modules/5.6.0-0.rc2.git3.1.fc33.x86_64/vmlinuz > └─50-dracut.insta,8489 /usr/lib/kernel/install.d/50-dracut.install add 5.6.0-0.rc2.git3.1.fc33.x86_64 ... > └─dracut,8490 -p /bin/dracut -f /boot/initramfs-5.6.0-0.rc2.git3.1.fc33.x86_64.img 5.6.0-0.rc2.git3.1.fc33.x86_64 > ├─cat,8509 > └─dracut,8660 -p /bin/dracut -f /boot/initramfs-5.6.0-0.rc2.git3.1.fc33.x86_64.img 5.6.0-0.rc2.git3.1.fc33.x86_64 > └─dracut,8661 -p /bin/dracut -f /boot/initramfs-5.6.0-0.rc2.git3.1.fc33.x86_64.img 5.6.0-0.rc2.git3.1.fc33.x86_64 > ├─blkid,8662 -u filesystem -o export -- /dev/sda3 > └─dracut,8663 -p /bin/dracut -f /boot/initramfs-5.6.0-0.rc2.git3.1.fc33.x86_64.img 5.6.0-0.rc2.git3.1.fc33.x86_64 > > > 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? > Maybe i misunderstood, but don't write up another bug report for the same bug. That's a dup and should be closed. But what you're describing sounds bad. So you have to do the tedious work of narrowing it down. Does it happen with clean installs of F33? Or just upgrades? Does it happen in a qemu-kvm VM? Or just Virtual Box? I'm pretty sure they're are vbox modules built now in Fedora kernels? But I'm not clear on specifics. I think 5.6 has merged some upstream work, and also Fedora folks backported it to 5.5. Chris Murphy _______________________________________________ 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
