OSDev.org

First of all, I just started out in the OS-Dev hobby, so I know it's probably wrong of me to have such a strong opinion about things I don't fully understand yet.

That said, what the hell were they thinking? The legacy Grub was easy to configure (huge mess in /boot/grub/ now) and to install (so far I failed to install Grub2 on a loopback device, following the Wiki instructions). Is the goal of Grub2 to be a UEFI-compliant bootloader? How does it justify how bloated and overengineered it is?

I don't like Grub2 so far, and I don't know if I should embrace it and leave Grub Legacy behind.

I would like to know what you people have to say about Grub2 and if your kernels are Multiboot2-compliant.

I don't particularly like GRUB either. I do use it, though, and my kernel is multiboot. I wouldn't recommend using ancient GRUB, it's ancient. It's unmaintained and nothing good will come from using it. Fortunately I rarely have to actually install GRUB onto disk images and such. I'll switch to another bootloader when that becomes an issue.

Some guys here are making Gandr. Might be interesting.

I'm indifferent about GRUB. My problem with GRUB2 is really in the Multiboot 2 specification (which is unspecific) and the liberties that GRUB2 takes in interpreting the specification. However, I also use GRUB2 as it gets the job done (for now) and allows me to focus my attention on writing my kernel. I did make the effort to have my kernel loadable with either a multiboot 1 or multiboot 2 compliant loader.

If your kernel supports legacy multiboot, then there are several bootloaders available that supports it - GRUB2 is only one of them. However, neither version of multiboot suffices to provide everything you could ever want for your, and a dedicated bootstrap is the best option in the end.

Considering any use of GRUB is like choosing from alternative evils, you might just want to choose whichever poison seems to result in the least painful death

I do have a personal aversion to GRUB2, but that's mostly because not even Ubuntu could get it right and had me manually fix the installation. A lack of usability is certainly not a good upgrade, so I'd keep preferring legacy as it requires hardly a second thought to maintain. I have since migrated to Refind.

eryjus wrote:My problem with GRUB2 is really in the Multiboot 2 specification (which is unspecific) and the liberties that GRUB2 takes in interpreting the specification.

What issues are you having with Multiboot 2? I know it's different from Multiboot 1 (you have to request what you want from it - here's my working example asking for the memory map), but it's no more difficult as many APIs, protocols, hardware, data structures, etc. out there. One of the hardest specs for me to decode was the SoundFont file format.

Hi,

Espanish wrote:That said, what the hell were they thinking? The legacy Grub was easy to configure (huge mess in /boot/grub/ now) and to install (so far I failed to install Grub2 on a loopback device, following the Wiki instructions). Is the goal of Grub2 to be a UEFI-compliant bootloader? How does it justify how bloated and overengineered it is?

For BIOS systems; traditionally you'd have an MBR that loads the OS's boot sector (in the OS's partition). When there are multiple OSs installed, you'd use a boot manager to allow the user to select which OS they want, which "chain loads" the selected OS's boot loader. The part the selects which OS to boot and the OS's boot loader are 2 completely different and separate things. This allows the user to install any boot manager they like, and any OSs they like - any mixture of OSs and boot managers should work.

The original GRUB developers completely failed to understand the benefits of "separation of concerns" and screwed this up. They built many different boot loaders right into the boot manager (e.g. for Linux, for FreeBSD, etc; plus multi-boot). It was a poorly designed from the very beginning.

Part of the reason multi-boot exists is because they were hoping to convince a lot of OSs to abandon their existing/native boot code and switch to multi-boot, and avoid the need many different boot loaders in GRUB. This didn't happen. For example, even after the GRUB developers added multi-boot support to the Linux kernel, none of the Linux kernel developers wanted it and Linux continued to use its own/native boot protocol.

Then UEFI came along. For UEFI it's the same - when multiple OSs are installed, you're supposed to have a UEFI application that lets the user choose which OS to boot, and that application would start the OS's own UEFI boot loader. GRUB legacy was designed for BIOS only and couldn't work on UEFI. They started GRUB2 in an attempt to screw up "separation of concerns" on UEFI too. While doing that they also attempted to add support for non-80x86 systems (e.g. MIPS, ARM, Itanium, etc).

Their utter failure to understand the benefits of "separation of concerns", combined with many more very different "concerns" (including different boot devices, different "boot protocols" needed by different OSs, different firmware types, different CPUs/architectures, etc) led to "second system effect". To help cope with such a ridiculous mess, they switched to a modular approach. This mostly only made things worse (optional modules meant a whole lot more mess for installation and configuration, plus additional risk of breakage - e.g. when a module one OS needs wasn't installed by another OS).

Note: The increase in complexity also led to OSs (e.g. Ubuntu) that attempt to hide the complexity of GRUB2's configuration under their own layer of scripts, etc; where if you update the OS its scripts "auto-re-generate" GRUB2's configuration for the user. This means if you have 2 or more OSs installed, they can "fight" and trash each other's GRUB2 configuration (a side effect caused by failing to separate the different OS's concerns).

For multi-boot itself, it was similar. The original version was only designed for BIOS and didn't work so well on UEFI or other systems; so they started "multi-boot 2". However, due to lack of interest (and because few OSs cared about multi-boot) this took an extremely long time. This also means that there are people using older versions of GRUB2 on their computers with old/incompatible versions of multi-boot2.

Espanish wrote:I would like to know what you people have to say about Grub2 and if your kernels are Multiboot2-compliant.

For my OSs; I design my own "transition state" standard that describes the state the computer has to be in when the boot loader transfers control to the OS (which information needs to be where, what state CPUs should be in, etc). Then I create a different boot loader for each different case (e.g. one for BIOS hard disk, one for BIOS network boot, one for UEFI, etc). Multi-boot is just one of those different cases - e.g. I'll have a piece of code that is started by multi-boot, that sets everything up to comply with the OS's "transition state" standard, and then passes control to the OS like any other boot loader would. However; because my own "transition state" standard is designed for my OS and includes special features that multi-boot doesn't support; the OS's multi-boot support is something my OS's user guides would warn potential end users against using (e.g. a "not officially supported" hack).


Cheers,

Brendan

MessiahAndrw wrote:

eryjus wrote:My problem with GRUB2 is really in the Multiboot 2 specification (which is unspecific) and the liberties that GRUB2 takes in interpreting the specification.

What issues are you having with Multiboot 2? I know it's different from Multiboot 1 (you have to request what you want from it - here's my working example asking for the memory map), but it's no more difficult as many APIs, protocols, hardware, data structures, etc. out there. One of the hardest specs for me to decode was the SoundFont file format.

My original post on the topic is here. It might read like a toolchain issue. But most of my unnecessary issues were related to the specs and grubs interpretation. For example, the spec mentions nothing about each sub-structure alignment which grub requires in order to be recognized. Also, the definition and use of the word, "size," is inconsistent between the specification (as well as unclear in the specification) and grub's implementation.

I like Brendan's narrative of how GRUB got to be the way it is

My own frustrations with GRUB have more to do more with long-standing brain-dead design decisions in their default configuration, encountered in my sometime capacity as a sysadmin for remote Linux machines.

For OS development, I just stick with Pure64, which is the simplest and most trouble-free bootloader solution I've yet to encounter.

grub2 looks like some "know-it-all" shitcrap person has just throw in bunch of scipt code into the configuration file and deserves himself a great assholic title. It is very unfortunate linux has gone this path. Same for many countless other stupid utilities in linux i.e. yum becoming dnf, ifconfig is obsolete in rhel7.0, linux distro-s has became a domain everyone just "disrupts" anything for their own good.

sortie wrote:I wouldn't recommend using ancient GRUB, it's ancient. It's unmaintained and nothing good will come from using it.

Software doesn't become bad just because it's old. If you're happy with the features that it has, GRUB 1 is a solid piece of software that just works.

GRUB 2 is considerably harder to get installed and working on a disk image, so when there is no GRUB 1 available, I often end up using syslinux instead nowadays to boot Multiboot kernels. Of course, syslinux isn't quite as nice as GRUB when you have to edit the configuration during the boot process, but as long as it's only images run in an emulator on my development box, I don't really have a reason to do that anyway.

ggodw000: Oh, and you might want to check the date of the last post in a thread before replying to it