{"id":55025,"date":"2026-08-29T07:23:30","date_gmt":"2026-08-29T07:23:30","guid":{"rendered":"https:\/\/accuweb.cloud\/resource\/?post_type=cs_article&p=55025"},"modified":"2026-08-29T07:23:43","modified_gmt":"2026-08-29T07:23:43","slug":"fixing-linux-boot-issues-after-migration","status":"publish","type":"cs_article","link":"https:\/\/accuweb.cloud\/resource\/cs\/fixing-linux-boot-issues-after-migration","title":{"rendered":"Fixing Linux Boot Issues After Migration"},"content":{"rendered":"

Fixing Linux Boot Issues After Migration<\/b><\/h1>\n

A server that boots perfectly on its original host and then refuses to come up after a migration is one of the more stressful situations you can run into, mostly because the fix usually has to happen from a rescue shell or console access rather than a normal SSH session. The good news is that boot failures after migration almost always trace back to a small handful of causes, and once you know what to check, getting the system back up is usually a fifteen minute job rather than a rebuild. This article walks through diagnosing and fixing the most common ones.<\/p>\n

<\/div>\n
\n
Create Account \u00bb<\/a><\/div>\n<\/div>\n
<\/div>\n

Step 1: Find Out Why the Boot Actually Failed<\/b><\/h2>\n

Before changing anything, pull up the previous boot’s logs to see what the kernel was complaining about right before it dropped into emergency mode. Combined with a quick blkid check, this usually tells you exactly what is wrong:<\/p>\n

\"Boot<\/a><\/p>\n

In this case the kernel is looking for a device by a UUID that no longer exists on this system. This is the single most common cause of boot failures after a migration. The disk itself came across fine, but its UUID changed, either because the disk was recreated during the migration or because it was attached as a fresh volume rather than a byte for byte clone of the original.<\/p>\n

Step 2: Point the Bootloader at the Correct UUID<\/b><\/h2>\n

Once you know the real UUID of the root disk from blkid, the fix is to update the kernel command line in the grub configuration to reference it, then regenerate the actual grub config file that gets read at boot time:<\/p>\n

grub2-mkconfig -o \/boot\/grub2\/grub.cfg<\/b><\/p>\n

\"Bootloader\"<\/a><\/p>\n

It is worth double checking \/etc\/default\/grub before running this, since that is the file that actually defines what GRUB_CMDLINE_LINUX gets baked into the generated config. If the UUID in that file still points to the old disk, regenerating the config will just carry the wrong value forward.<\/p>\n

Step 3: Rebuild the Initramfs and Reboot<\/b><\/h2>\n

The initramfs is what the kernel loads first, before your real root filesystem is even mounted, and it needs to contain the right drivers and device mappings for the new environment. If it was built for the old host, it can still cause a failed boot even after grub itself is fixed. Rebuilding it and rebooting closes the loop:<\/p>\n

dracut -f -v \/boot\/initramfs-5.14.0-427.el9.x86_64.img 5.14.0-427.el9.x86_64<\/b><\/p>\n

reboot<\/b><\/p>\n

\"<\/a><\/p>\n

If the reboot comes up clean and you get a normal login prompt, the migration related boot issue is resolved. On CloudStack or KVM in general, this is also a good moment to double check the VM’s disk boot order in case the migration process attached the new disk in a different order than expected.<\/p>\n

Other Common Causes Worth Checking<\/b><\/h2>\n

If UUID mismatches are not the issue, a few other things are worth ruling out:<\/p>\n