[Libguestfs] ovirt VM image to BM

[Laszlo Ersek]

On 05/18/22 15:30, Richard W.M. Jones wrote:
> On Wed, May 18, 2022 at 01:56:36PM +0100, Richard W.M. Jones wrote:
>>
>> On Wed, May 18, 2022 at 01:20:27PM +0200, Guilherme De Oliveira Santos wrote:
>>> Greetings masters,
>>>
>>> I got pointed to you guys as experts on smtg I'm struggling with.
>>> I'm trying to move an ovirt vm raw image to a bm machine and though
>> [bm = baremetal]
>>> I could do it successfully using dd (got able to see and work with
>>> the partitions and the data fine), I couldn't boot the disk.
>>>
>>> It may be an issue with drivers (like the virtio drivers), but idk,
>>> and I'm wondering if someone has done smtg similar or could help
>>> somehow with the process.
>>
>> So in IRC we established that it's a RHEL 8.6 guest, and that it
>> doesn't get as far as grub.  The virtual machine boots with UEFI and
>> the physical machine boots with BIOS which is why grub doesn't work.
>>
>> Conversion of a machine from UEFI to BIOS is usually quite tricky.
>> Are you sure the baremetal machine doesn't support UEFI booting?
>> Almost anything made in the last 10 years should, although you may
>> have to adjust the firmware ("BIOS") configuration.
>>
>> After that it'll probably not have the right drivers in the initramfs.
>> Symptoms would be that it gets to grub, then boots the kernel, but
>> fails when mounting the root filesystem.  Luckily this is easier
>> to solve - identify which drivers are needed for the target
>> hardware and before copying across, run “dracut --add-drivers ..”
>> You'll have to read the dracut man page closely.
> 
> Update is that after changing the hardware to use UEFI it booted all
> the way (a little surprising?)

It's a great outcome, but not really surprising -- this is how things
*should* work.

While the platform firmware on the physical machine did not have a UEFI
boot option for the RHEL-8.6 OS, RHEL-8.6 does provide the "fallback"
boot path, so it works.

Basically: provide a special boot loader at the default boot path that
is otherwise only used with removable media, namely,
\EFI\BOOT\BOOTX64.EFI. This utility (originally called "fallback.efi",
from the shim project) then recreates the proper UEFI boot options, from
a small CSV table that's also kept on the EFI system partition.

For this to work, the platform firmware and the (original) OS installer
must co-operate. Debian used not to provide such a fallback -- I'm not
sure about their current status.

> But the keyboard doesn't work.  This is also surprising because I
> *thought* that both virt and baremetal basically use emulated or real
> USB keyboard these days.

The keyboard does not work -- where?

Once the OS is reached (gdm or console root prompt), or in grub
(pre-boot, basically)?

The latter, I can explain. UEFI has a phase called "Boot Device
Selection" (BDS) where the firmware decides exactly what devices to
"connect" -- meaning what devices should be *bound* by UEFI drivers.

There is a number of policies here; the gist is that the platform vendor
can do whatever they want -- BDS is called "platform policy".

Usually they support at least two configs, "full config" and "fast
boot". Under "fast boot", the firmware only connects such devices to
UEFI drivers that the firmware *knows* are needed for booting, and
ignores everything else, including newly connected devices, potentially.
Therefore, a USB keyboard could end up "non-driven" by UEFI because it
is not needed for booting!

The fix is to get into the firmware setup UI by some other way [*], and
either disable "fast boot", or -- if the firmware is flexible enough --
explicitly enable the binding of USB devices.

[*] From "/etc/grub.d/30_uefi-firmware", the command

  grub2-mkconfig -o /etc/grub2-efi.cfg

should create a grub2 menu entry, usually at the end of the boot menu,
that invokes the "fwsetup" grub2 command. The trick is to make this
entry the default entry, once the OS has fully booted (I guess via
GRUB_DEFAULT in "/etc/default/grub"), and then reboot. When grub2
executes "fwsetup", it modifies a particular non-volatile UEFI global
variable ("OsIndications"), and upon seeing that, the firmware at next
boot will drop into the setup UI.

Thanks
Laszlo