[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB 2.06 release

From: Pete Batard
Subject: Re: GRUB 2.06 release
Date: Tue, 20 Oct 2020 21:03:39 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1

Hi Julian,

On 2020.10.20 20:00, Julian Andres Klode wrote:
That's a misunderstanding, nobody would upgrade existing OS to 2.06, you
can't just upgrade the entire bootloader in a stable OS.

We're talking about distro maintainers adding a GRUB bootloader for ISO/image boot. We're not talking about the case of GRUB usage with an installed OS.

In this case there's no upgrade to speak of. Which means that distro maintainers may tend to prefer a stable official dot release as their starting point.

You'd only
upgrade the latest in-development version and cherry-pick fixes to old

Well, I'm not sure what you are trying to dispute here, but the fact is, ditros (right now I know of Unbuntu 20.10 and Rescuezilla, and I haven't really tried to look for them) are cherry picking the BootHole fixes and applying them to older dot releases, because there is no official dot release that integrates these fixes. And that *is* creating issues, no matter how you look at it.

This has the consequence of actually breaking BIOS boot for ISO -> USB
conversion utilities like Rufus (disclaimer: I am the author of Rufus),
since we need to provide a matching core.img during conversion, that doesn't
exist on the ISO, and obvioulsy the one we provide which was compiled around
the time of release does not include the BootHole fixes, and will therefore
typically fail with "symbol 'grub_calloc' not found".

I don't understand. Just compile a new one with the cherry-picks?

But that's the issue: Now I have to *guess* the cherry picks that these maintainers might have chosen, because, in the absence of an official release, it's a free for all with regards to what patches maintainers decide they want to apply on top of their base (which can generally be assumed to be a dot release). So it becomes a complete lottery. I can't go around hunting every distro to see what patches they cherry picked by their maintainers. And that's where having an official dot release helps, because distro maintainers will naturally migrate to the full patchset and there's no guessing involved.

? Sounds
weird though, you need to keep core.img around for every possible ISO
you want to build against?

Pretty much [1]. For the ISO -> USB conversion process, in non DD mode (and for BIOS mode), I need to provide a core.img, since that's not something that can be derived from the bootloader that's being used for optical boot, since, for one thing, it'd tend not to include the modules for MBR/GPT partition or FAT/NTFS file systems, which we need. So, to keep the application small as well as address the occasional distro maintainers having applied a custom patch on top of a dot release to do something specific for their distro, I have to go through a "detect GRUB version and locate a matching core.img on our server" in the Rufus application, so that BIOS mode can work.

And before someone states "Well, most of these ISOs should be ISOHybrid, so why don't you just write them in DD mode and avoid this whole mess?", you may want to spend some time looking on social media sites to find out how a non insignificant amount of Windows users are utterly bewildered with seeing either their USB drive "disappear" (on account of being converted to a file system that Windows cannot natively mount) or reduced to a couple MB (on account of only the ESP being reported by Windows) after writing it in DD mode, and ending up not running GNU/Linux as a result, because they believe that their media was not created properly. This is why Rufus, while giving the choice of writing in ISO or DD mode for ISOHybrid, recommends ISO mode as a default of people who don't know which one they should pick, as, notwithstanding of the BootHole issue, it usually just takes a small core.img download to get it working. But that means we needs a whole slew of core.img's to work with the various versions of GRUB that various ISOs may use, and the new BootHole vulnerability is throwing this whole matter into further disarray, as, with the lack of an official dot release that includes the BootHole fixes, maintainers have taken upon themselves to cherry pick some of these fixes and update "older" GRUB versions in a manner that makes then incompatible with the core.img we provide.

All in all, an official dot release with the BootHole fixes, *soon*, would avoid this whole mess as maintainers, a lot of which don't appear to be keen on working with an in-development source that they consider as "potentially unstable", would naturally upgrade to a dot release with the BootHole fixes if there was one. Hence my request to see if this can be sped up somewhat.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]