Both the issues mentioned below are solved! My PR to switch to hyperv_drm
was accepted, and the kernel fix needed to boot the liveCD are in.
You can boot this as a generation 2 (UEFI) VM with secure boot enabled, using the Microsoft UEFI Certificate Authority
setting. Resolution switching works in GNOME under Wayland, even when booted from the live media.
This is a brief experiment I did to compare these two setups in a Hyper-V VM running Fedora 34
DRM-hyperv
kernel driver from Linux-next (sort of an in-progress 5.14), using Wayland compositor in Gnome 40hyperv_fb
kernel driver in Linux 5.12.9, using X11 in Gnome 40
Subjectively, the DRM-hyperv
+ Wayland setup felt a lot smoother and more responsive. glxgears
performance was similar in terms of total FPS rendered, but it looks smoother with the new framebuffer driver.
The steps to install the kernel were pretty typical, but covered here: https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/
Fedora rawhide currently has kernel 5.14-rc1 running. There are still a few issues that need to be worked out.
CONFIG_DRM_HYPERV
is not set, so the new graphics driver is not available. It does at least boot in BIOS / generation 1 VMs.
I opened a pull request https://src.fedoraproject.org/rpms/kernel/pull-request/49#commit_list https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1273
The current nightly Workstation-live-iso isn't booting in UEFI, there is some issue finding the root FS. Surprisingly the ISO is ejected from the virtual SCSI DVD after this failure happens. Adding rdshell
to the grub command line shows some more details but I would need to dig a bit deeper to get more logs.
Need to read https://docs.fedoraproject.org/en-US/quick-docs/debug-dracut-problems/ and file a bug
Fedora 34 works fine. /proc/cmdline
is
BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-34-1-2 rd.live.image
(maybe with rd.shell rd.debug log_buf_len=1M
but not default)
It seems like /dev/sr0 is processed twice by udev, and the second one is setting a different link to the device that's based on the SCSI ID instead of media's labels. When that happens, it ejects /dev/sr0 which of course is bad for a LiveCD
Rawhide boot failure - still need to debug