Monday, December 31, 2018

Missing console warning with UEFI and Xen

I recently begun building out two servers with the objective to run various docker-wrapped applications with CoreOS and VMs within Xen on top of debian-stable. The motherboards are from ~2013 and have full support for UEFI. I surprisingly hadn't done a UEFI-enabled installation previously, or at least one that I can explicitly recall, so I didn't think much about deciding whether to use UEFI or do a legacy boot installation. I threw the debian-stable ISO on a USB stick, plugged it, and booted it up.

All went well in the initial installation, until I installed the Xen kernel and attempted to boot into it, and was left with the curious warning on my VGA console (versions not accurate as I retroactively grabbed this from someone else's report, but the rest is representative):

Loading Xen 4.9-amd_64 ...
WARNING: no console will be available to OS
Loading Linux 4.15.0-20-generic ...
Loading initial ramdisk ...

After that, the system just hung. The system didn't appear to have completed booting, the network stack never came online, nor could I fish for the device on the local network and attempt to remotely connect to it. It was just frozen. If I rebooted it into the default debian-stable kernel, it had no issue.

I poked around the Internet and quickly learned that this was an issue between UEFI, Xen, and the seemingly inability to set proper default grub2 settings. I found numerous questions along similar lines going back to 2013, although curiously all of them had different resolutions, and there wasn't a consistent solution or patch to address what amounted to a rather vague fatal warning being thrown into the console. Some of them revolved around improper memory settings for the framebuffer, while others seemed to be as simple as specifying the proper console option within the multiboot command in grub2.

I tried some of the more obvious solutions but was not running into much luck ultimately allowing the system to boot. I did not want to spend too much time investigating this considering I knew I could just switch to Legacy BIOS instead of using UEFI as I did not need to support multi-booting multiple modern operating systems, let alone any other operating systems. There is also a current report open for this issue for xen-system-amd64, although it doesn't appear to be getting much attention considering both individuals were able to workaround the issue.

Without much additional thought I decided to just wipe the system and reinstall with the intention to use legacy BIOS. For some reason I made the assumption that the installer would provide a choice on the type of boot installation method the user would like, but it just proceeded with a grub-install without prompting which target. So while I had the goal in mind to do a legacy BIOS installation, it was just assuming the boot method preference by the method for which I booted into the installer, and thus also using the UEFI-specific grub packages corresponding to that method.

I had found it curious that it threw a warning about a missing EFI partition, and then wasn't surprised when the grub-install ultimately failed. I let it proceed and immediately rebooted into rescue mode to repair the boot partition and saw the EFI grub packages installed but using a target of i386-pc. It was then that I came to a realization that it installed the respective packages based on the installer boot method. Instead of messing with removing and reinstalling the appropriate grub packages, toying with fdisk, and given the base install is quite snappy, I booted into the installer via legacy BIOS this time and installation was seamless. Installed the Xen kernel and had no

I am still a little perplexed on what the cause of the original incompatibility with my system, UEFI, and Xen is since I'd prefer not to fallback on an old technology to remediate an unknown issue involving a current one. Perhaps I'll explore more when I set up the second system.