Hacker News Reader

Comment by pwdisswordfish2 | Hacker News Reader

Why is the Debian-derived system non-booting?

Many years ago I had disk error problem and could not boot. I tried a popular, Linux-based "system rescue" CD and it could not boot without accessing the disk. I tried my own "live" NetBSD USB stick and booted up no problem. No disk access needed.

I stayed away from Linux for many years as a result of experiences like that. I have been using Linux lately and I continue to find more stuff like this that would just never happen on BSD.

I do not understand why people use grub, let alone grub2. There are plenty of other bootloaders. What is wrong with syslinux?

View on HN

GRUB2 is the most flexible bootloader. I use it for a multi-boot flash drive, used for booting 64-bit FreeBSD on a 32-bit-EFI machine (earliest Mac mini + 64-bit CPU)…

But yeah for normal desktop usage… there's rEFInd.

Flexibilty would have been my first guess. Are there any other reasons besides flexibility?

I'd say support in distros. With grub you can throw pretty much any distro onto your machine and it will show up (except Solus) . Also I don't think you can just choose which bootloader you want in most distros except Arch and Debian if I remember correctly. You can do that manually of course, but grub is easy and it works.

In arch you can choose the bootloader as well. The recommendation I hear a lot and that I use is systemd-boot (formerly gummiboot), which strangely doesn't have much to do with systemd.

It can pick up Windows for multiboot and is straightforward to configure (can even be configured from a windows live disk if you mount that FAT partition).

Well, I just had a look at the Arch Wiki article on Boot Loaders [1]. GRUB is by far the most widely supported and also the most widely compatible bootloader.

[1] https://wiki.archlinux.org/index.php/Arch_boot_process#Boot_...

The table is somewhat misleading. The filesystem support for example refers to being able to boot a kernel that is on that FS from disk.

In most gummiboot setups, your kernel will be on the ESP partition along with everything else, so it doesn't matter what FS the root is.

The lack of support for MBR or BIOS doesn't matter much either, systemd-boot requires a 64bit System and most 64-bit systems that are still around and largely used (or actively sold) have a UEFI that supports GPT. If you absolutely need to, systemd-boot supports booting from a GPT that has a MBR wrapper.

So while the table looks like systemd-boot lacks support for a lot of things, the reality is that when you setup systemd-boot a lot of these columns simply don't matter

So does that mean that I can't use those filesystems for my /boot/efi partition and everything else is ok? Then it's really not that bad. I haven't played around with other boot manager as you might be able to tell.

That's pretty much your limitation; your linux kernel + initramfs can't be on filesystems other than VFAT (ie, must be on the ESP but there is some ways you can have it work across disks).

Hence the table being slightly misleading.

For example, it also mentions that EFISTUB means you can't boot on btrfs and friends anymore. But it's the same limitation, initramfs and kernel need to be on the ESP, everything after that is up to the initramfs to bring up.

Obviously you can with Gentoo. That's basically its "thing" (choice).

Oh yeah, I forgot about Gentoo.

Reply on news.ycombinator.com