After following the steps to downgrade GRUB, after a reboot I end up in a grub commandline (grub>)
Also, I am confused if I have not completely downgraded, as the header states
GNU GRUB version 2.02~beta2-36ubuntu3.28
Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. anywhere else TAB lists possible device or file completions.
From this command line, I can set the linux kernel requirements and boot into linux. However, I’m missing how to boot the hypervisor (it seems like my updates to /boot/grub/menu.lst are not occurring/being referenced after I downgraded GRUB).
linux /vmlinux-4.4.236+ root=/dev/<host>-vg/root
By changing the root=UUID=... to specify the device (i.e. root=/dev/...) I am able to successfully boot into linux. Is there a test function I can perform to verify I have successfully booted the hypervisor (i.e. is there a test hypervisor call I can make)?
I still seem to be having issues with my grub menu.lst After booting the micro-hypervisor, grub is invoked a second time. However, I seem to experience errors when I attempt to make any keyboard inputs (change grub menu items). To work around this, I attempted to use the savedefault options discussed in the docs. However, I’m not sure that I have things configured properly.
Looking at the log it seems like the micro-hypervisor is being loaded recursively. Which version of GRUB are you using? Did you remember to downgrade to GRUB 1 per the documentation?
Also, I would suggest removing everything from your menu.lst except for timeout, Default OS and uberXMHF. Remove the savedefault lines and set timeout to 20. Then follow the procedure below:
restart the machine and when GRUB menu pops up for the first time, manually select uberXMHF and let the micro-hypervisor boot
the micro-hypervisor will load with serial messages appearing on your debug console.
At some point, when the micro-hypervisor finishes loading up it will start the guest and you will find the GRUB menu pop up again. This time manually select Default OS and let it boot. Keep watching for serial messages from the micro-hypervisor, you should see some E820 related messages and then a few accesses to CRx registers before the guest OS begins to boot.
Post the new serial log and menu.lst and we can go from there…
Ahh ok. I think this is a good step forward. At least we have the micro-hypervisor booting up and loading the guest. It seems like there is some unsupported RDMSR exception caused likely due to some virtualization kernel module.
You may need to boot into the vanilla OS (without the micro-hypervisor) and ensure kvm-intel.ko is not loaded (e.g., via module blacklisting). Also can you please post your Linux kernel command line parameters?