Create Bootable Linux CD
Step # 1: Copy boot.iso to /tmp
Type the following command,
# cp boot.iso /tmp
Unmount cdrom
# cd; eject
Step # 2: Insert blank CD R/RW media
Find device name:
# cdrecord -scanbus
Write /tmp/boot.iso to blank cd, enter:
# cdrecord -v -dao dev=1,0,0 /tmp/boot.iso
Replace 1,0,0 with your actual device name obtained using cdrecord -scanbus command. See how to burn ISO images to Cds and CD-RWs under Linux for more information.
This section assumes that you are familiar with the process and workings of writing CDs in linux. Consider this to be a quick reference to include the ability to boot the CD which you will burn. The CD-Writing-HOWTO should give you an in-depth reference.
2.1. What is El Torito?2
For the x86 platform, many BIOS's have begun to support bootable CDs. The patches for mkisofs is based on the standard called "El Torito". Simply put, El Torito is a specification that says how a cdrom should be formatted such that you can directly boot from it.
The "El Torito" spec says that any cdrom drive should work (SCSI or EIDE) as long as the BIOS supports El Torito. So far this has only been tested with EIDE drives because none of the SCSI controllers that has been tested so far appears to support El Torito. The motherboard definately has to support El Torito. How do you know if your motherboard supports "El Torito"? Well, the ones that support it let you choose booting from hard disk, Floppy, Network or CDROM.
Boot modes
According to the El Torito specification, a 32-bit CPU PC BIOS will search for boot code on a ISO 9660 CD-ROM. The standard allows for booting in two different modes. Either the boot information can be accessed directly from the CD media, or in floppy emulation mode where the boot information is stored in an image file of a floppy disk, which is loaded from the CD and then behaves as a virtual floppy disk. It is sometimes useful to have this choice because booting directly from CD-ROM is vulnerable to BIOS bugs, in which case it is better to boot from the floppy image. This mostly affects computers built before about 1999, which were designed to boot only from floppy drive. In fact, for modern computers "no emulation" mode is generally the more reliable method. The BIOS will assign a BIOS drive number to the CD drive. The drive number assigned is either 80 (hard disk emulation), 00 (floppy disk emulation) or an arbitrary number if the BIOS should not provide emulation. Emulation allows older operating systems to be booted from a CD, by making it appear to them as if they were booted from a hard or floppy disk. Newer operating systems do not require emulation to boot; all that is needed is an appropriate boot loader such as3 ISOLINUX from the SYSLINUX project.
现在的启动光盘差不多都用ISOLINUX之类做bootloader ,下面是它的源码，
http://git.kernel.org/?p=boot/syslinux/syslinux.git;a=blob;hb=HEAD;f=core/isolinux.asm
还有El Torito 标准之中，搞清楚的就是当BIOS转到cd rom时，转到了cd的哪一个分区(sector),
对于是硬盘MBR,A master boot record (MBR) is the first sector of a data storage device that has been partitioned. The MBR sector may contain code to locate the active partition and invoke its Volume Boot Record.
回到该标准It was announced in November 1994[1] and first issued in January 1995 as a joint proposal by IBM and BIOS manufacturer Phoenix Technologies.该标准BIOS厂商参与其中，BIOS中有其跳转的指令，和标准。然后光盘厂商跟着做就是了。
具体讲有关BIOS INT 13 源码 http://docs.google.com/Doc?id=ddbccvgr_53hsv34ngz
1. The Normal CD-ROM configuration is not bootable, uses Root Directory and CD-ROM drivers to access CD-
ROM images.
2. A BIOS with Single Boot-Image capability accesses the Initial/Default Entry to access a single bootable disk
image. After loading the operating system, the system can revert to standard CD-ROM drivers and the Root
Directory to access CD-ROM images.
3. A BIOS with Multiple Boot-Image capability can access any one of a number of Bootable Disk Images listed
in the Booting Catalog. After loading the operating system, the system can access other items in the disk
image with standard INT 13 calls or return to normal access of CD-ROM images using CD-ROM drivers and
the Root Directory.
ISO-9660 and the Booting Catalog
One goal of this specification is to maintain ISO-9660 compatibility while providing system BIOSs with a simple way
of getting to the location on the CD that contains the material to be booted. ISO-9660 defines that a “Primary Volume
Descriptor” must reside at sector 10 (16 decimal), relative to the start of the session, followed by any number of other
Volume Descriptors, followed by a “Volume Descriptor Set Terminator.” The El Torito Bootable CD Specification
builds on this format by requiring a “Boot Record” Volume Descriptor as defined in section 8.2 of ISO-9660. See
figure 7 for a description of the Boot Record. This “Boot Record” must reside at sector 11 (17 decimal) in the last
session on the CD. The Boot Record contains an absolute pointer to the Boot Catalog. The Boot Catalog is a
collection of 20 byte entries (as described below), packed 40 entries to the sector. There is no limit to the number of
sectors the Boot Catalog uses. This catalog allows the system to pick a proper boot image and then to boot from the
selected image. The image may be virtualized into INT 13 drive number 00 or 80 for bootable disk emulation, or n+1
for a “non-bootable” emulation, where n is the number of the last hard drive initialized by the BIOS. The image may
also simply be some code which will be loaded at boot time (no emulation). The BIOS will choose a drive number
between 81 and FF when “no emulation” is specified. There are 5 types of entries diagrammed in figures 2-6. These
entries define a validation procedure for the bootable CD, an Initial/Default entry, a section header, a section entry, and
a Section Entry Extension.
INT 13 Function 4A - Initiate Disk Emulation
This function takes a pointer to the Specification Packet and uses it to make the specified drive letter available, using
the Image LBA “pointer” in the supplied packet.
Registers at call:
AH = 4A
AL = 00
DS:SI - Specification Packet as defined in figure 9
Registers on return
AX - Return Codes
CF - Clear if selected drive is emulating
CF - Set if system not in emulation mode
INT 13 Function 4B - Terminate Disk Emulation
This function returns the system to a configuration that matches a normal floppy or hard disk boot. If the CD booted
as a floppy, the “A” drive returns and the CD becomes driver addressed. If the CD booted as a hard disk, the drive
numbers are all decremented by 1, this returns all hard disks to their standard/normal device numbers.
Registers at call:
AH = 4B
AL = 00, Return Status and Terminate Emulation
AL = 01, Return Status only, Do Not Terminate Emulation
DL = Drive number to terminate, 7F = Terminate all
DS:SI - Empty Specification Packet, See figure 9
Registers on return:
DS:SI - Completed Specification Packet, See Figure 9
AX - Return Codes
CF - Clear if system released
CF - Set if system not in emulation mode
INT 13 Function 4C - Initiate Disk Emulation & Boot
This function takes a pointer to the Specification Packet and uses it to reboot the system from scratch. This function
only returns if the supplied packet does not contain a pointer to a bootable disk image.
Registers at call:
AH = 4C
AL = 00
DS:SI - Specification Packet as defined in figure 9
Registers on return
AX - Return Codes
CF - Set if system failed to boot
CF Clear will not occur because when this function succeeds no return is generated.
INT 13 Function 4D - Return Boot Catalog
This function takes a drive number in DL, a command packet in DS:SI, and returns the requested number of sectors
from the boot catalog.
Registers at call:
AH = 4D
AL = 00
DS:SI - Pointer to command packet as defined in figure 8
Registers on return:
AX - Return Codes
CF - Clear if successful
CF - Set if device is not an emulated CD, or command packet is out of bounds
2.2. How it Works
The El Torito standard works by making the CD drive appear, through BIOS calls, to be a normal floppy drive. This way you simply put any floppy size image (exactly 1440k for a 1.44 meg floppy) somewhere in the ISO filesystem. In the headers of the ISO fs you place a pointer to this image. The BIOS will then grab this image from the CD and for all purposes it acts as if it were booting from the floppy drive. This allows a working LILO boot disk, for example, to simply be used as is.
Roughly speaking, the first 1.44 (or 2.88 if supported) Mbytes of the CD-ROM contains a floppy-disk image supplied by you. This image is treated like a floppy by the BIOS and booted from. (As a consequence, while booting from this virtual floppy, your original drive A: (/dev/fd0) may not be accessible, but you can try with /dev/fd1).
2.3. How to make it work 5
First create a file, say "boot.img", which is an exact image of the bootable floppy-disk which you want to boot via the CD-ROM. This must be an 1.44 MB bootable floppy-disk. The command below will do this
| dd if=/dev/fd0 of=boot.img bs=10k count=144 |
Place this image somewhere in the hierarchy which will be the source for the iso9660 filesystem. It is a good idea to put all boot related files in their own directory ("boot/" under the root of the iso9660 fs, for example).
One caveat -- Your boot floppy must load any initial ramdisk via LILO, not the kernel ramdisk driver! This is because once the linux kernel starts up, the BIOS emulation of the CD as a floppy disk is circumvented and will fail. LILO will load the initial ramdisk using BIOS disk calls, so the emulation works as designed.
The El Torito specification requires a "boot catalog" to be created as well. This is a 2048 byte file which is of no interest except it is required. The patchwork done by the author of mkisofs will cause it to automatically create the boot catalog, but you must specify where the boot catalog will go in the iso9660 filesystem. Usually it is a good idea to put it in the same place as the boot image, and a name like boot.catalog seems appropriate.
So we have our boot image in the file boot.img, and we are going to put it in the directory boot/ under the root of the iso9660 filesystem. We will have the boot catalog go in the same directory with the name boot.catalog. The command to create the iso9660 fs in the file bootcd.iso is then:
| mkisofs -r -b boot/boot.img -c boot/boot.catalog -o bootcd.iso . |
Now burn the CD with the usual cdrecord command and it is ready to boot.
How to build a Live distro:
1)
Install your favourite distro to disk partition, or into a folder on your existing system.Slackware is recommended but not required.
2)
Build aufs kernel module and squashfs kernel module (optionally patched to support LZMA)The step above is not required if you use precompiled Linux Kernel from this website
Install kernel modules to the newly installed distro to /lib/modules/`uname -r`/fs/.
Make sure you are running the same kernel you used to compile modules
3)
Remove all unnecessary files (for example man pages and all other files you don't need),to make your Live Linux system as small as possible (this step is optional).
4)
Download Linux Live scripts from this website and unpack it in /tmpRead ./DOC/requirements.txt to find out what linux-live scripts need
Edit .config file if you need to modify some variables
5)
Finally login as root and run ./buildLive distribution's 'directory tree' will be created in /tmp/live_data_1234
where 1234 is a random number
6)
To make ISO image, run make_iso.shTo make a bootable (usb) disk, run bootinst.sh
Working example
If you're just looking for a working Linux Live system, visit www.slax.org
Interesting features of Linux Live scripts
1)
persistent changes
Use 'changes=...' boot parameter to specify persistent changes directory or file. If a directory is used, eg. changes=/some_dir/ and the /some_dir/ is found on some partition on your disk, then all the changes made to the root filesystem will be saved to that directory. This works even if /some_dir/ is on NTFS or VFAT, thanks to posixovl overlay (an userspace filesystem, already included). Important note: if you plan to save changes on VFAT, make sure to modify your distribution's shutdown scripts. It must not execute killall, else posixovl is killed and everything is wrong. Instead, call the cleanup script from /mnt/live/cleanup. If a file is specified for the changes boot parameter, eg. changes=/path/file.dat, and the file has a valid filesystem inside, then the file will be loop-mounted and changes written to it. You may also use changes=/dev/sda1/path/ and changes=/dev/sda1/path/file.dat ... to specify particular device where to look for. Other devices will be skipped (will not be even mounted).
2)
adding modules on the fly
In the ./tools/ directory of Linux Live, you will find 'activate' and 'deactivate' scripts. You may use these two to add and remove additional LZM modules to the root filesystem on the fly, while your Live OS is running.
3)
installable system to disk
As mentioned in the previous section, there exists a script called bootinst.sh (and bootinst.bat) to setup a boot sector to boot Live Linux from disk. If you combine that with persistent changes, your Live distro will behave like INSTALLED, all changes are transparently stored to the boot media (even to USB), and you can still use 'activate' and 'deactivate' commands to manipulate the root filesystem.
Basic Requirements for building Bootable CDs
First, you're going to need a machine pre-installed with a Linux distribution to create the CD on. I'm using Slackware 7.1 on a machine with a HP9100i CDwriter. I installed the cdrecord, mkisofs etc tools. I've had to compile into the kernel all the necessary SCSI options to use the IDE CD-Writer (See the CD Writer HOWTO), plus I have loop file support compiled in. I'd suggest you buy yourself a couple of blank CD-RWs to play with as you're going to be formatting, burning, trying it out ... repeatedly.You'll also need Syslinux. You need Nasm to build it. However, if you're too lazy to do this, all you need is the ISOLINUX.BIN file that is created.
Create a kernel for the CD
Now you need to create a kernel that can load the initrd. I'll assume you know how to build a kernel. All the experimentation here was done with a 2.2.18 kernel. You must compile in initrd support and RAM disk support. I am using the default 4096K RAM disk size. Other things that you'll need are ISO9660 filesystem support, ext2 filesystem support. Once you have this kernel, you need to set the root device on it: eg. Say you've just done a make bzImage
rdev /usr/src/linux/arch/i386/boot/bzImage /dev/ram1
NB: If you don't have a /dev/ram1 on your system, create one with:
mknod -m 640 /dev/ram1 b 1 1
Create a directory tree
You need a bit of template structure to work with. The layout I have is below:The key directories are:
cdimage/ This is what mkisofs will use to write an image to the CD initrd/ Holds the tree of our initrd filesystem root/ Holds the tree of our real (final) root filesystem If you download my bootkit, it lays everything out in this structure.
Setting up initrd
The INITRD phase has a simple goal ; Get a real root filesystem into /dev/ram1. I've actually tried a lot of different alternative ways to do this. In order they are:The C based linuxrc is really the best option. Its still quite small and uses a 'standard' for compressed files. Read about the asm one here, and the shell one here.
- Use a little shell script that uses the ash shell to mount the CD, gunzip a rootfs.gz file directly into /dev/ram1 and exit. This requires libc, so the initrd.gz image is about 600k. This is the most straightforward approach ... but the most wateful.
- Use an i386 assembly language program as 'linuxrc' to perform the same task except that I used an alternative compression/decompression algorithm as gunzip was too complex to implement in assembly. linuxrc ends up being about 1k!! and requires no external libraries. This ends up with an initrd.gz of about 10k.
- Use a statically linked C program for linuxrc that uses the gunzip.c source from Busybox as a basis, so that we effectively perform the same task as the shell script. By statically linking with dietlibc the linuxrc actually ends up being smaller than a dynamically linked one against libc 2.1.3!. The total size of linuxrc is about 20k, and the initrd.gz is about 15k.
The basic sequence of events in the C program are as follows:
The last step is simply to exit. The kernel should now take over, and mount /dev/ram1 as /, and try to run /sbin/init.
- Mount /proc
- Open the /proc/ide/ide0/hda/media file. If it says 'cdrom' inside it then we've found our boot CD, otherwise try /proc/ide/ide0/hdb/media, then /proc.../ide1/hdc/... , then /proc.../ide1/hdd/... until we find the first CDROM drive. This undoubtedly limits us to bootable IDE CDROMs on the two standard internal chains.
- Change directory to /dev and create a symlink for 'cdrom' to the newly found CDROM device (eg. cdrom --> hdc).
- Mount /dev/cdrom on /cdrom
- Open /cdrom/rootfs.gz and extract it into /dev/ram1. It must be a gzip of a 4mb ext2 filesystem.
- Mount /dev/ram1 on /ram
- Change directory into /ram/dev and create the same symlink for the CDROM again.
- Unmount /ram, /cdrom and /proc
The linuxrc.c source is here . To compile it you should get dietlibc . Version 0.9 has a 'diet' command that simplifies compiling programs using the new library. You should be able to compile linuxrc.c using: diet gcc -o linuxrc linuxrc.c
The 'Real' root filesystem
You can't do too much with an initrd only system. You really need to create a useable root filesystem. Again, I'm using a 4mb RAM disk, so its a bit of a squeeze (why didn't I go for a bigger RAM disk? I just hate wasting space, and I wanted this to be useable on machines with 16mb of ram or more). I chose Busybox to provide most of my /bin tools. In 0.51 of Busybox, you even get things like vi and wget. Its getting fatter at 250Kb or so these days with every tool compiled in (NB: You can reduce its code size by editing Config.h and commenting out the defines for the tools you don't want), but 250K is fine for our 4mb filesystem. I've put some libraries in too: ld-2.1.3.so
ld-linux.so.2 -> ld-2.1.3.so
libbz2.so.1.0 -> libbz2.so.1.0.0
libbz2.so.1.0.0
libc-2.1.3.so
libc.so.6 -> libc-2.1.3.so
libcom_err.so.2 -> libcom_err.so.2.0
libcom_err.so.2.0
libdl-2.1.3.so
libdl.so.2 -> libdl-2.1.3.so
libe2p.so.2 -> libe2p.so.2.3
libe2p.so.2.3
libext2fs.so.2 -> libext2fs.so.2.4
libext2fs.so.2.4
libm-2.1.3.so
libm.so.6 -> libm-2.1.3.so
libncurses.so.5 -> libncurses.so.5.0
libncurses.so.5.0
libtermcap.so.2 -> libtermcap.so.2.0.8
libtermcap.so.2.0.8
libuuid.so.1 -> libuuid.so.1.2
libuuid.so.1.2Not all of these are really required to get the system up and running. I think some are left over from when I had mke2fs. /bin is just busybox and a sh*#load of soft links. I have an /sbin/init (not linked to busybox, its a real sysvinit). In /etc I have an inittab, termcap and an rc.d directory. Currently I just have an rc.S startup script that is run during the sysinit phase of the init startup. The key parts of my inittab are: id:1:initdefault:
si::sysinit:/etc/rc.d/rc.S
c1:1235:respawn:/bin/sulogin /dev/tty1By using sulogin on the console, I force the user to enter a password (just a space), with the benefit that root's shell starts up in a normal login environment (ie. /etc/profile is run followed by ~/.profile)/etc/fstab looks like:
/dev/ram1 / ext2 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /proc proc defaults 0 0I also have an empty /initrd directory. This means that once that the initrd phase has finished, and the real root filesystem on /dev/ram1 is mounted, the initrd filesystem (on /dev/ram0) is moved under /initrd. This means we can unmount it and free the ramdisk space.
My /etc/rc.d/rc.S script looks like:
#!/bin/sh
PATH=/bin;export PATH
echo "System init"
mount -t proc none /proc
mount -o remount,rw /
echo "Find the extras on the CD and mount it"
if [ -r /dev/cdrom ] ; then
mount -t iso9660 /dev/cdrom /cdrom
mount /dev/hda9 /a
fi
fi
cd /
umount /initrd
freeramdisk /dev/ram0First we mount /proc, and then remount / (remember we have a valid entry for / in /etc/fstab now) as read/write. Now we check if the /dev/cdrom device is there (it should have been created in the initrd phase), then mount the cd. I have a symlink from /usr (in the root filesystem) to /cdrom/usr. This means that you can add your own extra binaries and extra libraries on the CDROM under its own /cdrom directory. For additional testing, I also mount an ext2 partition on my harddisk as /a.
Burning a CD with a kernel , initrd and a rootfs
Now that we have a kernel, initrd structure and rootfilesystem structure, how do we get them onto the CD. Lets look at the basic structure of the CD (how it would look if you just mounted it as an iso9660 CD): /rootfs.gz /isolinux/
isolinux.cfg - the isolinux config file
isolinux.bin - the isolinux boot program
vmlinuz - our kernel with initrd support
initrd.gz - our initial ram diskThe isolinux.cfg file contains: label linux
kernel vmlinuz
append initrd=initrd.gzIts similar to a LILO config. The main things are the kernel name and the append string which includes the name of our initrd. The fact that its gzipped doesn't matter. the kernel will automatically decompress it later.What about the initrd and rootfs? These are both 4mb files that have been compressed with gzip. The contents of the 4mb file is a valid ext2 filesystem. Here's how I create them, given that I have a directory on my hard disk with the structure of the initrd or rootfs:
BASE=/src/iso
SRC=$BASE/initrd
DEST=$BASE/cdimage/isolinux/initrd
dd if=/dev/zero of=$DEST bs=1k count=4096
losetup /dev/loop1 $DEST
mkfs -t ext2 -m 0 /dev/loop1
mount /dev/loop1 /mnt
cd $SRC
tar cf - . | (cd /mnt ; tar xf - )
umount /mnt
losetup -d /dev/loop1
gzip -f $DESTTo burn the CD, I have the cd tree shown above under my /src/iso/cdimage directory (.ie I have a /src/iso/cdimage/isolinux directory). I run mkisofs as per the isolinux.doc that comes with Syslinux: mkisofs -o /iso.img -b isolinux/isolinux.bin -c isolinux/boot.cat \
-no-emul-boot -boot-load-size 4 -boot-info-table -l \
-R -r /src/iso/cdimageThe boot.cat file is created by the mkisofs command. The -l , -R and -r options are essentially for RockRidge extensions which allow us to have softlinks on the CD and mixed case filenames. We should end up with a couple of meg iso.img file. You can now burn this to the CD using cdrecord (I'll leave this up to you as your speed and dev settings are undoubtedly different to me).
Reboot your system, enter the BIOS setup screens to check that your system will boot off a CD and load the CD and see if it boots. Hopefully, you should see 'Loading vmlinuz', then 'Loading initrd.gz', then the kernel should do its stuff. You should end up with a 'please enter the root password' message (just enter SPACE the ENTER). You should be able to cd and ls and so forth.
A basic image to try out
I've uploaded a very basic ISO that you can burn to a CD and have a play with. It doesn't do too much as yet, but it has the full set of busybox 0.51 commands available and I've added some scripts to simplify the setting up of your lan card and IP address details. To allow different LAN cards to be configured, I've included all the modules for different LAN cards in the /modules directory of the CD.First, download the iso.img.gz file. Decompress it with gunzip and burn it to a CD (I'd suggest a CDRW) using cdrecord or if you want to do it from Windows, you probably just need to rename it to blah.iso and Easy CD Creator or whathaveyou should be able to burn it.
The CD contains my own initrd.gz and rootfs.gz. You can have a look at these by decompressing them and mounting them as ext2 filesystems on a loopback mount.
Reboot with the CD in your CD drive and you should get some ISOLINUX message and away it goes. I've enabled framebuffer support, but you can select whether you want plain text or one of the graphical modes.
You'll get an sulogin prompt (please enter the root password or press ctrl-D), so enter the root password (a single space) and you should be at a bash prompt.
To configure your LAN card enter cfgcard and follow the prompts. The list of cards that is shown is simply the modules directory on the CD. Cards like 3c509 are obvious, but others are not. I have an rtl8139 based card which is the most common el-cheapo 10/100Mbps card you can buy.
Now do a cfglan which allows you to set the IP address, netmask and default gateway etc. It also asks you about nameservers and such as it creates a /etc/resolv.conf so name resolution will work.
Note: to keep the size of the ISO quite small, I have not included any X related stuff.... for now.
Framework for extensibility
OR ... how to add your own extra bits. As I said previously the /usr directory on the CD is symlinked in to become the actual /usr. Create a /usr/bin on the CD and add in all the tools that Busybox doesn't include. Add some libraries into /usr/lib ... and what I've been working on is the basic requirements to get X up and running. One thing to remember is that you really do have to run mkisofs with RockRidge extensions on in order for softlinks and mixed case filenames to be created properly on the CD.
Framebuffer
One of my experimental aims is to have an X windows environment on a boot CD. To achieve the widest possible compatibility, I've chosen to enable the Framebuffer console mode and to use the XF86_FBDev X server (its just the one from Slackware 7.1 at the moment). Note: Even though I am aiming for wide compatibility just so I can run X, Framebuffer mode doesn't work with pre VESA 2.0 video cards which means you may not want to add in Framebuffer if all you really need is a console prompt. To activate Framebuffer console mode you need to make sure some things are compiled into the kernel, typically this includes: [*] VGA text console
[*] Video mode selection support
[*] Support for frame buffer devices (EXPERIMENTAL)
[*] VESA VGA graphics console
[*] Advanced low level driver options
<*> 8 bpp packed pixels support
<*> 16 bpp packed pixels support
<*> 24 bpp packed pixels support
<*> 32 bpp packed pixels support
<*> VGA characters/attributes support
[*] Select compiled-in fonts
[*] VGA 8x8 font
[*] VGA 8x16 fontThe other thing that I didn't realise until later is you have to make sure you set a graphical mode for the console when it boots in order to use the X server in default mode. This means putting a specific vga= setting appended to the kernel at boot time. Specifically, you need to change the /isolinux/isolinux.cfg file on the CD so it looks something like: label linux
kernel vmlinuz
append initrd=initrd.gz vga=791The '791' means to start up in 1024x768x16bit colour mode. Hard coding the display resolution is fine if you know for certain that your video card/monitor can handle it, but what I've done is to let the user choose a display option at boot time. My isolinux.cfg looks like this: timeout 30
prompt 1
display menu.txt
default 1
label 1
kernel vmlinuz
append initrd=initrd.gz
label 2
kernel vmlinuz
append initrd=initrd.gz vga=788
label 3
kernel vmlinuz
append initrd=initrd.gz vga=791menu.txt is a simple text file that looks like: 1) Text Mode
2) 800x600 x 16bit colour
3) 1024x768 x 16bit colourThe user just enters '1' if they want text mode, 2 for 800x600 and so on.
Notes
- The isolinux.cfg file seems rather dodgy if I put something like: label linux
kernel vmlinuz
append initrd=initrd.gz root=/dev/rambut seems to work OK if I take out the root=/dev/ram and simply use rdev to set the root fs in the kernel to /dev/ram1.- You can't make /linuxrc start init properly. It just keeps spitting out a 'Usage' string. I think its because init is unable to start as pid 1.
- mkisofs will only write 8.3 style uppercase only filenames by default. If you want filenames up to 31 chars long, then specify the -l option. If you want mixed case filenames you need to enable the Rock Ridge extensions with the -R option, and may want to use the -r option as well which assigns sensible user/group ownership to all files. You will definately need the -R option if you want to copy whole unix directory trees to the CD.
- 这个命令查一下device name
- El Torito， the CD-ROM Standard .The El Torito Bootable CD Specification is an extension to the ISO 9660 CD-ROM specification. It is designed to allow a computer to boot from a CD-ROM.
- Isolinux
A program to boot Linux kernels off a CD-ROM using the El Toritoboot standard in "no emulation" mode, making the entire filesystemavailable. It is based on the SYSLINUX boot loader for MS-DOS
floppies. - cdrom 的 boot sector 图
BIOS 通过 INT 13 和光盘启动扇区跳转。 - According to the El Torito specification, a 32-bit CPU PC BIOS will search for boot code on a ISO 9660 CD-ROM. The standard allows for booting in two different modes. Either the boot information can be accessed directly from the CD media, or in floppy emulation mode where the boot information is stored in an image file of a floppy disk, which is loaded from the CD and then behaves as a virtual floppy disk. It is sometimes useful to have this choice because booting directly from CD-ROM is vulnerable to BIOS bugs, in which case it is better to boot from the floppy image. This mostly affects computers built before about 1999, which were designed to boot only from floppy drive. In fact, for modern computers "no emulation" mode is generally the more reliable method. The BIOS will assign a BIOS drive number to the CD drive. The drive number assigned is either 80 (hard disk emulation), 00 (floppy disk emulation) or an arbitrary number if the BIOS should not provide emulation. Emulation allows older operating systems to be booted from a CD, by making it appear to them as if they were booted from a hard or floppy disk. Newer operating systems do not require emulation to boot; all that is needed is an appropriate boot loader such as ISOLINUX from the SYSLINUX project.
- 需要的工具
1.ftp://ftp.slax.org/Linux-Live/linux-live-6.2.9.tar.gz
2.ftp://ftp.slax.org/Linux-Live/kernels/2.6.27.7/linux-2.6.27.7-i486-1.tgz
3.http://aufs.cvs.sourceforge.net/aufs/aufs/
4.http://squashfs.sourceforge.net/
5.http://www.squashfs-lzma.org/
6.ftp://ftp.slax.org/source/slax/kernel/2.6.27.7/src-core
博文
没有评论:
发表评论