Thoughts pertaining to the typical hobbyist-level user:
ASSUMPTIONS:
I'll assume you want to boot Linux off a hard disk and not only off a floppy. (The latter gives you more flexibility.)
I'll assume you know that "lilo" refers to both the program you use to install a lilo boot sector and that sector itself.
I'll assume you have only one hard disk. (It's not much different if you have two.)
PARTITIONING:
You can only have four primary partitions.
You should always MAKE four (on the primary disk at least); you'll likely regret not doing so a few miles down the road.
Usually, the first one is reserved for M$ OSes because, at least in the past (NT31), some of them have required its use.
Certain of the files in your Linux /boot directory need to be placed below the 1025'th cylinder. (This might not be true for some recent BIOSes; I don't know, but it's a safe bet.) There are several ways to ensure this, but having a root (/) directory partition completely below the 1025'th cylinder is the most common method.
Your disk may have several boot sectors. The one always used is called the MBR and it may be a M$ one or a lilo boot sector. There can be an additional boot sector for each of the primary partitions, including the extended partition but excluding a swap partition. (Putting lilo on a non-Linux primary partition would probably make it useless for anything else.)
The standard M$ MBR starts a boot from the boot sector of the first primary partition which is marked "active". Other MBRs including lilo MBRs (or any other lilo boot sector) allow the selection of another boot sector (other OSes by name) from the console during bootup.
Installing a lilo MBR avoids the need to mark active a partition with a lilo boot sector (or use another boot- manager type MBR), but it does require an extra step should you ever decide to use something else as the MBR.
Most people using Linux prefer to intall the lilo boot sector as the MBR or on a root (/) primary partition marked active and below cylinder 1025.
The lilo boot sector must be on one of the first 1024 cylinders.
The fourth primary partition should be an "extended" type partition which extends to the end of the disk. This partition can be divided into many small logical partitions or a few large ones, depending on your philosophy of filesytem apportionment to partitions (see below).
A logical partion should be created for use as the Linux "swap disk". (Linux can use a file for this purpose, but that is not efficient in use and wastes backup space unless steps are taken to avoid it.) The size of the swap partition should be "memory needed" minus "main memory". Emacs and Netscape running together with X-windows, system daemons, and a few other small programs, uses 20-some megabytes; heavy-duty graphics and computational programs will require more. It's your guess. Most people nowdays reserve a bunch even if they don't need it. You can also make (and use) more than one or make it very big and change things later. There is a limit of 16 swap partitions/files and a limit on the size of each to no more than 128 MB.
It's not a bad idea to make a small (30-50 MB) partition to install a minimal Linux OS which you use only as an emergency OS to repair damage to your other filesystems. To be extra safe, you'd make this emergency OS boot from a backed-up floppy with a lilo boot sector incase the hard- disk lilo gets damaged. This scheme is easier and probably safer than hoping you've got "rescue" floppies available with all the programs needed to do your repair work. Of course you should have those too, in case everything gets messed up.
If you've lots of room, consider making pairs of partitions so that one can be backed up to the other. This is nice to be able to do before making upgrades or other changes to some of your files or directories.
FILESYSTEM APPORTIONMENT TO PARTITIONS:
Some people prefer the simplicity of a single partition for everything. Others prefer, or eventually need, to have certain directory trees on separate partitions. The Linux file system standard has many good things to say about this and other subjects.
The main reasons for using separate partitions are: 1) When an unimportant partition fills, important ones won't be affected. 2) One can easily restrict searches or backups to certain partitions. 3) One can mount some partions read-only so they can't be harmed, by OS upgrades for instance. 4) Some sets of files don't change much in size and can be isolated on a fixed-size partition which needn't be changed when other sets of files outgrow their partition and need to be reapportioned to new or other partions.
Inter-networked Linux systems can be organized for sharing partitions, but I'll assume that is not needed here.
Linux systems with many users need to worry about the filling-up of certain dir trees with mail, news, etc, but I'll assume that's not an issue either.
Most recommendations are to put /, /home, /usr, and /usr/local on separate partitions as an minimum. The idea is to keep / fairly small and seldom changed so the basic OS files are unlikely to be damaged and the OS will boot even if the other partitions are corrupted. I suspect few systems follow the rules closely enough to do this, so the main reason to separate /usr is so it can be easily moved to a larger partion if needed. /usr/local is kept separate so it can be protected from OS upgrades. /home is kept separate because it is theoretically the most devorced from the OS and "unimportant"!
My theory for a single- or few-user system is to have these partions: 1) a small (50 MB) partion, for /. 2) a partition sized a little larger than needed for a reasonably full installation off the OS install disks, for /usr. 3) A partition using the rest of the disk except the last partition, to hold all "add-on" software in /usr/local. 4) A partition sized large enough for files that will be written or created by users and the system software, for /var and /home. Unfortunately, those using Red-Hat- packaged software add-ons will find RMPs seldom put things in /usr/local where they belong, so one is better off leaving /usr/local on the /usr partition so all add-on files (from RPMs and tarballs) can feed from the same trough, so to speak. This layout allows all partitions except the one for /var and /home to be mounted read-only during normal user operation. (Those without kid users probably wouldn't bother.) The main advantage to this scheme is that it lets all of the add-on- install-time dir trees "feed from the same trough", and all the user-run-time changable dir trees do the same (from a different trough). The benefit is that user operations won't fill one user-operations partition while there's still room on another (there is no other). Same for add-on software operations.
One problem with the previous scheme is that the lame Unix filesystem mounting scheme makes it impossible for multiple "/*"-level directories to share a partition. My solution is to mount /var and create a /var/root directory to hold /var/root/home and have /home point to /var/root/home. /var/root is created (and should be maintained) to look like / except that all enteries other than "home" are links to /* files. This messiness is only necessary so that people (like Red Hat folk) who use links to ../../../foo/bar won't find them broken. If one assumes these won't be used under "home", one can put home at /var/home.