It's far from clear how grub package updates work on Ubuntu(utcc.utoronto.ca)
utcc.utoronto.ca
It's far from clear how grub package updates work on Ubuntu
https://utcc.utoronto.ca/~cks/space/blog/linux/UbuntuGrubUpdateConfusion
68 comments
> 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. And if you want to get fancy, there’s rEFInd.
systemd’s efforts in the boot path are very welcome, they’re much better. Sadly as others have noted, a great many distros are still using grub.
To clarify a bit too, as it seems it may not have been clear: grub was never run or installed inside a fuchsia system, I was building disk images from Linux hosts.
To clarify a bit too, as it seems it may not have been clear: grub was never run or installed inside a fuchsia system, I was building disk images from Linux hosts.
Isn't rEFInd a Hackintosh thing? That's the context I hear about it in, anyway.
> 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.
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
I didn't know systemd had its own bootloader. I thought everything was still GRUB, I think all my systems are GRUB.
Course I'm a few years out of date
Course I'm a few years out of date
Pop!OS has systemd-boot on systems with UEFI
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!!!!!!
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.
This means you can just partition everything from Linux and then install windows safely into where you select.
This is the reason why I disable all non windows drives in my machine before letting any Microsoft installer do its things.
Don't forget Syslinux[0], available for both legacy BIOS systems as well as EFI. All binaries except for the really low level stuff are in ELF format, so can be generated, linked and manipulated by tools which support this.
[0]: https://wiki.syslinux.org/
[0]: https://wiki.syslinux.org/
Fwiw I've had pretty good experiences with getting LLMs to do the gruntwork of porting Bash to Python in my case. It's a translation task after all.
I threw the code away again in the end. We didn't have that much of a need for non-UEFI targets, but I was experimenting at the time with booting on some cloud x64 machines that lacked UEFI support.
If I had to do it again, I'd probably just write a loader myself. It took about the same amount of time to fight grub as it would have done to smush together a basic GPT / FAT / jump chain.
If I had to do it again, I'd probably just write a loader myself. It took about the same amount of time to fight grub as it would have done to smush together a basic GPT / FAT / jump chain.
> 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 Linux software by a very large margin.
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 Linux software by a very large margin.
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.
I guess reading the manual isn't popular these days, but GRUB has a complete one that explains it all.
Configuration in Bourne Shell is already a bad idea, documented or not. Add on top of it is that there isn't really a configuration... you edit some files (multiple!) then you need to know to run some other script, that on different distribution of Linux will be called differently (if it at all exists) to generate this configuration from another configuration. And the added bonus is that this script will also sometimes run when upgrading some (typically completely unrelated) packages, and if you were so naive as to try and edit the configuration w/o running the script, your changes will be undone without warning.
Configurations are supposed to use a languages that is just powerful enough to express it. The more declarative the better. Shell is a very bad configuration language because it allows to do way too much and is very forgiving of errors.
Now, add to this that GRUB installation is trying to do configuration too... and if you are doing stuff like creating VM images or similar, where you have to install packages in an environment that's not a real physical computer with a bunch of periphery attached, you will run into all sorts of problems (because for some reason GRUB wants to have a PTY and a bunch of other devices / pseudo-filesystems that it has no business sticking its fingers into) and if you aren't present at the keyboard during package upgrade / install you might not even notice that GRUB has failed to install / install correctly.
Configurations are supposed to use a languages that is just powerful enough to express it. The more declarative the better. Shell is a very bad configuration language because it allows to do way too much and is very forgiving of errors.
Now, add to this that GRUB installation is trying to do configuration too... and if you are doing stuff like creating VM images or similar, where you have to install packages in an environment that's not a real physical computer with a bunch of periphery attached, you will run into all sorts of problems (because for some reason GRUB wants to have a PTY and a bunch of other devices / pseudo-filesystems that it has no business sticking its fingers into) and if you aren't present at the keyboard during package upgrade / install you might not even notice that GRUB has failed to install / install correctly.
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.
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.
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.
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.
"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."
If you want to you can always run something like Devuan. You don't have to shit on other projects or people to run the software that you want.
If you want to you can always run something like Devuan. You don't have to shit on other projects or people to run the software that you want.
Sure if I want, I can indeed run anything at all, including that. What's that got to do with anything?
The observation of majority linux and systemd and unix design principles remains a fact regardless what I happen to run. Even if the only thing I happen to run is freebsd which has no such problem. "you can run ..." is both true and irrelevant, doesn't change a thing.
Another thing I can do if I want to, is observe something and describe what I see, even if someone like you doesn't agree, and has no better way to handle that than to suggest the speaker should do something else besides speak their mind rather than actually argue or counter any of the points. (Everyone including me already knows the sales pitch for systemd, it's unlikely you have any argument that I don't already know, this is very much a religious issue at this point, as in there is no actual changing of anyone's minds on either side)
You like systemd and don't like hearing blasphemy criticizing it? Tough shit!
The observation of majority linux and systemd and unix design principles remains a fact regardless what I happen to run. Even if the only thing I happen to run is freebsd which has no such problem. "you can run ..." is both true and irrelevant, doesn't change a thing.
Another thing I can do if I want to, is observe something and describe what I see, even if someone like you doesn't agree, and has no better way to handle that than to suggest the speaker should do something else besides speak their mind rather than actually argue or counter any of the points. (Everyone including me already knows the sales pitch for systemd, it's unlikely you have any argument that I don't already know, this is very much a religious issue at this point, as in there is no actual changing of anyone's minds on either side)
You like systemd and don't like hearing blasphemy criticizing it? Tough shit!
The complexity of GRUB isn't justified by the number of systems it has to support. The number of supported systems is also not the reason why GRUB is so complex. The cause of complexity is poor design choices, if you can even call it that, when it comes to configuration and defaults.
It doesn't matter that better options exist. GRUB is the subject of this discussion. If it were about systemd-boot, then it would've been legitimate to complain about it or to praise it. But, it's not the subject.
But, since you mentioned "other options"... they are both the indication of the larger problem: Linux boot process is poorly designed and that's why many independent teams tried to replace it to variable degree of success. GRUB isn't the only poorly designed piece of this process. And they work to obscure and make even less accessible the subject of system booting for the wider audience, creating a feedback loop where the only few people brave enough to dive in and try to understand it are the people who started way back and usually have very distorted ideas about how their code is used by the layers built on top of it.
The whole of the booting process didn't need to be this complex: it could have fewer stages, fewer utilities that are responsible for different stages, fewer possible boot scenarios, better defined order of device initialization... the list goes on. GRUB is only a part of the larger problem, albeit it's a big part.
It doesn't matter that better options exist. GRUB is the subject of this discussion. If it were about systemd-boot, then it would've been legitimate to complain about it or to praise it. But, it's not the subject.
But, since you mentioned "other options"... they are both the indication of the larger problem: Linux boot process is poorly designed and that's why many independent teams tried to replace it to variable degree of success. GRUB isn't the only poorly designed piece of this process. And they work to obscure and make even less accessible the subject of system booting for the wider audience, creating a feedback loop where the only few people brave enough to dive in and try to understand it are the people who started way back and usually have very distorted ideas about how their code is used by the layers built on top of it.
The whole of the booting process didn't need to be this complex: it could have fewer stages, fewer utilities that are responsible for different stages, fewer possible boot scenarios, better defined order of device initialization... the list goes on. GRUB is only a part of the larger problem, albeit it's a big part.
> 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.
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.
I just want to boot my system and get on with my life. Grub is exactly the sort of thing I aggressively don't want to spend time on.
[deleted]
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. 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.
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.
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.
[deleted]
I shifted to using systemd-boot as default years ago and don't look back.
Granted, prior to Debian Bookworm I had to roll my own initramfs- and kernel-hooks, but there were blog posts and I didn't need to develop them.
I even tried directly booting into Linux EFISTUB, but thats uselessly annoying compared to a proper bootloader.
Granted, prior to Debian Bookworm I had to roll my own initramfs- and kernel-hooks, but there were blog posts and I didn't need to develop them.
I even tried directly booting into Linux EFISTUB, but thats uselessly annoying compared to a proper bootloader.
> 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
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.
One of the use cases is booting into btrfs snapshots automatically. AFAIK systemd-boot still does not support this.
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.
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/
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/
I originally wrote ZFSBootMenu as a reaction to how awful Grub is. I was hacking on the Grub scripts and hitting all sorts of limitations that were just awful to work around (or not possible at all). I used Grub to chain load early versions of ZBM before I had the whole UEFI application build process worked out.
efi joined the chat
Iirc when I upgraded from ubuntu 22 to 23 grub stopped being able to boot my windows drive. I played around with it for like an hour and it just wouldnt work, so now whenever I want to boot windows I have to use the efi boot menu instead which is a good enough solution that I wont spend more time on the problem.
Had a reckoning too with unholy heap of shell scripts that is grub-probe and dracut. At least they don't use M4 preprocessing XD
Linux feels like a jumbled mess, akin to a box of LEGO where none of the pieces fit together. With countless package managers, desktop environments, and distros, etc. it's a chaotic maze of choices. Yet, despite the abundance, usability remains a distant dream. It's frustratingly disappointing, to say the least.
It's about the only game in town though. BSD isn't popular enough and Windows wants to be a cable TV channel
Linux is an OS kernel running everything from toasters to the largest HPC clusters. The user space will differ depending on what you want to do.
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.
Nah, I never understood it. You'd probably be better off writing your own from scratch that does exactly what you want it to do. I've written both MBR and EFI bootloaders, but for MBR it's probably better to copy at least some of the very early boot stuff from somewhere else.
This.. For a moderate somewhat prosumerish user like me, it's these kind of stuff which is why can't have nice things. It used to be the ./configure, make, make install hell which modern package managers and distributions seem to have fixed for most software, now it's this.
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.
barebox can be compiled as EFI payload and used on Desktop systems. The main impediment is packaging it for the OS and scripting the hooks that would write e.g. bootloader spec files on kernel updates.
The lower you go in the stack, the uglier it gets.
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.
20 something years ago, LILO was default on many distros and you had a choice. Not sure how grub took over.
> Not sure how grub took over.
Flexibility.
Flexibility.
LI
LI LI LI LI LI LI LI LI LI LI LI LI LI LI LI LI LI LI LI LI LI LI LI LI LI LI LI
-2 points, yikes.. not sure if if that's 3 angry people that had to deal with LILO not working or 3 people thinking I was just spamming who never had the pleasure of dealing with LILO.
The Boxen.
Speaking of the devil: I just upgraded an Ubuntu install which I hadn't touched for around a month, and after rebooting I'm unable to boot Ubuntu.
It's very odd. Instead of the GRUB menu, only a countdown number shows up on the top-left (5,4,3,..) with an underscore behind it. "5 _". All the rest is black.
When the countdown finishes, the system boots into the (UEFI) BIOS.
If I use the BIOS' boot disk selector, then it also happens both when I directly select the Ubuntu installation as well as when I select the GRUB bootloader.
I hope I'll enjoy the ride.
It's very odd. Instead of the GRUB menu, only a countdown number shows up on the top-left (5,4,3,..) with an underscore behind it. "5 _". All the rest is black.
When the countdown finishes, the system boots into the (UEFI) BIOS.
If I use the BIOS' boot disk selector, then it also happens both when I directly select the Ubuntu installation as well as when I select the GRUB bootloader.
I hope I'll enjoy the ride.
I had great luck with Limene! :)
I assume this person meant to say `Limine'.
It's what I use for dualbooting Windows and Linux. It's really easy to Install, Use & Understand.
https://limine-bootloader.org/
It's what I use for dualbooting Windows and Linux. It's really easy to Install, Use & Understand.
https://limine-bootloader.org/
[deleted]
The "install" scripts and so on are all horribly broken, and extremely badly behaved in terms of grabbing arbitrary stuff from the environment that has nothing to do with your desired target system. Using them for anything other than modifying the current host system is extremely sketchy at best.
I ended up re-implementing the whole process in a pile of bash (it should have been in something else, but I started in bash, and finished there). The slicing up of the bios segment that it does is also unnecessarily fiddly considering how it's all constructed, it would have been far easier to keep those segments in separate files and then you could just write one buffer after another in any language/tool environment you want.
The whole thing seems like an accident of history that no one wants to fix, which would be approximately congruent with all of the tooling in that area of the boot path, partition tools and so on.