This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
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.
Bug 1965176 - Debian UEFI cannot boot into OS normally after v2v conversion
Summary: Debian UEFI cannot boot into OS normally after v2v conversion
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: virt-v2v
Version: unspecified
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: tingting zheng
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-27 04:43 UTC by mxie@redhat.com
Modified: 2023-08-29 06:06 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-24 02:11:56 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
debian10.9.0-uefi-guest-cannot-boot-os-after-v2v.png (111.46 KB, image/png)
2021-05-27 04:43 UTC, mxie@redhat.com 		no flags Details
virt-v2v-debian10.9.0-x64-uefi.log (2.34 MB, text/plain)
2021-05-27 04:44 UTC, mxie@redhat.com 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker   RHEL-1631 0 None None None 2023-08-29 06:06:31 UTC

Description mxie@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 1 mxie@redhat.com 2021-05-27 04:44:59 UTC 
Created attachment 1787474 [details]
virt-v2v-debian10.9.0-x64-uefi.log
Comment 2 Richard 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.
Comment 3 mxie@redhat.com 2021-05-27 13:44:29 UTC 
(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
Comment 5 Eric Hadley 2021-09-08 16:49:43 UTC 
Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.
Comment 6 Laszlo Ersek 2022-01-19 16:14:46 UTC 
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 10 Richard W.M. Jones 2022-11-01 07:48:42 UTC 
Disable stale bug nonsense.
Note You need to log in before you can comment on or make changes to this bug.