[Libguestfs] Re: Can't boot UEFI VM after migration: "error: can't find command `linux16`"
On Mon, Aug 03, 2026 at 01:45:44PM +0530, Srihari Parimi via Libguestfs wrote:
Hi Richard,
This is a more comprehensive description of the problem, where I respond to
the specific issue and questions that you brought up during the discussion
last week. I also cover the proposed solution towards the end. Kindly bear
with the somewhat longish one
What thread is this all in response to ? AFAICT, there's nothing
in the list archives with this subjct.
- *[Comment 2] Confirming that the virtual machine Linux file
format is fully compatible with the new directive*
- Based on the analysis done for the previous comment, we can
safely conclude that this problem is very specific to RHEL 7 only.
Further, the problem occurs when following conditions are met
- Source VM must be in UEFI boot mode
- In the /etc/fstab, the /boot and /boot/efi partitions must
be identified by the corresponding /dev/sd* files instead of the UUIDs
(default) generated during FS creation.
- The second condition forces virt-v2v conversion to configure GRUB.
- As the grub configuration executes in context of
libguestfs appliance (BIOS mode), it is generated with linux16,
initrd16 whereas the VM is configured to boot in UEFI.
- The VM powers up with UEFI firmware, but the linux16
directive switches the CPU into 16-bit real mode and look for BIOS
services (/boot/grub2/i386-pc) which are absent.
- *[Comment 3] Regarding the potential modification of file system
table entries and disk device naming conventions, Richard Jones
insisted that any statements regarding potential disk access problems
must be accompanied by a detailed explanation of the "why" and
"what"
behind those risks*
- The kernel device discovery (names /dev/sd*) is
non-deterministic as it is based on order of driver initialization at
the boot time. The order variation is due to asynchronous driver
probe, kernel update or VM configuration changes.
Conceptually I agree, but in practice this is does not look like
an actual problem. If the original guest before v2v was using
device names already, then it must have been OK, unless the guest
was already broken in some way.
- By "hard-coding" the device names inside
/etc/fstab, there
could be a possibility of an unintended device being mounted onto an
incorrect mount point, thus causing the system to fail or corrupt.
- UUIDs (written into FS) are more reliable - where order of
initialization would not matter making it more deterministic.
- *The proposed solution*
- Convert the references to /dev/sd* files to corresponding FS
UUIDs *[Implemented and tested]*
IMHO the use of device names vs UUIDs in an image is a end user choice,
and v2v shouldn't really override that.
- Following change applicable only if OS is RHEL 7 and Boot
mode is UEFI
- Replace {linux16, initrd16} with {linuxefi, initrdefi}
*[Work in progress to change from using sed to using APIs]*
Rather than hardcoding that specific logic, why not query the original
grub.conf and preserve what it used in the new config? Or not even
re-generate grub.conf at all, instead replace the device paths inline ?
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|