[Prev][Next][Index][Thread]

Re: mkbsdimage

> From: "Jim Long" <longj@oit.edu>
> To: "Mike Hibler" <mike@fast.cs.utah.edu>, <oit_student@yahoo.com>
> Cc: <oskit-users@fast.cs.utah.edu>
> Subject: Re: mkbsdimage
> Date: Wed, 11 Apr 2001 11:17:34 +0100
> 
> Hi Mike,
> 
> Just to let you know what is going on over here at OIT, we are using the
> OSKit kernel for as a platform for development in our Operating Systems
> course.
> 
> The ideal situation would be to build a kernel that could be booted on a
> stand alone machine. Is it possible that we could use net-boot on a machine
> that is running over a local loop-back adapter with no NIC installed?
> 

Well, you can put any OSKit kernel you want on a GRUB boot floppy (as long
as it fits), it doesn't have to be netboot.  Netboot is just the most useful
for a couple of reasons:  1) it can boot arbitrary-sized other OSKit
(multiboot) kernels, and 2) it remains resident up in high memory while
your kernel runs.  #2 is the big win, especially in the environment you are
talking about.  The ideal scenerio is:

	you stick in your netboot floppy and boot the machine,
	the machine comes up to the netboot prompt,

	over on your development machine "foo" you build your OSKit kernel,

	to the netboot prompt you type: "foo:/users/mike/oskit/kernel",
	and it load and runs your kernel,

	when your kernel exits/crashes/whatever, control returns immediately
	to netboot, it doesn't reset the CPU and go through the BIOS
	memory test, SCSI device searches, etc.  You are immediately ready
	to try again,

	you go back to the development machines, make whatever changes
	and try again.

The benefit is the quick turn around.  Before netboot, we would boot the
machine into BSD, rcp/ftp over an OSKit kernel to the filesystem, reboot
the machine to run the OSKit kernel, reboot the machine back into BSD to
try again.  If your OSKit kernel happened to trash the filesystem, you
were screwed.

Obviously, netboot only works well if your kernel doesn't overwrite netboot
where it is hiding in memory and if it doesn't screw up HW beyond the
ability of netboot to reset it, but in practice it works well.

But netboot does require that you have a network interface in the test
machine and that requires a certain degree of trust of the OSKit kernel
maker or requires that you firewall the test machine heavily (or both).

> Explain a bit more to me about your PXE boot loader. I have a bit of
> resource here and would be willing to look into this a bit. What is used for
> this environment and how might I go about setting up a similar thing here?
> 

PXE is Pre-eXecution Environment or something like that.  It is a "standard"
that Intel came up with for booting over the net.  It requires support in
the NIC's BIOS.  Using the NIC's BIOS, you can force a PC to load a program
from the network rather than loading a boot block from floppy or hard disk.
However, the execution environment of the downloaded program is rather
austere, so we just use PXE to load a very simple boot program (pxeboot
which is in the OSKit distribution in the boot/pxe directory) which contacts
a server to find out what to do.  The choices are, boot from a specific
partition on the disk or use TFTP to load a specific file from another
machine.  Note that there are applications out there that use PXE to provide
much more sophisticated remote managment of nodes, for example Rembo
(http://www.rembo.com/rembo/).

Anyway, using PXE is another way to load a kernel over the network.
So you have to have not only a NIC, but the right NIC that supports PXE
(we use Intel EtherExpress Pro+ cards)  Probably no advantage for you here.

For more info on our network testbed setup see http://www.emulab.net.

> It is also possible that we boot from a linux based loader. What are the
> possibilities here?
> 

Yes, there is mklinuximage which IS known to work.  It allows you to load
an OSKit kernel using LILO.
Follow-Ups: