Re: GRUB 2.06 release

[Pete Batard]

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

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.

Regards,

/Pete

[1] https://github.com/pbatard/rufus-web/tree/gh-pages/files