Theodore Tso wrote:
And yes, it was intentional that it did what it did; basically, you
got lucky because the older e2fsck could have seriously screwed up
your filesystem to the point where seriously data loss could have
occurred (you do keep regular backus, right?).
The filesystem in question actually contains nothing but regular backups
of other machines. :-) If the old e2fsck had trashed the filesystem,
the result would have been a long, painful automated rebuild but no data
loss.
The corruption reported when you ran fsck manually, to wit:
# e2fsck 1.41.3 (12-Oct-2008)
# e2fsck: Group descriptors look bad... trying backup blocks...
# e2fsck: Bad magic number in super-block while trying to open
# /dev/vg2/backuppc
Should have shown up at the boot-time fsck, unless somehow the
filesystem was further corrupted after (or during) the initial
boot-time fsck run.
For what it's worth, I didn't have root on the machine, only sudo, so I
hit Ctrl-D at the root password prompt and then unmounted the filesystem
as soon as the system went multi-user -- but it *was* mounted read-write
in the interim. But I was curious about the discrepancy at the time,
and I noticed that manually specifying "-a -C0" on the command-line (as
though running from the initscript) caused the first (boot-time) set of
errors to appear rather than the second ("Group descriptors look bad") set.
--Benjamin Gilbert
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
