2 Hard drives, but boot is mounted on smaller drive

Ok, let me start by saying I'm a newbie.

I installed RH 8.0, my system has two harddrives, I think. When I did a df -h this is the outcome
Filesystem Size Used Avail Use% Mounted on
/dev/hda2 36G 2.6G 31G 8% /
/dev/hda1 99M 14M 79M 15% /boot
none 251M 0 250M 0% /dev/shm

Being a newbie, my breakdown of this is that I have two harddrives 1-36GB drive, and one roughly 100M drive. The boot is mounted on the 100MB drive though. I thought I had my master as the larger one, but I could be wrong. A couple of questions, is there anyway to switch my boot to the other larger drive, and secondly how do I know where all my programs are installed under. I am a windows user so I was wondering how I know what is stalled on which drive. Or is Linux's file structure totally different from Windows in that sense, and that question doesn't really translate.

Basically, if I have 2 physical drives, how do I know which data is on which drive?ex

It doesnt say that you have two harddisks - only one, i.e. hda. If you have two harddisks there will be hda and hdb. The one that isnt shown (as hda) is swap partition.

Both /(root) and /boot partition are on the larger harddisk (36GB) = hda. (You should check what is inside your box)

If you install e.g. kopete.rpm and want to know where those files go just type:

rpm -ql kopete
hint: /bin is the executable, but you can always call kopete to execute. Open menu editor and add the program shortcut/icon if it doesnt automatically create one for you.

If you want to see all rpm installed type:

rpm -qa

Just like in windows, if you have more than one harddrive you can just mount them. (on some distro it mounted automatically) e.g.

mount /dev/hdb1 /windows/C

Or create shortcut on desktop. On KDE right click anywhere on your desktop, Create new, Hard disk ...


Have a lot of fun :-)

Please excuse my retardo questions, but I've never manually installed an RPM. Anything that is in my system right now was installed initially when I installed RH 8.0, which probably means the RPM packages were installed automatically after I chose them. So in that sense, all those packages just went somewhere, and I have no idea where. But thanks for the explanation.

though the /hda1 and /hda2, what's up with the different numbers?

Indeed you have gotten some things wrong, and I'm preparing myself to rewrite the long answer to this question once again, in hope of finally getting it understandable this time. I'm really not a great teacher, but I'll do my best. This will be long.

First of all, let's go through the structure of your physical hard drives.
There are two major competing systems: IDE and SCSI. Almost all (the exceptions must probably be counted in units of ppm) home computers use IDE. SCSI is mostly used in servers and the like, and home users who like it. I think I can say for sure that no home computers at all are delivered with SCSI. So you most probably have IDE.
On IDE systems you have IDE busses. Each IDE bus corresponds exactly to one of these broad band cables that you have in your computer that goes from the motherboard to the hard drive. Each bus can connect at most two units to the controller board (usually the motherboard). The units can be hard drives, CD ROMs, IDE tape drives, etc. Each of the two units is referred to as the "master" and "slave" on the bus. You can have either a master or a master and a slave, but never only a slave. If you have only a slave, it will be as if it wasn't there at all. The master and slave setting is set on the hard drive itself. There is also a "cable select" (or CSEL) option on most hard drives that sets it automatically as master or slave depending on where on the cable it is. It's a bit easier to use, since you won't have to reconfigure each drive when you change their locations on the busses and so.
You can have a technically unlimited number of IDE busses; each bus is a system completely independent from the others. Motherboards come with two busses, referred to as the primary and secondary bus (or bus 0 and bus 1). You can then add extra IDE controller cards if you need more busses, which will then be referred to as the tertiary bus, quartenary bus and so on.
IDE drives are in Linux referred to as /dev/hda, /dev/hdb, /dev/hdc and so on. hda is the master of the primary bus, hdb is the slave of the primary bus, hdc is the master on the secondary bus, and so on. If you don't have a slave on the primary bus, the secondary master will still remain hdc, it's just that hdb cannot be used.

Let's continue with partitions.
Each hard drive can contain data. If you have a 36 GB hard drive, it will contain 36 000 000 000 bytes exactly (yes, hard drive manufacturers do divide by 1000, not 1024 as software developers do; this is the cause of much confusion). It will probably be another number that has been rounded to 36G, but let's stick to 36 000 000 000 for this discussion. The bytes are aligned in sectors, each of which are 512 bytes wide. When software reads or writes to the hard drive, it always does so with a number of sectors, individual bytes are never discussed by the hard drive. That means that this 36 GB hard drive will have 70 312 500 sectors. Each of these can be individually addressed with a number. Sector 0 is the first sector and sector 70 312 499 is the last sector.
While this can be excellently used to store data on, it's not quite that simple. Many people believe that however, probably because C: in Windows has an icon that looks somewhat like a hard drive. C: is, however, just one partition on your first hard drive.
The first sector on your hard drive, or sector 0, is called the MBR, or Master Boot Record, and it contains a partition table. You might say that partitions are "virtual hard drives". You can divide the data area of your hard drive into several partitions, each of which acts as a hard drive on its own, but is really just a part of the original hard drive. Most hard drives only have a single partition, though. If you create two partitions, you will in Windows get C: and D:, no matter how you create the partitions. That adds to the confusion a little bit. Here's how it really works:
The MBR can describe at most four partitions. These are referred to as the "primary" partitions of a hard drive. In the beginning, when IBM created their PCs, four partitions were far more than enough. As drives grew, more partitions were needed. Enter the extended partitions. One primary partition can be set to be an extended partition, and then several "logical partitions" in that extended partition. In Windows, you'll have C: and D: no matter if you have two primary partitions or one primary, one extended, and then a logical partition in that extended one. In Linux, the four primary partitions of hda will be referred to as hda1 through hda4. Commonly hda4 is used as the extended partions. All logical partitions will be referred to as hda5 and so on, no matter whether all primary partitions have been used up or not.
In your case, you'll see that you have hda1 and hda2. If you run "fdisk -l /dev/hda" you'll see all of your partitions (even those not mounted, like the swap partition) and where on the hard drive they begin and end.
hda refers to the entire drive, including the partition table and all partitions on it.

Now then, let's look at file systems.
So, how then does this relate to you home directory and the files therein? Now I'll just describe UNIX file systems, not that horrible Microsoft invention of FAT.
Each partition can contain a file system. A file system describes files and directories (and some more stuff, as we'll see).
The basics of a file system is a number of files. The root file system (I'll come back to that later) on the computer I'm using right now has 2 387 392 files, of which 238 537 are used. Each file has number, ranging from 0 to 2 387 391. That number is called the file's I-node (for Index Node). Each file can be a regular file or a directory (it can also be some more things, more on that later). A regular file contains data, which is arranged in bytes. A file can for example contain the text "Hello", which is 5 bytes, one for each character. It can also contain a program, but the data is nontheless arranged in bytes, only that if it is a program, you'll most likely not be able to read it (or it won't look like anything meaningful if you would read it, that is; it will, however, tell the system a lot). The standard "ls" program consists of 67 884 bytes.
In the beginning of file systems, file were referred to just like this; you might have wanted to get file #1534, because you had stored something interesting in there. People soon realized that it was a bit impractical, because it was pretty hard to remember the file's number. Therefore file 0, for example, it could be any file, but something that was easy to remember, could be made to contain a list of what files contained what. It could say something like this:
0: This list
1: Shopping list
2: Tasks for tomorrow
Maybe not precisely that, though... computers were used a bit more scientifically those days. However, when you wanted to open a file, you still had to refer to file #1534 when you wanted it, since it was the only thing the operating system knew about. After a while more, operating system developers realized that it would be practical to be able to refer to files by names, so they incorporated functions into the kernel itself that looked up the file number if you gave its name. File 0 became the directory of the file system, that mapped names to file numbers. That way no user of the system had to care about the numbers any more; they just had to open the file "shop", if they wanted their shopping list. However, there was still one large problem, namely that all file names lay in one large name space. There couldn't be two files called "shop", even though maybe two users wanted to store their shopping lists on the computer.
Thus, kernel developers designed the hierarchical file systems. The directory of the old file system was now called the "root" directory, which could contain directories of its own, each of which could also contain directories of their own and so on. By then using a character to seperate different directory levels, two users could each have their own home directory in which they could both have a file called "shop". In MULTICS, it could look like "usr>user1>shop" and "usr>user2>shop". In the earlier versions of UNIX it would be "/usr/user1/shop" and "/usr/user2/shop". Nowadays it is "/home/user1/shop" and "/home/user2/shop" in UNIX. Under MacOS it looks like "usr:user1:shop" and "usr:user2:shop" (provided that those would be the directories' names).
Anyhow, it is still very important to note that "/home/user1/shop" is just _a_ name of the file. "shop" is just the name of the entry in the "user1" directory. It still refers to file #1534, even though it might not seem like it. If you run "stat ." in your home directory, you will find out what I-node (or file number) your home directory has. Mine is #32 769. This means that a file name can be mapped to a file, but if you just have the file, you don't know its name. There are only one way mappings. It also means that a file may have two names. For example, the file names /bin/gzip, /bin/gunzip and /bin/zcat commonly refer to one and the same file (#294 443 on my computer). Run "ln file1 file2" to create a file name file2 referring to the same file as file1 refers to.

Let's get on to mounting, then.
What if you have two file systems, each of which contains a file named "shop" in the root directory? You can't be referring to both of those files if you try to open "/shop", right?
The answer is that you have a "root" file system, that is mounted automatically when the kernel boots. Each file system has a root directory, but the running system only has one, and that is the root directory of the root file system.
In your case, you have file systems on hda1 and hda2. Note that the file system on hda1 isn't your root file system, but it is mounted _as_ the root file system. That means that the root directory on hda1 is mounted on the system's root directory. The root directory on hda2 is mounted as /boot.
That means that in the file system on hda1, you have a directory called "boot". Note, however, that it is empty; it has no directory entries. The file system on hda2 is then mounted on that directory, making all accesses to /boot instead refer to the root directory on hda2. If you run "mount", you will see all file systems that are currently mounted.
There are also "virtual" file systems, such as the proc file system, which is usually mounted on /proc. That means that there is no device backing the files in /proc; the files in /proc don't really exist, they are created "on the fly" by the kernel when they are opened.
Also, there are network file system, like NFS (which actually stands for Network File System), which allows one computer to "export" a directory, which can then be mounted on another computer, making all file accesses to the files on it happen over the network.

Special files:
There are some other types of files apart from regular files and directories, for example /dev/hda.
/dev/hda is a device file. The file itself of a device file only specifies two numbers, the major and minor number. The numbers of /dev/hda are 3 and 0 (3 is the major, 0 is the minor). You can find out what numbers different device files have by running "ls -l" on the file. Device files are usually stored in /dev. The major number corresponds to a device "system", and the minor number corresponds to a file in that "system". 3 is the IDE system, and 0 is the first IDE drive. That means that /dev/hda need not be called /dev/hda, it just is by convention. For example, if you run "mknod /tmp/harddrive b 3 0", you will get a file called "harddrive" in /tmp that also refers to your first hard drive. There are block devices and character devices. Hard drives are typically block devices, since they consist of addressable "blocks". However, the sound card, which can be accessed through /dev/dsp (having device numbers 14 and 3), is a character device, since you cannot address certain blocks in it. Once you have written data to it, it will be played, and you can't read it again since it's never stored. You can write data to it manually, though. Try running "ps aux >/dev/dsp" for some funny sounds.
There are also FIFO (first in, first out) files, which can be created with both mknod and mkfifo. If one program opens a FIFO file for writing and another opens it for reading, the second program will read precisely what the first one writes. For example, try creating a FIFO file "test" (by running "mkfifo test"), and then open that file with a text editor, like gedit. gedit will hang, don't worry, that's cause it's reading the FIFO file while noone's writing to it. Then run "echo Hello >test", and "Hello" will pop up in gedit.
There are also some other kind of files, like sockets and symbolic links, but I won't go into that now.

This will be enough for now.

God, you can see that I'm tired... =)

Thanks...I'll let you know what I understand...after I finish reading it... :o