openSuSE 13.2: Grub2 on UEFI fails to load Xen hypervisor

Greetings!

I don’t know why Grub2 hiccups here, but whenever I attempt to fire up Xen, the bootloader immediately returns to the boot menu. However, when booting the normal desktop kernel, everything works fine.
I have already inspected /boot/grub2/grub.cfg, but I couldn’t find anything that were amiss, so the question is why Grub would not load Xen and then go on with the kernel.

The point is that everything looks similar to what has been set up on a machine with a legacy BIOS, and there things work like a charm.

Disabling secure boot has Grub display some messages with Grub complaining that the OS wouldn’t have any console. Nevertheless Grub tries to boot the hypervisor and the kernel, and as usual the screen briefly goes blank, but then a reboot happens, and I wind up back in the boot menu. The same thing happens when I switch to the non-secureboot entry in the UEFI boot manager, the only thing is that Grub complains about not finding a suitable video mode as well, causing the boot to fail instantaneously.

Does anybody know what could possibly be going wrong here? This thing is driving me crazy!

Robidu

Native booting Xen on EFI is work in progress that requires changes in both Xen and GRUB. 13.2 does not include necessary support (from Xen side in the first place). Factory grub tries dirty trick by chainloading Xen.

If you are interested in it, you probably should follow both Xen and GRUB development; asking on Xen list makes sense (grub patches were posted by Xen developers).

First of all, thanks for the pointers.

I’ve just tried chainloading Xen, but somehow that didn’t work, either. Grub simply is too quick with tossing away any messages that may be displayed (any chance to intervene in Grub’s script so that it waits for a keystroke to continue?) so I could not determine why it barfs again - and unfortunately the box I’m trying to get this working on doesn’t even provide a Pause key… :frowning:
Now I’m trying to set this thing up with multiboot2 instead of the initial multiboot, but that has Grub complain about a missing Multiboot header in Xen.

Now, how do I set that? The documentation I have found so far on how to do that seems to be cryptic at best.

Since openSuSE wouldn’t want to boot in UEFI mode (multiboot2 doesn’t accept it, and there’s no xen.efi available so that I could at least chainload this thing) I decided to switch to Legacy mode.

No sooner said than done, I have set UEFT to CSM only boot, put a DOS MBR onto the hd and recreated the partitions. At first the installation looked like normal, however, what puzzles me the first time is that the installer complains about a missing grub_boot partition. I ignored that for now and continued installing.
Everything worked fine, but once the installed system was about to be booted - it booted from CD again. Examining the boot devices it only had the Blu-ray drive; the hd was nowhere to be seen.
Firing up a rescue system and invoking fdisk indicated that the partitioning that I intended to use has been busted so I set the last entry to its intended dimensions (fortunately the partition has still been there), cleaned up a few things and rebooted.

This time Grub came up, but it immediately complained about a partition that couldn’t be found and switched to rescue mode. So I once again switched to the rescue system and examined /boot/grub2/grub.cfg - and what I found outright stunned me: For some reason Grub had been configured for GPT partitions, although the MBR is msdos.
So I changed everything from part_gpt to part_msdos and any gptn to msdosn, but the problem persists. Attempting to install the part_msdos module at Grub’s rescue prompt only had the bootloader complain once again about missing partitions. Attempting to insmod ext2, however, has been successful.

Now, how do I resolve this? The entire issue is becoming increasingly annoying.

Sounds like you are still using grub2-efi and not grub2 or maybe the boot flag is set wrong. If this is not a dual boot just put grub2 in the MBR. If you had GPT partitioning and switched junk can be left in the first and last track that can confuse things.It is best to do a total wipe of those areas then reinstall booting the installer in legacy mode

Thank you very much!
Your suggestion neatly resolved the issue with the Legacy boot - and indeed there has been a backup copy of that blasted GPT. Zeroing the entire disk merely left the DOS MBR that I put there before.

Anyway, YaST hasn’t complained any more about a particular partition type that would be missing.