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.
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.
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.
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.
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.
Boot issues on Linux are like most of the other problems Linux has, there is no standard way to do things, so people invent their own ways, and it results in the problems we see today. This doesn’t just apply to booting, it also particularly includes dns and network management. Combined with the fact that its a low level thing people don’t want to deal with, it gets left to rot. Few understand it leading it frustration.
Grub isn’t a simple tool because it’s not solving only simple problems. A simple situation would be booting a VM, where something like systemd-boot is probably preferred over grub since the heavy lifting should already be done by the host OS at that point.
Also, it’s not grub that is usually broken (grub did load after all…), it’s something else like a bad or botched update or something similar that breaks support for some hardware or the initramfs got messed up. I frequently encounter servers that suddenly stop booting and get stuck in either the initramfs or at grub, and selecting an older option usually gets me back into the os proper. Also, I have noticed it’s most often ubuntu that gets messed up while rhel and friends are much less likely to break. Breakage on arch is usually the result of specific user error, or some incompatibility was introduced.
In your case, the issue could have been (just guessing) a new kernel was installed, but the config tool might not have been run to create the new references. It’s not exactly grubs fault if the thing it was suppose to point to no longer exists. Simpler systems like arch do not have this problem at all since the kernel is always overwritten in-place, so the references are unlikely to ever get broken, but this is not without pretty annoying tradeoffs.
I didn’t think to check the number of patches, but as you can see, a lot of those patches have nothing to do with x86 specifically, and some relate to the scripts to implement or change behavior for their distro. If you check Arch, it has not nearly as many patches and still works fine. https://gitlab.archlinux.org/archlinux/packaging/packages/grub
You are correct that grub probably is the better part of an OS, but so are most other bootloaders that actually implement useful features (UKI IS linux, for example). systemd-boot implements few extra features like filesystems and lvm. On Linux, it’s not the end of the world since you can pack in much more stuff in the initramfs to support more filesystems and other interesting behaviors.
I can definitely agree that grub is not very actively maintained, and there are even some outstanding bugs and fairly important and reasonable feature requests that are sitting with ready to apply patches. But grub is also a mostly complete project. Most things boot fine with it as is, and it’s not like the EFI spec is constantly changing requiring regular updates. It’s also probably fair to say that working on grub probably isn’t a walk in the park due to how low level it is.
To be more clear on how I implemented my little scheme, neither grub or a script actually sync anything. I have two completely independent ESPs that are not synchronized automatically in any way. But because the grub EFI binary supports btrfs, it can just point to /boot in whatever btrfs filesystem which is where most of the configuration actually is. In this way, the dual ESPs are generated once and occasionally updated whenever I feel like, and /boot can continue to be managed by mainline scripts without any customization, such as mkconfig whatever initramfs build tool since the mirroring is completely transparent.
It simply is not possible to replicate this without grub since no other bootloader (to my knowledge) supports btrfs, or any other raid capable abstraction. You could get close by including additional scripts to ensure the appropriate configs and images are synced, but that is another point of failure.
Which bootloader would you suggest for UEFI system?
Thanks for the reply
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.