7mo ago

GRUB is confusing

hello,

I don't know if this is the right place to ask this question but could someone explain me how a UEFI system boots, I couldn't find a guide online. I want to know because I don't understand certain GRUB commands and how it get installed.

I just copy paste commands from Arch wiki and it just magically works without me knowing anything about it.

all the different distros use different grub command parameter and it's so confusing. eg, Arch and Gentoo.

Arch command: grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB Gentoo command: grub-install --efi-directory=/efi

why both command is different? exactly where does grub gets installed?

sorry if this is a naive question but i really don't understnad GRUB.

26 comments

Since you use UEFI, you don’t have to use GRUB. It basically consists 90% of cruft left over that was needed for BIOS boot, and has a lot of moving parts and bad design (such as a single config file which has to be shared between OSes, which is so complex it needs a generator for it).
Try systemd-boot, it’s lightweight and well designed.
Anyway, looks like the target parameter is default now, the “esp” in the arch command is supposed to be substituted for the ESP path, for example /efi, so the only difference is bootloader-id. Which looks like that’s the label that show up in your UEFI setup for the boot entry.
- Yeah I know everyone likes to hate on systemd, but I like systemd-boot way more than GRUB. It just does its job and stays out of the way, I never have to fart about with it at all.
- GRUB is still the standard bootloader in physical deployments because it is the most likely to work and supports most of the features you might want in a bootloader.
  UKI based booting is interesting since it seems like it might support even more features. But the last time I tried to test it, there wasn’t a ton of documentation on it and the software still seemed a bit green and inflexible.
  For example, my main computer right now has a completely redundant boot process. I have 2 disks which each have an efi system partition. And the root file system is btrfs raid1 across 4 disks. This was very easy to set up and completely supported by grub with no custom configuration needed. The only slightly tricky thing I had to do to install the second efi was to use an extra flag.
  
  GRUB is still the standard bootloader in physical deployments because it is the most likely to work
  The countless issues you can find online about being stuck at the GRUB prompt say otherwise. I've personally recently experienced GRUB on a computer seemingly randomly losing information about where the config file was stored, or at least not automatically loading it. God knows where that was supposed to be stored, running grub-install fixed it in any case.
  More likely it's used by the big non-DIY distros because it's less effort to maintain a single bootloader than one for UEFI and one for BIOS boot, because the latter you still need anyway.
  and supports most of the features you might want in a bootloader.
  That's the understatement of the century. It's basically a decently sized operating system at this point, with seemingly everything tacked on that you can think of such as support for what looks like a grand total of 11 partition table schemes, "The Bee File System", disk driver for classic Macintosh, and a JSON parser.
  While some of what it has may have been needed for BIOS boot, the essential functionality is now provided by EFI APIs, and you do not need 337979 lines of C code anymore to implement a suitable bootloader for a contemporary system.
  And I probably wouldn't even say anything if it was well written or maintained code. There's clearly something very wrong with it if distributions feel the need to apply hundreds of patches to it, Fedora has 283 right now. I've also had a terrible experience trying to script some of its commands.
  I have 2 disks which each have an efi system partition. And the root file system is btrfs raid1 across 4 disks. This was very easy to set up and completely supported by grub with no custom configuration needed.
  This is of course also supported by any other bootloader, since which of the two ESPs to load from is determined by the UEFI, and mounting the rootfs is done by the kernel. You just need to sync the two ESPs. systemd-boot's kernel-install admittedly can't do this out of the box, but you can make it work with hooks.
- Which bootloader would you suggest for UEFI system?
  Thanks for the reply
  
  Try systemd-boot, it’s lightweight and well designed.
  
  They specifically called out a suggestion which was even formatted so you couldn't miss it even if you weren't reading closely.
  
  Systemd-boot is the simplest, it just works.
I just copy paste commands from Arch wiki and it just magically works without me knowing anything about it.
Join the club.
- Building a Cathedral without Science or Mathematics: The Engineering Method Explained
https://wiki.archlinux.org/title/EFI_system_partition#Typical_mount_points
(Efi System Partition)
- Thank you so much for the link. It was a good read :)
GRUB gets installed on your harddisk in your root partition, it's configuration file on the boot partition and finally into your boot sector if I'm correct. UEFI is a standard for your firmware located outside your harddisk. You go from firmware -> partition layout -> bootloader (grub) -> kernel.
The firmware is closed source under BIOS or UEFI or if you're hardcore open source, libreboot/coreboot/'other options' and is located somewhere on your motherboard on some chip.
Then there's the partition layout and bootloader that are located inside /dev/sda I believe, so inside the device itself, which can be read if you want to take a peek at it.
Now the bootloader located in the boot sector /dev/sda loaded by the firmware located in some chip in the motherboard, has access to the boot partition, where it loads the bootloader's configuration file usually located at /boot/grub/grub.cfg for GRUB. I remember UEFI having some kind of standard bootloader by itself, so it doesn't even need a bootloader if I can remember correctly.
This what I recall as it was quite complicated for me too. Especially with software being called firmware and not being called motherbootware or pre-bootware or anything that indicates that this piece of software is the very first thing that starts running during boot.
But you look at /boot and what you can find there. There will be at least two files there called initramfs and vmlinuz, which were also part of the boot process, but I forgot what role those two played.
- Short answer to your last paragraph:
  vmlinuz is the kernel. It ends with z instead of x, because it's z-compressed to save space. (I've heard that it's possible to use an uncompressed kernel for that 1ms faster boot time)
  Initramfs (not intramuscular, which my autocorrect thinks is appropriate) is a small filesystem blob, "initial ram filesystem", meant to be loaded directly into ram to allow the kernel to talk to your hardware via drivers. It also has a lot of binaries needed to perform other tasks that need to run before the root filesystem is mounted.
  
  Oh wait, I see that vmlinuz file has a version to it. I couldn't remember if vmlinuz was the kernel or not, because I used to have multiples of them, but these days I only have one.
- I'm pretty sure UEFI systems don't make use of a boot sector anymore. They look for the bootloader in the form of an .efi file in the ESP or EFI System Partition, of each sata drive (maybe other block devices too).
  also, the disk it uses is not necessarily "/dev/sda". first because it can be on any of the disks, second because that's not a persistent ID but something that depends on detection order
  Especially with software being called firmware and not being called motherbootware or pre-bootware or anything that indicates that this piece of software is the very first thing that starts running during boot.
  firmware is a pretty common term for things like this (code on chip that manages low level startup)
  
  firmware is a pretty common term for things like this (code on chip that manages low level startup)
  It's still a stupid term no matter how common it is. It has little to nothing to do with firms.
I agree, Grub is horrendous and one of the most complex systems in linux. Grub2 is even worse, and searching the web for help is difficult as the two are named interchangeably, despite being hugely different in design.
Random files spread over the filesystem. Some you edit, some are done automatically, some are done by kernel upgrades, some you need to run yet more commands for them to work - and it all differs from distro to distro. The sooner more distros move away from this, the better.
What's confusing, when x86 initializes it preloads specific address in IP motherboard manufacturer has BIOS there that sets up first 512 bytes. and IP jumps to the new address then it sets up rest of /boot and switches your CPU to real mode up until that point it was in 8bit mode now it is in 16 bit. then jumps to that, now it switches to protected mode I.e. 32bit and loads kernel and initramfs (to solve chicken and egg problem) and then your os boots.
Throw in cryptsetup and shim and switching to 64 bit somewhere there.
- Yes, x86 legacy is really confusing. Especially if you are going to write your own kernel or bootloader.
If GRUB is too confusing, just uninstall it? You said you have a UEFI system, you don't need a bootloader. You can just put the vmlinuz and initramfs onto the ESP and boot into it directly. You can use efibootmgr to create the boot entry, something like this:

efibootmgr \ --create \ --disk /dev/sda \ --part 1 \ --index 0 \ --label "Void linux" \ --loader /vmlinuz-6.6.52_1 \ --unicode " \ root=PARTLABEL=VOID_ROOT \ rw \ initrd=\\initramfs-6.6.52_1.img \ loglevel=4 \ net.ifnames=0 \ biosdevname=0 \ nowatchdog \ iomem=relaxed \ "
--disk /dev/sda: What disk is the esp on?
--part 1 What partition number (counting from 1) is the esp on?
--index 0 At what index in the boot menu should the boot entry appear?
--loader Path to the vmlinuz file. These are normally in /boot, you have to move it to the esp yourself
root=PARTLABEL=VOID_ROOT this is the linux root partiion. I'm using PARTLABEL to identify mine, but you can use pretty much anything that /etc/fstab supports
initrd=\\initramfs-6.6.52_1.img Again, you have to move the initramfs file from /boot into the esp. For some reason this uses backslashes, not forward slashes as path separator (double backslashes in this case are to prevent the shell from interpreting it as an escape sequence)
The rest of the arguments are just misc kernel parameters that I use
Just search for EFISTUB for more info.
Pretty sure the main difference is that one puts stuff in a directory called esp (which I assume is a placeholder for the actual directory?), and the other one is put in /efi. That needs to be the path to your efi partition, because that's where the UEFI expects to find things it can boot. The target is probably redundant, i.e. it defaults to x84_64-efi on Gentoo (maybe not on Arch?) and the id is just a name, you can put whatever there. See man grub-install.
When I'm confused about commands, I find checking the man page for the command a good start to understand what the flags do. Once you've got man-pages installed on your Linux system, you can do "man grub-install" (or any other command) from a terminal to see information about that command and it's flags.
I'm not sure if it says it in the Arch wiki, I think it might, but "esp" is often shorthand for whatever directory you're using as an EFI boot directory, I don't think it's a literal directory. On my Arch system, my esp is "/boot/EFI" I'm pretty sure.
As for why Gentoo doesn't include the --target flag, it could be that "x86_64-efi" is either the default on gentoo's version of grub, or just the default for every version of grub, meaning if the latter is the case, that flag could be safely omitted for your arch installation.
I'm pretty sure the --bootloader-id flag is just a friendly name for the bootloader that you can see from the terminal when booted into a Linux system and probably also from the bios menu. I'm not 100% though, a check through the man page would tell you more about that specific flag. Gentoo may omit it, leaving it either blank, or as some sort of default.
To answer your original question, the system boots up, does some basic checking of hardware to make sure everything can run okay and that there are no obvious faults or incompatibilities, then tries to load a program called a "bootloader" (such as grub), which will then hand off execution to whichever operating system you select. If you're not fond of grub, good news! There are plenty of other good bootloaders available. I'm a big fan of rEFInd (UEFI only) or systemd-boot.
I don't know grub SUPER well, but I'm pretty sure it gets installed in that --efi-directory location that you provide when you run the command. It might be nested a few directories down though, not sure.
- Remember that the system documentation can be different for different operating systems. For example, it's notorious that the documentation for sed differs between GNU and macOS, particularly regarding the -i option: https://stackoverflow.com/questions/4247068/sed-command-with-i-option-failing-on-mac-but-works-on-linux
  In order to avoid surprises related to this, "POSIX.1-2024 defines a standard operating system interface and environment, including a command interpreter (or "shell"), and common utility programs to support applications portability at the source code level." https://pubs.opengroup.org/onlinepubs/9799919799/ https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html

26 comments