扩容/root分区后系统无法启动，emergency mode及default.target故障求助

Got it, this is a common headache after root partition resizing—usually from accidental filesystem corruption or messed-up systemd target configurations. Let’s walk through fixing this step by step while you’re in emergency mode:

1. First, Verify and Repair the Root Filesystem #

Partition resizing can easily leave filesystem inconsistencies, which often trigger emergency mode.

• First, check the root filesystem in read-only mode to avoid making things worse:

  fsck -n /dev/[your-root-device]
  

  Replace [your-root-device] with your actual root partition (e.g., /dev/sda1, /dev/mapper/vg-root). If fsck reports errors, run it in repair mode:

  fsck -y /dev/[your-root-device]
  

• If your root is on LVM, first ensure the volume group is activated:

  vgchange -ay
  

2. Fix the default.target Configuration #

The error Transaction is destructive usually means systemd can’t resolve the default target properly—either the symlink is broken, or the target itself has missing dependencies.

• Check what default.target is currently pointing to:

  ls -l /etc/systemd/system/default.target
  

  Normally, this should be a symlink to either multi-user.target (text mode) or graphical.target (GUI mode). If it’s broken, missing, or pointing to something invalid, reset it:

  # Set to text mode first (more stable for troubleshooting)
  systemctl set-default multi-user.target
  

• Reload systemd to apply the change:

  systemctl daemon-reload
  

3. Validate /etc/fstab and Partition UUIDs #

Resizing can sometimes alter partition UUIDs, making /etc/fstab entries invalid (which breaks root mount and cascades to target failures).

• List current partition UUIDs:

  blkid
  

• Compare the UUID for your root partition with the entry in /etc/fstab:

  cat /etc/fstab
  

• If they don’t match, edit /etc/fstab with a text editor like nano to update the UUID to the correct one from blkid.

4. Dig Deeper with Systemd Logs #

If the above steps don’t fix it, check the full systemd boot logs for hidden issues:

journalctl -xb

Look for lines marked FAILED or error messages related to services that depend on default.target—sometimes a failed critical service (like network, storage, or display manager) can cause this "destructive transaction" error.

5. Test the Fix #

Once you’ve made the necessary changes, try starting the default target manually:

systemctl start default.target

If this succeeds, you can exit emergency mode with exit and the system should boot normally. If not, go back to the logs to find remaining issues.

内容的提问来源于stack exchange，提问作者Harmnot