4 p.m.
I'm running an aarch64 guest in a qemu VM, on an x86_64 host. I tried every
combination of video and display server in virt manager. The best working
combination I found was virtio video and a VNC display.
The only thing that's not working is the system console when booting. After
grub loads and starts the kernel, "Guest disabled display." is shown until X
starts. "Guest disabled display." also gets shown when X turns off the
display after inactivity, but it comes when when I wake it up. Everything
seems to work except for the system console. After X starts I can even use
CTRL-ALT-Fn to switch to different VTs and log in.
And now, I'm upgrading F32 to F33, in the VM completely blind. The only
thing that tells me the VM is not dead is the CPU activity monitoring in
virt manager, and I see the timestamp of the disk image file getting updated
on the host.
Google searches come back with 2-3 year old bugs where the system console
was apparently being redirected to the virtual serial port. That's supposely
fixed, though.
If anyone has a working configuration for a system console, in qemu, I'd
like to compare notes.
6:13 a.m.
Hi,
The only thing that's not working is the system console when
booting.
That is normal. There is no efi gop support on arm, so no efifb boot
framebuffer.
After grub loads and starts the kernel, "Guest disabled
display." is
shown until X starts.
Yep. Once the virtio-gpu kms driver is loaded you'll get an functional
display. Maybe delayed until something is actually printed to the
console due to CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y. With a
"quiet" boot that very well might be no message before gdm starts.
"Guest disabled display." also gets shown when X turns off
the
display after inactivity, but it comes when when I wake it up.
Yep. That is X / wayland going into DPMS mode and turning off the
display. You can disable screen blanking in gnome settings when it
bugs you.
And now, I'm upgrading F32 to F33, in the VM completely blind.
The only
thing that tells me the VM is not dead is the CPU activity monitoring in
virt manager, and I see the timestamp of the disk image file getting updated
on the host.
Hmm. That is not normal. In theory F33 should behave like F32 did ...
Can you ssh into the guest, or login on the serial console? Anything
suspicious in the kernel messages?
take care,
Gerd
7:49 a.m.
Gerd Hoffmann writes:
Hi,
> The only thing that's not working is the system console when booting.
That is normal. There is no efi gop support on arm, so no efifb boot
framebuffer.
> After grub loads and starts the kernel, "Guest disabled display." is
> shown until X starts.
Yep. Once the virtio-gpu kms driver is loaded you'll get an functional
display. Maybe delayed until something is actually printed to the
console due to CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y. With a
"quiet" boot that very well might be no message before gdm starts.
I don't see the "quiet" option in the args. Grubby shows the kernel args to
be only:
args="ro cma=256MB"
I'll clarify – the console shows "Guest disabled display." pretty much
after the kernel starts, and until X starts. Pretty sure that there are
plenty of messages during a normal kernel boot, but nothing comes out.
plymouth is installed, but I don't see an "rhgb" option there.
> And now, I'm upgrading F32 to F33, in the VM completely
blind. The only
> thing that tells me the VM is not dead is the CPU activity monitoring in
> virt manager, and I see the timestamp of the disk image file getting
updated
> on the host.
Hmm. That is not normal. In theory F33 should behave like F32 did ...
I was talking about the upgrade itself. It took about eight and a half hours
of "dnf system-upgrade" to finish its thing. Afterwards it rebooted into
F33, and that was that, as soon as X started, the display came back.
dnf system-upgrade log gave me all the gory details of what was happening.
An ordinary, boring system-upgrade. But completely blind. I do have another
system that does not use plymouth or a graphical boot, and shows a text-only
console during boot until X starts. system-upgrade spews a mass of messages
doing its thing, one package at a time.
None of that was visible during the eight hours the VM went through the
paces of updating F32 to F33, just "Guest disabled display.". Virt-manager
was showing me CPU activity, and I had absolute faith in the progress, and
that it'll reach the end. Went to sleep, and in the morning found myself
staring at lightdm's login screen.
Would've been nice to see the upgrade progress, all along.
8:39 a.m.
Hi,
I don't see the "quiet" option in the args. Grubby
shows the kernel args to
be only:
args="ro cma=256MB"
Try adding an explicit "console=tty1" here.
Seems on aarch64 the serial console is the default:
kraxel@fedora ~# dmesg | grep console
[ 0.000000] ACPI: SPCR: console: pl011,mmio,0x9000000,9600
[ 0.943412] printk: console [ttyAMA0] enabled
[ ... ]
> Hmm. That is not normal. In theory F33 should behave like F32
did ...
I was talking about the upgrade itself. It took about eight and a half hours
of "dnf system-upgrade" to finish its thing. Afterwards it rebooted into
F33, and that was that, as soon as X started, the display came back.
Ah, missed that detail.
take care,
Gerd
8:04 p.m.
Gerd Hoffmann writes:
Hi,
> I don't see the "quiet" option in the args. Grubby shows the kernel
args to
> be only:
>
> args="ro cma=256MB"
Try adding an explicit "console=tty1" here.
Seems on aarch64 the serial console is the default:
That mostly worked, actually. I still got a "Guest disabled display." after
the kernel started. This seemed to have stayed throughout the initial part
of the kernel initialization, but the console came up just before the
"Welcome to Fedora 33" logo, and I watched the rest of the userspace come up.
Pretty sure that had I now started a system-upgrade, I'd be able to monitor
it, since most of the system-upgrade work gets into gear well past that
point.
1227
days inactive
1229
days old
4 comments
2 participants
participants (2)
-
Gerd Hoffmann -
Sam Varshavchik