Kernel 8: Test the Kernel

Shut down your computer and reboot it. Once again, depending on whether you’re using the older LiLO or the newer, Fedora-default GrUB boot loader, you’ll see different things.

If you’re using LiLO, you’ll see this prompt:


Type the name of the new kernel – this is the value you entered on the label= line of the last step. (Told you to keep it simple!)

Or, you may see a list of kernel images and OSs from which you can choose by using your arrow-up and arrow-down keys. Again, this list is contingent on the title or label that you gave your new kernel (KISS!).

Select your new kernel and watch the fireworks fly.

When things are working, run the command:

make clean

to clean up the huge wads of files you’ve unzipped.


Recheck Your Current Kernel Version

In most distros:

uname –a

gives you a long listing of your kernel information

uname –r

gives you the kernel version only

In Red Hat use :

cat /etc/redhat-release
cat /proc/version

Kernel 7: Boot the Kernel

Setting Up Your New Kernel To Boot: Automated Procedure

Life is so much easier with the 2.6 kernel….

All you need to do (under most circumstances) is issue the command:

make install

If you haven’t had your daily dose of masochism, you can refer to the manual procedure below. Otherwise, however, go to the next page.


Setting Up Your New Kernel To Boot: Manual Procedure

You need to copy your kernel and the file to /boot. Command:

cp arch/i386/boot/bzImage /boot/bzImage-your_kernel_version

cp /boot/

ln -s /boot/ /boot/

Note the symlink you’re creating. Also note that this assumes you used a bzImage; change this as necessary.


Setting Up LiLO

Edit /etc/lilo.conf. Find the lines like:


DUPLICATE these lines below the current ones,

  • changing the value of image=value to the new Linux kernel you’ve created, and
  • changing the value of label=value to something like Linux_kernel_version (don’t go wild here; you’re going to have to type this name, so choose something simple like Linux_2.6).
  • Also, let the default=value stay as it is, so your previous working kernel loads unless you specify otherwise. You can change this later if things work.

Save and exit, then command:


to reinstall LiLO with new settings. You’ll see an Added message. Voila!


Setting Up GrUB

GrUB is more flexible and a lot more forgiving of system errors. While LiLO requires that an alternate boot disk be used if your new kernel configuration renders the system unbootable, GrUB lets you modify kernel location, boot parameters, kernel to boot, etc. “on-the-fly.”

Edit GrUB’s configuration file in /boot/grub/menu.lst. Check if /etc/grub.conf is a symbolic link to this file.

# Note that you do not have to rerun grub after making changes to this file
title Red Hat Linux (2.4.21-20)
  root (hd0,1)
  kernel /boot/vmlinuz-2.4.21-20 ro root=LABEL=/
  initrd /boot/initrd-2.4.21-20.img
title Red Hat Linux (2.4.20-20.9)
  root (hd0,1)
  kernel /boot/vmlinuz-2.4.20-20.9 ro root=LABEL=/
  initrd /boot/initrd-2.4.20-20.9.img

Add your new kernel information in a new sectiong beginning with title. Keep in mind that the GrUB count is a 0-based array (it starts from 0), so (hd0,1) refers to the first controller, second partition. Your configuration should look like this:

title Test Kernel (2.6.0)
  root (hd0,1)
  kernel /boot/bzImage-2.6.0 ro root=LABEL=/
  initrd /boot/initrd-2.6.0.img

Kernel 6: Build the Kernel

In 2.4 kernels, you would first check dependencies:

make dep

This would check dependencies for each source file and include dependent binaries in various makefiles.

2.6 and later kernels don’t need it.



make clean

to prepare the source tree for your new build.


Historical note:

Once upon a time, the Linux kernel fit easily on a floppy disk. You would use compression, with a command like:

make zImage

Or, to save to both hard disk and floppy:

make zdisk #good for testing

Or, if necessary to create a really compressed image:

make bzImage

However, since version 2.4 the kernel is usually too large to fit on a floppy disk. There are various how-tos on the Internet for putting either the kernel or a bootloader on a CD, DVD or a USB key, if you’re interested.


The command you’ll end up using for modern compilations is:

make bzImage

Yes, that’s it. After a lengthy compilation, the resulting image will be in /usr/src/linux/arch/i386/boot/. The image itself likely will be called bzImage.

You must copy this file to /boot, as well as the file /usr/src/linux/


Patching the Kernel

Remember those patch files I mentioned at the beginning of this lesson? If you’re a genuine kernel-jockey and have already built a kernel on your current machine, you may be interested in patching your kernel. Patching is actually very simple, but it does require existing source code in /usr/src/linux. Download the next numerical version patch for your kernel. You must patch one version at a time: to go from 2.6.5 to 2.6.7, you must install the 2.6.6 patch first, then the 2.6.7 patch.

Uncompress the patch into your /usr/src/linux directory, and command:

patch < patchfile

You will then need to compile your kernel as I described above.



Make Any Modules

If you’ve chosen the M option in the configuration stage (and there are many defaults that use this setting), you’re also going to have modules to compile in your working directory. Command:

make modules

and then

make modules_install

They’ll end up in the /lib/modules/kernel_version directory.


About Modules

Module: a file containing code for a specific driver

See the man pages for the modprobe and insmod commands, for info on loading and unloading modules on the fly. With the 2.6 kernel, this is usually unnecessary. In most cases kudzu will detect hardware properly, which means the right modules for any new hardware get loaded automatically.

Generally, a list of modules is loaded at boot, taken from the file /etc/modprobe.conf. (Older distros may have the files /etc/modules.conf or /etc/conf.modules.)

However, here is some basic information for those occasions when you have to load modules yourself, or load them from a script.

You will typically find kernel modules in a subdirectory of /lib/modules/<kernel_version>/. Typically they are compiled files with a .ko (kernel object) file extension. (Older kernels, 2.4 and prior, used a .o extension.) insmod requires that you know the exact name of the module to be inserted, so most likely you will have to look in this directory. If I have an SIS video card, for instance, I can issue the command:

insmod sisfb

This will load the module, but won’t check for any dependencies it may have. To do a dependency check as well as loading the module, use the modprobe command:

modprobe sisfb


Module Commands


creates a dependency file for modules, which then can be used by modprobe

depmod –a

creates dependency files for modules listed in /etc/conf.modules

Some modules, whether very new or very old, may require manual editing of the /etc/modprobe.conf file.

cat this file to see its format. The syntax of each line is:

alias <device_alias> <driver_module>

For example, to load a DEC Tulip NIC with the device name of eth0, you would add the line:

alias eth0 tulip




loads a module into the kernel; once upon a time you had to do this manually or with a script to initialize, for instance, a sound card.


lists all loaded modules and their size (in units of 4k)

rmmod module(s)

unloads a module or list of modules from the kernel (this only works if they are not currently in use)

rmmod –r

recursively” removes all modules, i.e., if dependent modules are left behind on the first pass, they’ll be removed in another pass

modprobe module(s)

attempts to load the specified module and any dependent modules. Note that if you list more than one module, the others will load only if the first one fails.

modprobe –a module(s)

loads all of the modules, not just the first one

modprobe –r module(s)

removes specified modules and their dependencies.


Make an Initial RamDisk

Your kernel will need to load several modules at boot, which is tricky because the kernel needs the filesystem modules to access the filesystem (among other problems). The solution is a ramdisk: a filesystem image that is loaded into RAM at boot, as a step in the bootstrap process.


mkinitrd -v /boot/initrd-<kernel_version>.img <kernel_version>

Kernel 5: Config Options

There are hundreds of configuration options. Basically, be aware of these ones:

Power Management Options – If you’re using a pre-2001 computer, do NOT install ACPI or APM. Otherwise, be clear which options your chipset supports.

IRDA Support – If you don’t need it, ditch it.

ISDN Subsystem – If you’re not using ISDN, ditch it.

Input Core Support – Enable support for USB mice and keyboards here.

Character Devices – Enable support for serial mice, serial ports, and joysticks here.

Multimedia Devices – Video configuration is here.

File Systems – Use the ones you need, and no more.

Console Drivers – Set options for text-mode display.

Sound – If you must have a sound card.

USB Support – Yes, enable it here too.

Kernel Hacking – Do you really do this?

Most configuration settings accept values of Y (yes), N (no), or M (separately loaded module). Note that, joyfully, Linux handles almost all modules on an auto-loading basis. Modules take time to load, but save memory when they’re not loaded. You want your NIC compiled into the kernel, but may want your floppy drive to auto-load since you rarely use it.

Take some time looking through these options. It is highly worth considering them one by one, because the fewer unnecessary support options you choose, the faster your kernel will be. If you don’t need Bluetooth, IrDA, ATM, PCMCIA, SCSI, or any of the many, many other options, consider ditching them. This will be an experimental kernel; you might as well try for the fastest one you can get.

Once you’ve completed this configuration, depending on which make program you’re using, you’ll Save and Exit by various processes.


Kernel 4: make Options

You should be in /usr/src/linux-2.6** (the new directory). Before you start, you need to clean your configuration directories. (We’ll simply assume you have run previous kernel compiles.) Type:

make mrproper

Also, open the Makefile in a text editor and find the config value EXTRAVERSION. This configuration option lets assign a version number to your own build, so that it will build in a differently-numbered directory (and so it won’t clobber your original kernel build files).

If you’re compiling a kernel of the same version as your existing one, for instance because you’re doing some fine tuning, run the command:

make oldconfig

Now, you can use any of three other make commands to start configuring your kernel.

make config

will start a text-based config tool that can run on almost any Linux system. If this is your first time around, this is not the friendliest tool. But you can count on it being present. Note that the linear process is fixed: you can’t go back and change a previous choice. Try this some time when you feel masochistic.

make menuconfig

runs a text-based, menu-driven interface that lets you move around in the config process. If you’re doing this process from a remote terminal, for instance, it’s a good choice.

make xconfig # in KDI
make gconfig # in Gnome

provides a slick GUI interface. It requires Xwindows and a properly installed qt development package. If you didn’t choose to install the Xwindows development packages during your initial Fedora installation you are likely to be unable to use this method. Don’t worry; menuconfig is a very good interface.

Kernel 3: Get the Source Code


Note that the cleanest source code will not be RPMs or other pre-packaged units; the cleanest source code will be raw code packaged as tarballs.

However, RPMs (etc.) sometimes contain patches your system will need (if it’s Fedora, for instance). If you get RPMs, note that you’re likely to need two files, the kernel source and the necessary header files. Tarballs will (usually) have all this already.

Also be sure you do NOT get an RPM with “patch” in the name, unless you specifically want to patch your existing kernel from an immediately previous version. Patches are much smaller, but are NOT complete kernel source code.

You should be downloading a package of about 20-40 MB.


Get the signature file and fingerprint

NOTE that you should also download the signature file along with the tarball. It will have the same name as the tarball, with .sign on the end. See The Linux Kernel Archives OpenPGP Signature (

Also copy and save the key fingerprint, which will be this or similar:

Key fingerprint = C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E

Note that (almost) universally, when you see a “0” it’s a zero, not the letter O (“oh”).


Get and import the key

You must import the key. This key is available from most common PGP key servers, such as If you get the key from this HTML page, copy the text beginning with:


and ending with:


to a text file named 517D0F0E. Or, you can request it directly from the keyserver using GnuPG:

gpg –keyserver –recv-keys 0x517D0F0E

If the keyserver times out, get the key from the page linked above. Keyservers do get overwhelmed.

Then issue the command:

gpg –import 517D0F0E


Verify the signature

Use GnuPG to use the signature to verify the tarball:

gpg –verify linux- linux-

You may get messages (or variants) like this:

gpg: Signature made Mon Oct 9 23:48:38 2000 PDT using DSA key ID 517D0F0E
gpg: Good signature from “Linux Kernel Archives Verification Key <>”

Could not find a valid trust path to the key. Let’s see whether we
can assign some missing owner trust values.

No path leading to one of our keys found.

gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.

For the time being, don’t worry about these. However, the last line should be something like this:

Primary key fingerprint: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E

This number should match the fingerprint number you saved above. If it doesn’t, stop right here and get the kernel source from some other, presumably uncompromised, location!


Where To Put The Source Code

Download,copy or move your source code (in whatever form) into /usr/src/.

This directory is likely already to have a directory named linux! If it does, rename this directory before unpacking your tarball. Command:

tar zxvf ./linux- #update this
#to match the version you get

Don’t forget that the tab key lets you expand a long file name without typing the whole thing. If you got a bzipped tarball rather than the usual gzipped tarball, you’ll need:

tar xvf ./linux- –use-compress-program bzip2
or, more succinctly:
tar jxfv ./linux-

Once you’ve done this, run an ls and note the name of your new directory. Rarely it will be may be “linux;” more commonly it will be “linux-”.

At this point you’ll need to create a symlink to this directory. Command:

ln -s /usr/src/linux<new version> /usr/src/linux

This isn’t mandatory; you’ll just need it to keep from going insane. For an example why, change to this directory now.


Kernel 2: Determine Your Hardware

What hardware do you need to support? You particularly want to know your processor, hard drives and controllers, your NIC, graphics and sound cards. Use the lspci utility:

lspci # or, if necessary, /sbin/lspci

which gives you a comprehensive listing. Save, print or write this down as necessary. Particularly note your:

  • Ethernet contoller (NIC)
  • Audio controller (sound card)
  • VGA controller (video card)

Next, get your cpu info. Type:

cat /proc/cpuinfo

Again, write this down. Note your:

  • cpu family (e.g., 6, which indicates i686)
  • vendor_id (manufacturer)

(See the WikiPedia entry for more discussion of i-numbering schemes.)

Building a Kernel

This example uses Fedora Core 4. Other distros will be similar, but not identical.

Why Build Your Own Kernel?

  • Optimizing for a particular processor
  • Adding specific drivers: “disk-only” drivers for some IDE disks, and issues with IDE CD-ROMs
  • Removing unnecessary drivers (most are external modules, but some are internally compiled)
  • Networking: Gigabit ethernet vs 100 Mbps, iSCSI, Fibre Channel
  • Queuing: real-time devices
  • Upgrading: moving a current system to a newer kernel


Create an emergency boot disk for your system before you go any further.

Insert a blank floppy disk in your first disk drive (/dev/fd0). First, you need to know the version of your kernel. Issue the command:

uname -r #for a short listing
uname -a #for a long listing

Write down the kernel version. Typically it will be something like 2.4.21-20. Now insert a floppy in the drive and command:

mkbootdisk –device /def/fd0 2.4.21-20 #replace 2.4.21-20 with your kernel version

Also note that one critical update may need to be performed on 2.4 kernel systems to upgrade to 2.6 kernels: you might have to update module-init-tools.


Kernel Versions

Kernels have three numbers. The 2.6.12 kernel, for instance, has a:

  • Major number of 2
  • Minor number or 6
  • Revision number of 12

The kernel itself is frequently named “vmlinuz”.


Determine Your Current Kernel Version

In most distros:

uname –a

gives you a long listing of your kernel information

uname –r

gives you the kernel version only

In Red Hat use :

cat /etc/redhat-release
cat /proc/version


Review the Kernel ReadMe

2.6 Kernel Readme/How-To


Resource: Digital Hermit’s Kernel How-To


Using Kickstart

Review Chapter 2, Installing Red Hat Linux, pp. 41-46

Automating Installations

When rolling out multiple Red Hat installations, you can use a system similar to using Difference Files in Windows. As in this type of multiple installation in Windows, you start by building one machine and using it as a template for the rest.

The key to this is the kickstart file, which will be named ks.cfg. While you can build this file yourself, you should use the one Red Had leaves for you instead, at /root/anaconda-ks.cfg (in the root home folder, not the root of the file system). Rename this file to ks.cfg and you’re ready to start.

Note that you can get more information on this process from the Red Hat Linux Configuration Guide, available at or any mirror site.

You must provide answers to all items, or the installation will stop until you or a user provides the answers. As always, use the text editor of your choice, and like any Bash script file, the character “#” indicates a comment line.



# Kickstart file automatically generated by anaconda.
lang en_US.UTF-8
langsupport –default=en_US.UTF-8 en_US.UTF-8 en_US en en_US.UTF-8 en_US en
keyboard us
xconfig –card “S3 Trio64 (generic)” –videoram 4096 –hsync 31.5-37.9 –vsync 50-70 –resolution 800×600 –depth 16 –startxonboot –defaultdesktop gnome
network –device eth0 –bootproto dhcp –hostname vFedora4
rootpw –iscrypted $1$Yvz632B.$375eW3XjP8ih1WFTeW8O./
firewall –disabled
selinux –permissive
authconfig –enableshadow –enablemd5
timezone America/Shiprock
bootloader –location=mbr –driveorder=hda –append=”rhgb quiet”
# The following is the partition information you requested
# Note that any partitions you deleted are not expressed
# here so unless you clear all partitions first, this is
# not guaranteed to work
#clearpart –all
#part /boot –fstype ext3 –size=100 –asprimary
#part swap –size=384
#part / –fstype ext3 –size=100 –grow –asprimary
@ office
@ mysql
@ editors
@ system-tools
@ gnome-desktop
@ dialup
@ ftp-server
@ network-server
@ games
@ smb-server
@ base-x
@ graphics
@ web-server
@ printing
@ kde-desktop
@ server-cfg
@ admin-tools
@ graphical-internet


Modifying ks.cfg

You must log in as root (bad idea) or command:

su –

Now, line 1 (line numbers exclude comments): install or upgrade?

Generally, you’ll want install. If you choose upgrade, you need only specify

  • language
  • install method
  • install device
  • keyboard
  • boot loader

Subsequent lines:

cdrom #installation device
lang en_US.UTF-8 #default language
langsupport –default=en_US.UTF-8 en_US.UTF-8 en_US en en_US.UTF-8 en_US en #supported languages
keyboard us #keyboard type
xconfig –card “S3 Trio64 (generic)” –videoram 4096 –hsync 31.5-37.9 –vsync 50-70 –resolution 800×600 –depth 16 –startxonboot –defaultdesktop gnome #THIS ONE SAVES YOU A LOT OF WORK – but your video card must be the same on each computer
network –device eth0 –bootproto dhcp –hostname vFedora4 #Notice that each computer will initially have the same host name, so DON’T BOOT WITH A LIVE NETWORK CONNECTION.
rootpw –iscrypted $1$Yvz632B.$375eW3XjP8ih1WFTeW8O./ #encrypted password
firewall –disabled #firewall
selinux –permissive #secure Linux or not?
authconfig –enableshadow –enablemd5 #use a shadow password file, and use MD5 hashing
timezone America/Shiprock #time zone
bootloader –location=mbr –driveorder=hda –append=”rhgb quiet” #bootloader: Grub (Red Hat Grub Bootloader) by default
# The following is the partition information you requested
# Note that any partitions you deleted are not expressed
# here so unless you clear all partitions first, this is
# not guaranteed to work
#Notice that you must un-comment these lines if you want to want to partition.
#clearpart –all
#part /boot –fstype ext3 –size=100 –asprimary
#part swap –size=384
#part / –fstype ext3 –size=100 –grow –asprimary


Specifying Packages in ks.cfg

Let your initial installation take care of this messy business:

@ office
@ mysql
@ editors
@ system-tools
@ gnome-desktop
@ dialup
@ ftp-server
@ network-server
@ games
@ smb-server
@ base-x
@ graphics
@ web-server
@ printing
@ kde-desktop
@ server-cfg
@ admin-tools
@ graphical-internet
kernel #yes, we want the kernel, but it is possible to disinclude it
grub #default boot loader
e2fsprogs #ext2 filesystem management programs


Where To Put ks.cfg

  • Format a floppy disk ext2 or ext3:

    mkfs -t ext3 /dev/fd0

    then mount it and copy the file

  • On a local hard drive (which is a trick if you’re partitioning), which must be a Linux (usually ext3) or a shared Windows partition (VFAT)
  • On a network share, which requires a connection command:

    smbclient // -U someuser #for a Windows (Samba) share

Booting And Installing

The “easy” way (which quickly becomes a pain) is to

  • boot from the Red Hat CD
  • when you reach the command prompt, QUICKLY insert the ks.cfg floppy
  • then you’ll get the
  • SWIFTLY now, type:
    linux ks=file:fd0/ks.cfg
  • swap CDs when the installation requires

Try this three times, quickly, and see how often this gets tricky.

Instead, try

  • downloading the DVD image,
  • putting it on a network share,
  • mounting the ISO on the server:
    mount -o loop -t iso9660 redhat.iso /mnt/isoimage/
  • specify that mount in the ks.cfg file; instead of the line:
  • then, at the boot: prompt, type:
    ks:nfs:servername:fullpath #for an NFS server
    ks=http://servername/path #for a web-based installation
    or even
    ks=hd:device #for a local or mounted hard drive; you’ll need to specify hd0, or the correct hard drive




Recovering From A Crashed Hard Disk

Life gets rough when you start encountering filesystem failures. Are they caused by a software issue, or by failing hardware? Your first task is to determine exactly this.

1. Run the command:


and look for messages about disk failure. If you find these, the question is answered.

2. You can run a file system check on any read-only mounted partitions. Run the command:


and be ready for messages about bad blocks.

To check your root file system, you will have to mount it read-only, which is to say you’ll probably have to mount it under a running live-CD Linux system.

Again, if you’ve got bad blocks on the hard disk, your problem is hardware.

3. Get a low-level disk diagnostic program from your hard disk manufacturer’s web site.

Most of these are DOS bootable floppies. Again, you’ll know hardware is the issue if the tool tells you it is.


Dealing With Disk Hardware Failure

1. If you’ve got hard disk problems, back up your data NOW. Next, go get a new hard drive.

2. Get or make a DOS boot floppy. Put the file loadlin.exe on it (find out more about loadlin, and get it, here). If you don’t have a copy of a DOS boot floppy, get FreeDOS here.

3. Shut down the computer if it’s running and add your new hard drive to the system. Your old, bad hard drive should still be in it too. Be aware of where you’re adding that new hard drive: if it’s the master drive on the secondary IDE controller, for instance, it’s hdc.

4. Boot to a live-CD or floppy-based Linux distro. (See this page for some choices.) You can use the built-in utilities fdisk to create partitions on your new hard disk, and mkfs to make file systems on them (i.e. format them), or get the excellent GNU Parted partition editor.

Make life easy on yourself and use the same partition layout that your original disk used.

I highly recommend a /boot partition, a swap partition, and a /  partition. Modern hard disks are much more reliable than older ones, so elaborate schemes are generally not necessary. It’s your decision, though. (Disks over 8 GB outright require a /boot partition.)

Do NOT forget to make the swap file system on the new swap partition! (It is nice in some cases to use an older, smaller hard drive with a single partition for your swap partition. If you do this you don’t need to worry about a swap partition on your new hard drive. But don’t use a slow drive for the swap drive!)

5. Depending on the distro you’re currently running, your old hard drive’s partitions may already be mounted. You will, almost certainly, have to mount the new hard drive’s partitions once they’re created and formatted. See my page on this subject if you need help. I’d suggest:

mkdir /oldboot

mkdir /oldroot

mount /dev/hda1 /oldboot #assuming your old drive is hda

mount /dev/hda2 /oldroot

mkdir /newboot

mkdir /newroot

mount /dev/hdc1 /newboot #assuming your new drive is hdc

mount /dev/hdc2 /newroot

6. You are going to need to know the name of your old hard disk’s kernel:

cd /oldboot

and look for the kernel file. It may be named vmlinuz, bzImage, or almost anything. Look for a file of about 1.5 MB size or larger. Write down its name.

7. It’s time to transfer data from the old disk to the new one. One partition at a time, tar and transfer the contents of each partition. Change to each source partition to do this. I’d suggest:

cd /oldboot

tar cvplf – ./ | (cd /newboot; tar xplf -)

cd /oldroot

tar cvplf – ./ | (cd /newroot; tar xplf -)

8. Shut down the computer when this is done. Remove the old hard drive, and move the new one to the old one’s position on the IDE or SATA cable. Don’t forget to set the master/slave jumpers on the new drive to match the old one.

9. Now, boot your system to the floppy you prepared earlier. You’ll be in DOS, so you’ll need to load Linux with loadlin:

LOADLIN bzImage ro root=/hda2

This assumes your kernel image is named bzImage, and that your / partition is mounted at hda2.

Your system should boot. If it doesn’t, it’s time to troubleshoot further. One unfortunate possibility is that your old files may have been corrupted by the old hard drive’s failure, but don’t just give up!

10. Reinstall your boot loader. You must be root to do this. If it’s LILO, command:


If it’s GRUB (which I recommend), command:


If you’ve changed partition layouts, you’re going to have to edit your LILO or GRUB configuration file before reinstalling your boot loader (I told you to keep it simple).

11. Moment of truth: shut down, remove your DOS floppy, and reboot. If it does (and it likely will), you’re done. If it doesn’t, you now have the opportunity to become a more accomplished Linux geek by getting on the Internet and doing your own research.

Good luck!