File System Manipulation

Different people have various learning styles. For those of you who prefer examples rather than lectures, here are a few practical examples in which you learn how to create a file system within a file and mount it using the loopback file systema special file system that allows us to accomplish this useful feat. You can use the file system you create to experiment with and practice almost all the commands found in this chapter with no fear of damaging your system.

Creating a File System for Testing

Because most of us do not have a spare computer or hard drive on which to experiment and practice, we can make one of our own by creating an image file containing the file system of our choice and using the loopback file system to mount it. That way, we do not run the risk of accidentally wreaking havoc on the system itself. Although you could also use a floppy drive for these same exercises, their small size limits your flexibility.

Step 1Make a Blank Image File

Use the dd command to create a file with a block size of 1,024 bytes (a megabyte) and create a file that is 10MB in size. (You need to have enough free space on your hard drive to hold a file this big, so adjust the size accordingly.) We want 10,000 1KB (1,024-byte) blocks, so we select a count of 10000.

If we wanted a floppy-sized image, we would have selected a block size (bs) of 512 and a count of 2880 for a 1.4MB floppy or 5760 for a 2.88MB floppy. Here's how to do that:

# dd if=/dev/zero of=/tmp/fedoratest.img bs=1024 count=10000

We see the computer respond with the following:

10000+0 records in 10000+0 records out

If we check our new file command, we see this:

# file /tmp/fedoratest.img /tmp/fedoratest.img: data

Step 2Make a File System

Now we need to make the system think that the file is a block device instead of an ASCII file, so we use losetup, a utility that associates loop devices with regular files or block devices; we will be using the loopback device, /dev/loop0.

# losetup /dev/loop0 /tmp/fedoratest.img

Now we can format the file as an ext2 file system:

# mke2fs /dev/loop0

We see the computer respond as follows:

mke2fs 1.27 (8-Mar-2003) File System label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 2512 inodes, 10000 blocks 500 blocks (5.00%) reserved for the super user First data block=1 2 block groups 8192 blocks per group, 8192 fragments per group 1256 inodes per group Superblock backups stored on blocks:     8193 Writing inode tables: done Writing superblocks and file system accounting information: done This file system will be automatically checked every 21 mounts or 180 days, \ whichever comes first. Use tune2fs -c or -i to override.

Step 3Mount Our Test File System

After your test file system has been created, you can experiment with the different options for the formatting commands you will be using. It will be useful to make a mount point for our image file

# mkdir /mnt/image

and then mount it

# mount /dev/loop0 /mnt/image

We can do this now because we already have the loopback file system associated with the image file. Later on if we remount it, we must use the following format to use the loopback option:

# mount -o loop /tmp/fedoratest.img /mnt/image

After mounting the new file system, we can look at it and see that the /lost+found directory has been created on it and that the df command returns

# df -h /mnt/image File System      Size Used Avail Use% Mounted on /dev/loop0      \ 9.5M  13k 8.9M   1% /mnt/image

To unmount it, use this:

# umount /mnt/image

Make a backup of the image just in case we break the original:

# cp /tmp/fedoratest.img fedoratest.bak

After the test file system is created, you can create directories, copy files to it, delete files, attempt to recover them, and, in general, create controlled chaos on your computer while you are learning and practicing valuable skills. If you damage the file system on the image beyond repair, unmount it, delete it, and create a new one (or copy a new one from that backup).

Mounting a Partition as Read-Only on a Running System

Remember that to do almost any kind of file system manipulation (formatting, checking, and so on), you should unmount the file system; by doing so, you avoid having any writes made to the file system, which would corrupt it.

How do you remount partitions on a running system? For example, to remount the /home partition (assuming that it is on a separate physical partition from root) as read-only to run fsck on it and then remount it as read-write, use the remount option for mount:

# mount -o ro,remount /home

Note

Remounting will not work if a normal user is logged in because /home will be busy (in use). You might need to switch to runlevel 1 (init 1), which is single-user mode, to remount /home.

Now we can run fsck on the partition. When done,

# mount -o rw,remount /home

puts it back in service.

If you reboot your system to mount the root file system read-only for maintenance (enter the maintenance mode, s, as described in Chapter 15)

# mount -o rw,remount /

will remount it read-write and you can continue on. That's easier than unmounting and remounting the device.

Converting an Existing ext2 File System to ext3

An existing ext2 file system is easily converted to ext3 to take advantage of the benefits of journaling. After you convert an existing file system, any other operating systemincluding BeOS, Windows (with the appropriate drivers), and other UNIX systems that have drivers to access ext2 partitionscan access ext3 partitions. To those operating systems (and their drivers), your converted file system still looks just like an ext2 file system.

To begin the conversion to ext3, you use the tune2fs utility to add the journal to an existing ext2 file system. In this example, you are changing /dev/hda2, an already formatted ext2 partition.

# tune2fs -j /dev/hda2

It does not matter whether hda2 is mounted or unmounted at the time of the migration; if it is mounted, you will see a new file, .journal, in the directory.

Next, edit the line for /dev/hda2 in /etc/fstab and change the value from ext2 to ext3. It will be mounted as an ext3 file system the next time you reboot.

Note

If you have decided to convert your root file system to take advantage of the benefits of the ext3 file system, bear in mind that you cannot run tune2fs -j on it while it is unmounted because you cannot unmount the root file system. Because the file system is mounted when you run tune2fs -j, the .journal file on it will be visible when you finish the migration.

When compiling a new kernel, make certain to include ext3 file system support in your new kernel by selecting that choice in your kernel configuration (see Chapter 39, "Kernel and Module Management"). Also, note that you do not need to perform the actions described in the next section if you have just freshly installed.

Making an Initial Ramdisk

You need to create an initrd image file to load the ext3 driver and mount the root partition as an ext3 partition. The initrd file is an initial ramdisk that contains a small kernel and enough of the Linux OS to load drivers so that the real kernel and the rest of the operating system can load.

Note

If you forget to create the initrd file, your system will still boot, but it will mount the root partition as ext2. That's very clevernone of the other journaling file systems are as forgiving.

To create the file, run the mkinitrd utility before you reboot.

# mkinitrd /boot/initrd-2.6.7-1.478.img 2.6-7-1.478

The first argument is the name of the initrd file that will be placed in the /boot directory. The name can be anything; the name shown here follows the usual naming convention; you can find a number of other naming options in the mkinitrd man page. The second argument after the mkinitrd command is the version of the kernel you want to use. The value you enter here does not have to be the version you are currently using, but it must match the version you use when you boot (and the kernel must support ext3).

After you run the utility, edit /boot/grub.conf or /etc/lilo.conf to change the initrd loaded at boot time. For GRUB, add this same line beneath the kernel line in the section that references your kernel:

initrd (hd0,0)/boot/initrd-2.6.7-1.478.img

If you use LILO, add the following line to the appropriate LILO stanza:

initrd=/boot/initrd-2.6.7-1.478.img

Note

LILO is no longer used in Fedora, but you might have it on an older system upgraded to Fedora.

Examine an initrd Image File

The initrd.img file is automatically created during the installation process (if necessary) or with the mkinitrd command. You never need to examine it, but if you are curious about what's in the initrd.img file, just take a look: It is really just a gzipped ext2 file system. To examine it, first copy it to the /tmp directory and add the .gz suffix to it:

# cp /boot/initrd-2.6.7-1.478.img /tmp/initrd-2.6.7-1.478.img.gz

If your system does not have an initrd.img file in /boot, mount your boot floppy and see if it has one. Next, uncompress it as follows:

# gunzip /tmp/initrd-2.6.7-1.478.img.gz

Mount it as follows:

# mount -o loop /tmp/initrd-2.6.7-1.478.img /mnt/image

and browse the directory to your heart's content.

Not every system will have an initrd.img file. It is typically used to load device drivers for file systems (such as Reiser) or hardware (such as the Promise RAID IDE controller) that must be in place before the system can continue booting. Some floppy-disc-based Linux distributions use initrd.img to load a minimal operating system that can then uncompress and load the working file system from the floppy.

You can also mount .iso images in the same way, but remember that they are always read-only because of the nature of the underlying iso9660 file system; you can write to the other images unless you explicitly mount them as read-only. If you want to read and write to the files in an ISO file system, you must first copy the files to a device that is mounted read-write, make your changes, and then use mkisofs to create a new .iso image. This is a common "gotcha" for many users.