Mounting a normal thing in the normal Linux way:
mount /dev/sdc2 /mnt/c/2
This mounts the device
/dev/sdc2 to a mount point at
Here’s how to mount a CD image file so that you can poke around it:
mount -t iso9660 -o ro,loop /cds/distro.iso /mnt/cd
/etc/fstab/ file is a list of known mount points that can be
used by the mount command to do things with out providing more
explicit details. If you have a mount for
/dev/sdc to mount to
/data if you have an fstab entry for it, you can just say:
Mounting normal volumes
# <fs> <mountpoint> <type> <opts> <dump/pass> /dev/md1 /boot ext2 noatime 1 2 /dev/md3 / ext3 noatime 0 1 /dev/md4 /data ext3 noatime 0 1 raven:/xeddrive /ravendisk nfs rsize=8192,wsize=8192 0 0
Removable Media Devices
This is almost always handled by automount and magical stuff that
/media/ on modern distros. However if you need them to be
explicit, here’s how.
/dev/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0 /dev/fd0 /mnt/floppy auto noauto 0 0
This is not technically a mount point per se, but it belongs in your fstab if you want the swap space activated automatically.
/dev/hda2 none swap sw 0 0
There may be some weird entries already in your fstab. If so, leave
them alone. The
proc filesystem is usually a good idea to put in
here if you’re building a Gentoo system, for example. But just keeping
whatever fashionable weird entries that came with your distro’s fstabe
is probably the best plan:
proc /proc proc defaults 0 0 shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
Mounting RAM As A File System - tempfs
Here’s a good description of tempfs.
This kind of thing is possible.
# mount tmpfs /dev/shm -t tmpfs -o size=32m
Mounting Partitions On A Whole Disk Image File
Imagine you did something like this.
dd if=/dev/sda of=/mnt/otherdisk/mywholedisk.img bs=512
Fun! That gets the MBR and the partition table and, well, everything.
How do you pull that apart? One way which is described in
article is to mount with an offset. Like in the article this can
sometimes not work. It can be helpful to pull out a particular
partition from an entire disk image. First get the geometry details by
parted, changing units (
u B) to "B", and printing (
partition information. You then need to divide the start and size
(which are in bytes) by 512 to use for dd block counts.
time dd if=/mnt/sdb5/wholedisk.img of=/tmp/justtheboot.img bs=512 skip=2048 count=1024000 file /tmp/justtheboot.img # Confirms it's a partition. fsck.ext4 /tmp/justtheboot.img # Reset the journal if need be. mount -t ext4 -o loop,ro /tmp/justtheboot.img /mnt/image
This is helpful to be able to do. It turns out that there is an even
easier and better way. The
kpartx utility is found on systemrescuecd
and works great for exactly this job.
kpartx -av /archives/thewholedrive.img ls /dev/mapper fsck.ext4 -y /dev/mapper/loop2p5 mount -o ro /dev/mapper/loop2p5 /mnt/image # Do what you need to do... kpartx -dv /archives/thewholedrive.img
Note that I wasn’t sure that the last step actually worked (removed the mappings). But powering off will!
The automount daemon is a kernel level function that allows the system to mount the needed volumes at the moment it is needed. This cuts down on a lot of open connection overhead for a busy file server.
Automount is configured with a series of files that normally live in
This is the master map for the automounter. Here’s what a typical one contains.
/ /etc/auto.xed --timeout 15 /misc /etc/auto.misc --timeout 15 /net -hosts +auto.master
The first field here is the directory that contains the mount point.
So if you want to mount at
/pro/ you’ll need an entry here for
people believe that it’s probably better to not make
If you want to mount at
/home/xed you’ll need an entry here for
/home. If the directory
/home/xed doesn’t exist or even if
doesn’t exist, it will be created temporarily.
The second field is where to find instructions on what to do with requests to access this part of the file system.
Here’s what was in my auto.misc.
cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom
From the example above, there’s a reference to
is a custom mount mapping.
lab -rw,soft,intr,rsize=8192,wsize=8192 fs.xed.ch:/files/lab home -rw,soft,intr,rsize=8192,wsize=8192 fs.xed.ch:/files/users
This means that when a user does something like
ls /lab, the
automount daemon will realize that it has instructions about certain
points attached to
/. It looks in
/etc/auto.master by default and
determines that since the desired directory does have a definition
/ is defined in
/etc/auto.xed, that it will use the
line of that configuration and mount
Once these files are configured, you need to start the automount daemon.
sudo /sbin/service autofs start
Or if it’s already running do either of these to get configuration file changes enacted:
sudo /sbin/service autofs restart sudo /sbin/service autofs reload
A an interesting place to see what the kernel knows about automount mapping points is with:
|This seems to not always be completely accurate. For me it showed some old mappings that I had gotten rid of. Don’t know how to clear this.|
This is a complex topic that I don’t have a complete notes for. Basically a union file system is able to take two volumes and mount them both as one. This sounds kind of neurotic, but there are good reasons for doing this.
Potential Use Cases
First, let’s say that you have a lot of memory in a machine, you might want all disk transactions to attempt to be performed on a virtual disk but have the option of spilling over into slower media if the RAM gets full. This is also useful for certain devices like some netbooks with SSD drives that probably should not be used for transient file thrashing due to media write fatigue issues. A union fs can put a lot of that load on the memory.
You can also boot from a static image such as a CD ROM or a read only NFS root export. This is normally quite inflexible, but with a union file system, you can also mount some other kind of media that will be where all changes and modifications go. This allows, for example, many users to share a root image, but still be able to customize their own.