[conspire] fsck "differences between boot sector and its backup"

[Rick Moen]

Quoting roger at rogerchrisman.com (roger at rogerchrisman.com):

> Every time I boot Kubuntu 7.10 on my laptop, fsck runs and reports,
> "differences between boot sector and its backup".
> 
> Should I run fsck and have it, "Copy original [boot sector] to backup"?

You say that "fsck runs" every time you boot Kubuntu.  OK, but it 
runs on which filesystem?  You don't say, but that's important. 
I'm guessing that the Kubuntu bootup process reports that there are
errors on /dev/sda1, and that it will run dosfsck to try to fix errors.
Is that correct?

Your transcript, below, shows you running "fsck" manually from the
command line without specifying a filesystem at all.  (I'm guessing you
were running it manually from the command line in order to try to
redisplay for our benefit what's shown during bootup, right?  If so,
thanks for the thoughtful approach.)

By the way, please be a bit careful with fsck-type tools:  Always be
explicit (on the command line) about which filesystem you're fsck'ing, 
fsck only filesystems that are absolutely quiescent (they preferably
should be unmounted), and know _why_ you're running an fsck tool.
Personally, I like to make sure I'm running the specific, correct
fsck-type tool for a particular filesystem type.

In this case, you typed just "fsck" as a root-user command (via sudo).
This resulted on running /sbin/fsck, which (lately) is a front-end stub
utility that figures out what _real_ back-end fsck-type utility will be
required.  According to the manpage, if you run it with no parameters,
that's interpreted as:  "Run the fsck.[type] utility for each filesystem
listed in /etc/fstab".  In your case, that seems to have resulted in:
"Run the fsck.ext3 utility on /dev/sda6, followed by running the
fsck.dos utility on /dev/sda1".

For the first part of that sequence, fsck.ext3, aka e2fsck, aka
fsck.ext2, correctly issued you an appropriately dire warning that you
were about to ask it to do something really reckless, i.e., fsck your
mounted, non-quiescent (in the middle of being actively written to)
Linux root filesystem, and asked confirmation.  You wisely said "Er, no,
on reflection, please don't do that after all."

For the second part, fsck.dos aka dosfsck attempted to run and diagnose
the /dev/sda1 filesystem, which as you say is FAT32.  I've personally
never used dosfsck; it might be fine, or you might be better off using
native Microsoft Windows tools.  I really don't know.

If you believe dosfsck, there _is_ filesystem damage.  That's why it's
offering to replace one of the two copies with the other, and asked you
which one to regard as the undamaged copy.

Which is a really good question.  FAT was always an extremely fragile
filesystem, made much more vulnerable by Microsoft's increasing reliance
on write-behind caching plus the rather ghastly method used to store
long filename information on FAT.  

What would I do with a damaged FAT filesystem like that?  Well, when you
boot MS-Windows XP, does everything appear to be OK?  What does
Microsoft's disk-repair utility have to say about it?  

The problem with dosfsck's options #1 and 2 is that, if you guess wrong
about which boot-sector copy is good, you could mess up the FAT
partition completely.  Now might be an excellent time to do a backup,
if possible.

I guess, after that, I might be inclined to let the native-Microsoft
tools take a crack at the FAT partition, first (mostly because I have no
experience with dosfsck, and don't know how reliable it is).  However,
there's always with any fsck utility the risk of losing everything,
since any fsck repair algorithm is an educated guess.

> Then I used the live desktop Kubuntu CD installer to resize the drive
> and install Kubuntu 6.? on /dev/sda5. Recently I did a fresh new live
> CD install of Kubuntu 7.10 to that /dev/sda5.

According to your transcript, /dev/sda5 is not a data-bearing
filesystem, but rather is swap.  /dev/sda6 is your Linux root
filesystem.

> Also, why is above /dev/sda instead of /dev/hda?

Because you're using a driver that leverages the functionality of the
kernel's SCSI layer even for ATA ("IDE") mass storage.