[SOLVED] UEFI woes

cfr · 2013-10-27 00:20:42

Sure but the OP needs to figure out what to copy to EFI/boot/ and which file to copy to EFI/boot/bootx64.efi, right? Configuring gummiboot itself is a different issue.

FerretBuster · 2013-10-27 00:37:28

ok I sorted out the reconnection to the internet lol. Anyway I've installed the base system now and am going to attempt to install gummiboot, but I may need help with which files to copy where.

FerretBuster · 2013-10-27 00:56:54

just installed gummiboot and was confronted with this message after installation : partition /boot is not a FAT efi system partition. not sure where to from here.

WonderWoofy · 2013-10-27 01:22:12

Because the gummiboot command wants to install it to /boot as though the ESP were mounted at /boot. If this is not the case, you can use the --path= flag to specify where it is mounted. In your case, it would be gummiboot --path=/boot/efi install .

FerretBuster · 2013-10-27 01:24:55

I mounted my ESP partition on /boot. It is formated f32, it has the ef00 flag to indicate that it is an EFI partition. I have tried installing gumminoot both in and out of chroot and it still doesn't work... Any suggestions?
EDIT:
This is what I did :

# mkdir -p /mnt/boot
# mount /dev/sda1 /mnt/boot

Last edited by FerretBuster (2013-10-27 01:27:49)

WonderWoofy · 2013-10-27 01:27:54

Do it manually. The only things that the gummiboot command does is it copies the proper gummiboot binary to the ESP and then creates an efibootmgr command for it.

FerretBuster · 2013-10-27 01:30:52

How would I do that? Sorry to hassle you I feel like i'm asking so much. But honestly this EFI stuff is doing my head in - it's such a lot of new stuff to learn...

EDIT : I did try that command you suggested by the way - not sure if I made that clear, it just gives me the same result (my ESP partition is /boot by the way). Not sure if that's what you meant.

Last edited by FerretBuster (2013-10-27 01:36:59)

WonderWoofy · 2013-10-27 02:01:10

Is your ESP mounted? If it is there and it is indeed a valid ESP, gummiboot install should work.

But to do it manually you find the *.efi file in the gummiboot package, then copy it over to your ESP. Where you put it is up to you, but the gummiboot command would put it at /boot/EFI/gummiboot/gummibootx64.efi as well as /boot/EFI/boot/bootx64.efi (assuming your ESP is mounted at /boot of course). Then use efibootmgr to make a firmware entry for that particular efi binary.

The wiki explains this process quite well.

FerretBuster · 2013-10-27 02:15:28

I do understand the process that the wiki refers to. However my ESP should be mounted as I have followed the wiki directly. For example here is the output of parted print:

1 1049kb 1075mb fat32 boot

that is the partition I created for ESP.
In cgdisk it says partition type is EFI.
and running lsblk shows that sda1 is mounted to /mnt/boot.
Is that all the steps that I should have done?

But obviously I couldn't run the command

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars

because i'm not booted in uefi mode

So I assume that's why gummiboot install doesn't work?

Finally I know this is a lot to ask, but I really have no idea how I would locate the .efi file in the gummiboot package, I can figure out how to copy it to the EFI partition though I think. And the rest seems easy. So how would I locate it?

Last edited by FerretBuster (2013-10-27 02:16:16)

WonderWoofy · 2013-10-27 04:34:41

Since you are not booted in UEFI mode, you will need to use the "default" spot of the ESP. That is the \EFI\boot\bootx64.efi binary, and can actually be anything you want. So all you need to do in this case is move the gummibootx64.efi file to that spot of the ESP. Then rather than making a firmware entry, just boot from the disk itself as though you were going to boot from the MBR. But have the system set to boot with UEFI and not with bios compatibility mode.

To actually find that file you can do a number of things. You can use the find command, you could use pacman to list the files in the installed package, or you can use pkgfile (update it) then use that to list the contents of both installed and uninstalled files.

Steef435 · 2013-10-27 11:31:59

https://wiki.archlinux.org/index.php/Co … ng_networkNote to self: check on which page you are

Last edited by Steef435 (2013-10-27 11:32:54)

FerretBuster · 2013-10-27 13:26:52

I managed to create a bootable UEFI mode stick using a combination of linux to format my memory stick and this thread: https://bbs.archlinux.org/viewtopic.php?id=169354 and doing this:

 Thus, you can safely bypass the PreLoader program: Mount the USB flash drive's ESP and copy EFI/BOOT/loader.efi to EFI/BOOT/bootx64.efi, overwriting the original file.

Anyway I have managed to go through the entire install process again, I can even mount the efivars. I then run pacman -S gummiboot and it goes to install and suddenly my screen gets spewed with errors and my laptop keys all become unresponsive. To actually shutdown my laptop I have to remove the battery as holding the power button does not work. Does anyone have any idea why that would happen?

WonderWoofy · 2013-10-27 16:29:59

Firmware can be buggy sometimes. This is esepcially the case with UEFI implementations where vendors slap on all their extra crap. On my machine, for example, when I first got it the bios version would truncate any arguments given to the efibootmgr command. So I was unable to set up a direct boot (using the kernel directly). I worked around this by simply using a boot manager, but it was a PITA to try to figure out why it wouldn't work for me, when it worked for others. A bios update fixed it eventually. I have also seen reports of the Thinkpad X220 not being able to use a FAT16 ESP, and also not being able to use MBR partitioning with UEFI (and vice versa). These are all things that they should be able to do according to the UEFI spec.

I think in the sort term, just use the "default" spot mentioned above. It is a reliable way to get your machine to boot to something at least. Then you can go about debugging from an actual running evironment.

FerretBuster · 2013-10-27 17:36:13

I did actually try the method mentioned above but I think I failed miserably. Obviously none of the folders mentioned are created on my ESP partition. So I assume I just create them? Also gummiboot installs several files as far as I can tell when I run the "Pacman -Ql gummiboot" command. So your sure I only have to do is create the directory " \EFI\boot\" on my "/boot" partition (efi partition) and then copy and rename gummibootx64.efi to the created directory but with file name "bootx64.efi"?

Also I don't quite understand what you mean by this part:

Then rather than making a firmware entry, just boot from the disk itself as though you were going to boot from the MBR. But have the system set to boot with UEFI and not with bios compatibility mode.

If you could explain how I would do that, that would be great.

WonderWoofy · 2013-10-27 19:23:37

When you boot with the old legacy MBR/bios method, you would choose the disk itself. With UEFI, ideally you would use a tool (in linux's case this would be efibootmgr) to make a firmware entry. This firmware entry would have the label of your choice, though I think that the gummiboot command make a "Linux Boot Manager" option. So you would select that rather than the disk.

But UEFI also has something that makes it compatible with external disks. Since it is not terribly likely that you will have a firmware entry for an external disk, of you choose to boot from said external media, it will look for an ESP (or the first FAT partition) and then boot whatever is at \EFI\boot\bootx64.efi. This has since been carried over to work with internal disks as well. So it has become what is referred to as the "default" position. Whatever is there will boot when you select the disk itself rather than a firmware entry.

So as long as whatever is in that "default" position, also has the necessary configuration file(s) to properly run, then it will launch that. In the case of gummiboot being in that position, it will then just look for the \loader\{loader.conf,entries\*} stuff.

The gummiboot package doesn't install very many files at all. Listing the package contents will give you not only the files in the package, but also the directories that are used by the package. So for example, /usr and /usr/bin are only listed because it provides the /usr/bin/gummiboot binary. Similarly, /usr, /usr/lib, and /usr/lib/gummiboot are all listed because that is the directory where the efi binary is provided, as well as the example configurations. So in reality it only provide five normal files. There are two examples configs, a man page, the gummiboot command, and the efi binary.

In post #24, I wrote:

See here for gummiboot setup. It is really very easy.
http://freedesktop.org/wiki/Software/gummiboot

FerretBuster · 2013-10-27 22:58:57

Ok I just tried to install GRUB instead, following the arch beginners guide directly, but sadly this ended up giving me the exact same error as I got with gummiboot. So I will have to try this manual method - I was trying to avoid it at all costs, but it looks like it's my only option. Unless of course you know why the install would fail?

After running this command

# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck

it does the exact same thing where it spews out errors with numbers and letters, with the last line saying "/usr/bin/grub-install: line 1074: 6097 killed etc...
and my keyboard locks up and I can't seem to do anything... not even use the power button - even if I press and hold it.

Last edited by FerretBuster (2013-10-27 23:00:50)

WonderWoofy · 2013-10-28 00:33:51

Doing things manually is actually preferrable to me. I like the being able to directly control the contents and configuration of my ESP at all times. IMO, that type of control is why I am an Arch user in the first place, so it fits in well with my need to control things.

That said, I have never heard of running /usr/bin/gummiboot or /usr/bin/grub-install and having it lock everything. When the power button locks, it is likely the kernel has locked. But it is also rather interesting that it doesn't go into a full panic. You might want to try enabling the sysrq key. If it is not quite a full hard lock, then you can use sysrq+w to get debug info dumped to the console about blocked tasks. For more info about the magic sysrq key and what it can do, there is a wiki page for it, or you can install the linux-docs package and check out /usr/src/$(uname -r)/Documentation/sysrq.txt.

FerretBuster · 2013-10-28 01:05:42

After reading this I am having doubts that even doing things manually will work: http://askubuntu.com/questions/70025/ho … 5b-netbook.
This is pretty much the exact problem i'm having. (same laptop), any comments on this?

WonderWoofy · 2013-10-28 01:55:03

That is why I keep trying to tell you to use the default spot, and avoid using efibootmgr altogether... I'm not sure what else to tell you to try to explain this.

cfr · 2013-10-28 02:10:51

It's rather hard to know what is happening there and whether you are seeing the same bug or a different one. Definitely this is far from normal behaviour so in a sense all bets are off.

A few things:
1) if the error is triggered by trying to write the EFI menu entry, manually copy a suitable application to the fallback position should work fine;
2) is an update available for your BIOS?
3) do you need to boot in EFI mode?

WonderWoofy · 2013-10-28 02:15:28

cfr wrote:

1) if the error is triggered by trying to write the EFI menu entry, manually copy a suitable application to the fallback position should work fine

Just for the sake of clarity here, fallback==default.

FerretBuster · 2013-10-28 03:00:32

Ok great. I shall attempt to do everything manually tommorow, having read through your post a few times I think things are finally starting to make sense. Thanks for your help so far, I would have been pretty stumped without it.

FerretBuster · 2013-10-28 16:19:22

well I attempted to do it manually, using a non-uefi boot disk. And after running pacman -S gummiboot - it appears to have copied the files correctly, however even having created a config file when I boot up it says please select proper boot device

EDIT: I might have released what i've done wrong. Will post back

Well I added/edited both the config files (both the arch and loader.conf) and all the files appeared to be copied with the installation of gummiboot (done in chroot). However when I start up I still get please select proper boot device...

Last edited by FerretBuster (2013-10-28 16:30:24)

cfr · 2013-10-29 00:45:51

You need to post details. Which files appear to have been copied correctly? Where are they? What's in your config files? Etc.

WonderWoofy, does gummiboot update write an EFI menu entry? Because if so, this boot manager is a really bad choice for a situation where attempting to write such an entry causes the kernel to throw a wobbly.

FerretBuster · 2013-10-29 01:32:12

Here is the input and output of installing gummiboot without efivars mounted:
(all in chroot)

INPUT
Pacman -S gummiboot
OUTPUT
Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/gummiboot/gummibootx64.efi
Not booted with EFI, skipping EFI variable setup.

INPUT
gummiboot install
OUTPUT
created /boot/EFI/Boot
copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/gummiboot/gummibootx64.efi
copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/Boot/BOOTX64.EFI
Not booted with EFI, skipping EFI variable setup.

The config files are setup as they on the wiki pages.
/boot/loader/loader.conf

default  arch
timeout 4

/boot/loader/entries/arch.conf

title          Arch Linux
linux          /vmlinuz-linux
initrd         /initramfs-linux.img
options        root=/dev/sda3 rw

Last edited by FerretBuster (2013-10-29 01:39:58)

Arch Linux

#26 2013-10-27 00:20:42

Re: [SOLVED] UEFI woes

#27 2013-10-27 00:37:28

Re: [SOLVED] UEFI woes

#28 2013-10-27 00:56:54

Re: [SOLVED] UEFI woes

#29 2013-10-27 01:22:12

Re: [SOLVED] UEFI woes

#30 2013-10-27 01:24:55

Re: [SOLVED] UEFI woes

#31 2013-10-27 01:27:54

Re: [SOLVED] UEFI woes

#32 2013-10-27 01:30:52

Re: [SOLVED] UEFI woes

#33 2013-10-27 02:01:10

Re: [SOLVED] UEFI woes

#34 2013-10-27 02:15:28

Re: [SOLVED] UEFI woes

#35 2013-10-27 04:34:41

Re: [SOLVED] UEFI woes

#36 2013-10-27 11:31:59

Re: [SOLVED] UEFI woes

#37 2013-10-27 13:26:52

Re: [SOLVED] UEFI woes

#38 2013-10-27 16:29:59

Re: [SOLVED] UEFI woes

#39 2013-10-27 17:36:13

Re: [SOLVED] UEFI woes

#40 2013-10-27 19:23:37

Re: [SOLVED] UEFI woes

#41 2013-10-27 22:58:57

Re: [SOLVED] UEFI woes

#42 2013-10-28 00:33:51

Re: [SOLVED] UEFI woes

#43 2013-10-28 01:05:42

Re: [SOLVED] UEFI woes

#44 2013-10-28 01:55:03

Re: [SOLVED] UEFI woes

#45 2013-10-28 02:10:51

Re: [SOLVED] UEFI woes

#46 2013-10-28 02:15:28

Re: [SOLVED] UEFI woes

#47 2013-10-28 03:00:32

Re: [SOLVED] UEFI woes

#48 2013-10-28 16:19:22

Re: [SOLVED] UEFI woes

#49 2013-10-29 00:45:51

Re: [SOLVED] UEFI woes

#50 2013-10-29 01:32:12

Re: [SOLVED] UEFI woes

Board footer