0

I accidentally updated grub and broke my system entirely. On an encrypted device (I am able to chroot and access everything though). After a while with no luck I decided to purge grub and install rEFInd. I think I have everything correct, I'm pulling my hair out at this point and have no idea what I'm doing wrong.

I want to boot directly to the EFI stub and have /boot as my EFI partition with kernels and stubs. I'm going to show what I have now, I don't even care about the fact I'm showing IDs or anything. Let me know if there's something I'm missing out on or configuring incorrectly, or if there is any way to run more diagnostics.

parted /dev/sda print tells me:

Model: <blah> SanDisk <blah> (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  1050MB  1049MB  fat32              boot, esp
 3      1050MB  120GB   119GB

cat /etc/fstab says:

/dev/mapper/ubuntu--vg-root /               ext4    errors=remount-ro 0       1
UUID=D561-82E4  /boot       vfat    defaults     0       1
/dev/mapper/ubuntu--vg-swap_1 none            swap    sw              0       0

cat /etc/crypttab reveals:

ubuntu-vg UUID=0c8ec1d0-58c2-44fc-b2bb-a83880a079de none luks,discard

tree /boot/ displays:

/boot/
├── abi-4.10.0-24.efi
├── config-4.10.0-24.efi
├── EFI
│   ├── refind
│   │   ├── icons
│   │   ├── keys
│   │   ├── refind.conf
│   │   └── refind_x64.efi
│   └── tools
├── initrd.img-4.10.0-22.efi
├── initrd.img-4.10.0-22-generic
├── initrd.img-4.10.0-24.efi
├── initrd.img-4.10.0-24-generic
├── System.map-4.10.0-24.efi
├── vmlinuz-4.10.0-24.efi
└── vmlinuz-4.10.0-24.efi.signed.efi

cat /etc/crypttab prints:

ubuntu-vg UUID=0c8ec1d0-58c2-44fc-b2bb-a83880a079de none luks,discard

efibootmgr shows:

BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0000,0002,0001,0001
Boot0000* ubuntu
Boot0001* rEFInd Boot Manager
Boot0002* UEFI : USB : SanDisk 1.26 : PART 0 : OS Bootloader

Here's the entry in the refind.conf file:

menuentry Ubuntu {
    icon /EFI/refind/icons/os_kubuntu.png
    loader /vmlinuz-4.10.0-24.efi
    initrd /initrd.img-4.10.0-24.efi
    options "ro cryptdevice=UUID=0c8ec1d0-58c2-44fc-b2bb-a83880a079de:lvm root=/dev/mapper/ubuntu--vg-root"
}

Entire blkid command:

/dev/sda1: UUID="D561-82E4" TYPE="vfat" PARTUUID="a1234e37-91b0-4179-87d3-28eabf4ba49d"
/dev/sda3: UUID="0c8ec1d0-58c2-44fc-b2bb-a83880a079de" TYPE="crypto_LUKS" PARTUUID="5c4230fe-da7e-4826-980e-03dccc7c9c5e"
/dev/mapper/ubuntu--vg-swap_1: UUID="61516fcc-ecff-444a-a5d2-6382ae2a2a05" TYPE="swap"
/dev/mapper/ubuntu--vg-root: UUID="98fa485b-0e94-48b0-ae8a-7bc03de28eac" TYPE="ext4"

Do I need to provide a decryption key file? Am I supposed to be using the Partition UUID instead of the UUID somewhere?

Preston Garno
  • 103
  • Please describe what's not working -- where do things start to fail, do you see any error messages, what other symptoms of problems are there, etc.? Note that using FAT on /boot is inadvisable in Ubuntu because package updates can fail. It's better to use separate /boot and /boot/efi (ESP) partitions, with /boot using a Linux-native filesystem. – Rod Smith Jun 22 '17 at 12:58
  • I don't see any error messages. It's just nothing shows at boot. I made sure to install from a live disk I booted in EFI. So I'm thinking I just have a misconfiguration in something above. I don't have any indication that it won't work when running chrooted into the system – Preston Garno Jun 22 '17 at 14:08
  • Your description is still unclear -- I don't know if you're seeing the POST messages, the rEFInd menu, etc. Knowing where things start to go off the rails is critical -- if rEFInd doesn't appear at all, diagnosing kernel problems would be pointless; but if rEFInd appears and lets you choose a kernel but the system hangs at that point, the problem likely doesn't reside in your NVRAM boot configuration, for instance. – Rod Smith Jun 22 '17 at 16:09
  • @RodSmith Oh yeah, sorry, I'm awful at asking questions on StackExchange because of that. I'm not getting any indication of refind being detected at all, if I could get refind to show up would be able to diagnose it just by trial and error. I meant by my previous comment that it was showing up in efibootmgr, etc. I'm figuring it's just something that I just failed to notice in man pages for configuring this stuff – Preston Garno Jun 22 '17 at 17:30
  • I missed your efibootmgr output, which shows the problem: rEFInd is not first in the boot order. If you can boot to Ubuntu, you can run refind-mkdefault, which comes with rEFInd, to fix it. That usually works, but in some cases it doesn't, in which case other fixes will be required. – Rod Smith Jun 22 '17 at 17:34
  • @RodSmith done that already. For some reason it changes by the time I boot again. Is there some sort of conflict going on in some other bizarre service or tool that is trying to do somewhat the same thing? – Preston Garno Jun 22 '17 at 17:36
  • See this question and its answers, as well as this one. Chances are you're running into one of those two problems. – Rod Smith Jun 22 '17 at 18:01
  • @RodSmith I don't run windows. Its just 1 OS at the moment. to be honest I'm going to take it up with Intel because it's a good Z77 chipset motherboard and I think that's the problem. It is extremely maddening that the problem is something that low-level because I just lost 3 days fixing it... – Preston Garno Jun 23 '17 at 01:00
  • @RodSmith thanks for the help though. I tried everything though. I'm going to settle for installing arch, because I think that seems like an easier process – Preston Garno Jun 23 '17 at 01:02
  • Since rEFInd is installed, try sudo mvrefind /boot/efi/EFI/refind /boot/efi/EFI/BOOT. There's a good chance that this will get it working. The first link I presented a couple of comments ago is likely the cause, but using mvrefind to move rEFInd to the fallback boot loader (EFI/BOOT/bootx64.efi on the ESP). – Rod Smith Jun 23 '17 at 13:07
  • @RodSmith I've tried every combination in the book, and I'm about to finish up a clean Arch install at the moment. I solved the problem coincidentally, and it would've saved me a lot of frustration with Arch too if I hadn't read the wiki thoroughly. Intel's Z77 chipset doesn't support UEFI unless you're booting Windows Check out the bottom of this page: https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#UEFI_boot_loader_does_not_show_up_in_firmware_menu – Preston Garno Jun 23 '17 at 13:13
  • FWIW, that's not a chipset flaw; it's an EFI bug. It was a common one a few years ago, but is uncommon with modern EFIs. – Rod Smith Jun 23 '17 at 13:28
  • @RodSmith I was just reading about that. I think at a certain point I should assume that my problem is a bug from now on instead of wasting my time because that was extremely frustrating. Thanks for the help! – Preston Garno Jun 23 '17 at 13:35

0 Answers0