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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
