On Wednesday, June 24th, 2026 at 15:23, Przemek Klosowski via devel
<[email protected]> wrote:
> On 6/24/26 12:21 PM, CS Sushi Man via devel wrote:
> > write a simple boot loader, that loads the kernel
> > into RAM directly from the hard drive, *without using any
> > filesystem.* It would do this by baking an offset into the binary,
> > which the program can then use to load the kernel image from a
> > location on the hard drive.
>
> Yeah but the kernel is likely to be written across non-contiguous blocks
> on the filesystem, and then you need to keep the ordered list of all the
> consecutive blocks. You also need the same for the initrd. And it would
> have to be done on every new kernel install.
>
> Your proposal amounts to rewriting GRUB.
>
> --
Is it not possible to dedicate the first 100K or so odd blocks to
store a contiguous packed image (sort of like a SquashFS, but not
an FS)? And if need be, encrypt & sign it? I think a tool can be
written that will accomplish this task on the userspace side. This
will fix the problem of a non-contiguous kernel/initrd on the hard
drive, since everything will be stored without a filesystem to
scramble everything in the first place.
Note that I do not know how the kernel loads an initrd image, or
whether that requires a FAT/EXT file system or not (although I'm
pretty sure the kernel loads the initrd by using the primary EXT
file system on the hard drive).
I believe that most of the boot process can, and should be
handled by the kernel, since it contains so many drivers in one
package. I don't actually know how GRUB passes kernel parameters,
but if there isn't a way as of now to pass parameters via loading a
set of blocks off the hard drive, I'm sure a change in the kernel
can be made to address this. Again, I don't have much experience
with kernel development as of yet, so I don't know how easy or hard
making this change would be.
If this is done right, rewriting GRUB will not be necessary, and
can be entirely avoided.
- C. S. Sushi
Sent with Proton Mail secure email.
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
