Serious BL2 unzip/crash problem fixed with e2fsck -b superblock: was Re: [BL] BL3 kernel panic
sindi keesan
keesan at sdf.lonestar.org
Thu Oct 28 20:42:04 EDT 2004
I tried linux md5sum on both computers and the fs.img of BL3.32 is
identical. The DOS md5sum is not the same one as the linux md5sum.
On one computer BL3.x in loop still will not boot even from c:\baslin
(and yes I did md5sum on that fs.img as well as the one in e:).
I was able to pkunzip BL3-32.zip and make two floppy disks that boot on
this computer. So I have BL3-32 that I can try to install to hard drive
and boot with loadlin here.
When I tried to unzip (linux unzip) this same file earlier I got a bad CRC
message, with the file residing in a DOS directory.
So I copied the file to a linux directory of BL2 (where I have linux
unzip) and ran it there and got a segmentation fault. Then anything else
I tried to do gave me a segmentation fault including md5sum and even ls
and dial and I had to power off and on again. This caused problems (see
below).
I tried to reboot back into BL2.
It took about five tries on this computer to get past the 'Not an image
file' message which had been less frequent for a week or so but now occurs
more than half the time on this computer (which is similar to two others
with the same problem that also sometimes work but sometimes will only
boot from Win9X DOS and no other DOS).
Finally it started to boot (found the image file) then crashed badly.
E2fsck said things were clean.
Dmesg continued after that with something about NULL pointer.
Parallelizing fsck version 1.18 (11-Nov-1999)
LINUXEXT2: clean, 11442/366592 files, 892577/1463616 blocks
Remounting root device with read-write enabled.
Unable to handle kernel NULL pointer dereference at virtual address
00000000
current->tss.cr3 = 0faf9000, %cr3 = 0faf9000
*pdf = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c0137940>]
EFLAGS: 00010246
eax: 00000000 ebx: (and many more of these, registers?)
ds: 0018 (etc)
Process mount (pid: 13, process nr: 9, stackpage=cfad9000)
Stack: cffda600 (etc.)
Call Trace: [<c01392ef>] (etc)
Code: 01 c3 41 (etc.)
The screen blanker just worked but nothing else did and I had to power
off and on again..
I needed to find some way to fix BL2 short of wiping the partition and
recopying it from the other computer like I did last time I messed it up.
Also so I could not get ethernet to work now with BL3.0 on this computer,
which used to work fine, or serial connection either (pppd). nc
connection refused. BL2 on one computer, BL3 on the other. It will ping
but not transfer. When I type route I see two lines and the two IP
numbers for clark and lois are not listed. On either computer. ifconfig
eth0 clark lois (or lois clark) or 192.168.1.1 192.168.1.2 Where did I
goof on this one? I killed pidof pppd and tried ethernet again. At one
point I had all the hosts listed but they went away after that. Maybe I
should not have killed pppd, or else put it back after that? I did not
want to get serial and ethernet confused. But this is a separate
problem which I can probably fix eventually.
Anyway, I suggest using not linux unzip but pkunzip on the latest
bl3-32fd.zip file. I had assumed linux unzip would work since the readme
file gives a method of making the two disks using dd in linux. Steven,
can you 'unzip' bl3-32fd.zip with linux unzip in BL2? I was able to unzip
the antiword source code with it earlier (a zip file).
So I figured out that something is wrong with the file structure or
pointers or something and needed fixing. Once before I got e2fsck to fix
things when BL2 would not boot.
>From BL3 I typed e2fsck /dev/hdb2 and again it told me clean. e2fsck
--help lists things about superblock, blocksize, inode_buffer-blocks,
process_inode_size, bad_blocks-file, all optional. man e2fsk was more
helpful.
-b superblock which uses an alternative superblock specified by
superblock. This is used if the primary superblock is corrupted. There
are several primary blocks. (I figured out eventually that all but the
first are alternative and by primary they mean the first one).
-n automatically answer 'no' to all questions.
-f force checking even if it seems clean (it does)
I tried that first.
Pass 1: Checking inodes, blocks and sizes. (slowly)
Checking directory structure, directory connectivity, reference counts,
group summary information. That was no help.
-b requires an argument. man e2fsck suggests that primary superblocks are
at 8193 16385... I picked the second 'primary' as the 'alternative'.
e2fsck /dev/hdb2 -b 16385
Duplicate/bad block(s) in inode 12: 65720
Reconciling duplicate blocks
Clone duplicate/bad blocks<y>?
Since there was a -n option to answer No to all questions I figured
that is the safest approach to start with. N.
Delete file? N.
Fix summary information? N.
Reboot BL2 to see if this did anything:
(Luckily it found the kernel image this time instead of 'Not an image
file' - I would replace the computer but it is the fastest one that will
take our four 64MB SIMMs.)
Not cleanly unmounted, check forced.
IT BOOTED!!!! (I am utterly amazed).
Steven, have you actually made the two BL3-32 floppy disks without usnig
pkunzip? Download to linux, 'unzip' with linux, dd to install?
I now have two BL3-32 floppy disks from which to install to hard drive and
I hope I can figure out how to make this work with loadlin (which I hope
works for BL3 since it does for BL2) on this computer instead of getting
yet another kernel panic. But this is the computer where I need to bypass
system files to use Xvesa anyway - how do I set up lilo to let me choose
between DOS and BL2 and BL3, in case loadlin won't work here with BL3.32?
(From DOS I can get to Win98).
Four steps backwards, five steps forwards.....
On Fri, 29 Oct 2004 3aoo-cvfd at dea.spamcon.org wrote:
>> What might be letting BL2 boot but stopping BL3?
>
> Are you talking about the fs.img version of BL3?
> That is *very* different from BL2. BL2 uses a simple 4mb
> ramdisk; BL3 uses a tiny ramdisk plus a loopfile (fs.img).
So why won't the loopfile version work on the computer in which BL2
(ramdisk or hd) and BL3 floppy disk all work?
>
> Cheers,
> Steven
More information about the BasLinux
mailing list