Working with Key System Files

You are making good backups of your systems and especially your data, right? Right? Even so, sometimes you need to open the hood and get your hands dirty messing around with the files that help Linux run smoothly. Be careful doing so because one mistake can lead to worse problems. Keep your head about you, double-check everything you type, and success will be yours.

Resetting Forgotten Root Passwords

Sometimes you're given a box to administer, and guess what? The person who knew the root password is nowhere to be found. What can you do? Why, use Knoppix, of course! With Knoppix, you can easily change the root password — or, more accurately, remove the root password so that you can then change it to whatever you want.

Caution 

As always, make sure you have permission to change passwords on the machine before you do so.

After booting with Knoppix, mount the partition containing the /etc directory in which you're going to muck about. Make sure that it's writable — right-click on the partition icon, choose Properties, open the Device tab, uncheck Read only, click OK, and then click on the partition icon to mount it.

After mounting the partition, run cd /etc and then use your favorite text editor to open the /etc/shadow file (we prefer vi, but you can use any editor you want, as long as you're running it as root). Once /etc/shadow is open, find the line containing root's information, as shown in the following example:

 root:$1$k2xzdNaz$X.Fq9Xgp9.dhkTszwt4FP1:12893:0:99999:7::: 

Delete the stuff between the first and second colons, so that the line now looks like this:

 root::12893:0:99999:7::: 

Save the text file, and the next time you reboot, root will not have a password. This is obviously a very dangerous situation, so you should assign root a new (good) password as soon as possible.

Now that was pretty easy, wasn't it?

Fixing X

A frequent complaint on listservs is that someone's Knoppix boots just fine, and X works fine, but after installing a distro of choice, X doesn't load, or if it does, things look terrible.

This usually isn't that hard to fix. Boot again with Knoppix, and find the file /etc/X11/ XF86Config-4.

Copy the file to a USB flash drive, or email it to yourself, or store it on another machine on your network. (It's helpful to print the file, too, so that you have a hard copy somewhere.)

Now take Knoppix out and reboot the distro that's giving you problems. If you can, you want to open the XF86Config-4 file on the problematic distro and compare it to the "good" XF86Config-4 file that Knoppix generated. If possible, print out the XF86Config-4 file on the "bad" distro and compare it to the "good" XF86Config-4 file. Hard copy is sometimes easier to use for comparison. Keep in mind that a Knoppix XF86Config-4 file contains options for a million different configurations, so don't just copy blindly from the Knoppix file to your distro's file. You want to focus on these parts of the Knoppix file:

• Section "Module": Check whether Knoppix loads some modules and your distro doesn't. Try editing your distro's XF86Config-4 file to load those modules. Of course, that might not work if the modules aren't on your system, but it most likely won't hurt anything either.

• Section "InputDevice" (there will be several, for your mouse and keyboard): Wheel mouse not working? Look here.

• Section "Monitor": Pay attention to HorizSync and VertRefresh. Be very careful editing those numbers; a mistake can fry your monitor!

• Section "Device": Look at the driver. In fact, this is quite often the problem. Change it to vesa, save, and restart your machine to see whether that fixes your problem. Vesa is a generic driver, so you're not going to get the best graphics in the world, but at least you'll be able to use your machine to try to track down something better.

• Section "Screen": What you want is DefaultColorDepth, which will lead you to the resolutions your monitor uses. If you know that your video card and monitor support a higher resolution, try adding it to the appropriate Modes line in the Subsection "Display" area.

Whatever you do, back up your original XF86Config-4 file before you begin editing it. You just might make things worse, and it would be nice to revert back to a file that at least kind of works. Then you can begin again. Keep in mind that tinkering with XF86Config-4 is sometimes akin to voodoo, especially for newbies, so don't be afraid to turn to friends, online resources, or your local Linux users group for help.

Note 

The XFree86 developers shot themselves in the foot with their unwise licensing changes in 2004 (see http://en.wikipedia.org/wiki/XFree86 for the gory details), resulting in the abandonment of XFree86 by virtually the entire Linux world and a migration to the Xorg project (see http://www.x.org). Xorg offers several advantages over XFree86, including licensing palatable to the GPL and a more open developer community. Expect Knoppix to switch to Xorg sometime in the future, but don't panic — you won't have lots of new stuff to learn. Xorg's main config file is found at /etc/X11/xorg.conf instead of /etc/X11/XF86Config-4, but other than that, the formats of the two files are remarkably similar.

Performing a Filesystem Check

Occasionally a hard drive begins acting very, well, strangely. Copying files to and from the drive might take forever, even for a few tiny files, and produce scads of worrisome error messages. These signs indicate that it's time to give the drive the once over. Obviously, you can't really check a drive by running programs that reside on that same drive; instead, boot with Knoppix and then run a variety of programs to check your hard drives for errors.

Caution 

Make sure that any drives you're checking are not mounted. Once again: You should only check filesystems on unmounted drives!

The command you use to check the filesystem depends on the filesystem the drive is formatted to use. To find out what filesystem was used, take a look at /etc/fstab. The following examples use /dev/hda1, but just substitute the partition or drive that you'd like to check.

Examining and Repairing Ext2 and Ext3 Filesystems

This one is easy. To scan and repair a filesystem formatted with ext2 (nonjournaled) or ext3 (journaled), run this command:

 $ sudo e2fsck -C /dev/hda1 

The -C option displays a useful progress bar, which is always handy. If you want to see additional output, including the actual commands that fsck is using, add the -V option to the command.

If you want e2fsck to look for bad blocks on your hard drive, add the -c (lowercase) option (this is a different option than the uppercase -C), which runs the badblocks program. If badblocks finds that any areas on your hard drive are damaged, it adds them to a list that the system keeps, so that they are unused in the future.

When you run e2fsck, you may be asked a lot of questions — hundreds if your hard drive has a lot of problems. If you just want e2fsck to fix your drive automatically, add the -p and -y options. Most of the time, this isn't a big deal, but it may sometimes do things you weren't expecting (to be honest, though, we usually use these options because we're lazy and don't feel like typing the same letter over and over again).

Examining and Repairing ReiserFS Filesystems

Ext3 is a good journaled filesystem, but in recent years ReiserFS has been gaining a lot of converts. To check and repair a ReiserFS-formatted filesystem, use the following:

 $ sudo reiserfsck --fix-fixable /dev/hda1 

The –fix-fixable option does just that: It tells reiserfsck to fix the easy problems. If reiserfsck finds additional problems, it lets you know and suggests additional options to use, including some of the following:

• –rebuild-sb: If reiserfsck complains that "read_super_block: can't find a reiserfs filesystem," and you know for certain that the filesystem uses ReiserFS, you probably need to use this option.

• –rebuild-tree: reiserfsck tells you to run this command when it needs to rebuild the entire filesystem tree, and, no, this is not a good sign. Be sure to back up the partition using dd or the equivalent before using this option!

• –yes: This tells reiserfsck to assume "yes" as the answer to all questions, so that it runs without asking you a million things. Be cautious about using this option.

Examining and Repairing FAT32 (VFAT) Filesystems

Yes, FAT32, known as VFAT to Linux users, is a Windows filesystem, but it is widely used in the Linux world as well, especially on partitions shared between Linux and Windows installs, and on USB flash drives, digital camera storage cards, and other portable devices. It's therefore a good idea to know how to check and repair partitions formatted with VFAT using the command:

 $ fsck.vfat -a /dev/hda1 

The -a option automates the process, taking the least dangerous method each time there's a problem. If you want to be asked every time there's an issue, use the -r option instead. If you don't use -a or -r, the filesystem is examined, but not actually repaired.

If you want to watch fsck.vfat at work, tack on the -l option, which lists each file as it's examined, and the -v option, which tells the program to be more verbose. To mark bad clusters, use the -t option.

Examining and Repairing Other Filesystems

There are more filesystems, of course, but the ones covered here are the most common. Some of the other filesystems you may encounter, and the commands to use, are as follows:

• JFS: fsck.jfs (for more info, see man fsck.jfs)

• XFS: xfs_check (for more info, see man xfs_check)

• NTFS: ntfsfix, which you should use after writing to an NTFS-formatted partition under Knoppix because, as man ntfsfix puts it, "MS chkdsk is well known for its stupidity when fixing altered partitions." Keep in mind that ntfsfix is not a replacement for the Windows chkdsk command but a tool designed to keep that particular software from freaking out.

For more information about any of the filesystem commands, try man e2fsck, man reiserfsck, and man fsck.vfat. For more on filesystems in general, see man mount under Linux, or check out http://en.wikipedia.org/wiki/Filesystem.

Note 

rm usually means that a file is gone, and it ain't coming back. However, it is possible to undelete files that you removed on your Linux box. To find out how, check out "Performing Forensics with the Coroner's Toolkit" in Chapter 6.