[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: black screen troubles trying to boot with Xen Hypervisor grub option



I tried load_video, serial disable, and diverting I still got black screen but then I tried your suggestion of going into BIOS and just totally suppressing EFI and forcing the system to do strictly legacy stuff and now it actually boots!  I'm curious as to whether the EFI approach could still get to a bootable system, but not curious enough to re-break it and be stuck again.  Thanks for getting me to bootability!

-Jamie

On 2023-07-09 11:57 p.m., Pierre-Philipp Braun wrote:
While digging in to what's going on I also noticed that the base hypervisor entry has a conditional branch checking $grub_platform so I added an echo to figure out which branch it's picking, and it turns out that in my case $grub_platform isn't "pc" and isn't empty but rather is "efi" so it does the "no-real-mode edd=off" options.  When I read about them in the documentation says that no-real-mode should only be used for debugging because it prevents vga from working, and I got excited because I thought "and therefore black screen!" but when I force it to use no options, like the "pc" branch does, it still gets black screen.

About no-real-mode edd=off, you might be right.  But to test without it, I would go with my own grub.cfg by overwriting it altogether, to keep it simple (keep insmod part_gpt as for EFI). I find interesting that there is usually `insmod all_video` or a call to function `load_video` with the valid entries (EFI capable), but those are missing in the XEN entries.

So this is the relevant part:

menuentry 'Debian GNU/Linux, with Xen hypervisor' --class debian --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-simple-0e276b18-54a4-4ff9-a770-1bcdd946ea70' {
    insmod part_gpt
    insmod ext2
    set root='hd0,gpt1'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 1dd68754-c4eb-4011-98d4-6df73f99eb81
    else
      search --no-floppy --fs-uuid --set=root 1dd68754-c4eb-4011-98d4-6df73f99eb81
    fi
    echo    'Loading Xen 4.17-amd64 ...'
        if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then
            xen_rm_opts=
        else
            xen_rm_opts="no-real-mode edd=off"
        fi
    multiboot2    /xen-4.17-amd64.gz placeholder   ${xen_rm_opts}
    echo    'Loading Linux 6.1.0-10-amd64 ...'
    module2    /vmlinuz-6.1.0-10-amd64 placeholder root=UUID=0e276b18-54a4-4ff9-a770-1bcdd946ea70 ro  quiet
    echo    'Loading initial ramdisk ...'
    module2    --nounzip   /initrd.img-6.1.0-10-amd64
}

You could try add load_video in top of that and reboot (and without re-generating the entire thing with update-grub).

Besides, note there used to be an issue on Debian systems while setting up XEN.  One had to elevate the boot priority.

    dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen
        update-grub

However I am not sure this is still the case.  Also, to get the login prompt, some console needs to point hvc0, and I don't see any specific console= argument to the kernel here.  You can also disable the casual serial console prompt altogether, since you don't have any.

        systemctl disable serial-getty@ttyS0

It's usually harder to setup XEN on EFI systems compared to legacy MBR boot process.  The easy way would be to enable CSM in your firmware and go MBR.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.