Ask Your Question
-1

Computer only boots to emergency mode after upgrading hard drive

asked 2013-09-05 23:10:17 -0500

ZedGama3 gravatar image

What I've done so far:

  • Installed new hard drive /dev/sda
  • created the two partitions /boot and lvm2
  • copied files to new /boot ( cp -av /boot /new/boot )
  • updated fstab for uuid of new /boot
  • vgextended fedora /dev/sda3
  • pvmove /dev/sdb2 /dev/sda3
  • vgreduce /dev/sdb2
  • pvremove /dev/sdb2
  • grub2-install /dev/sda
  • grub2-mkconfig -o /boot/grub2/grub.cfg

Symptoms:

  • With both hard drives installed unit boots normally
  • When the old hard drive ( /dev/sdb ) is removed, the unit boots to grub and will attempt to load fedora ( showing the blue and white loading bar on the bottom of the screen.
  • After taking about 2+ minutes the loading screen will dump me to some kind of emergency shell and state that it is unable to boot and to look at sosreport.txt for further information to resolve the issue.
  • sosreport.txt states (in part): [ 1.862157] localhost.localdomain systemd[1]: Expecting device dev-disk-by\x2duuid-f178e0bb\x2d7cac\x2d46c8\x2d9911\x2d45e2843b14f9.device... (but I don't know what is requesting this to load because its not in fstab, nor part of the logical volume set)
  • lvdisplay shows that all logical volumes are active except for /home

I've done everything I can think of to remove my old drive, but something still keeps asking for it. Please help me figure out what it is. The uuid mentioned is for the old /boot.

edit retag flag offensive close merge delete

Comments

1

Did you update the new /etc/fstab to use the new UUID of all the new filesystems, or only /boot?

randomuser gravatar imagerandomuser ( 2013-09-06 00:19:00 -0500 )edit
1

Usually you perform these step from a separate environment (e.g. a liveCD) to make sure that none of the files are locked, or will change during the migration process. Additionally, commands like grub2-mkconfig need to be run from the new environment and thus require a chroot.

In general you've got the steps, but you issued them from the wrong linux installations.

Also it was very brave but not very smart to remove the old partition before testing the new one,

Jann5s gravatar imageJann5s ( 2013-09-06 03:36:55 -0500 )edit

@randomuser: My fstab only has one UUID and that is for /dev/sda2 (/boot). What I couldn't understand was why when I did a grep -ir f178e0bb /etc/* that nothing would come up. This is what lead me to believe that it might be contained within the initramfs.

ZedGama3 gravatar imageZedGama3 ( 2013-09-06 07:59:24 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
3

answered 2013-09-06 07:54:54 -0500

ZedGama3 gravatar image

The problem was that the initramfs had not been updated and still had links to the old file systems. This was easily resolved by running dracut as root.

The way that I determined this was the problem was by unzipping and extracting the initramfs image. After looking through the files I found references to the old UUID under /etc/systemd/system/.

edit flag offensive delete link more

Question Tools

Stats

Asked: 2013-09-05 23:10:17 -0500

Seen: 1,541 times

Last updated: Sep 06 '13