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(a)colorremedies.com>
wrote:
On Mon, Feb 24, 2020, 1:02 PM George R Goffe via test <test(a)lists.fedoraproject.org>
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