Troubleshooting Partitions and File Systems[分区和文件]

Troubleshooting Partitions and File Systems[分区和文件]

Troubleshooting Partitions and File Systems

Here are some tips for troubleshooting the partitions and file systems on your hard disks.

Computer Won't Boot (No Boot Screen)

If you don't get a GRUB boot screen when you try to boot from hard disk (and are expecting one), it could be that the master boot record is corrupted. You can reload the master boot record by booting from a rescue CD (assuming Linux is installed on the first IDE hard drive). Here's how:

1. Reboot your computer with the first CD in the installation set for Fedora or Red Hat Linux in the CD drive.

2. When you see the boot prompt, type:

   # linux rescue

3. Add information about your language and keyboard as requested.

4. Choose whether or not to start the network interfaces (you probably don't need to in this case). The rescue process will now look for your Linux installation.

5. If the rescue mode finds your Linux installation on your hard disk, select OK to continue.

6. After the computer enters rescue mode, you should see a regular shell prompt (#). Assuming rescue mode mounted your hard disk under /mnt/sysimage , type the following to change your root directory to that of your Linux installation:

   # chroot /mnt/sysimage

7. To install a new master boot record from the grub.conf configuration on your hard disk, type the following:

   # /sbin/grub-install /dev/hdaInstallation finished. No error reported.This is the contents of the device map /boot/grub/device.map.Check if this is correct. If any of the lines are incorrect,fix it and re-run the script 'grub-install.'#  this device map was generated by anaconda(fd0)    /dev/fd0(hd0)    /dev/hda

   Remove the CD and reboot your computer. You should see your original GRUB screen and be able to select which partition and/or kernel to boot.

If you had deleted a partition and simply reinstalling grub to the MBR doesn't work, you may need to do some more work. It's possible that your boot partition is no longer valid, so the boot loader is not able to find your /boot/grub/grub.conf file. Start by booting a rescue CD and running the grub command. Assuming you are booting from the MBR on your first IDE hard disk, type the following (with the first text followed by the tab key):

   grub> root (hd0,   <tab>    Possible partitions are:    Partition num: 0, Filesystem type is ext2fs, partition type 0x83    Partition num: 1, Filesystem type is ext2fs, partition type 0x83    Partition num: 2, Filesystem type unknown, partition type 0x82

After you press the Tab key, you will see a list of partitions on the first IDE hard disk. Look for the first one that shows up as ext2fs (ext3 file systems appear here as ext2fs). If the first ext2fs that shows up in the list is partition number 0, enter that into your grub command line by typing:

   grub> root (hd0,0)

To make sure that you assigned the proper partition as your boot partition, try typing the following:

   grub> cat /grub/grub.conf

If this lists the contents of your grub.conf file, you have assigned the correct partition as your boot partition.

Recovering a Deleted File

You deleted a file (or a set of files) by mistake and you want it back. Is it possible to get it back? Unfortunately, the answer is probably not. Unlike the earlier ext2, the ext3 file system erases pointers to the deleted file's inode.

If you are using an ext2 file system, however, you might be able to use the debugfs command to find and restore your lost file. With ext2, the blocks are simply marked as being unused, so if the space hasn't been reused yet, the file you need might still be there.

Let's say you deleted a file from your home directory (/home/chris/myfile.txt) and you want it back. If you have a separate /home partition (say, for example, /dev/hda5), you can have anyone using the computer log off for a moment, and then do the following:

1. Determine the partition containing the file you want to recover. Typing df - h or mount will show your currently mounted partitions.

2. Unmount the directory containing the file you want to recover. (If the file is on the root partition, you should shut down the computer and go into rescue mode, as described in Chapter 6.) Here's how to unmount the /home partition (if /home were on /dev/hda5, you could use that instead of /home):

   # umount /home

   If the directory fails to unmount, see the Can't Unmount a Directory section later in this chapter.

3. Run the debugfs command on the home partition. Then from the debugfs prompt, list the deleted files from the directory you are interested in:

   # debugfs /dev/hda5debugfs 1.35-WIP (07-Dec-2003)debugfs: ls -ld /home/chris

   Look for the inode number for the file you want to undelete. With an ext3 file system, the entry will look something like this and you will not be able to recover it:

   <    0>    0(1)    0    0    0    myfile.txt

   However, if you see the number greater than zero surrounded by less than and greater than signs, you might be able to recover the file. That is the inode number for the file. For example, if you were to try this on an ext2 file system and if the inode is shown as <115>, you could copy it from the /home/chris directory from the unmounted home partition by typing:

   debugfs: dump <115> /tmp/myfile_dumped.txt

4. Remount the file system (mount /home) and you are back in business with your recovered file safely in the /tmp directory. Copy it where you want it to go permanently and you are ready to go.

Can't Unmount a Directory

You try to unmount a directory or device representing a partition and you see a message similar to the following:

   unmount: /whatever: device is busy

The most common reason for an unmount to fail is that some process is holding a file or directory open on the partition. In particular, if a directory in the partition is the current directory for any shell, that will cause the device to be busy. To solve the problem, you can often simply close the shell or change the directory so that the current directory is on another partition.

On a multiuser system that has a lot of users logging in and out, it may not be as easy to find out who is making the partition busy. You can try using ps aux to see what is running and kill any run-away process. Or you can go into single-user mode, if it is critical to unmount the directory now. If you can bear to wait a bit, try a lazy unmount:

   # umount -l /whatever

The lazy unmount detaches the file system from the hierarchy. However, it waits until the file system is no longer busy to clean up all references to the file system.

Don't Know What Kind of a File System is on a Device

You can find out what file system type is on a device using the blkid command. For example, to check the first partition on the first IDE hard disk, type:

   # blkid /dev/hda1   /dev/hda1: LABEL="/boot" UUID="69477377-81c2-4846-bd3e-   ad5fe8c2caee" SEC_TYPE="ext3" TYPE="ext2"

Checking a File System

If a file system was not cleanly unmounted (for example, when someone kicks out the power cord) or if the time has been reached for a scheduled file system check, an fsck process will run and check (and correct) the file system when you boot the computer. You can check a file system yourself, without rebooting the system, however, if you like. To do that, first unmount the file system.

 Note 

If you are checking the root file system, you should boot from a rescue disk. You should not do an fsck on a mounted file system, and you cannot unmount the root file system on a running Linux system. You could mount the root file system (/) read-only (add ro to the mount entry in /etc/fstab and reboot) and run fsck on it.

Running fsck

Once the file system is unmounted, run fsck. For example, if you are checking the /boot partition, type the following after it is unmounted:

   # fsck /boot   fsck 1.34 (25-Jul-2003)   /boot: clean, 42/26104 files, 11632/104388 blocks

Checking for Bad Blocks

To see if there are bad blocks on the file system, run the badblocks command as follows:

   # badblocks -v /dev/hda1   Checking blocks 0 to 104391   Checking for bad blocks (read-only test): done   Pass completed, 0 bad blocks found.

Repairing a Damaged ext3 File System

You can force a more thorough check of an ext3 file system using the -f option. To see more details about the output, use the -v option as well:

   # e2fsck -fyv /dev/hda1   e2fsck 1.34 (25-Jul-2003)   fsck 1.34 (25-Jul-2003)   Pass 1: Checking inodes, blocks, and sizes   Pass 2: Checking directory structure   Pass 3: Checking directory connectivity   Pass 4: Checking reference counts   Pass 5: Checking group summary information   42 inodes used (0%)          1 non-contiguous inode (2.4%)            # of inodes with ind/dind/tind blocks: 10/4/0      11632 blocks used (11%)          0 bad blocks          0 large files   25 regular files          3 directories          0 character device files          0 block device files          0 fifos          0 links          5 symbolic links (5 fast symbolic links)          0 sockets   --------          33 files

This shows a forced, thorough check being done of a small file system. The -y option indicates that if any errors are encountered, and e2fsck would normally ask if you wanted to try to correct each error, it should instead just correct them all without asking for each one individually.

Creating, Modifying, and Deleting File Systems

The fdisk command and related commands such as sfdisk and cfdisk are used to display, modify, delete, and add disk partitions. Once added, file systems can be assigned to the partitions and those file systems can be mounted and used by Linux.

 Caution 

On a critical system, an inexperienced user shouldn't use fdisk other than for listing the partitions on your system (the -l option). If you do want to use fdisk to change, delete, or add partitions, be aware that a small mistake can completely destroy your data or make it inaccessible. If you are just learning, try this on a machine you don't require. Regardless of your experience, you should make sure that any critical data is backed up.

In this example, I had left about 1GB of free space on my hard disk that I wanted to create into a partition that is mounted on the /mnt/backup directories (so I could use it to make backup copies of my document files). Here is what I did to start the fdisk session, and create the new partition:

   # fdisk /dev/hda   Command (m for help): n   Command action      l   logical (5 or over)      p   primary partition (1-4)   p   Selected partition 3   First sector (75987450-78165359, default 75987450): <Enter>   Using default value 75987450   Last sector or +size or +sizeM or +sizeK      (75987450-78165359, default 78165359): <Enter>   Using default value /8165359   Command (m for help): w

In the previous example, I created a primary partition (partition 3 was available) and just took the defaults. That allowed me to use the rest of the available disk space for the new partition.

After that, I made the partition into an ext2 file system. Here is an example of creating an ext2 file system on the /dev/hda3 partition:

   # mkfs -text2 /dev/hda3   mke2Fs 1.34 (25-Jul-2003)   Filesystem label=   OS type: Linux   Block size=4096 (log=2)   Fragment size=4096 (log=2)   135648 inodes, 2/1096 blocks   13554 blocks (5.00%) reserved for the super user   First data block=0   9 block groups   32768 blocks per group, 32/68 fragments per group   15072 inodes per group   Superblock backups stored on blocks:           32768, 98304, 163840, 229376   Writing inode tables: done   Writing superblocks and filesystem accounting information: done   This filesystem will be automatically checked every 32 mounts or   180 days, whichever comes first. Use tune2fs -c or -i to override.

Next 1 added a label to the partition, based on its mount point:

   # e21abel /dev/hda3 /mnt/backup

If I want to make it into a journaling file system (ext3) now, I can do that using the tune2fs command. This action will take about 33MB of disk space to create the journal file needed by ext3. Here's an example:

   # tune2fs -j /dev/hda3   tune2fs 1.34 (25-Jul-2003)   Creating journal inode: done   This filesystem will be automatically checked every 32 mounts   or 180 days, whichever comes first.   Use tune2fs -c or -i to override

After that, I created an entry in the /etc/fstab file, so the partition would be automatically mounted each time Linux started (if I hadn't added the journal, the file system type would be ext2 instead of ext3):

   LABEL="/mnt/backup     /mnt/backup    ext3   defaults 1 2

After that I can mount the file system immediately by typing:

   # mount /mnt/backup

At this point, the new partition will be mounted on the /mnt/backup directory each time the system boots.