Le 06/03/2020 à 18:03, David Michael a écrit : > On Fri, Mar 6, 2020 at 9:02 AM Didier Spaier <did...@slint.fr> wrote: >> Le 06/03/2020 à 13:43, Daniel Kiper a écrit : >>> If we go that way then we have to care about them by the end of the >>> universe. And this means more and more issues like [1]. If somebody >>> wants to use new GRUB then he/she have to reinstall the machine or >>> something like that. IMO we should not care about users who do not want >>> upgrade their machines or whatnot. Or at least their choices cannot >>> impact GRUB development too much. And I think that this MBR constraint >>> is hindering the project too much at this point. So, as above... >>> >>> Sorry for being blunt... >> >> Sorry to be off topic... In case of a GUID partition table, if I >> understand the UEFI specification[1], as the first usable LBA should be >> greater than or equal to 34 for a 512 bytes block size or 6 for a >> 4096 bytes logical block size, it could begin after a gap of 24K. >> >> Then, if we assume that the first partition begins @ 1MiB, can't GRUB >> use the space unused between the first usable LBA and 1MiB instead of >> a Bios Boot partition, in case of "legacy" booting and a GPT? I ask as >> then a Bios Boot partition wouldn't be necessary any more. > > It would be best to use a boot partition so the core.img space is > reserved by the GPT, but I once wanted to tack i386-pc GRUB onto an > existing UEFI GPT disk, so I wrote the commands that do what you're > describing here: > > https://github.com/dm0-/installer/blob/master/examples/systems/fitpc.sh#L151-L178 > > I may be misremembering, but I think the core.img size was limited to > around half a megabyte, so it should be safe to write it to the unused > ~1MiB before the first partition after the GPT. But yes, using the > boot partition would probably be for the best if you are formatting a > new disk.
Thanks for sharing David. This can be useful to allow Legacy booting off a drive initially partitioned for UEFI booting only. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel