Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Descriptionmxie@redhat.com
2021-05-27 04:43:38 UTC
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:
Comment 2Richard W.M. Jones
2021-05-27 13:30:59 UTC
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
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.
Comment 10Richard W.M. Jones
2022-11-01 07:48:42 UTC