[Libguestfs] Re: Can't boot UEFI VM after migration: "error: can't find command `linux16`"

On Mon, Aug 03, 2026 at 11:54:44AM +0100, Daniel P. Berrangé via Libguestfs wrote: > 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. I believe it's related to this confusing upstream pull request: https://github.com/libguestfs/virt-v2v/pull/160 > > - 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. [Note this is largely unrelated to the PR above.] We've been discussing if it's a good idea to simply replace any /dev/XdX device reference with a UUID, where possible, for a few reasons: (1) A kernel upgrade can break an existing working guest. (2) Admins use device references wrongly, and it mostly works but occasionally breaks. For example it can work fine until you add a second disk and then it becomes intermittently flakey. (3) It allows you to move devices around or change drivers in future without breaking the guest. Basically it's just a good idea to use UUIDs to reference filesystems.

The con is that we want to make as few changes as possible, because every change we make in v2v can have unintended consequences when used at the scale of conversions we are doing now.