Last update: January 27, 2001

These notes describe insights I gained while learning about and installing Linux. They were written pretty much as the discovery process was happening, although I went back and filled in the blanks and made corrections later.

In a sense, this is my log. I strongly recommend that you keep a log as you go through this process (not to mention others). Odds are that you'll do a number of installs after which a long time may lapse before you do another one. During your first foreways, you'll remember things, but later you'll forget. You may have lots of Linux administration reference books around, but the record you keep yourself may be your best reference down the road.

I'm a student in Seneca's Linux System Administration post diploma program. No doubt, others possess more insight and expertise in these matters. But before you chuck this document away, consider this: I wrote these words with the advantage, perhaps, of being in your shoes. If you're just starting out with Linux and you have serious interest in it, then you're in the same situation that I was in just days or weeks ago. So, just maybe, I know where you're coming from.

If your attitude is
• "I need to know what button to push", then you're in the wrong place.
• "I need to know what's going on", then read on.

There are a few Seneca-centric comments here. For the most part, however, the issues addressed are relevant to anyone with a responsible interest in these matters.

This document is not a "how-to". It's not a recipe. It's not a blind list of step 1,2,3. The emphasis is moreso on what and why. The challenge here is to help you learn what's going on, what it's all about. I suggest you print this out and read it like a text book.

You should be able to understand and appreciate everything you read here. If you don't, it's my fault. Please let me know.
Send your comments to alan@ComputerAdvocacy.com
Ok. So let's start!

A tip-of-the-hat to our instructors who decided that our first install should be SuSE. Not only does 6.4 come with 6 CDs, but its documentation probably puts the other distributions to shame.

Seneca provides machines in Room 2123 but there's a problem. As part of your installation work, you need to make mince-meat out of the hard disk. (Excuse, me, I should say "custom configure".) To address this, they've built those machines with hard disk enclosures that slide out so you can slide in your very own hard disk.

You have to acquire your own disk for this purpose. But the challenge you may face is getting a hold of one of those slide-in enclosures. They cost about $27.00. The BookStore is supposed to have them. Don't be surprised if they don't. Consider this part of your real world education. Make sure you get the very same one that Seneca is using.

And be very careful with your disk. It's extremely sensitive. A 1.5 inch drop might be all that's necessary to destroy it.

It's really nice -- and you should grab the opportunity -- to do O/S installs with the comforting thought that it doesn't matter. I recently did a second SuSE install on the same hard disk as the first -- and royally screwed it up. But I had the luxury of not caring all that much.

Installations can be nerve racking. FDISK is a word which can strike fear to the heart. You'll have enough pressure to deal with tomorrow. Today, take advantage. Play. Make mistakes. Heck, make mistakes on purpose. (That's the best way to learn.)

YaST2 is the GUI install. I think they've put more effort into it for the benefit of us dummies. I used that one first, but I did them both.

YaST2 provided more help along the way. For example, it told me what network card it detected rather than just asking me to specify what it is. It let me specify my disk slicing in the same phase as I specified my mount points. YaST1 makes them separate operations.

• Keep notes as you go.
• These things take time! When you do an install, make sure to include the clock times in your notes. Don't start an install unless you have plenty of time available.
• For these several reasons, you do want to have the X11 files copied to your system but you do not want to engage in a time-consuming and thoughtful X11 configuration just now.
  • For the SuSE install, you can say "No X11". The files will still be copied to your system so you'll be able to configure X11 later.
  • In the Red Hat install, however, if you say that you don't want X11, it won't even copy the X11 files to your system, meaning there won't be anything for you to later configure. Ok. So you should elect to install X11 and you'll have to deal with Red Hat's "X-configurator", but you can choose to minimally do so. ie: you needn't think too much about the choices it presents. Just choose minimal things that you know will work, because you'll be changing them all later.
  • The SuSE, RedHat, etc distributions are all different. But the X11 configuration need not be done with their installers. The XFree86 installation routines are just as nice - I think they're better. And it's the same regardless of which Linux you're using.
  • Why learn about several X11 configuration tools when one is applicable to all distributions?
  • This is going to take long enough as it is. Better to break it up into two sittings.

Ok, so you're not expert. Now is the time to become one. Microsoft pretends that things are easy by not giving you choice. Here, at least, you have a choice.

By the way, partition is a Microsoft word. The Unix world likes slice. That's fine by me, as long as you don't think of a "slice" as something wedge-shaped, like a piece of pie.

As the Linux installation procedure guides you through disk partitioning, it eventually runs FDISK. (You won't necessarily see it, but it does.) Conceptually, Linux FDISK does much the same as the FDISK from DOS. It carves up your disk into slices or partitions.

In DOS, partitions translate into things like "C:" and "D:". You never actually specify which partition will be "C:" and which partition will be "D:". When DOS boots up, it assigns those labels on the basis of a few rules. For example, the first partition may be "C:", the 2nd "D:" and the 3rd "E:" If you subsequently blow away the 2nd partition and then reboot, you'll find that the 3rd partition, which used to be called "E:" will now be called "D:". The "labels" (Unix calls them "mount points") aren't stored anywhere. They are computed at boot up time.

Unix doesn't use this approach.

In Linux, information describing the nature of each partition is stored in a file called /etc/fstab as in file system table. There, rather than single letter labels, mount-points are called things like /home and /usr. (A mount-point always begins with a slash.)

As we'll see shortly, FDISK (be it DOS or Linux FDISK) speaks of partition types as being primary or extended. So for example, we might say of a particular disk, that its 2nd partition type is primary.

But there's a terminology problem here.

That 2nd partition may be formatted, for example, with a FAT16 or FAT32 file system. Depending on the context of our conversation, we might thus say that the 2nd partition is of type primary and/or we might say that the 2nd partition is of type FAT32. Thus, if I say "type", it may not be obvious what I'm talking about. It would be more accurate to say "file system type" and "partition type". Unfortunately, the single word "type" is often used and you have to figure out what's meant on the basis of context.

The same terminology problem exists in Unix.

Linux FDISK allows for many different file system types. The most common is ext2

To make matters worse, Unix has a file system type which really isn't a file system at all! It's called the swap area. Most Unix systems should have a swap area. Its "file system" is called swap. It's a partition. You decide how big you want it to be.

The swap area is used by the O/S when it needs more RAM and there isn't any available. The swap area could, in fact, be described as very slow RAM.

Windows 9+ has a swap area, but you might never see it. DOS implements its swap without consulting you. When the system boots, DOS sizes its memory and computes how big it thinks its swap area needs to be. It then creates a hidden file on disk of that size.

There's something important that you should note here. We've just discussed two things that are examples of a fundamental difference between DOS and Unix.

• In DOS, drive letters (Unix uses mount-points) are assigned without your say-so.
• In DOS, the swap area is assigned without your say-so

The general comment is that Unix gives you the ability to more specifically choose what goes on. The implication is that you are required to know about those choices.

DOS makes things easier because you need not choose. In fact, you often don't have a choice.

Let's look at one of those choices: the way you choose to partition your disk.

• It's safer. If one slice gets clobbered, other slices may still be ok.
• It's more secure. Access can be restricted to certain slices.
• Data on your system will obviously change. Some parts will change often, others little or not at all. Isolating things into slices may provide you with some protection in the event that your disk becomes cramped.
• Data in a particular slice cannot possibly grow in size beyond the capacity of the slice that contains it. This may be helpful at backup time, particularly if your backup device (a tape drive for example) itself has limited capacity.

A disk can have up to 4 primary partitions or slices.
Well that's not entirely true... You see, one (and only one) of those primary partitions can be an extended partition instead.

"So big deal", you say. "I can either have 4 primary or 3 primary and 1 extended slices. The total is still 4 isn't it?"

Yes and no.
In one sense, yes it's true that there cannot be more than 4 partitions. That's because of the structure of the Master Boot Record. Let's talk about that for a moment and then we'll see how we can get around this limitation.

By design, the very first 512 bytes of a disk, called Master Boot Record or MBR, is specially formatted.

• The first 446 bytes are reserved for program code. When the computer starts its "boot-up" process, it knows only that if it goes looking there, it will find its first set of instructions which will tell it what it should do next.
• The next 64 bytes are divided into 4 16-byte address locations. Each is the address of a partition. Without this table, no filesystem can exist.
• The last 2 bytes contain the "magic number" hex aa55. (The 446 byte code segment may vary, the 64 byte partition table may vary, but this magic number won't.)

It would appear that we can't have more than 4 partition/slices because there isn't room in the MBR to store more address locations.

The difference between primary and extended is that the extended partition is almost like a disk within a disk. It can be itself divided up into what are called logical partition slices.

The extended slice isn't hampered by any fixed-size table of address locations however. Instead, at the beginning of the extended slice, there's a single address that points to where the first logical slice begins.
At the beginning of the first logical slice, a single address points to where the second logical slice begins.
At the beginning of the second logical slice, there's a pointer to the third, and so on in daisy-chain fashion.

So you might have... hda1 A primary 200Mb slice hda2 A primary 200Mb slice hda3 A primary 200Mb slice hda4 An extended 1,000Mb slice that itself consists of 5 other 200Mb slices. This 1,000Mb extended slice consists of 5 logical slices ie: hda5,6,7,8,9

Start End hda1 1 200 hda2 201 400 hda3 401 600 hda4 601 1,600 hda5 601 800 hda6 801 1,000 hda7 1,001 1,200 hda8 1,201 1,400 hda9 1,401 1,600

So far, I've described slice measurement in terms of Megabytes. However, the proper units of measurement more closely reflect what the disk really looks like.

A disk more closely resembles a circular platter with a hole in the middle of it. Attached to a motor is a spindle that goes through that hole and makes it spin at speeds such as 3600, 4500, 5400, or 7200 rotations per minute. (E)IDE disks available today rotate as fast as 10,000 rpm and SCSI disks may rotate as fast as 15,000 rpm.

Here's an analogy that's not quite right, but it'll help explain a few things.

My record turntable spins at 33 1/3 rpm. (Are you old enough to know what I'm talking about?) At first glance, you might think there are a lot of grooves in an LP record. Surprise. There's only one. It starts at the outside of the record and spirals in until it reaches the centre. A needle (I'll use the term read/write head later) sits in that single groove and vibrates according to the tiny bumps in the groove as the record turns beneath it.

Song sections (I'll use the term sector later) follow each other along this one groove. The medium is essentially a sequential device. Although I could physically pick up the tone arm and randomly move the needle to the 4th song, there's no way that my record player could choose to do that itself.

I think we've reached the limit of this analogy. So let's leave it aside for a moment.

A single platter disk more closely resembles a racing track consisting of many separate lanes or tracks laid out in concentric circles. Tracks are numbered. The track on the very outside of the disk is called Track# 0. Typically, a floppy disk has 80 tracks. A hard disk may have thousands of them.

Each track is divided into sectors. Each sector has a storage capacity of 512 bytes. Eventhough Track# 300 is physically longer than Track# 0, all tracks have the same number of sectors. They are just spaced apart differently.

Imagine that this racetrack is turning. The finish line is a retractable rail mounted on a post just outside all the tracks. Mounted on the end of the rail is a camera that points down. The retractable rail with the camera on its end can slide in and out, across any number of lanes, thus positioning itself over any one of the tracks. Once positioned over a track, it can take a picture of any of the sectors that belong to that track as they pass beneath it.

Hmmmm.. we're about to push this analogy beyond its limits too... Why?- because our single platter disk has two sides: top and bottom. Hmmm.. You'll have to imagine that the Australians are running upside down on the bottom of each track and that there's a second camera available to take pictures of the sectors of those bottom tracks.

While we're at it, it's time to call these cameras "read/write heads". The same motor moves both read/write heads to the same track and sector of each surface.

Our disk is a single circular platter consisting of some number of concentric tracks. Each track holds some number of sectors. The number of tracks and the number of sectors per track are characteristics of the specific disk. Regardless of the disk, however, each sector holds precisely 512 bytes of data.

Let's say our disk has 100 tracks and that each track has 10 sectors. What's its storage capacity?

Well, 100 tracks X 10 sectors/track is 1,000 sectors. Since each sector is 512 bytes, that's 1,000 X 512 = 512,000 bytes on each surface. Since our single platter has both a top and bottom, our disk has a capacity of 2 X 512,000 = 1,240,000 bytes.

We're going to get confused unless we're careful. We just said that our imaginary disk had 100 tracks. Is that quite true? After all, there are 100 tracks on the top, but there are another 100 tracks on the bottom! Does that mean that there really are 200 tracks?

Well, Yes and No. There really are 200 tracks for recording data.

However, when we speak of "number of tracks", we're referring to "number of tracks per surface". Our single platter disk has two surfaces: top and bottom. Things get even more interesting when we consider multi-platter disks.

Our single platter disk had two read/write heads in order access each of its two surfaces. Let's extend that idea. Imagine 4 platters. They are both the same size, they are spaced slightly apart and they turn on the same spindle. Each has a top and a bottom. So now we have 8 surfaces and 8 read/write heads all on the same motor to access them.

Draw the 17th track. You should have drawn a circle. But what about the 17th track on the 1st platter and the 17th track on the 2nd, 3rd and 4th. For that matter, remember that each surface has a top and bottom, so we'd end up with 8 circles, one on top of the other.

In 3-dimensions, these 8 circles, one on the top of the other, would look like a cylinder. You might say that "tracks" is a 2-dimensional thing whereas "cylinder" is a 3-dimensional thing. If a disk has 80 tracks, it has 80 cylinders. However, when we refer to (say) the 11th cylinder on a 4-platter disk, we're referring to the 11th track on the top of the 1st platter, the 11th track on the bottom of the 1st platter and, indeed, the 11th track on all of its surfaces.

Cylinders may be easier to picture where you have a lot of platters. However the term is used even if you have only one platter, such as with a floppy disk.

The description of our imaginary single platter disk comes close to describing a floppy disk. Old, old floppies were low density and single sided. Density refers to both the number of tracks per side and the number of sectors per track.
Single sided quickly became double sided or DS.
Low density quickly became double density or DD.
After a while, double density became high density or HD.

	Heads (sides)	Cylinders	Sectors/ track	Capacity
5.25" DSDD	2	40	9	2 * 40 * 09 * 512 =	360Kb
5.25" DSHD	2	80	15	2 * 80 * 15 * 512 =	1200Kb
3.5" DSDD	2	80	9	2 * 80 * 09 * 512 =	720Kb
3.5" DSHD	2	80	18	2 * 80 * 18 * 512 =	1440Kb

I bought a 20GB hard disk. 20GB certainly seems like a lot, but remember: you're going to want to install several versions of Linux or the latest version of Microsoft Office. This means you will indeed need a lot of disk space.

My disk has almost 2,500 cylinders. Let's assume I decide to allocate the 1st half to my first install and the 2nd half to my second install. Even if I elect to take the easy way out and do a non-expert install I'd probably be in trouble when it comes time to do my second install.

Once an O/S is running, life is sweet. But first, it must be booted. And it turns out that you can't boot anything that lives beyond cylinder 1024.

This restriction is gradually being removed. It has to do with the 24 bits worth of space used to store the address location of the boot partition:
     10 bits (max 1024) for the cylinder number
      8 bits (max 256) for the head number
      6 bits (max 64) for the sector number

The solution is two-fold:

• Don't put everything in root. The part of the O/S that boots is actually quite small. In the very least, create a /boot slice and the Linux installation will use that slice to hold only what's necessary to boot. A 10Mb slice ought to do nicely.
• Leave a hole. When you do your first install, make sure you set aside a suitable portion beneath the 1024 cylinder line for anticipated use by the /boot slice that your next install will use.
  
  When you specify a slice, the installer asks you to specify its start and end points. Usually you'd start the jth slice at the very next cylinder that follows the j-1th slice.

The SuSE manual, Page 107 also discusses the 1024 issue. (It's actually part of a discussion on LILO)

I can only speak first hand for SuSE on this issue, but it wouldn't surprise me to learn that other distributions have a similar problem.

Linux allows up to 63 slices on an (E)IDE disk. (And surely that's plenty.) However, my 2nd SuSE install choked when I tried to define hda16. Here's the message I got:

Could not stat /dev/hda16 - no such file or directory. The device apparently does not exist; did you specify it correctly?

Thank you very much, but "continue" was my only option. ("Yes" was not an option.)

One of the nice things about Linux (compared with Microsoft O/Ss) is that you do have the option of seeing what's going on -- even during an install. So I bounced to a virtual console with something like ALT-F2 and did
     ls -l /dev/hda*
where I found that the SuSE install Linux only had hda1 through hda15. In other words, the powers that be at SuSE arbitrarily chose to provide only 15 hda's. (I'm told they aren't the only ones.) So, it was no wonder I got that error message.

Ross Tucker tells me that appropriate commands are needed to make these missing nodes. Linux, being a multi-tasking system, allows you to do this even while you're doing the Linux installation. I havn't tried it yet, but the commands are something like this
      mknod -m 660 /dev/hda16 b 3 16
      mknod -m 660 /dev/hda17 b 3 17
      mknod -m 660 /dev/hda18 b 3 18
   (Ownership commands such as
      chown root.disk /dev/hda17
   are unnecessary since, as the installer, you are root already.)

When you run FDISK in the DOS world, you specify your partitions and that's pretty much it. As far as the drive letters are concerned, you have no say-so.

In the Linux world, you also have to specify the mount points of those partitions. This latter task is separate and apart from FDISK. The distinction may not be obvious because the installation procedure typically presents a single input screen for both tasks at the same time.

I was lead astray, thinking that, somehow, the mount points were going to written into the partition table. That's not so. They are written into the file /etc/fstab (as in file system table)

This next section documents how I chose to set up my slices. The SuSE manual, Page 58-62 provides some guidelines. Ross Tucker and Harvey Haldorson made some suggestions as well.

There are a number of "well known" mount points, such as /usr. There's nothing to stop you from creating a partition with a mount point such as /alan. Doubtless, the installation process won't put anything in /alan but there's nothing to stop you from creating it.

Eventhough there may be many partition slices, they all fit into a single directory structure. The top of that directory structure is the root (Think of it as an upside-down tree.) Unlike all the other mount points, the root of the tree is not called /root!
Its name is just /

A partition that may be mounted as /usr/local is accessed as a subdirectory of /usr eventhough /usr may be physically located on an entirely different partition.

I confess to being seduced as I saw the huge number of packages that were offered in the "Software Single Selection" screen. Soon I was getting messages like "/usr needs 24 more megs". Here's something that will help. Do this in the graphical YaST2.

After you've rightly or wrongly specified your slice sizes and their mount points, the "Software Single Selection" screen invites you to add or subtract other pieces you might wish. In the lower left hand corner of that screen, there's a small window that shows the amount of free space per slice that you've got.

Scroll up and down through that small window and note the free space you will have in each slice. Are you happy with those numbers?

For better or for worse, here's how I sliced.

Start cylinder			End cylinder	Size in MB	Type	Mount point
created	hda1	0	2	23	ext2	/boot	(primary)
did not create [*]	hda2	(3	4)
did not create [*]	hda3	(5	6)
2GB hole just for fun
created	hda4	269	982				(extended)
created	hda5	269	294	204	ext2	/ (root)	(logical)
created	hda6	295	556	2000	ext2	/usr	(logical)
created	hda7	557	687	1000	ext2	/opt	(logical)
created	hda8	688	818	1000	ext2	/home	(logical)
created	hda9	819	949	1000	ext2	/var	(logical)
created	hda10	950	982	259	swap		(logical)

[*]

I actually did create hda2 and hda3 each sized at 1 cylinder and then went back and deleted them. It really wasn't necessary. It was not necessary to fool the installer into producing an /etc/fstab stating (or rather implying, conspicuous by its absence) that there is no hda2 and hda3. My thinking was to make it obvious to anyone looking at /etc/fstab that this is physically where I intend to later put 2 other boot slices.

(An "almost everything", which is everything except sources, requires about 5G for /usr and 2.5G for /opt)

Yes, it did work. But the truth is, I didn't do it quite this way at first. In trying to be efficient and in anticipation of Install #2, I erroneously felt I could re-use some areas from Install #1. The idea wasn't bad. Some areas can be re-used. It's just that I chose one that can't unless you really know what you're doing.

At least one slice, the swap area can be re-used for Install #2.

You see the gaps for hda2 and hda3? They are there (now) in anticipation of /boot slices for Install #2. (Notice that they are well below the 1024 mark.) But they weren't there before. I erroneously felt that /boot was a re-use candidate. It isn't.

During install, Linux writes its kernel with a typically predetermined name such as vmlinuz into /boot. So my vmlinuz from Install #1 got overwritten by Install #2. Oh well.

Perhaps /tmp is a candidate for re-use. Well, you'd have to decide how "temporary" is /tmp. If your sys-admin policy is that everything in /tmp will be deleted whenever the system starts up, it's safe. What might happen if that's not the case? Well, Linux doesn't know that a file in /tmp is owned by "Alan". Instead, it knows only that user number 1234 owns that file. So, if 1234 is Alan on one system but 1234 is Mark on the other system, you'd be in trouble.

Yet to be done:

• Finish installation section
• Principle directories and mount points
• Walk through
• Issues regarding hardware differences: home vs school
• Configuring X11
• Boot diskettes