debian:~# mount /dev/hda1 /backup

But if you add it to fstab later as suggested, you are assuming that it will mount when you reboot. You probably don\’t want to reboot just to verify if it remounts the way you expect it to.

There is a better way. You can unmount it, and then test it using the fstab entry:

debian:~# cd /
debian:~# umount /backup
debian:~# mount /backup

This will cause the mount command to consult the fstab entry for how to mount the partition. This way if you have any problems with your fstab entry you find it before you try a reboot.

–Adrian

I just like fdisk. It\’s quick and I\’ve never blown away the wrong disk or partition in it (knock wood) because I use the \’p\’ (print) command after I do anything. If you don\’t write to disk with \’w\’ then you\’ve made no changes so it\’s pretty safe. Like all things in *nix systems, you have to be careful because the system assumes you know what you\’re doing when you do it.

mount -a [-t type] [-O optlist]
(usually given in a bootscript) causes all file systems mentioned in fstab (of the proper type and/or having or not having the proper options) to be mounted as indicated, …

This means it will try to remount the already mounted file systems again. Probably not fatal but usually I try to avoid this whenever possible. Since you already added the entry, /backup, to the fstab, it\’s safer just to do (just like aotto has pointed out):

(cd away from /backup if you were there)
umount /backup
mount /backup

Also you might also want to mention -L (to specify a disk label) or -U (to give a uuid) when making filesystem. This way, you don\’t have to specify partition in fstab:

# mkfs.ext3 -L/backup /dev/hdb1

and in your fstab

LABEL=/backup /backup ext3 defaults 0 2

Thanks for the article.

But I\’ve never had a problem with \”mount -a\” trying to remount already mounted filesystems. It\’s smart enough to check what\’s mounted, and only mounts what\’s not already there.

Additionally, echoing ssbrshei and grdetil, use either a label or uuid in the fstab. Do not put an entry in the fstab using the /dev/<drive> format. While it may not come back to bite you, it just might. Consider that if you add a second partition, then delete the first, your partitions just re-enumerated. What if you decided to move your hard drive to a different controller? Now your drives are enumerated differently.

If you use labels, LVM or UUID, changing the partition table or moving drives around won\’t break things. At this point IMO, it is bad practice to setup persistent mounts using a dev path.

Since we\’re sharing our collective knowledge on installing fixed disks and what not, here\’s mine. (not in strict operational order)

A. ca. Summer 2009, I began using Xfs on my critical fs; not one hiccup since then; on my next distribution install I\’ll be using Xfs exclusively;

B. After I\’ve defined a new partition, my habit has been to run uuid and whatever applicable partition-info tool a fs provides and write that info to the newly-defined partition as /.uuid.<OEM-name> and /.info.<OEM-name>; for instance, when I purchase a new Western-Digital disk, those filenames being with WD and I append its model name.

C. IMHO having multiple disks in a computer\’s box can prevent a lot of headaches; for years I\’ve designated the first installed disk as the primary distro-boot-root disk: to that disk I install all the distribution\’s files to it exclusively; I break out /usr/local, /var and /home to partitions on other disks for non-distro-installed files and packages that must survive across any upgrade or refresh of the distro I use. Also, I usually define a swap partition on each new disk but that\’s not a rule written in stone;

Stay well.

– idknow.

I just use a liveCD.

The posted cli process is a good refresher though.