Ask HN: Resources for learning about boot loaders? | Hacker News Reader

Ask HN: Resources for learning about boot loaders?

102 pointsrayascott27 comments

I’m trying to find the best resources I can for learning about boot loaders. I recently installed Fedora dual boot on my MacBook Air and want to understand what is happening during the boot process, and why, for example, I’m now staring at a Grub console after resizing my APFS partition.

View on HN

Realmode assembly - writing bootable stuff:

https://0x00sec.org/t/realmode-assembly-writing-bootable-stu...

Writing a bootloader:

http://3zanders.co.uk/2017/10/13/writing-a-bootloader/

(Both from my HN archive, posted somewhere this year)

Obligatory: http://wiki.osdev.org/Main_Page

I think looking at the bootloader source is an excellent way to learn. However the more complex the bootloader, IME the less rewarding the time spent reading its source.

While Grub is highly well-known, popular, sometimes innovative and of course very flexible, it is also more complicated than I would like and so I am not a user. The primary reason is because of its strategy to locate parts of the bootloader on the media in a way that can vary from one installation to another. The alternative, "standard" approach being to locate all parts of the bootloader in some pre-defined area, usually near the start of the "disk".

The Grub approach obviously has its justifications and advantages. Maybe some see the Grub approach as an advantage because e.g. if one accidentally loses access to an area near the start of the media where most bootloaders historically reside, then one can still potentially recover.

However, if understanding the boot process is a goal, I see the Grub approach as a disadvantage. It makes locating and verifying the bootloader more complex when it is fragmented into parts that are potentially scattered around the media instead of located in a pre-defined area near the start of the disk. If one makes changes such as the formatting or partitioning of the disk, are all the fragments from a prior Grub install accounted for? I would prefer not to have to consider that question. Whereas I know how to completely remove/reinstall the bootloader if I always know where it will be located.

If the goal is to understand the bootloader one is using on a lower level than simply using it, e.g., verifying it is there on the media, I think there are more simple alternatives than Grub.

Alas, last time I checked the Linux kernel is still not compliant with the "Multiboot Specification". This is unfortunate for me because the non-Grub alternative I prefer supports it and it really works well for multibooting. I would love to use it to try booting a Linux kernel. I suspect there is probably a workaround but making the easy choice to use Grub probably obstructs people from experimenting with alternatives.

While experimenting years ago, if I remember correctly, I booted a NetBSD kernel using the FreeBSD bootloader (the part written in Forth). I seem to remember this was possible because of compliance with the Multiboot Specification.

"One bootloader, many kernels." (Without chainloading.)

The one I'm using at the moment: https://www.rodsbooks.com/efi-bootloaders/index.html

It is still maintained and updated. It covers most not loaders out there in context of Linux. It is also very practical.

I quite like rEFInd. It seems to be still getting regular updates and has definitely improved since forking from rEFIt.

That’s awesome thanks!

Hmmm. I thought that I told M. Smith about the relocation back when it happened.

The hyperlink on that page to one of my articles should read http://jdebp.eu./FGA/efi-boot-process.html

That is one of several frequently given answers at http://jdebp.eu./FGA/#Boot

This is what first got me started, and I highly recommend it:

http://www.brokenthorn.com/Resources/OSDevIndex.html

Thanks! That looks really interesting.

General purpose understanding probably won't help you with the specific problem you're having. I know quite a bit about the user space foils of your situation with Apple's EFI firmware, the NVRAM boot entries that point to the bootloader, GRUB2, and the peculiarities of Fedora's installer. And there is really nothing standard about it..

a. Fedora's installer, only on Macs, creates a 2nd "EFI System partition" that's HFS+ formatted. And that's because Apple's EFI firmware can read HFS+ directly, and it enables showing Fedora as a boot option when you boot with the option key held down. This doesn't happen if the bootloader is on the "real" FAT32 EFI system partition, which hilariously Apple doesn't use for booting either, they only use it for staging firmware updates.

Right out of the gate you're in the weeds of super esoteric stuff...

b. That you get a GRUB prompt means the firmware found the GRUB EFI OS Loader binary, which is on that HFS+ faux-EFI System partition. In that same directory should be the grub.cfg, which it should read automatically and display a menu of kernels to boot. Therefore, the GRUB prompt also means the OS Loader isn't finding the grub.cfg.

So you have something of a mystery on your hands and it'll take an autopsy to find out what's going on. First thing would be to use one of the netinstallers (any Fedora edition netinstall image) put onto a USB stick, boot that with the option key, choose Troubleshooting, then Rescue a Fedora system, wait for boot process, pick the first option to find and assemble the system. And then you'll

    chroot /mnt/sysimage
    grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
    exit
    reboot

That should work unless there are extenuating circumstances (some other distro's GRUB is somewhere on this system). But I still don't really understand how APFS resize can affect the grub.cfg alone, without nerfing the entire HFS+ faux-ESP as well, in which case you wouldn't have a GRUB prompt.

Thanks for your reply, it’s extremely informative and useful. It’s actually the second time I’ve resized the APFS container and this didn’t happen the first time. I was also shocked to wake up this morning to discover the resize had actually left me with a new partition, considering that every time I tried to resize it, the process failed with a well documented error code or the machine just spontaneous rebooted while frozen.

One other question I have is, that once I’d installed Fedora, my Mac would automatically boot into Fedora. So now if I want to use macOS I have to use the Option key. Has the Fedora boot loader over written something and is it even possible to swap it back? I’m going to give the net installer Rescue a bash now. Thanks.

Fedora's installer wrote a new boot entry to NVRAM and set the bootorder to default to Fedora. If you boot Fedora you can run efibootmgr -v to see these entries and change them with 'efibootmgr --bootorder' and then put in the boot numbers in the order you want, e.g. 0002,0001. If you make macOS first, then it will boot by default, to get to Fedora you'll use the option key at boot time to pick its icon in the firmware boot manager UI.

Sir, you are a genius and the most useful person I have ever discovered on the internet. Thanks!

This boot ordering I could not get working, but perhaps it was a symptom of the missing grub.cfg, but I'm just guessing. I have no desire to temp disaster by playing around with anything now that it's working. Thanks again!

Unfortunately that did not work. I guess I’ll be learning about Grub!

It's really tedious. Anyway I'm on irc.freenode.net. I'll want to see efibootmgr -v, blkid, and see how it's all being assembled. The easiest way to get data out of a Macbook Air is if you have a wired ethernet connection since the proprietary Broadcom firmware blob won't be on any of the install/rescue boot media. Once you've got an internet connection you can pipe anything to fpaste, which will spit back a URL containing the pasted data from the command.

See the section heading of http://jdebp.eu./FGA/efi-boot-process.html#Apple (-:

What did eventually work for me was using the following path:

grub2-mkconfig -o /boot/grub2/grub.cfg

I'd actually resigned myself to using the rEFInd boot manager, as I'd used it in the past, and I'd read that others had better luck when implementing dual boot systems with two OS's both using EFI. I had that all working when I decided to to have a closer look at how grub works, and used the path applicable to my system. I didn't even have a grub2.cfg, and I have read today that others have also had this same issue after resizing Mac partitions. I'm just glad it's working as I want now.

The fact that path works tells me this is a CSM-BIOS installation of Fedora. That is, there is an EFI compatibility support module that presents a faux BIOS firmware to the operating system to make it think it's a computer with BIOS rather than UEFI. On Fedora, the BIOS variant of GRUB puts its files in /boot/grub2; where the UEFI variant of GRUB puts its files in /boot/efi/EFI/fedora/.

Did you burn the Fedora installer to optical media? I'm not aware of a way to trigger CSM-BIOS booting with flash media.

I was hoping you hadn't seen this reply of mine. Because it turns out I was wrong. I do have a /boot/grub2 directory. And it has a symlink named 'grubenv' to ../efi/EFI/fedora/grebenv. Grub is actually using /boot/efi/EFI/fedora/grub.cfg. I realised this a few minutes ago when the /boot/grub2/grub.cfg I generated was having no effect on grub, after making a few timeout changes.

Is it possible that the grub2-mkconfig only updates the config file if there is a change in the system? I ask because, earlier in the day when I ran your grub2-mkconfig example, it had no effect. But since then I've removed 3 prior kernel versions so I'm guessing that would have caused an update of the config file. Although I'm still unsure as to why grub wouldn't load the config file earlier.

I spent an unreasonable amount of time working on grub2. The stuff I looked at the most where the uefi spec

http://wiki.phoenix.com/wiki/index.php/Category:UEFI

And then the uefi stub code in the Linux kernel, as well as the grub2 source code. It’s not too hard to figure out the flow in grub2, just figure out where it does EXIT_BOOT_SERVICES and work from there.

For some reverse engineered versions of the Windows bootloaders: http://thestarman.pcministry.com/asm/mbr/

You should take a look at U-Boot implementation.

https://github.com/u-boot/u-boot

I learned by playing around with the Grub bootloader in Linux VMs launched with Vagrant. I deleted every non-essential line of code in the bootloader config, and then stared at it & the Grub docs until it made sense. My ultimate goal was learning how to turn a Linux container into a bootable VM.

So how does one turn a Linux container into a bootable VM?

PoC || GTFO has a series of articles about the bootloader and operating systems all written in under 512 bytes. It's quite adorable. I also recommend the website wiki.osdev.org -- it saw me through harsh undocumented times.

http://reboot.pro/

Reply on news.ycombinator.com