From ArchWiki
Revision as of 07:43, 26 September 2014 by Jstjohn (talk | contribs) (Possible mistake?: add Brainwater's signature which is missing from the previous edit)
Jump to: navigation, search


Is there any reason why grub should be installed to /boot/efi/efi/grub and not to /boot/efi? UEFI wants to have the efi-image unter <EFI SYSTEM PARTITION>/efi/name, so /boot/efi/grub should do the trick. Additionally, mounting (e.g.) /dev/sda1 to /boot/efi and just placing the grub there will possibly conflict with having a LVM+LUKS setup, where /boot will then be encrypted. At the moment I'm running a funtoo installation on a thinkpad x121e with /dev/sda1 (200MB, fat32, sectors 1 - 201) mounted to /boot and /dev/sda2 being a LUKS encrypted system. /boot contains the bzImage and /boot/efi/boot/bootx64.efi is the grub-image.

Note: there should possibly be a section/table here containing information what firmware expects what name. having /boot/efi/grub/grub.efi didn't work for me, and as noted in the thinkwiki for an x220, /boot/efi/boot/bootx64.efi works fine. --Rochus 13:59, 16 August 2011 (EDT)

@Rochus: You have mounted your EFISYS partition at /boot ir you are using same part as both EFISYS and /boot and it is FAT32 formatted. The actual path is <EFI_SYS_PART>/efi/grub/grub.efi wherein <EFI_SYS_PART> is usually /boot/efi or in your case /boot itself.
But I do not understand your argument about mounting EFISYS at /boot/efi conflicting with LVM+LUKS. I don't have such a config in my system to understand what you are coming to say. <EFI_SYS_PART>/efi/boot/bootx64.efi is just a fallback path incase there's no boot entry in UEFI Boot Manager (see efibootmgr section). I already mentioned in the article that "If you have mounted EFISYS part at a different mountpoint, replace /boot/efi with that mountpoint in all the commands". I suppose that explains it. It is better to have /boot separate from EFISYS partition. I have /dev/sda1 as 200 MiB FAT32 EFISYS mounted at /boot/efi and /dev/sda3 as 400 MiB ext4 /boot part. For /boot/efi/grub/grub.efi to work you have to add a boot entry to grub.efi in the UEFI Boot Manager using efibootmgr utility. -- Keshav P R 23:15, 28 August 2011 (IST)

Custom keyboard layout

Hi. Could we add a section explaining how you can set your preferred keyboard layout within GRUB2? As i found here, we need the ckbcomp script, which can be obtained from Debian console-setup package.

Here's how I made things work:

sudo mkdir /boot/grub/layouts
ckbcomp it |sudo grub-mklayout -o /boot/grub/layouts/it.gkb

Then, I manually edited /boot/grub/grub.cfg, adding the following lines:


terminal_input at_keyboard
keymap it

This worked for me, but as of now, i think it's a very dirty method. Is there some support for keyboard layouts within /etc/default/grub?

Cheers. --Hilinus 12:50, 26 December 2011 (EST)

I followed instructions on the grub-devel mailing list. First you insert

in /etc/default/grub. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)
$ ckbcomp si | grub-mklayout -o si.gkb
Unknown key KP_Comma
Unknown key KP_Comma
Unknown key KP_Comma
Unknown key KP_Comma
Unknown keycode 0x79
$ sudo mv si.gkb /boot/grub/
After that you add

insmod keylayouts
keymap /boot/grub/si.gkb
to /etc/grub.d/40_custom and finally generate new grub.cfg with
$ sudo grub-mkconfig -o /boot/grub/grub.cfg
Cheers. --drevo 17:47, 6 January 2012 (EST)
The version of ckbcomp I got from Debian Squeeze kept giving this error:
Unknown name $sun_t6_custom
The Ubuntu Precise version worked out of the box.
A temporary solution for layouts would be an AUR package for ckbcomp or to distribute .gkb files somehow, but the proper solution would be for grub-mklayout to accept keymaps(5) files.
--Schizius (talk) 18:44, 26 July 2012 (UTC)
This won't work if /boot is on another root partition. At home / is on lvm and /boot on standard MBR partition. This was historical. But since grub.cfg is generated with the root partition in lvm, it can't find my keyboard layout.
The clean solution is to create a new file /etc/grub.d/50_keymapand put this:
set -e
# Include the GRUB helper library for grub-mkconfig.
. /usr/share/grub/grub-mkconfig_lib
if ! prepare_grub_to_access_device "`${grub_probe} --target=device "${KEYMAP_FILE}"`"; then
	return 6
KEYMAP_FILE=$(make_system_path_relative_to_its_root "${KEYMAP_FILE}")
cat <<EOF
insmod keylayouts
keymap "${KEYMAP_FILE}"
So that the root partition is detected, loaded, and then the file is read within that partition.
--Glandos (talk) 08:23, 14 November 2013 (UTC)

GRUB2 + Windows 7 TrueCrypt-encrypted partition

here is a link to my notes from my experience going thru this and Ubuntu Forum post which helped me a GREAT DEAL with this issue - below is a quick HOWTO ::

# ls -al /mnt/win7drive/Users/me/Documents/TrueCrypt\ Rescue\ Disk.iso
   -rwx------ 2 me users 1835008 Sep  5  2011 /mnt/win7/Users/me/Documents/TrueCrypt Rescue Disk.iso
# sudo cp /mnt/win7/Users/me/Documents/TrueCrypt\ Rescue\ Disk.iso /boot/
# mv /boot/TrueCrypt\ Rescue\ Disk.iso /boot/truecryptDesktop.iso
# pacman -S syslinux
# cp /usr/lib/syslinux/memdisk /boot/
# ls -alt /boot
   total 26388
   drwxr-xr-x  5 root root     4096 Jul 29 04:01 .
   -rw-r--r--  1 root root    26140 Jul 29 04:01 memdisk
   -rwx------  1 root root  1835008 Jul 29 03:59 truecryptDesktop.iso
            ....   ....
#mount | grep /boot
   /dev/sda3 on /boot type ext3 (rw,relatime,data=ordered)
# vi /etc/grub.d/40_custom

menuentry "Microsoft Windows 7 x64 Home Premium" {
   insmod part_msdos
   set root='(hd0,msdos3)'
   linux16 ($root)/memdisk iso raw
   initrd16 ($root)/truecryptDesktop.iso
# sudo grub-mkconfig -o /boot/grub/grub.cfg

--Fnord0 (talk) 17:59, 30 July 2012 (UTC)

encrypted /boot

Just so I remember when I come back to edit the article, grub-install (2.00) currently requires the GRUB_CRYPTODISK_ENABLE environment variable be set to "y". --Buhman (talk) 05:58, 10 October 2012 (UTC)

Possible mistake?

Hi there, since I do not feel familiar with Grub2 yet, you might check that:


# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX

Should /dev/sdaX be /dev/sdX?

--Mrln (talk) 14:13, 1 March 2013 (UTC)

This section is about installing to partition. So it is indeed /dev/sdaX. -- Fengchao (talk) 08:43, 4 March 2013 (UTC)
But the section does also have "Partitionless Disk" in its name, and there is the following text snippet just before the example given: " to a partitionless disk (also called superfloppy) or to a floppy disk".
I am not sure, but afaik for a Partitionless Disk the syntax given is indeed wrong (should be /dev/sdX). Not sure how the section could be reworded to make it not-confusing. Giving two separate examples runs the danger of making the whole article too bloated.
-- Bwid (talk) 09:35, 4 March 2013 (UTC)
Perhaps instead of /dev/sdX or /dev/sdaX, /dev/sdXX or /dev/sdZX could be used, to indicate that the disk and the partition should be based on the user's setup?
-- Brainwater (talk) 25 September 2014

Boot Arch iso from LVM (LVM hook in Arch iso?)

I added the following in /etc/grub.d/40_custom:

menuentry "archlinux-2013.03.01-dual.iso" --class iso {
    insmod loopback
    insmod iso9660
    insmod part_gpt
    insmod lvm
    insmod ext2
    set root='lvm/vg0-arch'
    set isofile='/home/jordy/data/isos/archlinux-2013.03.01-dual.iso'
    loopback loop $isofile
    linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201303 img_dev=$root img_loop=$isofile earlymodules=loop
    initrd (loop)/arch/boot/x86_64/archiso.img

My / is on LVM, the iso boots, but it can't mount the loop device (the iso) because the LVM hook hasn't been run before that. Is there a way to fix this and enable the LVM hook in the iso (without modifying it)

jordz (talk) 22:34, 24 March 2013 (UTC)

How to create EFI directory?

According to GRUB#Check_if_you_have_GPT_and_an_ESP, 'On [the EFI partition], there should be a folder called "EFI".' How is this created? I followed the instructions:

parted /dev/sda print
Number [...] File system Name       Flags
 1           fat32       EFI System boot

First, the instructions result in a "fat32" file system, and not a "vfat" one (as described in GRUB#Check_if_you_have_GPT_and_an_ESP). AFAICT "fat32" is not a subclass of "vfat", so that should probably be changed. Second, this partition, when mounted, does not contain anything at all, and I could find no instructions on how the "EFI" directory is supposed to be created. I expect some tool other than mkdir is supposed to do this (and possibly more)?

Other articles have mentioned a directory "/boot/efi". I guess that's just a case of FAT file systems being case insensitive, or does it actually matter?

"Install to partition or partitionless disk" ambiguous or no longer correct?

I just completed a test install of Arch, with Btrfs formatted directly on the disk (no MBR, no GPT). I followed the steps for the "Install to Disk" section, which is similar to how I have installed in the past following the section: "BIOS systems," "GUID Partition Table (GPT) specific instructions."

Long story short, I did not follow the steps as outlined under the "Install to partition or partitionless disk" and my test install in VMWare successfully booted. I do not know if this is something peculiar with Btrfs, or if the steps outlined under the section in question are no longer needed, or are only relevant for a specific use case, but the title of the section as it currently exists seems unclear following this test.

Bootloaders are not my strong suite, any thoughts or additional perspective on this?

AdamT (Talk) 05:23, 22 November 2013 (UTC)

Just a brief follow-up to this, I have completed this installation on hardware now as well. Further investigation is warranted though, as I want to investigate exactly how the drive is being structured by Btrfs and GRUB. -- AdamT (Talk) 03:32, 30 November 2013 (UTC)

os-prober does not require partition to be mounted

it says that os-probe only works for mounted drives, but this is incorrect. I've removed that statement, but I'm wondering why it was there. Are there conditions where this is true?

Thanks for the correction, I'm responsible for adding that information.[1] It was based mainly on this old "discussion": [2]. Even if there are cases when it is necessary to mount the partition, it's certainly not necessary... -- Lahwaacz (talk) 20:14, 5 December 2013 (UTC)

Is there something missing?

I tried this on a Virtual Machine and on two physical machines and i always end up with "EFI variables are not supported on this system"

This seems due to an bug that arch-chroot does not mount the efivars directory at all inside the chroot.

You have to run

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

or it will not work so this should be in the article.

Alpha sorting for kernel names without versions

When installing the "linux" and "linux-lts" kernels on a basic install, the /etc/grub.d/10_linux in 2.02-beta1 will try and use a numeric-oriented sorting routine that doesn't work well for kernels without any versions in the names of the files. I've submitted a feature request and patch for this upstream:

Forum discussion w/patch:

I solved this (and other problems) long ago… why nobody applied this patch to the Arch package is beyond me. felix (talk) 14:11, 8 August 2014 (UTC)

EFI Single Standard?

As some firmware isn't fussy about the name of the directory after $esp/EFI/ - nor apparently the name of the efi stub contained within it - then logically bootx64.efi in $esp/EFI/boot should work for them as well.

For example, the standard Grub UEFI installation command:

# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug

Could possibly be changed to:

grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=boot --recheck --debug

To install to $esp/EFI/boot rather than $esp/EFI/grub. All that would be required then is to rename the efi stub, which again - logically - should work for all firmware.

Does anyone have any experience of this, or be willing to test? Unfortunatly my UEFI hardware only works with bootx64.efi in $esp/EFI/boot.

Did a bit more research, and $esp/EFI/boot/bootx64.efi is essentially used to set the "default" bootloader for most UEFI firmware, hence having a higher chance of detection. The negative of this is that it would cause issues where using multiple bootloaders... Carlduff (talk) 22:59, 24 September 2014 (UTC)