Fedora 21/UEFI recovery

From Sugar Labs
< Fedora 21
Revision as of 22:42, 13 August 2014 by Satellit (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

https://fedoraproject.org/wiki/User:Dmossor/uefi-recovery Copy of this web page is shown below: User:Dmossor/uefi-recovery

The Problem

So, I recently was attacked by anaconda, the Fedora installer we all know and love (to hate). While testing out a nightly build of Fedora 21, I installed to a USB hard drive attached to my laptop, with the intention of simply unplugging the USB drive and continuing on my way when I was done. However, one of the steps of the build is to create the boot entry in the UEFI firmware. Here is the log that shows exactly what happened: 

Aug 11 22:48:35 g55-f21 program[2698]: Running... efibootmgr
Aug 11 22:48:35 g55-f21 program[2698]: BootCurrent: 0004
Aug 11 22:48:35 g55-f21 program[2698]: Timeout: 0 seconds
Aug 11 22:48:35 g55-f21 program[2698]: BootOrder: 0000,0004,0003,0005
Aug 11 22:48:36 g55-f21 program[2698]: Boot0000* Fedora
Aug 11 22:48:36 g55-f21 program[2698]: Boot0003* Hard Drive
Aug 11 22:48:36 g55-f21 program[2698]: Boot0004* UEFI: KingstonDT 101 G2 PMAP
Aug 11 22:48:36 g55-f21 program[2698]: Boot0005* CD/DVD Drive
Aug 11 22:48:36 g55-f21 program[2698]: Running... efibootmgr -b 0000 -B
Aug 11 22:48:36 g55-f21 program[2698]: BootCurrent: 0004
Aug 11 22:48:36 g55-f21 program[2698]: Timeout: 0 seconds
Aug 11 22:48:36 g55-f21 program[2698]: BootOrder: 0004,0003,0005
Aug 11 22:48:36 g55-f21 program[2698]: Boot0003* Hard Drive
Aug 11 22:48:36 g55-f21 program[2698]: Boot0004* UEFI: KingstonDT 101 G2 PMAP
Aug 11 22:48:36 g55-f21 program[2698]: Boot0005* CD/DVD Drive
Aug 11 22:48:36 g55-f21 program[2698]: Running... efibootmgr -c -w -L Fedora -d /dev/sdd -p 1 -l \EFI\fedora\shim.efi
Aug 11 22:48:36 g55-f21 program[2698]: BootCurrent: 0004
Aug 11 22:48:36 g55-f21 program[2698]: Timeout: 0 seconds
Aug 11 22:48:36 g55-f21 program[2698]: BootOrder: 0000,0004,0003,0005
Aug 11 22:48:36 g55-f21 program[2698]: Boot0003* Hard Drive
Aug 11 22:48:36 g55-f21 program[2698]: Boot0004* UEFI: KingstonDT 101 G2 PMAP
Aug 11 22:48:36 g55-f21 program[2698]: Boot0005* CD/DVD Drive
Aug 11 22:48:36 g55-f21 program[2698]: Boot0000* Fedora

If you are familiar with the efibootmgr command, you see that the fist thing it does is delete entry 0000. According to the folks from Anaconda, it searches for a boot entry labeled "Fedora" (case insensitive) and deletes it - this is not well publicized, so there is a workaround (more on this later). No checks as to the install destination are performed.

What this effectively does is cripple the system. There are no real easy to find write-ups on editing the boot entry directly in the firmware - if your firmware even gives you the option. I could no longer boot to the internal hard drives. The Solution 

   Remove the USB hard drive from the system.
   Boot to a live image, either on disc or via USB thumb drive (I suppose a PXE boot would work, too, if you can do that).
   If your discs are encrypted, you'll need to unlock them.

        cryptsetup luksOpen /dev/sdXY name

   Mount your disks - you'll need to mount all of them so we can chroot to the system.

       mount /dev/sda3 /mnt

       mount /dev/sda4 /home

           For encrypted disks, or LVMs this is slightly different. That name you gave it when you unlocked it is the device you need to mount:

            mount /dev/mapper/name /mnt

       mount /dev/sda2 /mnt/boot

       mount /dev/sda1 /mnt/boot/efi

       mount -o bind /dev /mnt/dev

       mount -o bind /proc /mnt/proc

       mount -o bind /sys /mnt/sys

   chroot /mnt

    yum reinstall grub2-tools grub2-efi shim

   yum install grub2-efi-modules

   grub2-install /dev/sda

Part of the grub2 installation creates your boot entry in the EFI firmware. Now your system can at least boot from the hard drive - but there is still more work to do. When grub2 installs, it installs itself with the current kernel, no matter if your chrooted or not. When you boot, you will need to select the rescue kernel, since none of the other options will likely work.

Once at the command line, check to see what your latest kernel installed is:

ls /boot/

With that piece of information, you'll need to directly edit your grub.cfg using your favorite editor (vi, vim, nano, whatever), and edit one of the boot entries to point at an existing kernel version. You'll need to edit three lines - the boot entry line, and the last two lines in the boot entry with the vmlinuz info:

This is the entry I started with:

menuentry 'Fedora, with Linux 3.13.3-200.fc20.x86_64' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.13.3-200.fc20.x86_64-advanced-7c189a71-2f39-434e-a636-7f779b4fe9c1' { 

       set gfxpayload=text
       insmod gzio
       insmod part_gpt
       insmod ext2
       set root='hd0,gpt2'
       if [ x$feature_platform_search_hint = xy ]; then
         search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  d34de5bc-e563-46e7-ac48-877fe88095c2
       else
         search --no-floppy --fs-uuid --set=root d34de5bc-e563-46e7-ac48-877fe88095c2
       fi
       linuxefi /vmlinuz-3.13.3-200.fc20.x86_64 root=UUID=7c189a71-2f39-434e-a636-7f779b4fe9c1 ro rd.lvm.lv=vg_g55/swap rd.luks.uuid=luks-240788df-a9c7-43ab-ac44-38470c6def3c vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ebe74a8e-9c1e-4200-88d6-ed3bc9cb0435  rhgb quiet 
       initrdefi /initramfs-3.13.3-200.fc20.x86_64.img

}

Editing the menuentry line, and the linuxefi and initrdefi lines, I ended up with this:

menuentry 'Fedora, with Linux 3.15.8-200.fc20.x86_64' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.15.8-200.fc20.x86_64-advanced-7c189a71-2f39-434e-a636-7f779b4fe9c1' { 

       set gfxpayload=text
       insmod gzio
       insmod part_gpt
       insmod ext2
       set root='hd0,gpt2'
       if [ x$feature_platform_search_hint = xy ]; then
         search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  d34de5bc-e563-46e7-ac48-877fe88095c2
       else
         search --no-floppy --fs-uuid --set=root d34de5bc-e563-46e7-ac48-877fe88095c2
       fi
       linuxefi /vmlinuz-3.15.8-200.fc20.x86_64 root=UUID=7c189a71-2f39-434e-a636-7f779b4fe9c1 ro rd.lvm.lv=vg_g55/swap rd.luks.uuid=luks-240788df-a9c7-43ab-ac44-38470c6def3c vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ebe74a8e-9c1e-4200-88d6-ed3bc9cb0435  rhgb quiet 
       initrdefi /initramfs-3.15.8-200.fc20.x86_64.img

Once this is done, you can reboot into a working kernel. The first thing you should do here is run grub2-mkconfig to get it to clean up the config file. The Workaround

That workaround I mentioned earlier? It is possible to rename your boot entry to something other than "Fedora", but efibootmgr appears to be incapable of this - or at least my knowledge of it is.

Retrieved from "https://wiki.sugarlabs.org/index.php?title=Fedora_21/UEFI_recovery&oldid=93214"