About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
A Linux VM that stops after migration may have the right data on disk and still be unable to find it. The new hypervisor can change the storage controller, firmware, device path and network identity. The quickest useful diagnosis is to locate the failed stage: firmware, boot loader, initramfs, root filesystem, later mounts or networking. Each stage has different evidence and different repair tools.
This article provides a diagnosis and planning method, based on source documentation. No recovery procedure was executed in a lab. Rebuilding an initramfs, activating storage, mounting an offline installation or installing a boot loader needs a procedure for the actual distribution and release. Those operations are deliberately kept out of the diagnostic examples below.
Recommendations and interpretations are editorial unless attributed; source research is not lab validation.
Start with an evidence bundle
Record the source distribution, release, kernel, firmware mode, controller type, disk layout and encryption method. Keep the conversion logs, original VM configuration and the exact target configuration. A photograph or console capture of the final boot message is more useful than a description such as "Linux is broken" because it identifies how far the system progressed.
Identify the authoritative copy before any recovery boot. A VM that appears unused may have accepted a queue message, updated a database or run a scheduled task during an earlier attempt. The source is only a current rollback point while its data remains current or newer writes have a reconciliation plan. Keep duplicate machines isolated from production identities, networks and shared storage.
Use a separate disk copy for repair validation where possible. Booting rescue media is not automatically a write-free operation: storage discovery, activation and automatic mounts may change state. The person preparing the environment should control those behaviours and document which devices are visible. Do not expose both the original and a block-level clone casually; they can contain identical filesystem and LVM identifiers.
Locate the failed boot stage
| Observation | Leading area to investigate | Evidence to collect |
|---|---|---|
| Firmware cannot find a boot device | Firmware mode, attachment or boot entry | Source and target firmware, boot order and disk map |
| GRUB prompt or loader error | Boot partition, loader configuration or path | Exact error and the selected boot entry |
| Kernel starts but cannot mount root | Kernel drivers, initramfs or root identifier | Selected kernel, command line and early logs |
| Emergency shell after root mounted | Required mounts or system services | Failed units, journal and mount configuration |
| Login works but networking fails | Adapter identity, profile matching or network delivery | Link names, MAC addresses, routes and profile bindings |
These are investigation directions, not exclusive diagnoses. A kernel panic does not uniquely prove a missing VirtIO module, and systemd emergency mode does not uniquely prove an incorrect fstab. Preserve the first relevant error and connect it to the observed device state before choosing a repair layer.
Keep firmware and the boot loader separate
Proxmox's migration guidance maps BIOS guests to SeaBIOS and UEFI guests to OVMF. Some UEFI installations register a custom loader entry without placing a loader at the default fallback path. Copying the main disk does not necessarily preserve that firmware entry or the platform's persistent firmware storage.
Record whether the EFI system partition and any separate boot partition were included in the migration. The presence of a GPT partition table alone does not establish that the target is using the correct firmware or loader. A firmware-level failure should first be investigated against the source layout, rather than treated as permission to reinstall GRUB or convert the partition table.
The GRUB manual describes the loader's configuration, but distribution packaging decides how installed files are generated and updated. Some systems use Boot Loader Specification entries for kernel options. A generic instruction to rewrite one grub.cfg file can therefore update the wrong place or bypass the distribution's supported mechanism.
Distinguish the running kernel from the installed kernel
A rescue environment runs its own kernel. Entering an offline installation does not change that kernel. Therefore, a kernel version reported by the running rescue session cannot identify which installed kernel the failed VM was trying to boot. Record both versions and the selected boot entry before comparing modules or initramfs contents.
An initramfs supplies the early userspace needed to find and mount root. dracut can build a host-only image containing what it detects for a particular machine. That image may not contain what a different virtual controller needs. Debian's initramfs-tools configuration has a related distinction between broader and dependency-based module selection.
Those manuals describe mechanisms, not a guarantee about every distribution image. The word most in Debian's module policy does not itself prove that a particular VirtIO block driver is included. The evidence must concern the actual selected kernel, its configuration and its associated initramfs image.
For VirtIO storage, distinguish the controller driver from the transport. VirtIO Block and VirtIO SCSI require different storage support; PCI-attached VirtIO devices also need the relevant transport support. A kernel can compile a driver in rather than load it as a module. An absent module filename is therefore insufficient evidence that the kernel lacks the capability.
Read the early-boot evidence
Where the initramfs provides a diagnostic shell, collect the command line, visible block devices and logs without changing them. Tools differ between images, and a missing utility says nothing about disk health. Dracut documents /run/initramfs/rdsosreport.txt as a useful diagnostic report when available.
These examples inspect the environment in which they run. They are not a rescue setup sequence:
cat /proc/cmdline
ls -l /dev/disk/by-uuid/
lsmod
The command line shows the root target and any storage-related parameters selected by the boot loader. The UUID links show what the current environment has discovered. Loaded modules show only loadable drivers currently in use; built-in drivers do not appear there. Record the environment, selected kernel and timestamp with the output so another engineer can interpret it correctly.
If no expected disk appears, compare the target attachment with the controller support in this kernel and image. Other possibilities include a missing virtual disk, a storage-access problem or a failed discovery path. If the disk appears but the root identifier does not match, investigate identity and layout before proposing a driver rebuild.
A successful boot using a rescue entry or another supported controller narrows the investigation. It shows that this combination could read enough data to boot. It does not prove the filesystem is healthy or uniquely identify a missing driver, because the alternative may also change names, startup parameters and storage discovery.
Follow identifiers through the whole stack
Device names such as /dev/sda and /dev/vda describe enumeration, which can change when the controller or disk order changes. Filesystem UUIDs usually survive a block-level copy, making them useful migration references. That same property creates duplicate identities when both the original and its clone are visible together.
Compare the expected root reference, filesystem UUID, partition UUID and disk mapping. These are different identifiers and should not be substituted for one another. Labels can also be duplicated. Controller-based paths can change after migration, so a path that was stable on the source may not identify the intended device on the target.
The investigation should cover more than /etc/fstab. Root parameters, encryption configuration, swap-resume settings, RAID assembly and multipath mappings may each contain identifiers. A correct root mount can still be followed by emergency mode when a required secondary mount is missing. Conversely, adding an option that ignores a mount failure can conceal an unavailable application data volume.
Before approving an identifier change, record the application's expected mount point and which dataset belongs there. The acceptance test must prove that the correct volume is mounted, not merely that boot now continues. Detailed repair of encrypted storage, software RAID and multipath belongs in a separate, version-specific procedure.
Check LVM in its actual context
An LVM physical volume identifier and the device identifier stored in an LVM devices file are not the same thing. A migration can preserve the physical volume contents while changing the virtual hardware identifier. The lvmdevices manual explains how system.devices records both, and how refresh can locate a preserved physical volume on a newly identified device.
The LVM change log records automatic refresh on a changed system in version 2.03.23. Older distribution packages may not provide the same behaviour or options. The upstream manual uses a machine identifier derived from the DMI product UUID or hostname, so a migration that preserves those values may not trigger the same refresh decision as one that changes them.
Check the installed package version, local manual and configuration before drawing a conclusion. Also determine whether the failure occurs inside the initramfs or after the installed system has started. The independently reviewed upstream dracut LVM module copies LVM configuration and system-ID material without an explicit system.devices reference; distribution builds and other hooks may differ. Inspect the actual image rather than assuming the installed devices file controls early boot.
If a diagnostic view changes when a devices-file restriction is bypassed, that is evidence worth investigating. It is not exclusive proof that the file is the only fault. Duplicate identifiers, filters and missing devices can complicate the result. A proposed repair should name the intended physical volumes, expected device identities and version-supported refresh mechanism, then verify the resulting image on an isolated copy.
Encryption and TPM changes
A disk protected by a TPM-bound secret can become inaccessible when the virtual TPM changes. The virt-v2v manual requires a passphrase-based LUKS keyslot where its conversion path needs to unlock an encrypted guest. It also warns against removing the source TPM binding because the source must remain bootable if conversion fails.
That guidance does not mean every TPM-enrolled disk exposes a usable passphrase. The manual distinguishes clevis handling from systemd-cryptenroll, whose sealed secret is not exposed in the same way. Confirm the available recovery material and the converter's supported method before migration. Do not remove an existing protection merely because the target cannot use it yet.
A recovery plan should connect the encrypted device, its unlock method, its mapped name and the filesystem above it. If the encrypted layer is unavailable, the absence of the filesystem UUID is an expected consequence, not a reason to rewrite fstab. Handle recovery secrets outside ordinary logs and shared diagnostic reports.
When Linux boots but the network does not
systemd's naming documentation describes names derived from device characteristics, including placement. A different virtual PCI layout can produce a different interface name. A changed MAC address can independently break DHCP reservations, licensing rules or a network profile's matching conditions.
Compare current link names and addresses with the recorded source configuration. Then identify which network manager owns the interface. NetworkManager profiles, Netplan configuration and traditional interface files use different matching rules. A profile tied to the old interface name or permanent MAC may no longer select the new device.
A profile without an interface-name restriction can match more broadly than expected; inspect its other constraints before calling it correct. Disabling predictable naming is also not a universal repair. A systemd .link file with an explicit name can still apply, and renaming does not correct an incorrect VLAN, bridge, route or DNS setting.
Once the profile matches the intended adapter, verify network delivery separately. Check the hypervisor attachment, network tag, address, gateway and resolver path. A working link indicator proves less than a successful application connection. Keep console access available during any approved network change so loss of the current connection does not remove the recovery path.
Build a repair plan that can be verified
Write down one hypothesis, the evidence supporting it and the expected result of one change. A driver-image plan needs the installed kernel version, supported distribution tooling, required controller support, available boot space and a preserved previous boot option. A boot-loader plan needs the correct firmware mode, system partition and distribution update mechanism. A network plan needs an identified adapter and an explicit configuration owner.
Validate the selected procedure on a separate copy, including a second boot and the failure path. Confirm all required filesystems, encryption behaviour, services and network dependencies. Test the application with controlled data and check that any test writes are accounted for before opening production access.
Finally, record which machine holds the current data and the route back if acceptance fails. The useful outcome is more than clearing an emergency prompt: it is a repeatable boot, correct volumes, working application dependencies and a recovery path that has been demonstrated for this exact guest.
Sources
Source research checked 2026-11-10; commands were not lab tested.
- dracut(8), dracut.conf(5), dracut.cmdline(7)
- Debian: initramfs.conf(5), initramfs-tools(7), grub-install(8), interfaces(5)
- fstab(5), lsblk(8), findmnt(8), mount(8), umount(8)
- lvmdevices(8), vgchange(8)
- systemd.net-naming-scheme(7), systemd.link(5), systemd.network(5), systemd.mount(5)
- NetworkManager settings, Netplan YAML reference
- GNU GRUB manual
- Linux source:
drivers/block/Makefile,drivers/block/virtio_blk.c,drivers/scsi/Makefile,drivers/scsi/Kconfig,drivers/virtio/Makefile,init/do_mounts.c - LVM2 change log
- dracut LVM module source
- UAPI Group: Boot Loader Specification
- Proxmox: Migrate to Proxmox VE
- libguestfs: virt-v2v manual
This article was originally published on .