[Solved] installation and setup question - gummiboot and EFI

Question

Hi,
This is the first time i'm installing arch. i hit the below issues. hope someone can help me out. my understanding of uefi is just about an hour worth of reading or less..
(the wiki didn't mention the kernel requirement when I started installing it... now it does and i updated the beginner's guide wiki post.)
Problem
Gummiboot#Installing says that "If you are still running kernel 3.7 or have not booted in EFI mode, creating the boot entry will fail. You should however still be able to boot gummiboot as it copies the binary to the default EFI binary location on your ESP (/boot/EFI/BOOT/BOOTX64.EFI on x64 systems). "
the gummiboot part fails. gummiboot gives this error at install  saying file system is not FAT EFI, so first I got gummiboot and gummiboot-efi both using pacman. then, I provided the --path to install and now it coughs up because the latest iso isn't 3.8 yet.
Failed to access EFI variables. Is the "efivarfs" filesystem mounted?
I can see efivars but this is asking for efivarfs.
so instead I did,
# cp /usr/lib/gummiboot/gummibootx64.efi /boot/efi/EFI/gummiboot/gummiboot.efi
# efibootmgr -c -d /dev/sda -p 1 -w -L "Gummiboot" -l '\EFI\gummiboot\gummiboot.efi'
how do I set this up? I'm afraid if I overwrite /boot/efi/EFI/BOOT/BOOTX64.EFI  windows might not boot.
after the installation (of course without gummiboot stuff) now when I reboot, I don't see any gummiboot menu at all because i didn't copy it to EFI/BOOT. it goes straight to windows 8 boot. during boot if I press F12 and see the menu option on thinkpad, I see gummiboot as the first entry(must be because of efibootmgr) followed by windows boot manager. When I select the gummiboot and enter, it just circles back to the same menu. I have setup the loader.conf and arch.conf as described in the wiki.
how do I set gummiboot to work? i dont mind pressing F12 and then going to gumiboot-> arch until 3.8 is out.
If this isn't possible, can I install rEFInd without messing gummiboot? looking at the dir structure of FAT EFI I think it should be possible but not 100% sure until i try it out. Also, to get rid of gummiboot, i should delete the directories, uninstall using pacman and get rid of the efibootmgr change I made, right?
Last edited by lobo2 (2013-03-15 04:07:47)

Answer 1

srs5694 wrote:
sidneyk wrote:Maybe not, I use rEFInd and mount ESP on /boot/efi and copy over updated kernels and initramfs. Maybe if you are mounting ESP at /boot the kernel and initramfs get written to both places at once, I don't know. I also don't know if /boot is where gummiboot expects them to be.
I realize this has been at least partially addressed by others, but I want to make two points very explicit:
In Linux, partitions (or more precisely, the filesystems that most of them contain) are accessed by mounting them at a mount point (a directory). Thus, when you mount the ESP at /boot, the contents of /boot are the ESP. Put another way, mounting the ESP at /boot means that to read or write the ESP, you read or write files and directories under /boot. You can test this yourself by mounting and unmounting a partition that's not basic to the minute-to-minute functioning of the computer. The ESP will actually work fine for this. Unmount it from /boot or /boot/efi and then issue a mount command to mount it elsewhere (say, "mount /dev/sda1 /mnt"). Then check the files under your temporary mount point, and even copy a file there. You can then unmount it and mount it back where you normally do and look for the file you copied -- it should be there. Play with this until you fully grok it.
Gummiboot runs before Linux, and it has no conception of Linux mount points. Thus, whether you mount the ESP at /boot, at /boot/efi, at /home/fred/abadmountpointforanesp is irrelevant, so long as the files on the ESP are laid out in the way that gummiboot expects. The trickiest aspect of this for those unfamiliar with the Linux mount system is that you do not include the Linux mount point in filename references for pre-boot programs like gummiboot. That is, if you mount the ESP at /boot and place the kernel at /boot/vmlinuz, then in gummiboot, the kernel would be \vmlinuz.
Yeah, I figured this out based on the OP's response to that and thinking it through, I just never really thought about it much before now. But I will argue that the mount point /boot and the EFI partition are indeed 2 different locations. I know that once the ESP is mounted at /boot that this distinction disappears until it is umounted and something written to /boot, but while mounted as such, /boot and ESP are virtually the same, at least to the Linux system. I realize the EFI programs are ran before any OS and therefore don't really care about any OS specifics.
I wonder if the OP has confused the info between gummiboot and rEFInd (possibly from the Beginners Guide) because to me, after reading the gummiboot wiki, it just seems that it would be much simpler to just give gummiboot what it wants, i.e. ESP mounted at /boot, whether it's a separate partion or not. I'll have to take a look again at the Beginners Guide to see again the order of things there, but if it isn't, maybe it should be having the user ensure that pacman has completely updated the new system and then go on to the boot loader specifics. I was just thinking though, that the way the install medium is now, that it was automatically pulling the latest stuff down as part of the install process. I know it's not pulling testing or multilib without user intervention, but the core, stable stuff it is. That seems to be part of the confusion here maybe, 2 different versions of gummiboot with gummiboot changing some things between the 2 and maybe the kernels, too.
[EDIT] I took another look at the Beginner's Guide and it says that most users will probably want to use the [core], [extra], and [community] repos, which are enabled by default. It goes on to recommend that [multilib] be enabled for users wanting to run 32 bit programs and then reminds you to run #pacman -Sy to update the package lists, but not #pacman -Syu which would apply any changes from the repos since starting the install. Shouldn't matter much, even if the [multilib] repo was enabled because at that point no 32 bit libs have been installed, but it would matter if a user decided to enable the testing repos.
I wouldn't ordinarily recommend it, but in this case, if the OP is comfortable with the risk, then it might be useful to, at least temporarily, enable the [testing] repo and do #pacman -Syu to pull in the 3.8 kernel. Note that this is likely to also pull in other packages from [testing], but if you haven't installed X yet or any desktop environment, then what is pulled in shouldn't be too overwhelming. He can then immediately go back and disable [testing] if desired. I'm currently using testing without any issues, but there are risks to doing so.
Last edited by sidneyk (2013-03-14 18:13:43)