The latest system install processes all seem to want to use that "cool" new feature, the UUID, to mount partitions from the file system table. If you look in /etc/fstab you'll see something like this:
# /boot was on /dev/sda1 at boot time
UUID=ABC123...
This is another fabulous idea whose time has "come". With this method, you may notice one day that your swap space is missing. Or you may not be able to mount partitions after copying a disk or doing something else to the partitions (because the UUID has changed). Whatever the reason, the good old reliable way of mounting partitions by device name is the best. You should check your fstab to see that it looks something like this:
/etc/fstab:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/sda1 /boot ext3 defaults 0 2
/dev/sda2 none swap swap 0 0
/dev/sda3 / ext3 defaults,errors=remount-ro 0 1
/dev/sdb1 /mnt/sdb1 xfs defaults 0 2
/dev/sdc1 /mnt/sdc1 xfs defaults 0 2
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec 0 0
Use absolute partition names (e.g. "/dev/sda1"), under normal circumstances, and you shouldn't experience any problems with partition mounting.
Unfortunately, it has now become a case of the inmates truely being in charge of the asylum.
If you are using an HBA to attach disks (e.g. for recording volumes), as well as the ATA ports on the system's motherboard, this can lead to the the names that are assigned to the disks being inconsistent from one boot to the next. This makes it particularly fun when it comes to mounting the disks. And, better yet, there's no way to fix this stupidity. You just have to take what they give you.
So, in spite of what we just said above about using actual device names in fstab, the fstab instead needs to mount the disks by UUID. The UUID in question is assigned when the partitions are built so you need to get the UUID after the disk is partitioned and formatted. You can do this with:
su
/sbin/blkid /dev/sdxx1
/sbin/blkid /dev/sdxx2
/sbin/blkid /dev/sdxx3
.
.
.
But, before you do this, you might want make sure that the disk you are asking for the UUID for is really the disk you mean to mount. You should copy down the physical serial number from the disk's external label, when you install the disk, and then look at the disk information for the device that you suspect is the disk in question. If the serial number you copied down is the same, you can proceed. Get the disk info this way:
su
/usr/bin/udisks --show-info /dev/sdxx
It may be of assistance to you to note that the disks plugged into HBA ports are assigned disk names first (e.g. /dev/sda, /dev/sdb, etc.), before the disks plugged into the motherboard ATA ports. Also, it appears that for most HBAs (which implement SAS/SATA ports with a 4-port controller chip), the disk names are assigned in ascending order, to the disks plugged into Port 3, Port 2, Port 1, Port 0, then Port 7, Port 6, Port 5, and Port 4, etc. So, Port 3 gets the name /dev/sda, Port 2 gets /dev/sdb, ..., Port 7 gets /dev/sde, Port 6 gets /dev/sdf, etc. But, only if there is something actually plugged into the port.
Once you have the UUIDs for all of the disks/partitions that you want to mount, you can update /etc/fstab, which should now look something like this:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
UUID=820d621e-f14e-4c4c-b9ae-24d225b8a952 /boot ext3 defaults 0 2
UUID=f0ec04cc-cc3a-4038-a03d-9a67dbc8d803 swap swap defaults 0 0
UUID=4dbc04b2-ff1a-4161-bbcc-8a0587b5ccc3 / ext3 defaults 0 1
UUID=19c03f99-9017-7730-f44e-710bf87c7671 /mnt/sdb1 xfs defaults 0 2
UUID=39f7c43c-e620-49b8-8cb4-e4b7e1a622a0 /mnt/sdc1 xfs defaults 0 2
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec 0 0
If you add a new disk or replace an existing disk with a different one, you will need to go through all of the steps described above to find the UUID of the disk and update /etc/fstab with it.
Once fstab is updated, you can either reboot the system or, we prefer, try auto-mounting everything first (this way, if fstab is broken, your system will still be up and running and you'll have a chance to fix things):
su
mount -a -v
Incidentally, while we're talking about the partition table, if you are mounting any XFS partitions, you need to make sure that the xfsprogs package is installed on the system, or the XFS partitions will fail to mount upon startup with a disconcerting message about "a serious error". You can choose to skip the error and then mount the drives later on, with no problems, like this:
mount /mnt/sdb1
So, what's going on? Failing to install the xfsprogs package, omits the fsck.xfs program which is needed to check XFS drives. Since it is missing, when fsck tries to invoke it to check the XFS drives at startup, the check fails and fsck decides that there is a serious error. However, there's nothing really wrong with the drives, which is why you can mount them later on. The solution is to reinstall the xfsprogs package, like this:
apt-get install xfsprogs