Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

utcc.utoronto.ca

Post reply on HN
Print view View original

41–50 of 69 posts

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

#41

Post by Brian_K_White »

c0l0 wrote: post #28
userbinator wrote: post #21

Earlier quoted context omitted.

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-…

I think it's fair to wonder, if the job is that varied, then was it ever the correct design approach in the first place to presume to ever be able to predict and handle the unpredictable infinite permutations?

This is init vs systemd. 50 years ago, they could not predict all the crazy infinite things a unix system would want to do. And yet they made a system that handled it all possible needs by knowing enough to avoid making assumptions about the infinite other end users or the infinite future. They knew the most important thing which was not to pretend to know the unknowable.

They made a simple base framework and a toolbox, and everyone was able to serve their own crazy individual needs, still 50 years later.

And it still works. Systemd did not need to come along to fix some deficiency, it just came along anyway because for every wise engineer there are 10 clever engineers, and after 50 years of rapid growth the population of linux admins is less than 1% people that know how to reject a shiny new bad idea and 99% kids who do not. Plus of course a few huge businesses who just want that kind of appliance system for their own business reasons and don't care one turd about engineering or empowering the end user or anything like that outside of their own walls.

It's at least fair to look at grub2 and wonder if it's not just a huge self-inflicted wound from trying to deny the undeniable.

Maybe it should be something more like a library of smaller scope scripts that the end user uses a bit more manually.

The common cases can still be handled automatically so no change for 99%, the uncommon but known cases the user can configure their system to use something from the library for that situation, and totally new unknown situations are simpler to handle by writing a new script or adapting an existing one, because the framework is fewer layers and less indirect.

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

#42

Post by [deleted] »

chungy wrote: post #9
ur-whale wrote: 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.

[deleted]

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

#43

Post by Macha »

usr1106 wrote: 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.

> 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

Isn't it deliberately slow to resist brute forcing? At least at one point, the default number of rounds in cryptsetup was decided by counting how many rounds it could do in 10s as part of the setup process on your specific machine

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

#44

Post by shuvuvt5 »

WWLink wrote: post #14
jorvi wrote: 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.

Actually, with refind being a thing, I'm not sure why grub is still a thing. Also why MS' bootmgr stuff is still a flaming pile of junk. Edit: And why MS has never given us a way to dictate where it installs its junk and/or to not install its junk!!!!!!

Windows is a bit better these days, if you create an EFI partition it'll just use that even if you've made it much larger than it normally creates for itself.

This means you can just partition everything from Linux and then install windows safely into where you select.

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

#45

Post by kstrauser »

Macha wrote: post #43
usr1106 wrote: 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.

> 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 Isn't it deliberately slow to resist brute forcing? At least at one point, the default number of rounds in cryptsetup was decided by counting how many rounds it could do in 10s as part of the setup process on your specific machine

You want key operations to be slow for those reasons, but not the encryption once the key is unlocked.

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

#46

Post by magicalhippo »

userbinator wrote: post #2

It's far from clear how grub works. IMHO it contains enough functionality (filesystem access, user interface, program execution, etc.) that it could already be considered an OS itself.

> it contains enough functionality [...] that it could already be considered an OS itself.

That's what ZFSBootMenu[1] is, an OS to start the OS. And as sibling points out, if you're using EFI you got an OS booting your OS booting your OS...

[1]: https://www.zfsbootmenu.org/

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

#48

Post by brnt »

usr1106 wrote: post #33
serf wrote: post #30

Earlier quoted context omitted.

> 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.

For root partition sure. But for boot? Normally when you choose an encrypted root partition you get an extra boot partition without encryption. Unless that has changed rather recently.

Depends on the distro. openSuse encrypts all, and has (or had?) slow boot as consequence. I think Tumbleweed just switched away from Grub.

The theory is that messing with boot can compromise your system and leave you vupnarable despite encryption.

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

#49

Post by k8svet »

brnt wrote: post #48
usr1106 wrote: post #33

Earlier quoted context omitted.

For root partition sure. But for boot? Normally when you choose an encrypted root partition you get an extra boot partition without encryption. Unless that has changed rather recently.

Depends on the distro. openSuse encrypts all, and has (or had?) slow boot as consequence. I think Tumbleweed just switched away from Grub. The theory is that messing with boot can compromise your system and leave you vupnarable despite encryption.

I mean, something still accepts your password that's unencrypted. The solution for this is, yay I get to say it, Secureboot.

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

#50

Post by rcxdude »

andrewstuart wrote: post #8

One of the areas of Linux that I slunk away from defeated is understanding grub and the boot process in general for Linux. Either I am stopid or it is stopidly complex or both.

Grub is just unnecessarily complicated. Simpler options exist (even ones with the same level of flexibility, though I am most familiar with embedded options there: Something like barebox shows an alternative approach that could be applied to desktop: basically just make a shell environment in your bootloader to script your more complex requirements). But 90% of users nowadays can just use systemd-boot.
Post reply on HN