On Fri, Jan 25, 2013 at 09:18:50AM +0100, Dr. Tilmann Bubeck wrote:
> The basic problem is, that GRUB needs a safe place to store
> (currently 32k) for its boot loader "core.img". That place should be
> simple to find from the primary boot code ("stage1") and the place
> should be safe for user intervention.
>
> QUESTION:
>
> You have reserved a special inode #5 called "EXT4_BOOT_LOADER_INO".
> Is this inode currently used or supported by kernel or user land?
> What is the idea of this inode?
It was basically for something exactly like this. :-)
> PROPOSAL:
>
> I can think of using that inode to store the file "core.img" of
> GRUB. That file is used by GRUB to boot and the block list of that
> file is stored in GRUB when using "--force" to override the above
> error.
>
> ext2/3/4 must make sure, that the block list of that file never
> changes. I propose an additional EXT4 ioctl to tell ext4, which file
> to store in EXT4_BOOT_LOADER_INO.
What I'm thinking about is a new ioctl that would swap the i_block and
i_blocks array of the BOOT_LOADER_INO and the file descriptor. That
is, if there were any blocks attached to the boot_loader_ino, they
would become attached to the inode associated with the file
descriptor, and the blocks associated with that inode would be
attached to inode #5.
> Probably there must be more changes to e2fsck and friends.
Actually, no changes to e2fsck would be necessary. The original plan
was that boot loader inode would be installed while the file system is
unmounted. But it's already the case that blocks associated with
inode <5> are already accounted for by e2fsck.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
