HowTo: Making a bootable ISO w/ miniroot.kmod etc.
Hubert Feyrer
I've asked how building a bootable ISO works now that we have kernel
modules and a bootloader that can load kernels before the kernel,
e.g. for a ramdisk. After some digging, I've managed to fit the pieces
together, get things going[1], and here is a write-up so others that
are intestested don't have to wade through that swamp again.
Old (pre-5.0/current):
* build INSTALL kernel, which reserves fixed space for a ramdisk
image (pseudo-device md, options MEMORY_DISK_HOOKS,
MEMORY_DISK_IS_ROOT, MEMORY_DISK_SERVER=0, MEMORY_DISK_ROOT_SIZE)
* build ramdisk image (done in src/distrib/i386/ramdisks). This uses
crunchgen(1) and makefs(8) to assemble things, configuration is in one
or several "list" files.
* insert ramdisk image into kernel to get an instkernel (done in
src/distrib/i386/instkernel). This is done via mdsetimage(8).
* build ISO with instkernel and bootloderer (done in
src/distrib/i386/cdroms/bootcd). This uses makefs(8) again.
New (5.0/current):
* build GENERIC kernel, which tells there will be a ramdisk, but size
will be detected at load-time (pseudo-device md, options
MEMORY_DISK_HOOKS, MEMORY_DISK_DYNAMIC)
* build ramdisk image as before (in src/distrib/i386/ramdisks)
* build the miniroot.kmod (in src/sys/modules/miniroot). This is an
empty module for a start, which will get the ramdisk appended in
the next step.
* add the ramdisk image to the miniroot.kmod module (done in
src/distrib/i386/kmod). This uses the GNU bintools objcopy(1) to
append the ramdisk into a special ELF section.
* prepare an instkernel that is basically just a compressed version
of the GENERIC kernel (done in src/distrib/i386/instkernel). This
is the same code as before, but for each kernel, variables can be
set to prevent it from getting stripped and a ramdisk image
inserted (MDSET_NOSTRIP.netbsd-GENERIC,
MDSET_NOIMAGE.netbsd-GENERIC).
* build ISO with the instkernel kernel, the miniroot.kmod file, the
bootloader and a config file for the bootloader (done in
distrib/i386/cdroms/bootcd).
Enjoy!
- Hubert
P.S.: I wonder if/how module loading works in a PXE boot environment.
anyone got experiences with that?
[1] g4u 2.4alpha3 is available for testing
http://www.feyrer.de/NetBSD/blog.html/nb_20081122_1744.html
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
David Laight
>
> P.S.: I wonder if/how module loading works in a PXE boot environment.
> anyone got experiences with that?
I wonder about that as well, especially when I use 'boot -i' and
specify that the root filesystem is on a local disk even though the
kernel was loaded from the pxe boot stuff.
I did have some thoughts...
If a kernel.o file were generated during the build (ie do an 'ld -r'
of all the object files, prior to the final link), then it ought
to be possible to use 'ld' to link some modules into a final
fully fixed up kernel image.
Something needs to know about the modules (and any dependancies) in
order to get the initialisation code run. But that can't be too hard.
The kernel build itself might link in some modules (eg the module
loader code!) which could be excluded in specific environments.
David
--
David Laight: da...@l8s.co.uk
Manuel Bouyer
>
> P.S.: I wonder if/how module loading works in a PXE boot environment.
> anyone got experiences with that?
Yes, I got it working once. At the boot prompt:
load tftp:miniroot.kmod
boot tftp:netbsd-GENERIC.gz
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
Hubert Feyrer
>> P.S.: I wonder if/how module loading works in a PXE boot environment.
>> anyone got experiences with that?
>
> Yes, I got it working once. At the boot prompt:
> load tftp:miniroot.kmod
> boot tftp:netbsd-GENERIC.gz
Can we use a boot.cfg file with PXE to put that in?
Or do we have to revert to embedded ramdisks again for that?
- Hubert