Hacker News Reader

Comment by nneonneo | Hacker News Reader

Neat - but it’d be nicer to replace that motherboard logo with a Fedora logo or something, so it’s clear when the kernel has taken the reins. Otherwise, people might think that the system is stuck in the BIOS!

Yes, I know the menu disappears - but that’s only going to be true for some subset of BIOSes, and it’s not an indicator that most people would be expecting.

View on HN

Speaking as one of the people who originally implemented the Linux support for the Boot Graphics Resource Table (BGRT) which provides the BIOS logo, here's why both the BIOS and the OS want this:

BIOS vendors support this because otherwise the BIOS boots so fast (with modern system requirements) that they don't get as much branding opportunity.

OS vendors love this because then when you're waiting around for your system to boot, you're looking at the BIOS logo and blaming the BIOS, not the OS.

This crap is why we need coreboot.

Why? The bootloader and OS are free to ignore BGRT entirely and draw whatever they want.

Why?

>BIOS vendors support this because otherwise the BIOS boots so fast (with modern system requirements) that they don't get as much branding opportunity

So that the speed of my computer isn't decided by a marketing team, that's why.

I think you misunderstood. It doesn't affect the speed. The BIOS still boots as fast, but the logo stays up while other things happen.

Ah, I see. Regardless, coreboot is still important for other reasons.

As the other reply in this thread pointed out, this doesn't mean that the BIOS takes longer to boot, it means that the logo keeps showing as the OS boots.

(I would still love to see more open BIOSes, though.)

As pointed out this isn't what happens, but even if vendors did ship Coreboot it'd have the same behaviour (because that's what the vendors want) and you still wouldn't be able to reflash it because they'd still be using Boot Guard. Coreboot isn't some magical freedom enhancing technology that can be sprinkled on a platform to make it respect its users, in the same way that the use of Linux in Android doesn't guarantee any strong user benefits over the iOS kernel.

I think the implication was pretty clear that coreboot plus the ability to reflash your firmware is necessary.

Standard behaviour for Windows 8+ on modern UEFI machines is for the OEM logo to remain.

You know when Windows has started to boot when the distinctive Microsoft spinner appears beneath.

This messed me up for a while when I'd see the windows spinner on an Ubuntu redbrownpurple background

That's because you probably launched windows from a grub bootloader. What windows actually does is just leave up whatever was the last thing drawn on the screen, which for single-OS systems is usually the manufacturer logo.

Perfect description of that color, thanks.

At least there's some "sign of life" from the OS in this case - although I can totally imagine this being a confusing experience for people as well! If it's technically infeasible to replace the OEM logo while avoiding a modeset (flicker), maybe a small spinner or animated logo would do - an animated Fedora logo could look extremely cool there!

They note in the post that this functionality is coming soon:

> 2. Write a new plymouth theme based on the spinner theme which used the vendor logo as background and draws the spinner beneath it. Since this keeps the logo and black background as is and just draws the spinner on top this avoids the current visually jarring transition from logo screen to plymouth, allowing us to set plymouth.splash-delay to 0. This also has the advantage that the spinner will provide visual feedback that something is actually happening as soon as plymouth loads.

That's basically what sbupdate [0] for Arch does, it allows you to set your own bitmap for boot logo (after the vendor logo, of course).

Another benefit of sbupdate (besides Secure Boot) is that it allows running Linux kernel directly as a UEFI executable, no GRUB or systemd-boot needed!

[0]: https://github.com/andreyv/sbupdate

> is that it allows running Linux kernel directly as a UEFI executable

Like rEFInd?

Like rEFInd and System boot and even the inbuilt UEFI firmware of most manufacturers.

> even the inbuilt UEFI firmware of most manufacturers.

I have a <3yo laptop that boots NVME OSes fine, Windows and Linux alike ... except for the Windows feature-upgrade process, which just hangs indefinitely on the OEM logo.*

I also have a desktop whose UEFI firmware doesn't output anything to its PCI videocard, and also refuses to boot at all if anything is connected to its integrated videocard. So getting Linux installed on that silly thing at all, was an exercise in frustration.

I furthermore used to have a little "mini PC" that utterly refused to allow its UEFI boot entries to be modified at all - on top of having no boot-time video output and a soldered-on bootable storage. So I had to abandon and rollback my efforts to install Linux on it, lest I brick it. Brick, an x86-based system. Ugh!

In short, I don't respect manufacturers' UEFI firmware any farther than I can defenestrate their products.

* I would say something about how imaging from a SATA SSD onto an NVME SSD even required a reinstall of Windows, whereas the dual-booted Linux install worked perfectly; but that's probably just Windows being its usual stupid self.

Like rEFInd in the sense that it replaces rEFInd. The kernel itself can be executed by the firmware directly as an EFI application.

Here's the documentation for Kernel's EFI stub: https://www.infradead.org/~mchehab/kernel_docs/unsorted/efi-...

Reply on news.ycombinator.com