Live data from Hacker News

It's far from clear how grub package updates work on Ubuntu

utcc.utoronto.ca

21–30 of 69 posts

Re: It's far from clear how grub package updates work on Ubuntu

#21
post #9
post #7

> It's far from clear how grub package updates work on Ubuntu It's far from clear how grub works, uprade or otherwise, period. Much less how to configure it or install it. Sendmail.cf or jq level configuration language in terms of obscurity. Cryptic error messages the severity of which is impossible to infer (actual impact being from no impact whatsoever to my computer won't boot anymore). Not my favorite piece of Li…

It's pretty well documented with a pretty simple configuration language (if you already use a bourne shell (and you probably do), you already know how GRUB's syntax works). I guess reading the manual isn't popular these days, but GRUB has a complete one that explains it all.

The point is, GRUB is unnecessary complexity for probably 99.9% of all systems that boot Linux and maybe one other OS.

Re: It's far from clear how grub package updates work on Ubuntu

#22
post #11

I miss LILO, life was song much simpler, to this day I barely understand grub beyond basic kernel parameters.

You may have a look attt elilo which is lilo with efi support. Slackware still ship it. https://sourceforge.net/projects/elilo/

Re: It's far from clear how grub package updates work on Ubuntu

#23
post #11

I miss LILO, life was song much simpler, to this day I barely understand grub beyond basic kernel parameters.

You may have a look attt elilo which is lilo with efi support. Slackware still ship it. https://sourceforge.net/projects/elilo/

Cool, specially now that I am dealing with a pure UEFI motherboard.

Re: It's far from clear how grub package updates work on Ubuntu

#24
post #9
post #7

> It's far from clear how grub package updates work on Ubuntu It's far from clear how grub works, uprade or otherwise, period. Much less how to configure it or install it. Sendmail.cf or jq level configuration language in terms of obscurity. Cryptic error messages the severity of which is impossible to infer (actual impact being from no impact whatsoever to my computer won't boot anymore). Not my favorite piece of Li…

It's pretty well documented with a pretty simple configuration language (if you already use a bourne shell (and you probably do), you already know how GRUB's syntax works). I guess reading the manual isn't popular these days, but GRUB has a complete one that explains it all.

> has a complete manual that explains it all.

So does quantum field theory, which, as a matter of fact, has many manuals.

Doesn't mean either QFT or grub are understandable or even usable by mere mortals.

Difference being than in the case of grub, given what is does, the complexity and opacity of the manual, config languages and diagnostics message is completely unnecessary.

Re: It's far from clear how grub package updates work on Ubuntu

#26
So assuming your machine supports UEFI, what are the common use cases that systemd-boot would not support, requiring you to use grub?

Encrypted boot partition I'd guess? I tried that once with grub, but it was unbearingly slow, because grub did not / could not use modern x86 extensions to do the decryption. So not a common use case either, maybe a desirable one.

Re: It's far from clear how grub package updates work on Ubuntu

#28
post #9

Earlier quoted context omitted.

It's pretty well documented with a pretty simple configuration language (if you already use a bourne shell (and you probably do), you already know how GRUB's syntax works). I guess reading the manual isn't popular these days, but GRUB has a complete one that explains it all.

The point is, GRUB is unnecessary complexity for probably 99.9% of all systems that boot Linux and maybe one other OS.

... can you really fault software that has "Grand" and "Unified" right there in its name for trying to be just that? The number of systems supported by GRUB is really impressive, the number of special-sauce features supported (filesystems, RAID levels, snapshots, etc.) downright staggering. And if you don't like it, there's plenty of alternative, simpler options with a narrowere focus. I use systemd-boot on most non-Debian (which supports A LOT of other platforms, mind you) x86 EFI boxen of mine.

GRUB might be an unnecessary complexity for a number of use cases, but it's a solution that strives towards being universal (which is also a goal of Debian). I think it comes rather close, and I am happy it exists. Learning you way around it for an hour or two will yield payoffs down the road.

Re: It's far from clear how grub package updates work on Ubuntu

#29
post #5

Earlier quoted context omitted.

> The whole thing seems like an accident of history that no one wants to fix I can’t really speak to Fuchsia systems, but a lot (most?) Linux desktop distros use stub or systemd-boot bootloading these days. And if you want to get fancy, there’s rEFInd.

> I can’t really speak to Fuchsia systems, but a lot (most?) Linux desktop distros use stub or systemd-boot bootloading these days. Which ones are you thinking of? Most 'desktop' distros I've used recently still default to Grub (Debian, Fedora, Linux Mint, Ubuntu) though I'd certainly be glad if change is on the horizon.

Arch install script defaults to systemd

Re: It's far from clear how grub package updates work on Ubuntu

#30
post #26

So assuming your machine supports UEFI, what are the common use cases that systemd-boot would not support, requiring you to use grub? Encrypted boot partition I'd guess? I tried that once with grub, but it was unbearingly slow, because grub did not / could not use modern x86 extensions to do the decryption. So not a common use case either, maybe a desirable one.

> So not a common use case either, maybe a desirable one.

it's a literal checkbox install option on Ubuntu at least a few versions back (i'm not up to date), so I wouldn't call it uncommon.

Post reply on HN