So.. It looks like the -b option will alternate superblock. 
you can issue the below line to find out what type file system you using... 
its probabl ext3... then use the appropriate fsck with the apropriate 
paramater(s).

mount |grep "/ "

fsck.ext3 -help
fsck.ext2 -help
Usage: fsck.ext2 [-panyrcdfvstFSV] [-b superblock] [-B blocksize]
                [-I inode_buffer_blocks] [-P process_inode_size]
                [-l|-L bad_blocks_file] [-C fd] [-j ext-journal] device

Emergency help:
 -p                   Automatic repair (no questions)
 -n                   Make no changes to the filesystem
 -y                   Assume "yes" to all questions
 -c                   Check for bad blocks
 -f                   Force checking even if filesystem is marked clean
 -v                   Be verbose
 -b superblock        Use alternative superblock
 -B blocksize         Force blocksize when looking for superblock
 -j external-journal  Set location of the external journal
 -l bad_blocks_file   Add to badblocks list
 -L bad_blocks_file   Set badblocks list



Sometime just before Tuesday 02 July 2002 10:43 pm Dexter Graphic Wrote
about:[EUG-LUG:3261] Re: Dexter's boot troubles
: > : > My guess is your original boot block had an issue (not being properly
: > : > linked?) and the fsck ran by the boot process probably re-linked to
: > : > an alternate boot block
: > :
: > : What causes a boot block to become unlinked? And wouldn't one of the
: > : many filesystem checks I ran manually have found that right away?
: >
: > Sigh... hard drive crashes, unproperly shutting down possibly... I dont
: > know all the reasons.. but hard disks are not absolutely reliable
: > devices... hence the expression "backup, backup, backup".
:
: Assuming that my boot problem was caused by an "unlinked boot block" what
: is the preferred way to check for and fix this? My roundabout technique of
: precipitating a complete system lockup by viewing certain system log files
: and then turning the power off seems rather crude; there must be a better
: way. As I said previously, running "fsck.ext2 /dev/hda1" manually did not
: detect any problems or fix anything.
:
: > Hard disks are the most common form of secondary storage devices, while
: > RAM is the most common primary storage device.
:
: Hum, is that how the Unix world sees it? I never thought of RAM as
: storage--it goes away when you turn the power off. I guess in a Unix/server
: environment you don't turn the computers off (or crash a lot) like you do
: at home with DOS/Windows.
:
: Dexter

-- 
for setting/changing your eug-lug mailinglist subscription use this website:
http://wWw.RockSolidNetworks.com/eug-lug.html
no microsoft products were used to produce this message.

Reply via email to