GRUBless UEFI stub Kernel >=3.3 installation and maintenance

KairiTech · 2012-05-25 23:42:28

For a completely GRUBless UEFI boot (which I think I finally understand) of the stub kernel >=3.3 your install script should copy (I choose to move) the kernel and initramfs images to the appropriate location. Note that the kernel has “.efi” appended to the end while there is no name change for the initramfs images.

mv  /boot/vmlinuz-linux /boot/efi/arch/ vmlinuz-linux.efi

mv /boot/initramfs-linux.img /boot/efi/arch/

mv /boot/initramfs-linux-fallback.img /boot/efi/arch/

You should also pipe the boot command line parameters to efibootmgr to store them and the new location in the motherboard’s NVRAM. Use your own settings for “root=” , “--disk”, “--part” and “--label” but the /efi/arch/ directory MUST be located in /boot. Notice the backslash “\” below. /boot is a FAT formatted partition after all. The forwardslash “/” will not work.

echo "initrd=\efi\arch\initramfs-linux.img root=/dev/mapper/crypt cryptdevice=/dev/sda3:crypt ro quiet" | efibootmgr --create --gpt --disk /dev/sda --part 1  --label "Arch Linux" --loader '\efi\arch\vmlinuz-linux.efi' --append-binary-args -

Alternatively, you could save the boot parameters to a linux.conf file instead of putting them into the NVRAM. This is not supported by the 3.3 kernel but may be supported by the time 3.4 or perhaps 3.5 kernel is out.

echo "initrd=\efi\arch\initramfs-linux.img root=/dev/mapper/crypt cryptdevice=/dev/sda3:crypt ro quiet" > /boot/efi/arch/linux.conf

efibootmgr --create --gpt --disk /dev/sda --part 1  --label "Arch Linux" --loader '\efi\arch\vmlinuz-linux.efi' --append-binary-args -

You can issue the efibootmgr command without any arguments for a list of boot options stored in your motherboard's NVRAM. You can set the default as the 5th. one in the list as show below:

efibootmgr -o 5

And if you mess up remove it or any other with:

efibootmgr -b 5 -B

So what about kernel updated? Currently I use incron to monitor the initramfs-linux-fallback.img file because kernel updates create the new fallback image last and only after the new image is created can we be sure that the kernel update is complete. Install and configure incron to run a batch file every time the kernel is updated to move the kernel and initramfs images in exactly the same way that you did during the initial install.

EDITOR=nano incrontab –e

Add the following line to the incron config which says in effect “when /boot/vmlinux-linux-fallback.img is closed, after it is written to, run script_that_moves_stub_kernel.sh”

/boot/vmlinux-linux-fallback.img IN_CLOSE_WRITE /path_to/script_that_moves_stub_kernel.sh

Don’t forget to restart indron for the changes to take effect and to insure that incron starts at boot add the incron daemon to the DAEMONS=( … incrond ...) line in /etc/rd.conf.

/etc/rc.d/incrond restart

I have added a few things besides the move to the script. I make a backup of the old kernel and images with the running kernel version appended and I log details of the update. /var/log/messages.log will keep a record of exactly when the kernel was updated. I choose not to move or copy the fallback.

mv /boot/efi/arch/vmlinuz-linux.efi /opt/myArch/vmlinuz-linux.efi.$(uname -r)
mv /boot/efi/arch/initramfs-linux.img /opt/myArch/initramfs-linux.img.$(uname -r)
mv /boot/vmlinuz-linux /boot/efi/arch/vmlinuz-linux.efi
mv /boot/initramfs-linux.img /boot/efi/arch/

logger "Kernel $(uname -r) was updated to $(pacman --query linux | cut -c7-) on $(date +%F) at $(date +%X)"

From now on matter how or when the krenel is updated it will be moved (or copied if you prefer) to the location that your UEFI motherboard can find it.

On a side note…I only recently discovered incron and its ability to trigger actions based on filesystem events. This opens up a myriad of possibilities for automatic alerts and system maintenance. I am sure I will find many more useful things I can do with incron now that I know it exists.

No distro currently supports maintenance of the UEFI stub kernel but I'm sure it will turn up in Arch sooner rather than later.

Last edited by KairiTech (2012-05-25 23:45:41)

fbcon · 2012-07-31 08:53:47

KairiTech wrote:

echo "initrd=\efi\arch\initramfs-linux.img root=/dev/mapper/crypt cryptdevice=/dev/sda3:crypt ro quiet" | efibootmgr --create --gpt --disk /dev/sda --part 1  --label "Arch Linux" --loader '\efi\arch\vmlinuz-linux.efi' --append-binary-args -

You may want to echo $cmdline | iconv -t ucs2 | efibootmgr $args -@-, because that's the encoding the kernel uses to parse the cmdline.

No distro currently supports maintenance of the UEFI stub kernel but I'm sure it will turn up in Arch sooner rather than later.

What you're trying to do is very similar to grub: updating initramfs, probing os' and kernels, installing them to somewhere and setting some flags, all managed by a few centralized config files. Actually the UEFI boot manager in the firmware does the same thing as grub, thought it's often incompetent or inconsistent. If you dislike an extra layer of booting consistency and can get used to your firmware boot manager, booting the kernel directly from firmware is actually quite manageable IMO. Let's hope there is somebody that can reuse grub's infrastructure for EFI stub booting.

TheSaint · 2014-09-29 11:57:24

Time gone by, I'd like to know if the actual kernel will read from a configuration file (e.g. linux.conf)

jasonwryan · 2014-09-29 16:14:07

Please don't necrobump: https://wiki.archlinux.org/index.php/Fo … Bumping.27

Closing

Arch Linux

#1 2012-05-25 23:42:28

GRUBless UEFI stub Kernel >=3.3 installation and maintenance

#2 2012-07-31 08:53:47

Re: GRUBless UEFI stub Kernel >=3.3 installation and maintenance

#3 2014-09-29 11:57:24

Re: GRUBless UEFI stub Kernel >=3.3 installation and maintenance

#4 2014-09-29 16:14:07

Re: GRUBless UEFI stub Kernel >=3.3 installation and maintenance

Board footer