Shared publicly  - 
+Kay Sievers and +Harald Hoyer just made their little no-nonsense EFI boot loader public. It's tiny (< 64K), can show a menu, discovers all kernel configurations automatically (no wacky autogeneration of boot loader scripts), and can chain-load another boot loader if necessary. It doesn't really need any explicit boot loader configuration file at all, and if you want to change the timeout or the default entry you can do that with simple keypresses in the boot loader itself. It's a mini boot loader that just works, is robust and needs zero userspace infrastructure to work. Oh, and as extra gimmick it can pass performance data to systemd so that it can show after boot how much boot time is spent in the BIOS, in the bootloader, in the kernel, in the initrd and in userspace until the system is up.

Given that this code is clean, minimal and small (< 64K) maybe this should be the boot loader that the various distributions get signed for the SecureBoot jumble?

Oh, and the name is just awesome, too: Gummiboot!
gummiboot - simple UEFI boot loader. Simple UEFI boot loader which executes configured EFI images, where the default entry is selected by a configured pattern (glob) or an on-screen menu. Operates on ...
Maciej Piechotka's profile photoBernhard Wiedemann's profile photoMatthew Garrett's profile photoSteven Rostedt's profile photo
gummiboot? And they claim Germans have no sense of humor? ;)

Gummiboot means rubber boat. Hope it will get some attention, I guess a google search for "gummiboot" will not produce too many useful results at the moment. ;)
A multilingual pun! That takes talent.
+Lennart Poettering If it supported the full set of features that we wanted from a bootloader then it'd be an option, but (a) it doesn't and (b) we already have a full time bootloader developer.
As a user, gummiboot's "one simple config file per kernel, configure other bootloader behavior through EFI variables" approach seems REALLY nice.

I can never remember which file to edit to change the kernel command line with grub2.
+Lennart Poettering Oh, right. In that case it's a mixture of doing too much (the shim shouldn't have a menu) and too little (none of the signing code).
+Matthew Garrett Well, the menu code is actually quite short. Might be worth including that anyway... All I am suggesting is to merge the shim approach and this one and you have something that works without any configuration on 95% of all systems, and which would automatically hand-off to grub if it isn't sufficient...
What are the pros/cons comparing to refit/refind?
Does it have serial support? That's a must in my setup.

I'll have to take a peek at it.
+Steven Rostedt It /should/ just need to set the output console appropriately to have serial support. If your firmware is configured the right way it'll happen by magic.
Some boxes have serial support, some don't and some just get buggy if you enable it via BIOS. This is why I just gave up on it from bios and use the grub "serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1" and "terminal --timeout=10 serial console", and things just work.

Note, I do not use grub2, just plain old original grub.
+Steven Rostedt EFI makes the serial interface consistent. The firmware provides the same text output interface on serial ports as it does on a graphics console. It's one case where it genuinely is better than BIOS.
Will MicroSoft sign a bootloader, if it can load everything? Doesn't that somehow circumvent the whole secure-boot idea?
+Matthew Garrett my test boxes are getting old, I don't think they support EFI. And since I don't have companies sending me desktops out of the blue anymore, I haven't been updating those boxes.
BTW, my "newest" test box is 4 years old. If anyone would like to donate a newer desktop to me  to add to my test suite, I'd be much obliged ;-)
Of course that only applies to my x86 test boxes. I have much newer MIPS, ARM, and PPC boards.
Add a comment...