On Wed, May 18, 2022 at 01:20:27PM +0200, Guilherme De Oliveira Santos wrote: [bm = baremetal] 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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html

On 05/18/22 15:30, Richard W.M. Jones wrote: 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. 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

On 05/19/22 12:50, Richard W.M. Jones wrote: Yes, USB devices should be enumerated and re-inited by Linux from zero. Laszlo