Linux Gazette July, 1995Linux Gazette July, 1995
So what is the Linux Gazette...Primarily writings, ramblings, and other stuff...
About a year ago, after getting my first glimpse of the internet via a dial-up 2400 baud VAX account (ouch!...), I started reading about a freely available UN*X-like operating system that would let you run a unix operating system on an i386 or better PC. Sounded good to me...
So... after spending days tying up the dial-up line into the wee hours of the morning, AND after spending 45 bucks in floppies, I finally managed to get a copy of Slackware 2.0.0. I spent an entire afternoon thereafter shoveling disks in and out of my PC and watching dialog after dialog describe what was happening. Eventually, I managed to get it all loaded up, rebooted, and presto!...
LINUX!
I got hooked! This thing was awesome, huge, and bewildering. At times it was so frustrating that I was sure it was either a 120MB virus in disguise... or possessed. Eventually, I started making some headway and things worked! Now, I was really hooked. What had happened was that by reading everything I could find --
If you're in the same boat... keep paddling! The result is definitely worth it! Running Linux means having to do your homework. It's a matter of reading and learning until things make sense. There are LOTS of folks out there who are more than willing to help and have invested a LOT of time into writing the documentation that makes Linux knowable.
Great software without the knowledge to run it is pretty useless.
Sermon over. What I've tried to do with the Linux Gazette is pass along some of the ideas that I've tried, liked, and have worked for me. Just one caveat:
This ain't technical wizardry and it won't advance you to gurudom...
Hopefully, what it will do is make running Linux a bit more fun, enjoyable, or easier. This is a compilation of ideas I've shamelessly plagerized from so many sources that, quite frankly, I'm not sure where some of them came from, let alone being able to give due credit to the originator. And so... to the great nameless, faceless, unknown but all-knowing Linux gurus (ooh, kinda spooky, eh?)...
Thanks.
And off we go...What I'll try to do is make this as pleasant, or at least as painless, as possible. It's admittedly a bit loose and rambly and probably best purused when you've got a bit of time to browse...
eh?... what?! Your student account at rigid.frigid.toxic-megahosers.edu times you out at 2 minutes of inactivity?! Hosers.
Try this. If you're running a PPP account set up a small shell script:
#!/bin/sh
#program: hose-em
#purpose: keeps a dial-up line from timing out while you're
# reading Web stuff or doing your laundry (OK... let's be
# responsible)
#
# We'll use the gateway server as your host.
HOST=000.00.00.000 # the dotted-quad address of your gateway which
# you can get by typing "ifconfig"
SLEEP=8m # how long we'll wait between pings
###############################################################################
#
# Set up a while loop that pings the host as long as the PID file exists.
# But first, make sure that the connection is still up.
#
if [ -e "/var/run/ppp0.pid" ]; then
echo "
* * * PPP-UP is running * * *
"
else
echo "
* * * PPP0 interface is not up! * * *
"
exit 1
fi
while [ -e "/var/run/ppp0.pid" ] # Now, set up the while loop.
do # As long as the PID file exists
ping -c 1 $HOST > /dev/null # we'll ping the host once every 8 min.
sleep $SLEEP
done
exit 0
you'll notice we use the ping -c 1 designation -- that keeps ping from endlessly pinging. Set the variable SLEEP= to whatever interval you need. And that's it! Don't forget to chmod 711 hose-em when you're done.
Now, you can browse in peace. When you terminate the link, the while-loop ends and ping goes back to sleep.
So what is this MOTD thingy and who keeps eating my issue...!Ever notice that when you log into Linux you get the same ol'
Welcome to Linux 1.x.x. Login: Linux 1.x.x. (POSIX)...and you finally discover /etc/issue and /etc/motd. And after hacking away on them until they finally say anything besides the usual brain-dead information about what kernel this is... you reboot.. and there it is AGAIN!!. Arggghhh!
So what happened? There's a line of code in your /etc startup files that resets the /etc/issue and /etc/motd files back to their original. BTW... /etc/issue is the first message that is displayed immediately before the login prompt, while /etc/motd (Message Of The Day) is displayed once a user has successfully logged in.
To fix this you'll need to edit one of those obscure config files in your /etc/rc.d directory. You'll need to edit /etc/rc.d/rc.S and look for:
# Setup the /etc/issue and /etc/motd to reflect the current kernel level: # THESE WIPE ANY CHANGES YOU MAKE TO /ETC/ISSUE AND /ETC/MOTD WITH EACH # BOOT. COMMENT THEM OUT IF YOU WANT TO MAKE CUSTOM VERSIONS. echo > /etc/issue echo Welcome to Linux `/bin/uname -a | /bin/cut -d\ -f3`. >> /etc/issue echo >> /etc/issue echo "`/bin/uname -a | /bin/cut -d\ -f1,3`. (POSIX)." > /etc/motdIf you look closely at what this does, it echo's several lines into your /etc/issue file, thereby wasting whatever you'd previously written, and it does the same with your /etc/motd file. Now, thing to do is comment these out by simply putting a " # " in the beginning of each of these lines. Now, you can go ahead and edit your issue and motd files and know that when you boot up again... they'll be there!
Aliasing for fun and efficiency...While we're talking about fixing up boot up stuff... if you're using bash (which most folks running Linux probably are since it's often installed by default) then there's a great little config file you need to get aquainted with:
Your ~/.bash_profile
Two cent tip: the squiggly-thingy (" tilde ") just indicates your home directory. It should point to the same directory that the environment variable $HOME points to.
If you browse the manpage for bash you'll discover that there are several configuration files that can be read at the time of initialization
Aliases are command substitutions, if you will, that can be used with certain shells such as bash. The syntax is:
alias shortcut=`command -options`
Notice the use of the "`" after the equals sign (you know, the backwards apostrophe that lives underneath the squiggly thingy on the top of the keyboard).
Now... make life easier for yourself. If you set up shortcut aliases you can speed up your keyboard commands considerably. Some examples:
alias c='clear' alias d='ls -lF' alias dir='ls -lF' alias ftp='ftp -v' alias lpr='lpr -h' alias rm='rm -i' alias startx='startx >& /dev/null' alias x='startx >& /dev/null'You'll notice that this speed things up a lot. Instead of constantly typing out ls -lF for a directory listing you simply enter " d " . Also, if you're running X Window and you're tired of looking at all the startup information cluttering your screen when you shut it down then adding an alias to send the usual stdout into the /dev/null bitbucket clears up your screen. Nice and tidy.
Notice one other thing -- a safety point. As long as you're not running as root all the time you're probably safe from the standpoint of not fatally and irretrievably zapping some critical system file. But you can still effortlessly do away with hours/days/weeks of work on a file if you inadvertently " rm " something you hadn't intended. UN*X can be kinda harsh, and Linux is no different. Once somethings gone... it's gone. Now there are programs that handle safe deletes, but the plain vanilla Linux will still uncaringly discard anything you tell it to.
By adding an alias for " rm " -- so that it is always invoked with the -i option, it will always ask you for permission to delete something. Yup, it's can be a bit of an annoyance, but if it saves your butt once, you'll be happy that you did. Also, you can override this by issuing " rm -f delete_me.text " and Linux will happily delete it without another thought.
Adding some functions for even more time savingsWell, now that we've added some helpful aliases, let's make life even more fun and efficient...
Adding functions to the ~/.bash_profile.
Yup, you remember the idea of functions -- the short bits of little-black-box code that takes in input and spits back some kind of output. Well, you can set the same basic thing up, only in a more modest fashion.
Under bash you can define functions that work in your shell script programs by defining them like:
Say_hello()
{
echo "Hello world"
}
Now, if you invoke the function Say_hello, you'll get a profound sense of accomplishment as it issues a " Hello world " back. Pretty lame, eh? Well, not so fast. You can use this bit of wizardry in your ~/.bash_profile to set up commonly used functions. Like what? Well, if you use tar frequently, then it's helpful to add something like:
# Now, some handy functions...
#
tarc () { tar -cvzf $1.tar.gz $1 }
tart () { tar -tvzf $1 | less }
tarx () { tar -xvzf $1 $2 $3 $4 $5 $6 }
popmail () { popclient -3 -v -u myname -p mypassword -o /root/mail/mail-in any.where.edu }
zless () { zcat $* | less }
z () { zcat $* | less }
to your ~/.bash_profile initialization file. Now, instead of having to type out tar -xvzf some_very_long_filename-3.1415926535-bin-Motif-static.tar.gz you can just type in tarx some_ver (and then hit TAB to do a filename completion... just because UN*X allows 256-character file names doesn't mean that you actually have to USE all 256 characters). The function call will do the rest. An even handier situation is if you've got an excruciatingly long command line to enter, such as for the program popclient.
For short functions you can just as easily set up an alias. Someone with more UN*X wizardry than me might be able to say whether one is more efficient/desirable than the other. Fact is, they both work, and they'll both let you save a LOT of time if your spending much time at the keyboard.
One final point... you can use this basic idea to save yourself some harddrive space. How?
If you gzip -9 your documentation files (you probably don't want to do this with your /etc/inittab file) then it's easy to view them by setting up a function or alias such as " z " , which is listed above. This will zcat the compressed file and pipe it to less (or more if you like that) for viewing. On my machine this action is nearly instantaneous for all but the most gigantic files.
Playing .AU stuff at boot upFor any of you that have a sound card and have had the unfortunate pleasure of firing up Windoze you'll recall the scratchy, irritating .wav noise that eminates from your speakers. This fingernails-on-the-chalkboard greeting reminds you of what you have in store...
Fortunately, you can do a lot better than the cheesy ding.wav thing. Linux is here to rescue you. First, you'll need to get your hands on some half-way decent .au files -- try the multimedia subdirectory at sunsite.unc.edu for a veritable smorgasbord of great .au sound files.
(In case you need some hints, there are great trekky clips, some wonderful stuff by Monty Python -- try out spam.au and the lumberjack.au files -- as well as the classics from the Three Stooges in the /series/three_stooges subdirectory)
Once you've gotten a few good .au files, you can make logging in a much more rewarding and eventful experience by adding something like this to your /etc/rc.d/rc.local file:
cat /usr/local/sound/spam.au > /dev/audio &
If you put this at the end of the file, after all the other housekeeping chores are done, then you'll be greeted with a rousing rendition of "Spam, Spam, Wonderful Spam" in four part harmony (...honest!) as the login prompt is displayed. One minor point -- don't forget to add the " & " at the end of the command line or else you'll find yourself having to sit throught the ENTIRE rendition before it gives up control to the login prompt. Mounting your cdrom and floppies the easy wayOk, we're on a roll here... While we're messing around with all the initialization stuff it's time to hack away on something else.
The /etc/fstab file.
Here are just a couple suggestions to make life easier.
First, for all of you who've upgraded to kernel 1.2.x and have suddenly found yourself getting the same annoying error message at bootup... you know, something about your /etc/fstab lacking a passno field entry... well, here's how to make things right.
The problem is that mount is now looking for two additional field in the /etc/fstab file -- the fifth (fs freq) and the sixth (fs passno) fields -- which are not, at least as yet, included by default in the stock Slackware distribution of Linux. So, after you've installed everything correctly, you still end up getting an error message. Time to fix it.
The manpage for fstab is actually quite intelligible when it comes to the entries. What's important, at least to rid yourself of the annoying error message, is to know that two additional fields have been set up for each file system entry. The fifth field (fs freq)has to do with information regarding the dump (?) program -- it specifies which filesystems need to be dumped. (?) ... I'm not sure either, but I've read that it's safe to simply put in a " 0 " and let it go at that.
The sixth field (fs passno) is the one of interest. It contains a numerical value used by the fsck program at boot time to determine the order in which filesystems are checked. The rules are
The root filesystem is given a value of 1
Other filesystems are given a value of 2
File systems that do not need checking -- such as the /proc or /cdrom -- are given a value of 0
So, your fstab might look something like this:
# entries for file system table "fstab". File systems are entered in a format: # # device: mount: fs-type: options: dump: fsck: # _______ ______ _______ ________ ____ ____ # /dev/hda6 / ext2 defaults 0 1 /dev/hdb7 swap swap defaults 0 0 /dev/hda2 /dosc msdos defaults 0 2 /dev/hdb5 /os2 msdos defaults 0 2 /dev/hdb6 /dosf msdos defaults 0 2 none /proc proc defaults 0 0 # # These last five are for the CDROM and floppy drives A and B. The fs-type # is indicated and the 'noauto' keeps init from trying to automount the fs # at bootup. The option 'user' *should* allow normal non-root users to mount # the fs. # /dev/sbpcd /cdrom iso9660 ro,noauto 0 0 /dev/fd0 /a msdos user,noauto 0 0 /dev/fd1 /b msdos user,noauto 0 0 /dev/fd0 /fd0 ext2 user,noauto 0 0 /dev/fd1 /fd1 ext2 user,noauto 0 0So what's going on here?
When you boot your system, there's a line in your /etc/rc.d/rc.S file that looks like:
/sbin/mount -avt nonfs
at least this is what's in the plain vanilla Slackware distribution, your's may vary. The mount command with the -a option results in the automatic mounting of all the filesystems in your /etc/fstab file execept those that have the noauto option .
So, if you look at what's going on, you'll see that in the above example, there are several filesystems automatically mounted at boot time and include a Linux native (/dev/hda6), a Linux swap (/dev/hdb7), a couple DOS partitions (/dev/hda2 and /dev/hdb6), an OS/2 (FAT partition, hence the " msdos " fs-type) (/dev/hdb5) and the /proc filesystem.
What you'll also notice is that, in the lower section of the fstab file, there are several stanza's with the " noauto " option indicated.
Here's where life get's easier
Adding the " noauto " option keeps mount from trying to mount my cdrom or floppies at boot time -- since it's likely that there's nothing there. However, when I'm ready to mount one of these, instead of having to type the usual
mount -r -t iso9660 /dev/sbpcd /cdrom
I can simply type in:
mount /cdrom
Mount will look in the fstab file and if it finds an entry for /cdrom it'll go ahead and mount it with the options specified. Two other quick points: By setting up /a and /fd0 entries for /dev/fd0, and /b and /fd1 entries for /dev/fd1 I can easily mount floppies that are either in DOS or ext2 format by entering:
mount /a for DOS floppies or
mount /fd0 for ext2 floppies
And adding the " user " option allows me to mount the filesystem as a non-root user.
Slick, eh? Linux is excellent.
Managing your wandering system configuration filesI suspect that most people who are running Linux have found themselves, for better or for worse, the de facto sysadmin of their workstation. Yeah, it's cool to be root but it can also be a major league pain-in-the-butt .
Here's another two cent tip to make life easier.
If you've run Linux for any length of time you've probably ended up making a boatload of changes to the system. If you haven't done so already, you should probably made a subdirectory off your /root directory and put copies of ALL the system configuration files that were installed by your distribution.
So, you create a /config_dist subdirectory and start to collect some files:
The prepared mind.
One more suggestion...
After you've created a subdirectory to save all the original config files, create another subdirectory called /links. Now, for all of your widely scattered configuration files, create symlinks for them in your /links directory.
So, if you're messing around with trying to get your PPP setup going, make a link to /etc/ppp/options or /usr/lib/ppp/pppon:
cd ~/links
ln -s /etc/ppp/options ppp_options
ln -s /usr/lib/ppp/pppon pppon
Now, when you cd to your /links directory, you'll find symlinks to your various config files. Then, if you need to make any further changes in them, you can easily do so from anywhere in your system by entering vi ~/links/ppp_options. Having all the system configuration files symlinked to one directory makes housekeeping a bit easier. Some further ideas about what to include:
Thing is... why go through all the bother of doing this by hand when you can create a simple shell script that makes life MUCH easier.
Two cent tip: if you have a long, repetitive task then think seriously about writing a shell script to automate the process. Remember: you're not running MSDOG, this is Linux. Try something like:
#!/bin/sh # # program: hack # author: johnMfisk 7 july 1995 # purpose: create a backup and a symlink to an important system file. # CURR_DIR=`pwd` cp $1 "/root/config_dist/$1.dist" ln -s "$CURR_DIR/$1" "/root/links/$1" vi $1 exit
Don't forget to " chmod 700 hack " when you're done. Then, every time you need to alter a system configuration file, you simply enter in:
hack important_sys_file.cfg
Hack creates a backup copy in your /config_dist directory with the " .dist " suffix; then it creates a symlink to the file in your /links directory; and finally, it fires up vi (or whatever other editor you like) and let's you make your changes. This is a pretty barebones example, and you could easily spiff it up by, for instance, testing for the existance of the file in your /config_dist directory and not copying over it if it already exists, or asking for permission to copy over it.
Accessing Linux from DOS!?Face it, a lot of folks who use Linux are actually converts from other OS's such as DOS or Windoze. And in reality, a lot of folks are actually in the multiple-OS catagory. There's a lot of software that we've spent good money on or just simply like that either can't be run, or doesn't run well, under a non-native OS. The simple fact is, no one OS is perfect enough to run everything you'd like to run (and that goes double for Bill Gate$ and Co.)
Fortunately, Linux comes with filesystem support for accessing your DOS FAT partitions. It'll read from and write to your DOS filesystem. There's also work that's ongoing to provide both DOS emulation (DOSEMU) and Windows 3.1 emulation (WINE) that would allow you to run your DOS and Win 3.1 programs directly from Linux. If you're interested in this kind of thing check out the Linux Documentation Project web page for HOWTO's and other information.
At present, there's a handy little program called ext2tool.zip written by Claus Tondering that'll allow you to access your Linux files from DOS. It's a bit shy in the looks department, but it seems reasonably sturdy and functional. It supports the ls, cd, cp, and cat operations and includes a small utility that helps identify your Linux partition number -- you'll need it to set up the E2CWD variable.
To set it up simply unzip it into a directory, I put it in its own \ext2tool directory for the sake of tidiness, and then follow the guidelines in the README file. About the only thing you'll need to do is set up the E2CWD variable:
[from the README]
Before you use the ext2 tools, you must set the environment variable
E2CWD using a statement similar to the following:
SET E2CWD=129:5
or
SET E2CWD=129:5:234
The three numbers after the equals sign are interpreted thus:
The first number (129 in the above example) identifies the physical
disk on which the ext2 file system is located. The number is used as
the second parameter to the DOS biosdisk() routine. Typical values
are:
0 for A: disk
1 for B: disk
128 for first hard disk
129 for second hard disk
(Your BIOS may use different values, especially if you have an SCSI
drive.)
The second number (5 in the above example) is the number of the disk
partition on which the ext2 file system is located. This number is
typically part of the Linux file name for the disk device. If, for
example, you are used to referring to the disk as /dev/hdb5 under
Linux, the partition number is 5. The E2PART program can help you
identify the partitions.
The third number is the inode number of the directory that is to be
your current working directory. If this number is omitted, 2 (the root
inode number) is used. If you don't know what an inode is, don't worry.
Just omit the final number from E2CWD.
Since my Linux partition is on the first harddrive and on the /dev/hda6 partition I just entered:
SET E2CWD=128:6
in my c:\autoexec.bat file and everything worked fine.
It's actually easier than it looks and, once you've set things up, it works pretty well. As mentioned before, to get things back into Linux you'll need to reboot and then copy it from from DOS since ext2tool doesn't support writes. But then again, who'd want to spend much time in DOS anyway... ;-)
Rolling your own kernel... it ain't that tough!For some people, the idea of compiling their own kernel gives them the willies and wads their shorts in a knot.
The good news is... it really ain't that tough.
The reason is simple: the guys who spend their time hacking away on the kernel have done a pretty good job of making everything work right. The actual task of rolling your own kernel is technically quite simple. There is, however, one small
Caveat: you have to know what you're doing.
That said, let's see what you'll need to do in order to know what you're doing. The heart of the matter is the step involving the " make config " procedure. It's during this step that a script is run that asks you a series of questions about what you want compiled into your kernel. Options include
If you have a Logitech bus mouse, a GUS sound card, and run a PPP dial-up connection, then you really don't need support for NFS, Ethernet cards, or cdrom drives. If you answer one of the configuration questions incorrectly, it's not that the kernel won't work... it will either have drivers included that you can't use (kernel too large and takes up more memory), or it will lack some option that you really need -- such as support for your bus mouse.
So where do you go to learn?
An excellent place to start is by reading Brian Ward's very helpful Kernel-HOWTO which can be found, with an entire reference shelf of other HOWTO's, on the Linux Documentation Project's HOWTO section. Brian takes you through the process step by step and explains what each of the options entails. Another helpful place to find information and advice is in the Linux sunsite kernel directory. Several authors have written programs specifically to assist with compiling your own kernel.
And don't forget printed material. Matt Welsh and Lar Kaufman have written an excellent book that needs to be on everyone's bookshelf called Running Linux (Published by the folks at O'Reilly). At $24.95 this is an absolute steal for over 500 pages of instruction, tips, tricks, and step-by-step howto's. If you don't have it, get it.
Once you've done your homework, the technical part is quite straight forward:
ln -s /linux-1.2.x linuxmake mrproper ; make config ; make dep ; make clean ; make zImage
That's it. You'll see miles of script go whizzing by your screen and then a series of questions will begin, asking you how you want your kernel configured -- you're in make config. Answer the questions and when it's done it will set about compiling your new kernel.
How long will it take?
/usr/src/linux/arch/i386/boot
It'll be called zImage and is usually at the bottom of your directory listing. There you go! you've done it!
Now I'll bet you want to try it out, eh? First, a couple caveats!
Caveat #1: make absolutely sure you have a working boot disk before you do anything else.
Caveat #2: make sure the boot disk actually works!
Caveat #3: make a backup copy of your current working kernel image (usually, /vmlinuz) and put it in a safe place.
Now, rename you current kernel image -- e.g., mv vmlinuz vmlinuz.bak and then copy the new zImage kernel to the root partition or wherever you put your kernel images -- e.g., cp zImage /vmlinuz.
You may need to chmod 400 vmlinuz to set the proper permissions and then don't forget to rerun LILO! -- e.g., /sbin/lilo. Once you've done all this, you're ready to reboot.
Ok, go ahead... you can do the old shutdown -r now and keep your fingers crossed!
It didn't work??!!! Arrgghhh...!! But don't fret, it's fixable. If your system yurks up on your new kernel for some reason simply reboot using your boot floppy and then copy your old kernel image, which you put in a safe place, back into the root directory and rerun LILO -- e.g., /sbin/lilo.
You should now have your old kernel image safely in place and can reboot your system off the harddrive once again. But keep reading... we'll look at some ideas for safely and easily test driving a new kernel in the next section.
Test driving your kernel the safe wayNow that you've had a run at compiling your own kernel, it's time to try it out and see whether it actually works. Simply copying over your trusty old kernel is... well, maybe just a bit brash, unless you really know what you're doing, or you really are a thrill-seeker. If you're either of the above you can probably stop reading here.
For the rest of you, keep reading.
There are two rather easy ways to try out your new kernel:
To create a useable boot disk simply copy the zImage file that's in your /usr/src/linux/arch/i386/boot/ directory to a floppy:
cp zImage /dev/fd0
to install it onto a disk in your first floppy drive. Keep in mind that this is a bit of a kludge as it will wipe out any filesystem that exists on the disk. It also goes without saying that you'll want to do this on a floppy that doesn't have any important stuff on it. Copying this to the floppy that had your 327 page doctoral dissertation in LaTeX2e format on it is probably not a good idea.
Then, to try it out just reboot with the usual shutdown -r now and sit back and enjoy. Keep an eye out for any error messages that may crop up during the boot process. There is a utility you should be aware of if you're messing around with kernels -- rdev, which allows you to set certain boot time options for the kernel. These include such things as which partition to set up as the root partition and as the swap partition, the root flags (read/write or read only), the bootup videomode, the ramdisk size, and the byte offset to use. You'll probably not need to adjust your kernel as it will likely point to the correct root partition. If it doesn't, then you can enter:
rdev /dev/fd0 /dev/hda6
for example, if your root partition is, in fact, the /dev/hda6 partition. You might, however, want to issue the command:
rdev -R /dev/fd0 1
This sets the root partition as read-only at boot time so that the filesystem can be checked prior to being mounted. If you forget the exact syntax of the command entering rdev -h will pop up a short help screen to jog your memory.
Now, once you know for sure that your new kernel works -- it actually let's you mount your new CDROM, or dial up your PPP link -- you can go ahead and make a back up copy of your trusty old kernel, put it in a safe place, and copy your zImage file into your root directory. And don't forget to run LILO -- i.e., enter /sbin/lilo at the command prompt. If you don't, and you're using LILO as your boot manager, you probably will not be able to boot your new kernel, even if it works correctly.
The other method is to simply add a stanza to your lilo.conf file that will let you choose to boot either your usual kernel (often, /vmlinuz in your root directory) or a new kernel you've just compiled.
You'll need to edit your /etc/lilo.conf file. It might look something like:
# LILO configuration file # # Start LILO global section append="sbpcd=0x230,SoundBlaster" # this is for my SoundBlaster CDROM boot = /dev/hda6 # name of device where LILO installs itself #compact # faster, but won't work on my system. delay = 5 # wait time vga = normal # force sane state ramdisk = 0 # paranoia setting # End LILO global section # # My normal Linux set-up -- boot from /vmlinuz # image = /vmlinuz # normal kernel in root directory root = /dev/hda6 # my root partition label = Linux # boot time label read-only # Non-UMSDOS filesystems should be mounted read-only for checking # # Stanza to allow test driving of new kernel images # image = /usr/src/linux/arch/i386/boot/zImage root = /dev/hda6 label = zImage # what I'll call the test kernel read-only # Same as above # Linux bootable partition config endsSuffice it to say that configuring LILO, and actually getting it to work, can be a bit hairy at times. This is one file you definitely want to have a boot disk and a backup copy of before you blithely wander in where angels fear to tread. Having done that, however, you should only have to make minor additions to your /etc/lilo.conf file to get things working.
What you'll need to add are primarily in the last 5 lines of the example above. You'll need to add a stanza for the new test kernel. The image entry indicates where the kernel image is located. In this case, it points to the directory where the new kernel is found after you've compiled a kernel with the make zImage command. Kinda tidy, eh?
The only other required entry is the label, which is what LILO will use when it asks you what you want to boot. The remainder of the entries, such as root or vga can be left out and the options included at compile time or set using rdev will be used. If you're a bit on the timid side and don't want to hack away too much, you can safely enter just the image and the label entries and things should work all right. Last, but not least, don't forget to rerun LILO -- i.e., simply enter /sbin/lilo at the command prompt and you should see something like:
Adding Linux * Adding zImage
Now, after you reboot, simply hold down the Shift key as LILO starts up and it'll prompt you for which kernel you'd like to boot. Hitting the Tab key will present you with a list of options. So... go ahead and enter zImage and, if everything went as planned, voila! a new kernel. Using either of these methods allows you to try booting a new kernel without disturbing your present setup. If things don't work you can either remove your test boot floppy or tell LILO to boot from your previous kernel.
Well, that's it!Hope you enjoyed this premier issue of the Linux Gazette. I've tried to make every effort to ensure that the information presented here is up to date and correct. Please let me know if there are any glaring oversights or errors in this. Also, if you have suggestions, comments, or critisms let me know.
If there's any interest in this, I'd be happy to keep writing new editions.
Back up to Linux HomeBoy WebPage