Grokking miniroot.kmod etc.
Hubert Feyrer
Hi Andy,
I'm trying to understand how the new world order works WRT loading a
ramdisk from the boot loader, in order to update g4u.
My understanding of the previous system is:
* we make a ramdisk image (ramdisk.fs) e.g. from
src/distrib/i386/ramdisks
* we make a kernel that has options MEMORY_DISK_HOOKS and
MEMORY_DISK_IS_ROOT (and possibly MEMORY_DISK_ROOT_SIZE)
* we put the ramdisk image into the kernel with mdsetimage,
and get a kernel that has the ramdisk
* we then use the regular boot loader to load the kernel and
use the ramdisk image as root filesystem
Now with the new world order, I see a number of bits that I can't fit
together:
* we build a ramdisk image from e.g. src/distrib/i386/ramdisks as
before
* There's src/sys/modules/miniroot which builds/installs e.g.
/stand/i386/4.99.72/modules/miniroot/miniroot.kmod, but it seems
unrelated to the ramdisk image. Is that correct? What's this
needed for, at all?
* for the kernel, I guess the MEMORY_DISK_HOOKS kernel option is still
needed, but instead of MEMORY_DISK_IS_ROOT and esp.
MEMORY_DISK_ROOT_SIZE, MEMORY_DISK_DYNAMIC is needed. Does that make
sense?
* Now, how to fit things together? Where does the ramdisk image come
into play?
* How to tell the bootloader to load the ramdisk after the kernel?
My guess this is done via boot.cfg - is there an example?
What is the /ramdisk.kmod mentioned in boot.cfg.4, is it the
ramdiskbin.fs? Where exactly is this put?
Thanks!
- Hubert
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Adam Hamsik
On Nov,Monday 17 2008, at 1:54 AM, Hubert Feyrer wrote:
>
>
> Now with the new world order, I see a number of bits that I can't
> fit together:
> * we build a ramdisk image from e.g. src/distrib/i386/ramdisks as
> before
> * There's src/sys/modules/miniroot which builds/installs e.g.
> /stand/i386/4.99.72/modules/miniroot/miniroot.kmod, but it seems
> unrelated to the ramdisk image. Is that correct? What's this
> needed for, at all?
to get root filesystem into the kernel.
Regards
Adam.
Andrew Doran
> Now with the new world order, I see a number of bits that I can't fit
> together:
> * we build a ramdisk image from e.g. src/distrib/i386/ramdisks as
> before
> * There's src/sys/modules/miniroot which builds/installs e.g.
> /stand/i386/4.99.72/modules/miniroot/miniroot.kmod, but it seems
> unrelated to the ramdisk image. Is that correct? What's this
> needed for, at all?
We add the ramdisk image to miniroot.kmod as an ELF section:
http://nxr.homeunix.org/source/xref/distrib/i386/kmod/Makefile#15
When miniroot.kmod is first built from miniroot.c, it contains nothing
other than the small code fragment in that file. It's useless until the
ELF object has had the disk image added.
> * for the kernel, I guess the MEMORY_DISK_HOOKS kernel option is still
> needed, but instead of MEMORY_DISK_IS_ROOT and esp.
> MEMORY_DISK_ROOT_SIZE, MEMORY_DISK_DYNAMIC is needed. Does that make
> sense?
Right, MEMORY_DISK_HOOKS + MEMORY_DISK_DYNAMIC.
> * Now, how to fit things together? Where does the ramdisk image come
> into play?
It's in the module!
> * How to tell the bootloader to load the ramdisk after the kernel?
> My guess this is done via boot.cfg - is there an example?
boot.cfg on the install CD:
http://nxr.homeunix.org/source/xref/distrib/i386/cdroms/installcd/boot.cfg.in
The 'load' commands can be given at any time. They are processed after
the kernel has been loaded, but before the kernel has been started.
> What is the /ramdisk.kmod mentioned in boot.cfg.4, is it the
> ramdiskbin.fs? Where exactly is this put?
It should say miniroot.kmod, someone made a mistake.
Andrew
David Brownlee
be any sense in adding a 'loadroot' command similar to
'load' which would load and use a filesystem image rather
than a 'wrapped in kmod' version?
That would allow us to distribute miniroot.fs files, which
are easier for people to modify and can be written directly
to devices or partitions (very helpful for embedded devices).
--
David/absolute -- www.NetBSD.org: No hype required --
Hubert Feyrer
Am 17.11.2008 um Mo, 17. 11 2008, 14:34 schrieb Andrew Doran:
> We add the ramdisk image to miniroot.kmod as an ELF section:
>
> http://nxr.homeunix.org/source/xref/distrib/i386/kmod/Makefile#15
>
> When miniroot.kmod is first built from miniroot.c, it contains nothing
> other than the small code fragment in that file. It's useless until
> the
> ELF object has had the disk image added.
OK
>>
>> * How to tell the bootloader to load the ramdisk after the kernel?
>> My guess this is done via boot.cfg - is there an example?
>
> boot.cfg on the install CD:
>
> http://nxr.homeunix.org/source/xref/distrib/i386/cdroms/installcd/
> boot.cfg.in
>
> The 'load' commands can be given at any time. They are processed after
> the kernel has been loaded, but before the kernel has been started.
OK... I tried to build the ISO in there, but didn't really succeed.
What target to I pass to make in .../distrib/i386/cdroms/installcd to
get an ISO that uses boot.cfg and the module etc.? "prepare" and
"iso_image" give me an ISO that uses an old-school embedded ramdisk.
>> What is the /ramdisk.kmod mentioned in boot.cfg.4, is it the
>> ramdiskbin.fs? Where exactly is this put?
>
> It should say miniroot.kmod, someone made a mistake.
Please check... I'm not sure what the exact point of mentioning this
is, as it's not mentioned in the text at all. Maybe the whole process
should be described somewhere?
Andrew Doran
> >http://nxr.homeunix.org/source/xref/distrib/i386/cdroms/installcd/
> >boot.cfg.in
> >
> >The 'load' commands can be given at any time. They are processed after
> >the kernel has been loaded, but before the kernel has been started.
>
> OK... I tried to build the ISO in there, but didn't really succeed.
> What target to I pass to make in .../distrib/i386/cdroms/installcd to
> get an ISO that uses boot.cfg and the module etc.? "prepare" and
> "iso_image" give me an ISO that uses an old-school embedded ramdisk.
I'm not sure, you'll have to dig around - or maybe someone else can answer
it. I know that you can build the ISO images using build.sh. There is a
target.
> >> What is the /ramdisk.kmod mentioned in boot.cfg.4, is it the
> >> ramdiskbin.fs? Where exactly is this put?
> >
> >It should say miniroot.kmod, someone made a mistake.
>
> Please check... I'm not sure what the exact point of mentioning this
> is, as it's not mentioned in the text at all.
I have changed it to say miniroot.kmod.
> Maybe the whole process should be described somewhere?
It's not of general interest to users or developers so I don't have plans to
do that. A page on the www developer docs could be useful.
Cheers,
Andrew
Hubert Feyrer
>> OK... I tried to build the ISO in there, but didn't really succeed.
>> What target to I pass to make in .../distrib/i386/cdroms/installcd to
>> get an ISO that uses boot.cfg and the module etc.? "prepare" and
>> "iso_image" give me an ISO that uses an old-school embedded ramdisk.
>
> I'm not sure, you'll have to dig around - or maybe someone else can answer
> it. I know that you can build the ISO images using build.sh. There is a
> target.
Digging more, it seems "iso_image" in distrib/i386/cdroms/installcd is the
best thing. BUT it takes a kernel from the "instkernel" dir, which has an
embedded ramdisk. The resulting ISO first boots the kernel, then loads the
/miniroot.kmod (good!), but apparently it still runs the embedded ramdisk.
Of course this situation shouldn't arise in the first place, but my gut
feeling is that a miniroot.kmod should override an embedded ramdisk.
Hubert Feyrer
> Digging more, it seems "iso_image" in distrib/i386/cdroms/installcd is the
> best thing. BUT it takes a kernel from the "instkernel" dir, which has an
> embedded ramdisk. The resulting ISO first boots the kernel, then loads the
> /miniroot.kmod (good!), but apparently it still runs the embedded ramdisk.
That's actually wrong - the kernel is from the "instkernel" dir, but the
kernel in there apparently doesn't get the ramdisk image inserted.
src/distrib is a scary maze...