Talk:GRUB2 Quick Start

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 14:44, 5 November 2024 (UTC)
:: Your reply ~~~~

UEFI/GPT

Talk status

This discussion is still ongoing.

I miss some more compact information about UEFI/GPT or in other words: I would have liked to see it here when I set up my first UEFI/GPT boot:

1. EFI boot entries are saved in the EFI NVRAM. They specify the location (disk and partition) of the boot loaders.
2. Bootloaders (i.e. windows bootloader, grub binary) are stored in a EFI vfat partition. It is recommened to use only one EFI vfat partition (my mainboard firmware shows a huge growing list of the same boot entries if I have more than one EFI partition). If you have installed an OS via UEFI previously (like Windows), you already have an EFI partition, that you can use.
3. If you want to use features like "grub2-reboot" or GRUB_SAVEDEFAULT=true, your /boot must be placed on a file system on which grub has write support (it does not have write support vfat partitions (It fails on "save_env" with "malformed file")). In this case the EFI partition should be mounted to /boot/efi (and not directly to /boot). A typical partition table would look like
   CODE

   /dev/sda1 EFI vfat
   /dev/sda2 /boot ext2
   /dev/sda3 swap
   /dev/sda4 /
   

4. You should check the EFI boot menu entries after grub installation: efibootmgr -v. The path \EFI\gentoo\grubx64.efi must correspond with your /boot/efi/EFI/gentoo/grubx64.efi. If not, create an entry efibootmgr --create --disk /dev/sda --part 2 --label gentoo --loader "\EFI\gentoo\grubx64.efi"
5. If you want multiple boots you should check: If the other OSs have their own EFI boot loader (like windows) or if you can boot them directly from grub (like a linux kernel). To add an EFI bootloader to your grub boot menu, list your EFI boot entries with "efibootmgr -v" and you will see something like "\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI". You should check the partition and location of the bootloader (i.e. /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi). Now you can create your boot entry in /etc/grub.d/40_custom:
   CODE

   menuentry "Windows" {
       root=hd0,2 #the partition where the bootloader is located
       chainloader /EFI/Microsoft/Boot/bootmgfw.efi
   }
   

   To add another linux boot entry it would look like
   CODE

   menuentry "Linux" {
       root=hd0,3
       linux	/vmlinuz-4.1.12-gentoo root=/dev/sda3
   }
   

6. UEFI_Dual_boot_with_Windows_7/8 should be tidied up/changed/updated. As you see above it is in most cases not that complicated to chainload the windows bootloader.

--Mattenklicker (talk) 18:34, 28 January 2016 (UTC)

The no-maintenance approach

Talk status

This discussion is still ongoing.

I'm not sure where to put this right now - this seems to be as good a place as any:

I don't like that I have to auto-generate the grub config every time I update my kernel, that's so LILO. For me, GRUB is something I set up at the beginning, and then never think about it again. With a setup as described in this article, and in the main GRUB article, as well as the guide, the user is forced to do the grub2-mkconfig dance every time after a kernel update.

I solved the problem by having a menu entry that boots '/boot/vmlinuz' - the good old symlink generated by the kernel's 'make install', that always points to the newest kernel:

root #chmod -x /etc/grub.d/10_linux

and instead use

FILE /etc/grub.d/10_current_linux_simple

#!/bin/sh
echo "Adding Linux... [$0]" >&2
echo "
menuentry 'Linux' {
        set root=(hd0,1)
        linux /boot/vmlinuz ${GRUB_CMDLINE_LINUX_DEFAULT}
}
"

That's better than editing /boot/grub2/grub.cfg directly, as proposed in the Manual Configuration section, because you can still change stuff in /etc/default/grub or elsewhere and rebuild the config, without having to edit grub.cfg again afterwards. And it's just much more KISS than that huge /etc/grub.d/10_linux.

--Padde (talk) 02:19, 3 January 2013 (UTC)

A bit outdated

Talk status

This discussion is done as of 2022-08-05.

The name (grub2), and the multislot behaviour has changed. News 2016-08-11-grub2_multislot_default says:

The multislot use flag in sys-boot/grub-2.x is no longer enabled by default. When the flag is enabled, all upstream binaries and documentation are renamed to "grub2" so as not to collide with grub-0. Now that the use flag is no longer default-enabled, these names will revert back to their upstream defaults. For example, grub2-mkconfig will become grub-mkconfig, grub2-install will become grub-install, etc. If you wish to retain the previous naming scheme, please make sure to explicitly enable USE="multislot" on sys-boot/grub in the usual manner.

Also, my architecture is amd64, and when I didn't specify GRUB_PLATFORMS in make.conf, grub chose to install for both efi-64 and pc platforms, which is ok, I guess (as I would be specifying --target=x86-64-efi anyway). Niku (talk) 05:54, 7 January 2019 (UTC)

Also, efivarfs needs to mounted rw for grub-install/efibootmgr to work. (mount -o remount,rw efivarfs) Else the commands fail with error "Could not prepare Boot variable: Read-only file system". See https://bugs.gentoo.org/627964.Niku (talk) 06:46, 7 January 2019 (UTC)

I have added a reference to this. Niku (talk) 13:01, 10 January 2019 (UTC)

This discussion has been resolved. If anything else needs attention please update the article. Thank you! --Maffblaster (talk) 19:11, 5 August 2022 (UTC)