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

On Wed, Aug 05, 2026 at 10:29:16AM +0100, Richard W.M. Jones wrote: > 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. I agree, but I'm very sceptical that v2v should be forcing that decision on users during a VM conversion. > 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. Yep, there may be reasons an org chose to use device names that we are not aware of. If an organization has a corporate standard provisioning workflow that uses device names, we should honour that in VMs we convert IMHO.