On Mon, Oct 19, 2020 at 05:30:41PM +0100, Pete Batard wrote: > Hi Daniel, > > On 2020.07.29 18:46, Daniel Kiper wrote: > > I think this link [1] will explain my long absence... Sorry about that. > > > > I am going to go back to GRUB work next week. I will triage all the patches > > and take all (obvious) fixes. Then I will release rc1 ASAP... All new > > features > > will be taken after 2.06 release. > > > > Daniel > > > > [1] https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00034.html > > Just wanted to mention that the 2.06 release (btw, is GRUB jumping straight > from 2.04 [1] to 2.06 then?) delay with the BootHole fixes is starting to > create some issues as folks (e.g. Rescuezilla) have started to take upon > themselves to cherry pick from the BootHole patches and apply them to things > like GRUB 2.02, instead of simply upgrading to a new official release, that > would include these fixes.
That's a misunderstanding, nobody would upgrade existing OS to 2.06, you can't just upgrade the entire bootloader in a stable OS. You'd only upgrade the latest in-development version and cherry-pick fixes to old releases. > > 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? Sounds weird though, you need to keep core.img around for every possible ISO you want to build against? -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
