[SOLVED] Trouble with UEFI in laptop Arch install

nilesOien · 2017-09-04 00:42:07

Hi,

I'm having my first experience with UEFI and I'm finding it utterly baffling.

I just got a laptop that I want to install Arch on. I'm doing this by booting off a new Arch optical drive. The laptop is an ASUS with Intel pentium processors. It keeps booting to the UEFI firmware menu. The directory /sys/firmware/efi/efivars exists, although I can't really follow the contents of it.

Basically what I did was to set up a 512MB EFI partition with gdisk (as well as a swap partition and the main partition). The output of "gdisk -l /dev/sda" is :

GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Model: TOSHIBA MQ01ABF0
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 54BBA24A-5835-4B05-BC79-B034F5114A71
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System
   2         1050624        22022143   10.0 GiB    8200  Linux swap
   3        22022144       976773134   455.3 GiB   8300  Linux filesystem

OK, so that first partition should be an EFI partition. I formatted it FAT32 with "mkfs.fat -F32 /dev/sda1". I then got it mounted as /boot. genfstab seemed to pick up on things correctly, in /etc/fstab I have :

# /dev/sda3
UUID=68aa761c-ebda-4604-ba42-3a46c3c04add	/         	ext4      	rw,relatime,data=ordered	0 1
# /dev/sda1
UUID=65DF-237B      	/boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro	0 2
# /dev/sda2
UUID=5f5cc955-e9ab-4a82-87dc-ad6b1ed62dec	none      	swap      	defaults  	0 0

If I mount /dev/sda1 and look at what's in /boot I see :

initramfs-linux-fallback.img  initramfs-linux.img  intel-ucode.img  vmlinuz-linux

Beyond that, I'm utterly baffled. I've tried installing grub and making the config file /boot/grub/grub.cfg automatically with grub-mkconfig as per :

https://wiki.archlinux.org/index.php/GR … ation_file

But no luck, in fact it seemed to get in the way so I deleted /boot/grub/. I'm not sure if EFI is an alternative to grub? Am I supposed to be messing around in the UEFI firmware adding a "boot option" (although I don't really know what that is)? Or do I have more setup I should be doing while booting off the Arch DVD?

I'm finding this UEFI stuff very hard to follow. For instance, looking at :

https://wiki.archlinux.org/index.php/Mi … de_updates

Just under the "EFI boot stub / EFI handover" section it says "Append two initrd= options". I can't follow - append to what, exactly?

The basic problem is probably that I only buy new hardware very rarely. I tend to use things until the hardware fails. The last time I installed Arch I went into the BIOS, changed the boot order so that it would boot off optical drive, then booted off that and pretty much followed the Arch documentation from there. Not trivial, but not overly involved, either. Now BIOS seems like it's a thing of the past? With UEFI I'm utterly stuck, I can't seem to find an entry point in the the documentation that tells me what (U)EFI is. Is it a bootloader, in which case I shouldn't have tried grub? Or do I need to integrate UEFI with grub in some way?

When I'm unsure on that basic "what is UEFI" level, finding the right way forward becomes pretty hard. Is there something I can read about UEFI that starts from a very basic premise? Because all my systems so far have been BIOS, I have no idea about UEFI. And can anyone see from what I've posted here something that I'm doing wrong?

Basically I need to learn this UEFI stuff, because all the systems are coming out with it now, and I've no idea.

Thanks,

Niles Oien, Boulder Colorado USA.

Last edited by nilesOien (2017-09-07 17:21:36)

jasonwryan · 2017-09-04 00:51:32

UEFI is the BIOS replacement. This article covers it nicely: https://www.happyassassin.net/2014/01/2 … work-then/

nilesOien · 2017-09-04 01:58:29

Thanks, I appreciate it! I've only had a chance to skim read it so far, but already it looks like I should not be messing around with grub, since it seems like UEFI is essentially the bootloader menu. The UEFI that the system currently gets to kind-of "sees" the FAT 32 partition,in that I can get it to sort of browse around looking at files on that partition from the UEFI firmware menu... but I have to do more reading to figure out what, exactly, it should be looking for.

BTW I just visited your web page - I grew up in Wellington and went to Canterbury university in Christchurch. Currently one of my dreams is to launch a weather balloon with a raspberry pi tracker on it - google "Pi in the sky" if you're interested.

jasonwryan · 2017-09-04 02:10:49

I would avoid Grub if at all possible. With UEFI you can boot directly from efistub, via systemd-boot as a boot manager. AFAICT, Grub is only useful if you want an encrypted /boot.

Pi in the Sky looks very cool!

circleface · 2017-09-04 02:17:55

I agree with Jason's opinion. Grub is overkill for what you are trying to do. Check https://wiki.archlinux.org/index.php/Systemd-boot for more info on systemd-boot. I've been using it for over two years and have had no trouble at all. It is very easy to install and config, and unlike grub, doesn't require you to read a 500 page manual to get it working.

nilesOien · 2017-09-04 03:21:28

Thanks. I've actually used both boot managers. My basic misunderstanding is that I kind of thought UEFI *was* a boot manager. Between that and the fact that I only do this once every few years, there's a lot of room for confusion.

I'm going to have to leave this for a day or so - it's getting late here - but I'll read that page Jason suggested and see what I can learn sometime in the coming week.

Blasphemist · 2017-09-04 14:32:55

UEFI has some real good to it once you get the light turned on. UEFI is the replacement for BIOS, and has added features. One of those added features is a boot manager, not boot loader, and it sounds like your flavor includes almost a file browser/picker. It's also used with GPT as you have seen and using both of them lets you do some interesting things.

In order to learn more and for helping others I have installed all of the normal boot loaders and boot managers for UEFI. I can just switch from one to the other using the efibootmgr utility.

The UEFI boot process simply works like this. UEFI initializes the hardware and uses variables stored in the UEFI NVRAM to determine what the boot options you have are and what the boot order is from those options. It then hands off the boot process by launching a UEFI executable file (.efi) which can be another boot manager, a boot loader or as mentioned above an EFISTUB kernel such as Arch's kernel. My normal default is just to have UEFI launch the kernel directly. The simplest, the fastest.

The efibootmgr utility is what we use to look at the UEFI boot related variables, create new boot entries, edit variables and other things such as setting one of your boot entries as first in line for the next boot only. It's man page is pretty complete and shows examples of it's use.

The ESP, Efi System Partition used with GPT, beats the hell out of every boot loader or boot manager overwriting each other in the disk MBR. Mount the ESP at /boot to start wtih at least. Since the kernel is always installed to /boot that means the kernel lives on the ESP. UEFI can launch directly files from the ESP only so this is perfect.

No matter whether a boot loader or boot manager is installed manually or via script there are certain common steps. The package or packages are installed via pacman just as all packages are. Then components are put on the ESP, that isn't of course necessary if you use the kernels default EFISTUB capability. You'll see there is no real common standard for directory structure on the ESP so there are some weird directory nests. The boot loader or manager may include drivers that it uses to access other partitions if kernels aren't on the ESP. Grub and rEFInd both include such drivers. Systemd's bootctl does not include such drivers so it can only launch kernels from the ESP. The new boot entry is created in UEFI NVRAM and there may be configuration of the boot loader or manager too.

c00ter · 2017-09-05 01:26:35

Blasphemist, thank you for the informative, very readable post on UEFI. I have read a number of pieces on it and the benefits were always vaguely stated, "Because it is newer...because it is better..." and not much else. I have run either GPT/EFI or MSDOS/MBR on this 2014 i7 machine and have had no problems with either. But your post gives me valid reason for making the better choice.

Thanks

nilesOien · 2017-09-05 01:36:01

I just had a look at the man page for efibootmgr and I'm confused. It says that "efibootmgr -c" will be called (or do I do that by hand?), and that that is going to assume that /boot/efi is going to be my UEFI partition (presumably made with code ef00). But I've also seen stuff that suggests that /boot should be that partition? The Arch install guide seems to imply that?

Also, should I make /boot/efi manually or does efibootmgr do that?

I'm sorry, I'm sure you may be rolling your eyes at this but really I do this very rarely. I'm a bit puzzled that it isn't written up in one place? As it is the documentation seems a bit scattered.

I'll have access to the machine tomorrow and that will give me a chance to try things, but I think it would help if I knew if my EFI partition was supposed to pop up as /boot or as /boot/efi - can someone clarify?

Thanks!

Last edited by nilesOien (2017-09-05 01:38:06)

circleface · 2017-09-05 02:21:45

The placement of the EFI directory depends on which boot loader/manager you are going to use. For grub, it can be mounted pretty much anywhere. If you choose systemd-boot you will mount your EFI partition at /boot. The /boot/efi directory will be created when you install the bootmanager (at least, that was the case when I set my computer up). The thing is, you don't have to worry about /boot/efi. The system will take care of that. All you need to do is mount to /boot and then configure at least one kernel entry in the config to boot your arch system. The kernel and anything else needed will be automatically stored in /boot if you mount the EFI partition there. If you don't mount it there, be prepared to do a lot of configuring grub to get it working.

Edit for clarity:
On my system I use systemd-boot. /boot is where the kernel and initramfs are located. /boot/loader/loader.conf is the main config file that defines which kernel to load by default. /boot/loader/entries/ is where the config files go to load the actual kernel.

Last edited by circleface (2017-09-05 02:26:15)

Blasphemist · 2017-09-05 03:29:05

nilesOien wrote:

I just had a look at the man page for efibootmgr and I'm confused. It says that "efibootmgr -c" will be called (or do I do that by hand?), and that that is going to assume that /boot/efi is going to be my UEFI partition (presumably made with code ef00). But I've also seen stuff that suggests that /boot should be that partition? The Arch install guide seems to imply that?
Also, should I make /boot/efi manually or does efibootmgr do that?
I'm sorry, I'm sure you may be rolling your eyes at this but really I do this very rarely. I'm a bit puzzled that it isn't written up in one place? As it is the documentation seems a bit scattered.
I'll have access to the machine tomorrow and that will give me a chance to try things, but I think it would help if I knew if my EFI partition was supposed to pop up as /boot or as /boot/efi - can someone clarify?
Thanks!

The -c option on an efibootmgr command tells efibootmgr that you are creating a new boot entry (c for create). Some boot loader or boot manager install scripts will do that for you, call the command. When you do the install of the boot loader or manager manually you issue the command. I always think do things manually is the right choice for the same reason that the Arch install process as a whole is better for you, you learn and understand more.

During partition creation for the EFI System Partition, ESP, the partition needs to have the boot and ESP flags set. You can create the partition in various ways and some of them require you to use the ef00 code to get those flags set. That's really what using that code does, sets those flags on the partition. At the stage of installation where you prepare to mount your new root and ESP partitions you haven't installed anything so no directories exist. On the installation medium there is a /mnt directory that we use to mount these new partitions. First we mount the new root partition on /mount. Then we create a boot directory on /mnt. Remember that nothing is on that new root patition other than /boot directory at that stage. We normally then mount the ESP to that /mnt/boot directory. We have not yet used arch-chroot so the path is /mnt/boot still, not just /boot. Then we do use arch-chroot to make these new partitions our new file system.

The simplest, surest mount point to choose for the ESP is /boot. The main reason has to do with ensuring that the EFI executable for your boot loader, boot manager and/or kernel is on the ESP. UEFI can only access UEFI executable files on the ESP. UEFI has no access to other partitions. Further, some of the boot loaders and boot managers don't have access to any file not on the ESP. Some such as rEFInd and Grub include drivers of their own to allow them to access OS kernels that aren't on the ESP. Some, such as systemd's bootctl don't have any such drivers and can only access objects on the ESP.

This isn't often clear in my opinion so I'll make an attempt at clarity here. The Arch kernel is installed and updated at /boot whether you have BIOS or UEFI, MBR or GPT, always. When you mount the ESP at /boot the contents of /boot are actually on the ESP. Be sure to understand that. All contents of /boot are on the ESP if the mount point of the ESP is /boot. If the mount point of the ESP is at /boot/efi, the kernel is still at /boot, always. In that configuration the kernel is on the root partition since the ESP is mounted on a sub-directory of /boot. Since the UEFI can only launch objects from the ESP, if the kernel is on another partition other than the ESP that boot loader or boot manager has to provide it's own way to access the kernel.

The simplest, fastest, fewest moving parts boot process is have UEFI launch the kernel directly, something that is a new feature possible with UEFI that a BIOS system couldn't do. To do that you don't install grub or any other boot loader or boot manager. You install efibootmgr and use it yourself to create the boot entry. When that entry is first in the boot order, UEFI launches the kernel from the ESP and it's off to the races. Here is the command I use to do this:

# efibootmgr -c -d /dev/sda -p 1 -L "ArchLinux" -l \vmlinuz-linux -u "root=/dev/sda2 rw initrd=/initramfs-linux.img"

This breaks down as follows. The -c option tells efibootmgr to create a boot entry. The -d option defines the device that holds the ESP, sda in my case. The -p option defines the partition number of the ESP, partition one on sda in my case. The -L option defines the label for my boot entry for this. The -l option defines the loader file path and name on the ESP. Note that since that file is at the root of that FAT32 partition it is shown in this command preceded by a backslash. The -u option is used to pass kernel parameters that include the root device id.

The next simplest thing is using a boot loader or boot manager to launch a kernel that is on the ESP. When you do that though you have to ensure that you configure the boot loader or boot manager to know what partition the kernel is on.

I had an interest in getting to the bottom of all this and over time it came to be that I now have a bunch of boot loaders and boot managers installed on my UEFI system. First in my boot order is having UEFI launch the kernel directly. When I want to test something to do with one of the other loaders or managers I can use efibootmgr to set the boot next variable to that loader or manager boot entry or I can use efibootmgr to change my boot order. That's all it takes. I can also use the boot manager built in to my UEFI to choose from one of the available boot entries without changing boot order, boot next or anything. All of the boot entries and boot loaders or boot managers can exist on the same system without interring with each other. They don't interfere with each other in UEFI or on the ESP. They all exist independently.

There are conditions when it makes sense to use /boot/efi as the mount point for the ESP. The main and best example is rare and somewhat complicated but I'll briefly describe it. If you have 2 instances of one OS you would have 2 instances of the kernel, both with the same name (unless one instance uses a different kernel, say the ck kernel). If for both instances you used /boot as the mount point the second kernel installed would conflict with the first kernel since they would both be files of the same name in the directory of the ESP. Really dual or multi boot with more than one instance of the same kernel is when you run into this. Even then you just need to use /boot/efi as the mount point of the ESP for the second install, you still use /boot for the ESP mount point on the first install.

Sorry for all the long wind but I wanted to be as clear as possible.

nilesOien · 2017-09-05 14:43:02

Thanks Blasphemist, I appreciate the detail! That said, it may be a day or so before I really get to look at this again - things keep coming up.

nilesOien · 2017-09-06 22:58:52

Thanks, everyone, for all the help. I have things sort-of working but I have some questions.

So, I got the system booting from hard drive with pretty much what Blasphemist suggested :

efibootmgr -c -d /dev/sda -p 1 -L "ArchLinux" -l \vmlinuz-linux -u "root=/dev/sda3 rw initrd=/intel-ucode.img initrd=/initramfs-linux.img"

I have an intel system, so I prepended the intel-ucode to the kernel in the above.

I also installed linux-lts (long term support). I repeated what I did above, but with "linux-lts" instead of "linux" throughout. I can use efibootmgr to chose between linux and linux-lts by changing the bootorder, assuming that I've booted OK and can run efibootmgr.

Some things are kind of puzzling, though.

First, If I do go with a bootloader, presumably the EFI has to run the bootloader? So does the bootloader (grub or whatever) have to be on the EFI partition, because that's all the EFI software can "see"? And then I'd have to tell the bootloader where everything is, I guess - is there an example of that?

Second, I'd also like to boot from a DVD if there is one in the DVD drive. Oddly, in order to do that I have to boot off the hard drive and then change the boot order - every time. The boot order that puts the DVD first doesn't persist after a boot with the DVD drive empty, it seems. It goes back to putting the hard drive first after booting with nothing in the DVD drive. That seems odd. It's a cheap ASUS laptop, maybe the EFI firmware just isn't that great? That's kind-of why I asked my first question - I'm starting to suspect that getting the EFI to fire up a bootloader may be a better way to go. But I could be missing something.

It isn't clear what it would do if the hard drive failed. I *think* it would go back to booting the DVD, because it seems like the DVD is still on the list, it just gets put after the hard drive in order if a hard drive boot has taken place.

Thanks for all the help on this. I find it pretty baffling, although it's starting to make sense. It could be that what I have now is the best configuration - I'm not sure. I think this is a valuable discussion, I'd almost suggest having a link to the gist of this topic in the Arch documentation and linking to it from the Arch install guide, but that could just be me. As I said I came to UEFI late.

circleface · 2017-09-06 23:43:17

https://wiki.archlinux.org/index.php/Sy … t#EFI_boot describes how to install systemd-boot, which is what I personally reccomend. The way you have done it now is to create actual entries into the firmware of your computer. Something like systemd-boot will automatically create its own boot entry in the firmware when you install it with 'bootctl --path=esp install' Also, read the rest of that article if you plan on using systemd-boot because you also have to configure each kernel you want to boot (very easily done, the config is not hard at all). If you go the systemd-boot route, when you power up your computer you will be greeted with a simple list of configured kernels to load. Just select the one you want and your system will boot.

Last edited by circleface (2017-09-06 23:44:10)

nilesOien · 2017-09-07 17:28:48

I'm marking this as [SOLVED], although more accurately it seems like I have some more reading to do. But now I at least grasp the context. I think the gist is :

* The UEFI specification is great.
* A lot of UEFI problems stem from incomplete implementations of the UEFI specification.
* UEFI can basically be your bootloader through using efibootmgr to set up UEFI firing up the kernel directly, or
* You can use UEFI to fire up a bootloader

I'm going to try to look into that last point, and also see why I can't seem to get my system to boot from DVD every time I put a DVD in the drive.

Thanks, all!

Blasphemist · 2017-09-07 22:30:12

nilesOien wrote:

Thanks, everyone, for all the help. I have things sort-of working but I have some questions.
So, I got the system booting from hard drive with pretty much what Blasphemist suggested :
efibootmgr -c -d /dev/sda -p 1 -L "ArchLinux" -l \vmlinuz-linux -u "root=/dev/sda3 rw initrd=/intel-ucode.img initrd=/initramfs-linux.img"
I have an intel system, so I prepended the intel-ucode to the kernel in the above.
I also installed linux-lts (long term support). I repeated what I did above, but with "linux-lts" instead of "linux" throughout. I can use efibootmgr to chose between linux and linux-lts by changing the bootorder, assuming that I've booted OK and can run efibootmgr.

This is very good work well done. This is the first step in the boot process on UEFI. As soon as the initialization function of UEFI is done, UEFI looks at the boot related variables where it holds this information that you provided. You told it what drive, what partition, what to load and what to pass as parameters to the kernel. Good work on passing the intel-ucode. Creating these two entries is a great way to make use of the built in UEFI boot manager. That boot manager runs from key press during the initialization before the boot process so the only negative is that you need to press the key immediately. Each entry runs a kernel directly so this cannot be beat for simplicity and speed. If you don't press the key for the boot manager, your normal/default kernel will launch. In addition if you do know ahead of time that you want to boot to the non-default kernel you can use efibootmgr to set the boot next variable to that and it will go to that kernel first for just the next boot.

nilesOien wrote:

First, If I do go with a bootloader, presumably the EFI has to run the bootloader? So does the bootloader (grub or whatever) have to be on the EFI partition, because that's all the EFI software can "see"? And then I'd have to tell the bootloader where everything is, I guess - is there an example of that?

You've got it. UEFI launches what it is told to, with stipulations. The file must be one that UEFI can understand and it does have to be on the ESP which must be FAT32. Then you do have to tell the boot loader or boot manager enough that it can do it's job. Different boot loaders and boot managers have different scopes and capabilities.

I look at as there being 3 steps to installing a boot loader or boot manager. First the package gets installed just as any other does. Then files get put into place on the ESP that UEFI launches and that are needed for that boot loader or manager need to "run". Creating the entry in the UEFI variables for that boot loader or manager is also part of that. Lastly, you have to configure the boot loader or manager. Configuration can mean telling it what kernels can be loaded and from where and can include passing kernel parameters and menu labels. This is a lot less straight forward than just creating the boot entry yourself with efibootmgr and using the built in UEFI boot manager.

To me the Arch way is to do everything you can as simple and efficiently as possible. Boot loaders and installed boot managers are rarely that. They also seem to expect a lowest common denominator of us and often provide scripts to do simple things that we would understand if the details weren't hidden by the script. Fortunately the Arch wiki usually does describe the manual method.

To your last question, My UEFI (Insyde of some version) has a boot order setting like the old bios does. I set my optical drive to first in that order and it will then boot to what's in the optical drive if it is present and bootable. You can also boot to that drive from the built in UEFI boot manager and that drive would boot if all ahead of it in the boot order variables were invalid, because of a failed hard disk for example.

Arch Linux

#1 2017-09-04 00:42:07

[SOLVED] Trouble with UEFI in laptop Arch install

#2 2017-09-04 00:51:32

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#3 2017-09-04 01:58:29

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#4 2017-09-04 02:10:49

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#5 2017-09-04 02:17:55

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#6 2017-09-04 03:21:28

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#7 2017-09-04 14:32:55

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#8 2017-09-05 01:26:35

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#9 2017-09-05 01:36:01

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#10 2017-09-05 02:21:45

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#11 2017-09-05 03:29:05

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#12 2017-09-05 14:43:02

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#13 2017-09-06 22:58:52

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#14 2017-09-06 23:43:17

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#15 2017-09-07 17:28:48

Re: [SOLVED] Trouble with UEFI in laptop Arch install

#16 2017-09-07 22:30:12

Re: [SOLVED] Trouble with UEFI in laptop Arch install

Board footer