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

[Rick Moen]

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

> I have now done Daniel's Windows did the file system check, steps 1-6.
> It schedued and ran but did not report anything to fix.

I've not been an MS-Windows user for quite a long time, but have
sometimes heard claims that third-party diagnostic and repair tools for
MS-Windows are better than the bundled ones (thus the relatively limited
aftermarket for whatever occupies the niche of Norton Utilities, these
days).  It's your call, as to whether you want to spend cash on
something like that, for further assurance.  Alternatively, you could
back up everything significant from your FAT32 partition, blow it away,
reformat, reload MS-Windows XP, reload applications, reconfigure, and
put your data back.  The latter fire drill would be an immense pain in
the neck, but in my experience is something you ideally should do with
MS-Windows anyway at 6-month intervals, to halt various forms of system
bit-rot.

Personally, I'd feel better about the results of that admittedly
time-consuming rebuild than I would about a defective system that has
had mysterious healing rays applied to it by one or more utility.  FAT
is simply very fragile, and your best bet is (1) frequent checking and
defragging[1], and (2) backups and periodic rebuilds.

> But Kubuntu still does fsck during boot and still finds on sda1 (my
> Windows XP partition) "differences between boot sector and its
> backup." It does nothing about it and proceeds the boot process okay,
> but with that delay and possibly some other delays (see NOTE at bottom
> of this post).

Well, I'd tend to believe dosfsck, that the backup copy of the FAT32 boot
sector has somehow gotten scrambled -- and, in your shoes, would likely
infer that the primary copy is still good, based on your assertion that
MS-Windows XP runs fine.  A little Web-searching suggests that probably
the bundled Microsoft diagnostic utilities are a little stupid in this
area, e.g., http://support.microsoft.com/kb/247575 has:

  This behavior occurs because the FAT32 file system contains a backup
  copy of the boot sector. However, Chkdsk.exe does not attempt to use the
  backup FAT32 boot sector unless the primary boot sector is physically
  located in a bad sector and Chkdsk.exe receives an I/O error message
  while trying to read the volume.

(Disclaimers:  1.  I'm not experienced at MS-Windows diagnosis, and
don't really aspire to be -- though I'm glad to help you.  2.
Above-quoted technical note is said to apply to various Windows 2000 
versions, and may or may not also apply to MS-Windows XP.)

You might wonder:  What _are_ the ramifications of your FAT filesystem's
backup copy of its boot sector getting somehow corrupted?  One
consequence you already know:  Your Linux boot process fusses over the
error, lengthening your Kubuntu boot time.  The other obvious
consequence is that, if the primary boot-sector copy also gets hosed,
you have nothing to restore it from using standard Microsoft (and
third-party) tools.


> It doesn't say it will, it just does it -- it runs fsck on the whole
> drive, I think, during bootup.

The phrase "runs fsck on the whole drive", at least if interpreted in a
literal-minded way, doesn't really make sense.  Apologies if this seems
like a pedantic objection, but I just want to make sure you understand
that, _inherently_, an fsck-type utility operates on a filesystem, not 
on a "whole drive".  The whole basic notion of an "fsck" algorithm (or
the utility that implements that algorithm) is that it's a filesystem
check:  That's where the word "fsck" comes from.  It's a contraction of
the phrase "filesystem check".

> I find no record of this fsck in dmesg and don't know where else to
> look for it.

Try "sudo less /var/log/fsck/*"

The logfiles within /var/log are often really informative, though
admittedly it takes a bit of experience and/or playing around to know
where to look.

> I'd rather not wait 45 seconds during Kubuntu boot up while fsck does
> its check but fix nothing every time, if easily avoided.

So, just for the sake of completeness, I believe you'll find that the
startup script that checks your non-root filesystems at startup is
/etc/rcS.d/S30checkfs.sh (which is a symlink to /etc/init.d/checkfs.sh ,
a shell script).  

Looking at that shell script, one sees a couple of things:

1.  That's one way you'd know, other than my just telling you, that it
    writes logfiles to /var/log/fsck/ .
2.  The script checks the value of environment variable FSCKFIX to
    determine whether to fix filesystems with problems, or merely 
    advise you of any problems found.

So, you _could_ make the 45-second delay go away by disabling the check
script, S30checkfs.sh, e.g., by renaming it to "K30checkfs.sh.  However, 
again, I'm just mentiioning that option for the sake of completeness,
and strongly recommend against it, as it would be akin to dealing with
danger by donning Douglas Adams's peril-sensitive sunglasses so as to
cease noticing the threat.

> What does fsck mean, below, by "1) Copy original [boot sector] to
> backup" and "2) Copy backup [boot sector] to original"?
> 
> Might I be relying on a *current* boot sector that is neither of above?

My _own_ interpretation is that "original" means your in-use primary
copy of the FAT32 boot sector and "backup" is of course the backup copy.

Just to make sure I'm really, _really_ clear about this:  Your data on
the FAT32 partition are obviously at risk.  If you haven't already done
so, you should make sure you have backup copies of everything there that
you care about, and make sure you have the means to reinstall the OS and
applications.  Once you are _sure_ you have those things under control,
then perhaps you could try option #1, under the assumption that the
primary boot sector copy is good and the backup copy is bad.

(It's possible that my interpretation is incorrect, as I claim no
expertise in MS-Windows and the repair of damaged FAT filesystems.  Me,
I'd backup, blow away, recreate, and reload -- but you'll need to choose
your own poison.)

> Can Grub do something to help resolve the "boot sector"
> inconsistencies fsck reports?

No.  GRUB (GRand Unified Bootloader) has nothing to do with that.


[1]  Why defragging?  Because any fsck-type process, including
CHKDSK.EXE / DSKPROBE.EXE / whatever-Microsoft-has-today, inherently has
to make educated guesses about how to repair wonky parts of the
partition structure -- and fragmentation makes those guesses less likely
to be accurate.