Yes, thats exactly the use case: I always have multiple linux
installations (ubuntu and fedora) in two seperate partitions. To stay
compatible with their individual kernel and grub updates, I always
install a second GRUB into the root parition of the specific linux
installation. In MBR I have a master GRUB to select the linux system
(partition) to chainload the second GRUB of that distribution. For this
use case I need GRUB to be installed into ext4 of the root partition of
that linux system.
On 13/03/2024 at 11:25, Mate Kukri wrote:
Do you have a proposed use-case for this in mind?
On MBR disks there is usually enough space for core.img before the
first partition.
On GPT you can simply create a so-called "BIOS boot partition" to
store core.img.
A use case could be when you do not want to install the GRUB boot image
in the disk MBR as the primary boot loader but in a partition boot
sector as a secondary boot loader.
On Wed, Mar 13, 2024 at 10:22 AM Dr. Tilmann Bubeck
<tilm...@bubecks.de> wrote:
I would like to propose a change to GRUB to allow embedding
(fs_embed)
of core.img for ext2/3/4 into the
filesystem. This allows the installation of GRUB into ext2
without the
need to use (unsafe) block lists.
It will be realized using the ioctl(EXT4_IOC_SWAP_BOOT)
introduced into
Linux 3.10 in 2013. This ioctl basically swaps the data blocks
of the
associated file with the EXT2_BOOT_LOADER_INO inode. After using
the
ioctl the code of core.img is stored in the BOOT_LOADER incode
of the
filesystem and it is not accessible to file system tools
anymore. This
ensures, that the boot code is safe and installation into a
partition is
possible.
What would you think about this proposal. Are you willing to
integrate
this, if I develop this for GRUB?
Changes will be done mainly in setup.c and ext2.c
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel