Funny you ask, I’m trying to figure the host kernel requirements to do things correctly under newer Heads kernels, which seems to have changed as opposed to linux 4.x.
What we know:
On xx20/xx30:
- Heads uses 4.x kernel.
- kexec patch reuses VGA if host kernel identifies vga as either VGA or inteldrmfb.
- newer kernel changed the name of inteldrmfb to i915drmfb, but changing kexec patch to add i915drmfb is not enough to obtain same old behavior of 4.x kernel when version bumped to 5.x, something else changed.
What we know and is still valid when kexec’ing from newer kernel version:
- Heads will not get working frame buffered console until the kexec’ed OS will reuse VGA and reinitialize the vga framebuffer (on load drm driver + i915 on xx20/xx30). Prior of that, host will stay at kexec prompt, looking like frozen but on kexec’ed system, most probably waiting for LUKS password and having either plymouth or something else loading i915 too late to have prompt on a working vga console, otherwise if i915 loaded, vga works.
- Heads
CONFIG_LINUX_COMMAND_LINE="intel_iommu=igfx_off"on first kernel load - When kexec’ing into OS kernel, it passes additional OS boot options through CONFIG_BOOT_KERNEL_ADD=
"intel_iommu=on intel_iommu=igfx_off"making sure IOMMU is setuped correctly, otherwise hanging at kexec call. - heads kexec-boot handler adds the following when xen mode is detected, parsing grub.cfg :
kexeccmd="$kexeccmd --command-line \"$restval no-real-mode reboot=no vga=current\"". That is, taking grub.cfg boot line, addingCONFIG_BOOT_KERNEL_ADDoptions and then appendingno-real-mode reboot=no vga=currentto kexec -l call
Clear host kernel requirements for kexec to enter nicely into kexec’ed kernel are not clear.
Some hints as of now:
- vgaarb is helpful permitting to change vga handler on boot, where fb console reclaim vga when loaded and active
- on early kernel boot, if enabled, vga in dmesg logs can be seen to switch on vgaarb trace from vga 16 to to vga or simple fb if present when kexec’ing from 4.x to 5.x and even 6.x kernels
As a result, an x230-maximized board config boots Qubes 4.2 with the following kexec -l line on my testing machine (keeping installation parameters that are taken into consideration to craft grub.cfg config):
Trying to get the essentials, and keep the ball moving to understand once and for all what are host’s kernel requirements and options to be passed to kexec call (and maybe further kexec script magic) under Debugging kernel 5.x kexec issues add tools to ease kernel version bumping by tlaurion · Pull Request #1351 · osresearch/heads · GitHub
@disp6252 Any help welcome, but the kexec call above, if your host grub config replicates Heads behavior passing intel_iommu=igfx_off prior of booting live cd, and then replicating kexec -l above, should work. On kexec -l xen call, passing vga=current and reboot=no should work. Any input you get might help the situation forward as well.