Created attachment 1787473 [details] debian10.9.0-uefi-guest-cannot-boot-os-after-v2v.png Description of problem: Debian UEFI cannot boot into OS normally after v2v conversion Version-Release number of selected component (if applicable): virt-v2v-1.42.0-12.module+el8.5.0+10976+d40a93e9.x86_64 libguestfs-1.44.0-3.module+el8.5.0+10681+17a9b157.x86_64 libvirt-client-7.3.0-1.module+el8.5.0+11004+f4810536.x86_64 qemu-kvm-6.0.0-16.module+el8.5.0+10848+2dccc46d.x86_64 nbdkit-1.24.0-1.module+el8.4.0+9341+96cf2672.x86_64 How reproducible: 100% Steps to Reproduce: 1.Convert debian UEFI guest from VMware to rhv4.4 by v2v # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -ip /home/passwd -o rhv-upload -oo rhv-direct -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -of raw -os nfs_data -b ovirtmgmt esx7.0-debian10.9.0-x64-uefi [ 0.6] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-debian10.9.0-x64-uefi -it vddk -io vddk-libdir=/home/vddk7.0 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 [ 2.2] Creating an overlay to protect the source from being modified [ 3.0] Opening the overlay [ 8.1] Inspecting the overlay [ 11.5] Checking for sufficient free disk space in the guest [ 11.5] Estimating space required on target for each disk [ 11.5] Converting 10.9 to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: This guest has virtio drivers installed. [ 30.1] Mapping filesystem data to avoid copying unused and blank areas virt-v2v: warning: fstrim on guest filesystem /dev/sda1 failed. Usually you can ignore this message. To find out more read "Trimming" in virt-v2v(1). Original message: fstrim: fstrim: /sysroot/: the discard operation is not supported [ 31.0] Closing the overlay [ 31.2] Assigning disks to buses [ 31.2] Checking if the guest needs BIOS or UEFI to boot virt-v2v: This guest requires UEFI on the target to boot. [ 31.2] Initializing the target -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data [ 32.6] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.hJkJlj/nbdkit4.sock", "file.export": "/" } (raw) (100.00/100%) [ 430.2] Creating output metadata [ 432.1] Finishing off 2.Power on guest on rhv after v2v conversion, guset can't boot into OS, please refer to screenshot'debian10.9.0-uefi-guest-cannot-boot-os-after-v2v.png' Actual results: As above description Expected results: Debian UEFI can boot into OS normally after v2v conversion Additional info:
Created attachment 1787474 [details] virt-v2v-debian10.9.0-x64-uefi.log
When mounting the /boot partition, virt-v2v says: [ 27.767466] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. This guest definitely works/boots OK on the source? Also there's a program called "fsck.vfat" and it could be useful to run that on the guest when it's running on VMware to check the /dev/sda1 partition.
(In reply to Richard W.M. Jones from comment #2) > When mounting the /boot partition, virt-v2v says: > > [ 27.767466] FAT-fs (sda1): Volume was not properly unmounted. Some data > may be corrupt. Please run fsck. > > This guest definitely works/boots OK on the source? > > Also there's a program called "fsck.vfat" and it could be useful > to run that on the guest when it's running on VMware to check > the /dev/sda1 partition. Yes, the guest can boot into OS normally on VMware, below is some guest info: $ uname -a Linux vm-197-19 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 12G 0 disk ├─sda1 8:1 0 512M 0 part /boot/efi ├─sda2 8:2 0 10.6G 0 part / └─sda3 8:3 0 976M 0 part [SWAP] sr0 11:0 1 1024M 0 rom $ cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda2 during installation UUID=27867a36-576a-4f5e-a41d-60d4ce4a91e4 / ext4 errors=remount-ro 0 1 # /boot/efi was on /dev/sda1 during installation UUID=54BB-77DA /boot/efi vfat umask=0077 0 1 # swap was on /dev/sda3 during installation UUID=606f10dc-85c5-4184-999e-794c3b7aeb12 none swap sw 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.
As far as I remember, this is a well-known Debian bug. Debian does not implement the fallback logic that "shim / fallback" implement e.g. in Fedora. To provide an analogy from the physical world: if you grab a physical hard disk with a UEFI Debian installation on it, from one machine, and insert it into another UEFI machine, it will not boot. Fedora will. The fallback logic is described here at length: <https://blog.uncooperative.org/uefi/linux/shim/efi%20system%20partition/2014/02/06/the-efi-system-partition.html> Upstream virt-v2v commit 59f0c2795263 ("v2v: fix UEFI bootloader for linux guests", 2020-07-24) introduced a workaround for this, but as far as I can tell, it only applies to "Ubuntu 14", and not "Debian *". Furthermore, the upstream commit was released as part of v1.43.2, and this BZ was reported against virt-v2v-1.42.0-12, so I think the upstream commit could not have been included in the RPM. This BZ should be re-tested against the latest code, and if necessary, we could extend the ubuntu match to some debian releases.
Disable stale bug nonsense.