Re: Idea: Improve ext2 to allow for embedding
Am 13.03.24 um 16:31 schrieb Pascal Hambourg: On 13/03/2024 at 16:18, Dr. Tilmann Bubeck wrote: 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. Alternatively, the primary GRUB can load a secondary GRUB core image file /boot/grub/i386-pc/core.img with the "multiboot" command to avoid relying on block lists. Yes, there are many ways to chainload a second GRUB. As fs_embed is already implemented for btrfs I thought it would be good to be available for ext2 as well. So question is, if this should be done (I am willing to do so) or if grub-devel is not interested in this. This is why I ask first, before doing the work. :-) Thanks. :-) ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Idea: Improve ext2 to allow for embedding
On 13/03/2024 at 16:18, Dr. Tilmann Bubeck wrote: 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. Alternatively, the primary GRUB can load a secondary GRUB core image file /boot/grub/i386-pc/core.img with the "multiboot" command to avoid relying on block lists. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Idea: Improve ext2 to allow for embedding
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 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
Re: Idea: Improve ext2 to allow for embedding
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 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
Re: Idea: Improve ext2 to allow for embedding
Hello, 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. But in either, BIOS is a legacy platform, so I doubt many new users of this would emerge. Best regards, Mate On Wed, Mar 13, 2024 at 10:22 AM Dr. Tilmann Bubeck 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 > > Kind regards > Tilmann Bubeck > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Idea: Improve ext2 to allow for embedding
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 Kind regards Tilmann Bubeck ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
