Alright I figured I may as well update this. I fell a little silly, but I do know at first the DVD was booting in UEFI mode, but apparently at some point that stopped, and that was what was causing all my issues. I am now up and running and all good. Thanks for the help everyone!
I find it a very good idea to keep something as /boot/EFI/boot/bootx64.efi (or \EFI\BOOT\BOOTX64.efi relative to the root of the ESP). That is the "default" efi application. It is what is run if you have your machine set to boot in UEFI mode and you choose the disk to boot from (rather than a firmware entry like those created by efibootmgr). It was put into the spec so that one could boot a removable medium, like a USB flash drive or cdrom, with UEFI. Obviously, a removable whatever is not going to have a firmware entry for it, so there needed to be some kind of standardization on how to make those work. From there, apparently that idea carried over to the internal devices as well, and now a vast majority of UEFI firmwares use this for all disks, not just removable ones.
Nowadays, I keep gummiboot there. But when I first started using UEFI, I kept the UEFI Shell v2 there since it that is probably the most versatile thing that could be used as a fallback. But as long as you have somethign there, in the event that you lose all your firmware entries, this might save your ass. In my Phoenix bios, the exit and save changes, you would use F10, while a total reset of the bios to defaults is F9... yeah, I reset my bios by accident once. Having the UEFI Shell in that spot made my life quite a bit easier.
]]>cfr wrote:If you want to use gummiboot, you *must* mount your ESP at /boot and *cannot* have a separate boot partition.
I don't think this is true. The only reason why you would possibly want to mount your ESP at /boot when using gummiboot is because this is what the gummiboot command expects. But if it is not the case, I believe it will just fail (or succeed by doing nothing, I'm not sure). It will also not be able to set up the boot.automount generated unit discussed in jasonwryan's mlocate thread either. But this should not actually be a hard requirement for just the basic ability to boot the machine.
Oops, sorry, you are right.
I think the Beginners' Guide used to say it was necessary and I assumed it was correct. Now it just erroneously claims that if you follow the guide from the beginning your ESP will be mounted at /boot. (I'm not sure what is meant to justify this claim - does anybody know?)
grub will be fine with the ESP at /boot but you may need to tell it it is there. (I think it'll find it anyway but you can certainly pass it the option if not.)
]]>If you want to use gummiboot, you *must* mount your ESP at /boot and *cannot* have a separate boot partition.
I don't think this is true. The only reason why you would possibly want to mount your ESP at /boot when using gummiboot is because this is what the gummiboot command expects. But if it is not the case, I believe it will just fail (or succeed by doing nothing, I'm not sure). It will also not be able to set up the boot.automount generated unit discussed in jasonwryan's mlocate thread either. But this should not actually be a hard requirement for just the basic ability to boot the machine.
]]>This is covered in the wiki but gummiboot and rEFInd are boot managers. grub (and some others) are boot loaders as well. The former give you a menu etc. but you boot with the kernel's EFI stub loader. When this works, it works great. When it doesn't, it doesn't. Boot loaders don't use the stub loader: they load the kernel themselves as with traditional bios. (Well not quite like that but the same idea.)
Different options have different kinds of flexibility and different options work better or worse on different hardware and with different kernels.
Personally, I would recommend installing a boot manager (gummiboot or rEFInd) and a backup boot loader (grub or something else). That way if you get bitten by the recent EFI stub loader bug, you have a fallback in place and will still be able to boot. I have rEFInd and grub installed, for example. I have an entry in rEFInd's config to launch grub. That means I can boot rEFInd -> grub -> kernel even though I cannot boot rEFInd -> kernel because I am bitten by the bug.
Note that not only may your mileage vary, your mileage WILL vary. If not now, sometime. Lots of UEFI implementations are buggy and the bugs hit in mysterious ways and at mysterious times. Just be prepared.
]]>David
]]>I recommend either creating a separate partition for /boot or mounting your ESP at /boot rather than at /boot/efi. The latter option will make it easier to use certain other boot loaders or boot managers, such as gummiboot, so it might be preferable if you're not 100% certain you want to use GRUB. (Hint: If you're not an EFI expert, a 100% certainty that you want to use GRUB is mistaken; EFI has its own quirks and you may find GRUB to be a less-than-optimal choice, depending on your specific needs.)
]]>My setup is: 3x500GB drives (sda1 is a 1GB partition for /boot/efi, sd[bc]1 raid 1 for swap, sd[abc]2 raid 5 with LVM for /, /home, and /tmp). ASUS m5a97 LE R2.0 motherboard.
I am currently chroot into /mnt, where my / LVM is mounted, I have dm_mod loaded, and I was following the instructions here.
I get an error from grub toward the end saying "Path `/boot/grub' is not readable by GRUB on boot. Installation is impossile. Aborting." (there's a LOT of output before that because of --debug.
I tried looking around, and I saw some people say that they had success with a fresh install when upgrading, but that doesn't really apply to me as this is already a fresh install.
Does anyone have any ideas what could be causing this? Thanks in advance!
David
]]>