Baslinux mailing list

[sindi keesan <keesan AT sdf.lonestar.org>]

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