Why the ext3 fsck’s after X days or Y mounts?

Reading through my RSS feeds, I came across the following blog post describing one Linux administrator using tune2fs to disable the “please run fsck on this file system after X days or Y mounts.”

I’ve got to admit, this is kind of annoying. I’ve taken production critical Linux boxes down for some maintenance, only to have the downtime extended +15-30 minutes because the file system was configured to run a fsck. Google searching this topic even shows other administrators trying other stupid tactics to avoid the fsck on reboot.

Is there really any value on having fsck run after some period of time? On Unix based systems (and even in Windows), fsck (or chkdisk) only runs when the kernel notices that a file system is in some sort of inconsistent state. So then I ask, why did the Linux community decide to run fsck on file systems in consistent state? ZFS has a “scrub” operation that can be ran against a dataset, but even that is comparing block level checksums. Ext2/3, RiserFS, XFS don’t perform block level checksums (btrfs does) so why the need to run fsck after some period of time? Does running fsck give folks the warm n’ fuzzies that their data is clean, or is there some deeper technical reason why this is scheduled? If you have any answers / historical data, please feel free to share. =)

Resintalling grub from single user mode

While surfing the web this weekend, I came across the following procedure for reinstalling grub from the command line:

1. Boot the system from an installation boot medium.

2. Type linux rescue at the installation boot prompt to enter the rescue environment.

3. Type chroot /mnt/sysimage to mount the root partition.

4. Type /sbin/grub-install /dev/hda to reinstall the GRUB boot loader, where /dev/hda is the boot partition.

5. Review the /boot/grub/grub.conf file, as additional entries may be needed for GRUB to control additional operating systems.

6. Reboot the system.

This is useful stuff, and having it handy can save you time you get into a bind.

Redhat recovery modes

If you have ever had to deal with a sick Redhat server, you may be familiar with the rescue, emergency and singler-user modes of operation. I have heard people refer to rescue modes incorrectly, which can sometimes lead to some interesting stories (there are several slight subtleties between them). To clear up any confusion surrounding these terms, here are the official descriptions from the Redhat administration guide:

Rescue mode:

Rescue mode provides the ability to boot a small Red Hat Enterprise Linux environment entirely from CD-ROM, or some other boot method, instead of the system’s hard drive. As the name implies, rescue mode is provided to rescue you from something. During normal operation, your Red Hat Enterprise Linux system uses files located on your system’s hard drive to do everything — run programs, store your files, and more.

Emergency Mode:

In emergency mode, you are booted into the most minimal environment possible. The root file system is mounted read-only and almost nothing is set up. The main advantage of emergency mode over single-user mode is that the init files are not loaded. If init is corrupted or not working, you can still mount file systems to recover data that could be lost during a re-installation.

Single-User mode:

In single-user mode, your computer boots to runlevel 1. Your local file systems are mounted, but your network is not activated. You have a usable system maintenance shell. Unlike rescue mode, single-user mode automatically tries to mount your file system. Do not use single-user mode if your file system cannot be mounted successfully. You cannot use single-user mode if the runlevel 1 configuration on your system is corrupted.

Recovering root passwords with Fedora Core

I performed a Fedora core 4 installation today, and for some reason the root password I typed in during the installation got munged (or I typed it incorrectly two times). Since Fedora Core uses grub as a boot loader, I was able to recover from this situation relatively quickly.

To get to a shell where I could use the passwd(1) utility or vi(P) to change the password, I first needed to reboot the box to get to the grub menu. Once I was greeted with the grub menu, I used the up and down arrow keys to select a kernel, and then hit the ‘e’ key to edit the boot paramaeters. Once the editor displayed the kernel boot string, I added a 1 immediately following the LABEL definition:

kernel /boot/vmlinuz-2.6.11-1.1369_FC4 ro root=LABEL=/ 1 rhgb quiet

The number following the LABEL definition indicates the run level to boot into, and in this case 1 refers to single user mode. Once you finish editing the boot definition, you can hit ‘b’ to boot. This will boot to single user mode, and should dump you into a shell if everything goes well. Once your in the shell, you can use passwd(1) or vi(P) to update the root users password. Since I haven’t tinkered with grub for quite some time, this experience reminded me how important physical security and grub passwords are!