Originally posted by jrch2k8
View Post
so projects like GRUB growed into such monsters because they had to replicate kernel functions to set an environment good enough to handoff the boot process to the kernel.
For example:
For example:
- Grub actually need a proper filesystem to read the filesystem where the boot partition is to be able to exec the kernel, if the filesystem doesn't match it cannot handoff the boot to the kernel because it cannot see it, see is a circle.
It's total bs like rich commandline environment for scripting support, sound support and other things that have no bearing in a bootloader, but are of course available in GRUB.
It also needs to hack around the very basic old-school garbage display interface provided by the BIOS to have a semblance of GUI when in fact it still is a text-mode bootloader.
is not that easy for the GRUB to keep current.
It's more like ZFS developers just don't care about GRUB, or GRUB developers don't merge things for years (which is a known issue), and everyone else accepts this because it's just easier to make a boot partition than write code or force GRUB devs to do their job faster.
For BSD for example they use their own bootloader https://reviews.freebsd.org/source/s...ad/stand/i386/ for both BIOS and UEFI
I don't know if they support all features required, but afaik all serious NAS appliances using ZFS are using a dedicated root partition (either with or without ZFS), where they can probably not enable anything the bootloader does not support.
For everything else (Linux/Mac) they make boot partitions, or keep the root filesystem separate from the data filesystem.
UEFI on the other hand is really dumb and simple with a proper standard,
so basically you need a fat32 partition on GUID that contains the loader and a kernel, then the kernel and initramfs do wathever they need to do to boot,
Comment