grub-netboot

Aktuell

Seminare

Reports

Homepage

Software

draheim

@informatik.hu-berlin.de

Reports

-

postindustr.CC

-

XML/Ti Report

-

pTA StudienArbeit

.

-

sch_llf study

-

Geschichte des PC

TechDocs

-

Perl Objects

-

Installing Oracle

-

shell cmds in python

-

Using css for xml

defs

tricks

-

Unsafe mono

[x]

!

-

Docbook Manpages

-

Java Bean

Code

rpm-suse

-

schema-mapping

en

ig cv hg re dv ev

zz mk pr

-

java problems

en

lang swing ext gtk jjtree

xul

boot

-

grub-netboot

-

grub-gtk

-

partclone freshmeat

-

partimage links

-

releaseuploader

sitemap

-

guidod-pygtk

sitemap

*offsite link

2005-05-22

(C)

Guido Draheim
guidod

@

gmx.de

generated by

mksite.sh

I am working on a solution to run a tftp server in a network that clients should be able to get the rootdisk from. I want all the possible solutions: a pxe netboot, a floppy disk netboot, an usb stick netboot, a
cdrom netboot, a harddisk netboot from a single cylinder (i.e. stage1.5 grub netbook). That is actually quite a thing to know about. Especially,... when the grub boot menu should be customized to bear a thing
like "install", "update", "backup", "restore", "identify", "memcheck".

Prerequisites

Per default, GNU GRUB ist not compiled with network support. The network support is provided by third-party package "netboot" that can be compiled into classic grub (i.e. pre 2.0). Therefore, one does first need to
get the source tarball. On a suse system the following might help:

rpm -Uhv /media/cdrom/suse/src/grub-0.92-69.src.rpm
# i.e. /usr/src/packages/SOURCES/grub-0.92.tar.bz2

Each netboot grub should know its network card type that it is being compiled for. And not every possible network card is being supported - you need to check the netboot web database to check out compatibility.
(Actually, I had problems with a grub netboot floppy that contained almost all network card drivers - only using a specific floppy image for that card type did help).

There are many way to detect the hardware type of a card. Perhaps just use an all-in-one bootfloppy and have a look at the screen what gets detected. In one case I was just looking at the ms windows network
configuration for the card type. The netboot database can even map most pciprobe vendor/model numbers to intelligible product names. Or, do some trial-and-error - there is vast number of products but the number of
hardware designs is very small compared to that.

Compiling

The GNU GRUB is plain autoconf, so just type "configure --help" to see the available "--enable-xx" options. Many of them are related to network card models that should be enabled in the sources. Recompile the tarball
after selecting a bunch of "enable"d optios. When done, you should be able to find "stage1" and "stage2" and perhaps some "stage1.5". Perhaps just "make install DESTDIR=/tmp/usr/". The manual creation of a floppy
disk can be done like

dd if=/tmp/usr/lib/grub/stage1 of=/dev/fd0
dd if=/tmp/usr/lib/grub/stage2 of=/dev/fd0 seek=1

portal.suse.com/sdb/de/2003/02/fhassel_grub_net.html

Menu.lst

When running a grub netboot floppy disk, you have to set most of the boot variables manually, i.e.

ifconfig --address=192.168.0.2 --mask=255.255.255.0 --server=192.168.0.1
root (nd)
kernel /linux insmod=e100 install=ftp://rpm-mirror/pub/
initrd /initrd
boot

That processing can be optimized. The menu.lst is officially a menu but in reality it is more like a batch file. That batch file can be subdivided into multiple sections - each section starts with a "title" tag. The execution of
a menu.lst starts on the first line and executes each command until the first "title" is seen which is a command to print a menu to the screen. The user can then select to jump right after another "title" section which is
executed. In many cases that section will not return but only if its last line is "boot". Otherwise the gnu grub batch processor will hit a "title" command again which draws again a menu on the screen.

Anyway, the /boot/grub/menu.lst can be used as a model for a network boot by copying it to /tftpboot/menu.lst - that is pretty much it. Now you can reduce the typing on boot to just too lines:

ifconfig --address=192.168.0.2 --mask=255.255.255.0 --server=192.168.0.1
configfile (nd)/menu.lst

Remember that the configfile menu.lst should contain references to "(nd)" in order to reference files on the "network drive". So just replace any "(hd0,x)" in your menu.lst file being compied from a harddisk system
installation.

Menu.lst on the floppy

That is about simple - additionally it allows us to reverse the two commands in that we start loading the "configfile" first which contains a network configuration command like "inconfig" or "dhcp".

mke2fs -m 0 /dev/fd0
mount /media/floppy/
cp /usr/lib/grub/stage1 /usr/lib/grub/stage2 /media/floppy/
cat > /media/floppy/menu.lst
dhcp
gfxmenu (nd)/message
color white/blue black/light-gray
default 1
timeout 8

title SuSE Linux Installation
kernel (nd)/linux insmod=e100 install=ftp://192.168.0.1/pub/
initrd (nd)/initrd

guidod - university - howto boot via network with gnu grub netboot disk

http://www2.informatik.hu-berlin.de/~draheim/boot/grub-netboot.html

1 z 3

2010-03-12 13:35

title SuSE Linux Rescue System
kernel (nd)/linux insmod=e100 install=ftp://192.168.0.1/pub/ rescue=1
initrd (nd)/initrd
title Booting from local hard disk
root (hd0)
chainloader +1

When done then run "grub" to get to its interactive commandline shell. Type

grub> install (fd0)/stage1 (fd0) (fd0)/stage2 p (fd0)/menu.lst
grub> quit

Build a Floppy Image

cd etherboot-x.y.z/src
make bin32/{NIC name}.fd0
or...
cat bin/boot1a.bin bin32/{NIC name}.rom > floppy.img

There is also a diskless floppy image. That is what? Well, just go ahead and do everything that you would do for a floppy image but run "configure --enable-nic --enable-diskless" during compiling. There should be a
new "stage2/nbgrub" which should be copied to /tftpboot/. That's it. (But remember that PXE does automatically do DHCP, so there is need for "ifconfig" or "dchp" in the menu.lst).

However, that assumes your DHCP sends a boot filename to the client pointing to "nbgrub". In other words, look at your /etc/dhcp.conf (on 10.0.0.1) for a section like:

subnet 10.0.0.0 netmask 255.255.255.0 {

range 10.0.0.128 10.0.0.192;
option routers 10.0.0.1;
option broadcast-address 10.0.0.255;

# GRUB network boot stuff
filename "/tftpboot/nbgrub";
server-name "10.0.0.1";
option option-150 "(nd)/tftpboot/menu.lst";

}

More tips

www.stud.uni-goettingen.de/~dsuchod/ldc/node5.html

describes a few packages for construction of thin-client bootdisks.

Note that it is possible to chainload to another grub. So just let it fetch one menu.lst, fetch a kernel and boot which does nothing else than run a bootmanager that is more sophisticated. There is no description for that on
the net. However, note that any kernel for netbooting needs to be marked specially - the etherboot and netboot projects contain a utility for that.

/www.lug-kr.de/cgi-bin/lugwiki.pl?BootenVomNetzwerk

http://www.mega-tokyo.com/osfaq2/index.php/GRUB

Hardcoding the imageserver (tftp)

To load the network bootfiles the grub boot loader does only ever require a tftpserver adress - after being given its own address but that may come from a different source. Most documentation on the internet describes
how to setup a dhcp server so that it can send the adress of the tftpd image server in response a dhcp request. But it many cases one can not specialize the dhcp configs! So, I want a floppy with a hardcoded tftpserver
address.

i30www.ira.uka.de/%7Eud3/mkgrubdisk/

is a boot disk creator.

It seems that the stage2.netboot is 189700 on my system, and the nbgrub happens to bei as well 189700 bytes. The pxegrub is again 190724. We could not be less obvious that a network bootmanager is a big thing -
probably due to the many network cards that need to be supported. That is all fine for a boot floppy that shall boot from a tftp server. However, I am thinking about having a special bootstage with only one network card
support that could be installed as the stage1_5 and which can boot up into another partition bootmanager (possibly chainload) so that it can work even without a network server. Possible scenario?

According to the grub manual, it is possible to chainload a dos/win partition by the sequence "rootnoverify", "makeactive", "chainload +1". That does effectivly skip all weird behavior and possibly another bootmanager
is being called in sequence. So now, is it possible to have stage1_5 that does have a network stack, chainloader and minimal menu support?

Originally, there is no support for that - the grub "setup" command will check the given stage2 file and call grub "install" with the corresponding stage1_5, and that grub "install" will call grub "embed" with it. Effectivly,
the stage1_5 is only ever responsible to help extracting the corresponding stage2 - it was not meant to live alone. In the case of a network boot floppy we have a stage1_5 for fat and a stage2 in the fat filesystem. The
menu.lst (hey!) is never loaded by stage1_5 but only with stage2. In the case of a network boot the stage2 is network-enhanced - that's pretty much all about it.

The grub documentation is a little bit confusing here: you may compile up a lot of filesystem drivers to be packed all into stage2. But the stage1_5 does not have that. It is truly independent. And the network stack - is in
the stage2. Remember that we have to run some "ifconfig" if there was no bios network helper (or "dhcp" or "bootp"). But commands are part of stage2. So, this is going to get a little tought - one would need to teach
stage1_5 to simply "know" the ifconfig and execute it without the presence of a command shell. Ouch.

guidod - university - howto boot via network with gnu grub netboot disk

http://www2.informatik.hu-berlin.de/~draheim/boot/grub-netboot.html

2 z 3

2010-03-12 13:35

So, skip it? It happens that one of my targets does only have an ntfs partition on the drive - as there is no stage1_5 for that one can not have grub on that drive. More specifically one can not have a stage2/menu.lst on it.
Most of the grub documentation does not tell about it: you can not have a scenario with only grub and only ntfs. You can only chainload an ntfs partion by having a stage2/menu.lst that was drawn from a (dual boot)
linux partition. It always goes to one of the stage1_5 partitions. (grub4dos and grub4all are google hits to have a menu.lst on another stage1_5 partition type).

It is not strictly impossible though - the various netboot or etherboot projects are developing a bios lookalike that can be "burned" as the boot prompt of a pc. However, I guess that we talk about a lot of very lowlevel
assembly stuff here - if them have not done it then me should not try. So, I skip that question to a later pointer in time - I got other stuff to do, man.

Grub Installation

I did always have problems with installing grub on a different partition than the grub-install is living on. The solution comes around with a grub-install option that looks rather unimportant: it is named "--root-directory".
If you know the usual automake compile stuff then you can just read it as the lookalike of a "DESTDIR" for a "make install". It is not sufficient to put a different "root" into the menu.lst, it is not sufficient to put it on a
separate partition, it is not sufficient to tell grub to use that "configfile". Instead you need to tell "grub-install" a different partition.

The grub-install will know check that "--root-directory" looking for the DESTDIR/boot/grub/menu.lst and the DESTDIR/boot/grub/stage2. It may even copy a good stage2 from /usr/lib/grub/*. The grub-install will check
for the filesystem-type of /boot/grub/stage2 guessing an apropriate /usr/lib/grub/*stage1_5. It will then copy the stage1_5 and hardcode the parition number of DESTDIR/boot/grub. Only after this mode d'emploi we find
that the original OS is not needed anymore to let grub be able to boot. One can even delete the original partition - include the removal of a cdrom or floppy disk with its grub-install.

Now, that is the way to make a PC bootable that does not ship with the special grub variant that is being wanted. To get things going, you can "configure && make" the latest grub tarball (or cvs), then install into a
floppydisk or into a destdir'ed staging area that you want to be using for an initrd image (initrd = initial ramdisk). You can take that floppydisk to different computer to put a specialized bootmanager on that drive.
Similarly, you can place an initrd on a network server, use a generic boot floppy that can draw that initrd, and use that initrd to place a specialized grub on the client machine.

Therefore, the intesting thing is about specializing a grub and about creating an initrd. As for the initrd you can also put up some special installer applications on it that is being run via the local "/etc/inittab" of that
ramdisk. That is the way to install a (diskless) client machine - just boot with a generic floppy disk that does a network boot to your local installation server. The initrd wil run the installer and the installer will run a
grub-install somewhen thereby preparing the client machine to be bootable on its own.

The initrd building is a specialized topic however - most will not want to link the applications with gnu libc but instead they link up with busybox libc. That requires some specialized configure options to be done. It has
its own art of making.

InitRD Building

www.linux.org/docs/ldp/howto/Bootdisk-HOWTO/buildroot.html

and jumpstart with

http://www.linux-boot.net/InitRD/Howto/

. but anyway you need at some point to look at "mkinitrd(8)".

Many systems (suse) have a shell script as "mkinitrd" (or "mk_initrd") that will do the necessary stuff for a simple bootdisk derived from the current system. Run " mk_initrd -k vmlinuz -i initrd". Possibly edit
/etc/sysconfig/kernel with INITRD_MODULES="aic7xxx reiserfs". (but that is really suse specific).

http://www.intra2net.com/opensource/diskless-howto/howto.html
and via UML (user-mode-linux) we are left to know that there are some templation projects and gui tools that can help with build rootdisk. Just use

gbootroot.sf.net

or redhat "mkrootfs" or debian "rootstrap". And let us

not forget about

umlbuilder.sf.net/

MKNBI

MaKe NetworkBootable Image - provided by etherboot to help with creating a boot image that is being understood by the boot loader rom of the network cards (or the boot loader roms of etherboot). More details at

www.fli4l.de/german/howtos/howto-netzboot-fli4l.htm

Related Linux Howto Docs

Bootdisk-HOWTO

: How to design and build your own boot/root diskettes for Linux.

Clone-HOWTO

: Describes a setup that allows a machine to boot Linux from BOOTP/TFTP, using the Grub boot loader, and save and restore disk and partition images to and from a TFTP server.

Network-boot-HOWTO

: Explains how to quickly setup a linux server to provide what diskless linux clients require to get up and running, using an IP network.

grub-floppy.sh

guidod - university - howto boot via network with gnu grub netboot disk

http://www2.informatik.hu-berlin.de/~draheim/boot/grub-netboot.html

3 z 3

2010-03-12 13:35