Cloned VM enters emergency mode after disk copy
An Ubuntu 22.04 server was cloned at the storage layer to create a disaster-recovery test VM. The clone boots into emergency mode. The root filesystem is on LVM (/dev/vg0/root), with separate /var and /data logical volumes. /etc/fstab uses UUIDs for all three plus swap. The original VM remains online, and the clone's disks are presented from the same SAN array but are separate LUNs; the clone's root and /var filesystems therefore have the same UUIDs as the original. The clone's /etc/fstab still references the original /data UUID, which is a LUN that was not mapped to the clone. journalctl -xb shows a dependency failure for /data and a timeout waiting for the device; the root filesystem is mounted read-only. The DR test requires the clone to boot without the /data LUN for the first 48 hours, then attach a copy. No console automation is available, but you have an emergency shell.
1. Bring the system to a usable state and identify which mount is blocking boot. Give commands and explain why you would not simply delete every fstab line.
Read the worked answer
At the emergency shell, remount root read-write with mount -o remount,rw /. Run systemctl --failed, journalctl -xb, lsblk -f, blkid, and cat /etc/fstab. The journal already points to /data; confirm the UUID in fstab is absent from blkid. Do not delete all fstab lines. Root and /var are needed for a normal boot and should remain required; only /data is optional for the 48-hour test. Comment out /data or add nofail,x-systemd.device-timeout=10 to its mount options, create the mountpoint if missing, run systemctl daemon-reload, and reboot. If /var is also missing because of a stale UUID, fix that UUID first; /var cannot be nofail without risking journald and package state. Swap can be made optional. After boot, verify with findmnt --verify and systemctl list-units --failed.
2. The clone and original now have duplicate filesystem UUIDs. What are the risks, and when should you change UUIDs versus leaving them?
Read the worked answer
Duplicate UUIDs are not automatically fatal when the LUNs are visible only to separate hosts; Linux mounts by UUID locally. They become dangerous when both LUNs are mapped to one host, when multipath sees both, or when an administrator attaches the clone's disk to the original for rescue. Then blkid returns two devices with the same UUID and mount can pick the wrong one. Change UUIDs on the clone, not the original, because the original is in production. For ext4 use tune2fs -U random; for XFS use xfs_admin -U generate. Update the clone's fstab, then rebuild initramfs and GRUB if root or /var changed. Do this from a chroot or rescue environment with the filesystem unmounted. If the /data copy is attached later, give it a new UUID as well and update fstab. Document the mapping so DR tests do not reintroduce duplicates.
3. Make the fix persistent for attaching /data after 48 hours, and describe how you would verify both boot states.
Read the worked answer
Add to the clone's /data entry: nofail,x-systemd.device-timeout=10. nofail lets boot continue when the LUN is absent; the timeout prevents a 90-second default stall. Keep the entry so that mount -a or systemd mounts it when the copy appears. Create /data with correct ownership before the attach. After attaching the copy, verify the new UUID with blkid, update fstab, run systemctl daemon-reload, then mount /data and findmnt --verify. Test both states: reboot with the LUN absent and confirm the multi-user target, then attach and confirm the mount. If /data is needed by an application, use a systemd unit with RequiresMountsFor=/data rather than assuming it is present. Do not use nofail on /var or root. Record the 48-hour change and revert the fstab line to a required mount once the copy is permanent.