| 
 | 
|  | 
| 
 | 
| This document is available in: English Deutsch Francais Italiano Nederlands Turkce | 
| ![[Photo of the Author]](../../common/images/TjaboKloppenburg.png)  by Tjabo Kloppenburg (homepage) About the author: I've been infected in 1996. Slackware 3.1 :-). I like scripting in languages like Python, Perl, GAWK and so on. And I'm interested in booting devices. Translated to English by: Tjabo Kloppenburg (homepage) Content: | 
| 8cm-Multiboot-CDROM with modified Knoppix linux![[Illustration]](../../common/images/illustration298.png)  Abstract: 
 After reading some linuxfocus articles and other web pages I
    finally found a reliable method to create bootable cdroms,
    booting clean bootdisks (without viruses), single-disk linux
    disks, or an adapted knoppix system. | 
I assume that you have some basic linux knowledge and you know how to burn CDs. You should
    have a cdrom burner that can burn CD-RW, too. That's a good
    thing, because making errors is one of the ways how we learn...
    You should have a CD-RW disk, some 8cm CD-Rs (or CD-RW), and a
    running linux system with some hundred MB free.
    Later - when integrating knoppix - we should have fast network
    access, because we need to install packages from the internet. If
    you know how to setup nfs or samba to provide a local debian
    mirror, you don't need the fast network access. Finally, you
    should have some debian knowledge (install and deinstall
    packages), or a friend / irc channel you can ask. And you
    should know how to use a loopback device.
    
Booting from cdroms is very simliar to booting from a
    floppy disk or hard disk. Something from the disk is read into
    memory by the BIOS and then started. In the early days of
    cdroms they were not intended to be used for booting, so the
    hardware developers had to do some magic: after cooking some
    vendor specific BIOS changes they finally defined the "el
    torito" standard.
    
    It defines a structure on the cdrom containing a bootdisk image,
    and some code in the BIOS to load this structure into memory -
    emulating a floppy disk in memory. After loading the disk into
    memory it boots like every other boot disk.
    
    With this floppy emulation we could build a bootable cdrom with
    a single boot disk image, booting a 1.44MB disk, or one with
    2.44MB. You've never seen such a floppy, but the BIOS can
    handle it. When booting from cdrom we do not need a 2.88 MB
    disk - just a disk image created with the loop device and some
    tools.
    
    A single disk is not yet a multi boot disk. We need a tool to load and
    start other boot images from a file system. Boot-Scriptor is
    our friend. With boot-scriptor we'll boot from cdrom with a
    loader (without disk emulation. that's possible, too), and then
    we'll choose a disk image in a menu. Boot-Scriptor will do some
    magic to load the image into a floppy disk emulation, where the
    image boots like a floppy disk in the drive.
    
    These bootdisks can be images of disks like windoze bootdisks
    of different versions, an NT password changer, mini linux
    distributions, or a knoppix bootdisk to boot a medium size
    knoppix system.
We need a directory with enough empty space to build the
    directory structure of our cdrom. I assume we have plenty of
    space in "/data". The base directory of our
    project may be "/data/mboot". Inside I created two
    directories, "toolcd/" (cdrom content) and
    "/archive" (orginial versions of the tools I use,
    like virus scanners).
    
Get the archive and the INI files from Boot-Scriptor (bootscriptor.org).
     There's no documentation in the archive, you'll
    find it only on the website.
    
    Boot-Scriptor need its own directory "bscript/" on
    the cdrom, with the loader, an optional graphics file (see
    docs), and the file called "bscript.ini".
    This file defines the boot menu in a language like basic, with
    commands like "print", "onkey"
    (branch on key press), and "memdisk" (bootdisk
    image).
    
    Take a look at this small example, and write your own ini
    file:
print "\ac\c0e--=> my multi boot cdrom with linux <=--" print "F1 Bootdisk1" print " w warm reboot" MenuLoop: onkey f1 goto bootDisk1 onkey w reboot warm goto MenuLoop bootDisk1: memdisk \images\boot1.img
There is a bunch of other commands. Make a local copy of the boot scriptor documentaion, and place it somewhere in the directory structure of the cdrom. You'll need this in your early steps to understand the basic commands.
For a first test cdrom we need just a single bootdisk like a
    windoze bootdisk. Or a linux bootdisk created with lilo. Or try
    one of those tiny single-disk linux systems like HAL or
    TomsRtBt (2.88MB). Ask your favorite search engine on the
    web.
    
    We use "dd" to create a disk image file from the disk:
    
( insert disk ) # cd /data/mboot/toolcd # mkdir images (directory for the disk images) # dd if=/dev/fd0 of=images/boot1.img
The program "mkisofs" has to be called with the "-b" option,
    to ensure proper installation of the boot loader. The path of
    the argument of "-b" is relative to the base directory of the
    cdrom ("toolcd/"):
    
# cd /data/mboot
# mkisofs -r -o iso.01 -b bscript/loader.bin \
          -no-emul-boot -boot-load-size 4 toolcd
    bscript.ini" can turn your
    fresh cdrom into something finding its place in the dustbin. So
    better burn a CD-RW :-).cdrecord" has two modes:
    "blank=fast" and "blank=all". The
    fast mode is faster :).dev
    parameter of the burner. Enter "cdrecord -scanbus"
    to see all devices available. If there's no device, you
    probably have to load a device driver module like
    "ide-scsi" with a command like "modprobe
    ide-scsi".# cdrecord -scanbus Cdrecord 1.10 (i686-pc-linux-gnu) (C) 1995-2001 J. Schilling Linux sg driver version: 3.1.22 Using libscg version 'schily-0.5' scsibus0: 0,0,0 0) 'LG ' 'CD-RW CED-8083B ' '1.05' Removable CD-ROM ... # cdrecord -v dev=0,0,0 speed=32 iso.01
The "mkisofs" call has many characters, making
    it easy to forget or mistype something. "cdrecord"
    needs correct parameters, too, so it is a good idea to use a
    script or Makefile to ensure correct command arguments. We'll
    use a Makefile for the "make" command. Install it
    if you don't have it on your system. "make" is one of the
    commands a programmer should know.
    
    We'll place the Makefile into the cdrom dircetory structure,
    linking it into the "mboot/" directory.
   It is a
    good idea to place all things we need for remastering onto the
    cdrom. It makes it possible to create a new, better cdrom even
if you don't have the files anymore on harddisk, so it's a good backup too... :-).
    
    The Makefile can be simple. Here's an example:
    
BASE = toolcd
DEV = 0,0,0
SPEED = 4
VERSION = 01
ISO = iso.$(BASE).$(VERSION)
OPTIONS= -b bscript/loader.bin -no-emul-boot -boot-load-size 4
blank:
    cdrecord -v dev=$(DEV) blank=fast
blankall:
    cdrecord -v dev=$(DEV) blank=all
iso:
    echo "deleting ~ files:"
    @find $(BASE) -name "*~" -exec rm {} \;
    echo "creating iso file:"
    @mkisofs -r -o $(ISO) $(OPTIONS) $(BASE)
    @echo
    ls -al $(ISO)
burn:
    cdrecord -v dev=$(DEV) speed=$(SPEED) $(ISO)
    /data/mboot/toolcd/scripts" is good. We'll
    softlink it into "/data/mboot/Makefile":
# cd /data/mboot # ln -s toolcd/scripts/Makefile Makefile
mboot/" directory:# make blank # make iso # make burn
You'll find more bootdisks in your disk boxes, and in the
    world wide web. But remember that you never really know what's
    on a disk image downloaded from internet. I think it's always a
    good idea to ask a search engine like google, whether someone
    encountered problems using a bootdisk from a site. And run a
    virus scanner over the disks.
    
    I've taken some bootdisks from www.bootdisk.com. The disks are
    english versions, most of them with cdrom support. You can
     access a virus scanner on the cdrom, or to run a bios update
    from another cdrom. I really like the "drdflash" bootdisk
    image, providing a minimal bootdisk with enough space for a
    BIOS flasher. Just use "rawrite" (dos) or
    "dd" (linux) to write the image on a disk, and you
    have a bootable disk for the flasher in a minute. I've been on
    a LAN party and saw how long a group of linux gurus needed to
    find a bootable floppy disk for a BIOS update... :-)
    
    Note: You can find "rawrite.exe" on most of the
    common linux distribution cdroms.
With your tiny and handy 8cm cdrom you've got a tool to boot
    a clean disk everywhere. Why not putting a virus scanner onto
    the cdrom? I've taken "F-Prot" from F-Secure. They have a linux and
    a dos version for free to download.
    
    The only problem is the question about how to update the virus
    definitions on the cdrom. I've heard of 8cm CD-RWs, but I've
    never seen one in a shop. Too bad. Another solution would be to
    boot a minimal linux system from our 8cm cdrom, to download new
    definition files from internet.
    
    Two of the problems I faced with f-prot where:
If you don't know Knoppix by now, have a
    look at it! It is a complete bootable linux system with 2-3 GB
    software on a single 650MB live cdrom. With hardware detection
    and other useful features. But it doesn't fit on our mini
    cdrom.
    Don't cry, because it is possible to remaster the knoppix cdrom
    (or a clone project). You just need some basic debian
    knowledge, and some more space on your hard disk.
    
    Knoppix uses some special magic to put 2-3 GB of software on a
    650MB cdrom: the filesystem has been compressed into the file
    "/KNOPPIX/KNOPPIX", and is mounted by the initial
    init process of a booting floppy disk (*) by using a special
    "cloop" driver module. (* In fact it is the
    content of a bootdisk image file used when calling
    "mkisofs" with the "-b" switch.)
    
    The bootdisk image that has been used to create the knoppix
    cdrom can be found in the "/KNOPPIX" directory of
    every knoppix cdrom: "boot.img". There's again the
    idea to have all genes for the next evolutionary step "on
    board"...
    
    I suggest mounting the knoppix bootdisk image with the loop
    device to try to understand how the boot process of knoppix (or
    linux) works. Search the web for the "bootdisk howto" to find
    more information. One of the files you find on the disk image
    is a ".gz" compressed file with a filesystem image inside. It is
    the initial ramdisk with the ramdisk filesystem used at the
    early moments of boot time.
    
    So when booting knoppix this happens: The "boot.img" file
    written into the iso file loads the linux kernel from the
    emulated floppy disk, loading the initial ramdisk. The linuxrc
    process loads the "cloop.o" driver module, and searches for a
    file "/KNOPPIX/KNOPPIX" on all attached devices with a known
    filesystem. Yes, it should be possible to boot the compressed
    knoppix even from a hard disk. But I've never tested that.
    After finding a device with the compressed filesystem, it
    becomes mounted, and hardware detection and all the other
    things start.
    
    The floppy disk "boot.img" does not care about from where it
    boots (drive, emulated), so it's rather simple to integrate it
    into our multi boot cdrom: copy "boot.img" in the
    "images/" directory, and add a hotkey in
    "bscript.ini".
    
An original knoppix cdrom is much too big for our handy 8cm
    cdrom. Remember: we have 183 MB on a mini cdrom. We need to
    delete lots of stuff, but that's too much work. Why not
    benefit from the project of someone else? The website Knoppix
    Customizations lists a couple of modified knoppix versions,
    some of them minimalized to a compressed size around 50-60 MB.
    I decided to use "Model_k". It is small, but there's no GUI,
    and support for non-english keyboards is missing. Perhaps "Damn
    Small Linux" is better...
    
    I took the instructions you find below  from a
    document by Sunil Thomas
    Thonikuzhiyil, who describes the process of remastering
    very detailed. Read it if you want to know how to change the
    boot kernel or the initial ramdisk of the bootdisk. But
    normally we do not need all that stuff when remastering
    "Model_k" or a similiar system for our mini cdrom...
    
    The basic idea about remastering knoppix lies in the fact
    that knoppix is a full working debian system - when there's a
    writable fileystem [a cdrom is read-only :)]. The main part of
    remastering is the installation and deinstallation of packages.
    Not much magic.
    
    To alter a knoppix we have to boot it first. After that the
    following steps are necessary:
    
# mkdir /1 # mount -t ext2 /dev/hda<n> /1 # cp -Rp /KNOPPIX /1
# chroot /1/KNOPPIX # mount -t proc /proc proc
# (use ifconfig, when there's no DHCP server in your network.) # (change nameserver setup when there's no DHCP. Delete the link "/etc/resolv.conf" and create your own file.)
# apt-get install joe (Model_k 1.2 comes without editor :) ) # ...
# (if you changed /etc/resolv.conf, delete it and add the link.) # umount /proc # exit
/KNOPPIX/KNOPPIX" with
    "cloop". We already know "loop" - we
    use it to mount a filesystem file. "cloop" is a
    "loop" with (de)compression, so we have to create
    a filesystem with "mkisofs", and compress it with
    a special program from knoppix:
    "create_compressed_fs": 
# mkisofs -R /1/KNOPPIX | create_compressed_fs - 65536  > /1/KNOPPIX.2
    
    As you see we pipe the output of "mkisofs" directly into the
    compression tool. Make a copy of your original
    KNOPPIX file, and copy the result file
    "KNOPPIX.2" over "KNOPPIX/KNOPPIX" of
    your cdrom directory structure. Now make and burn another
    cdrom, and try out your "new" knoppix variant. 
    
     
We've seen it's not that difficult to create a handy multi
    boot cdrom, with useful tools on it helping us in different
    situations. We did not invent every wheel, but used wheels
    invented by others, with some extra magic added.
    
    We've put all we needed on that cdrom, so we have a backup at
    hand - and it is possible to remaster the cdrom with just the
data from the cdrom.
    
    I hope you enjoyed my small article.
    
    Bye!
| 
 | 
| Webpages maintained by the LinuxFocus Editor team © Tjabo Kloppenburg, FDL LinuxFocus.org | Translation information: 
 | 
2003-05-01, generated by lfparser version 2.37