On May 16,  6:10pm, Arthur Hoffmann wrote:
> You were right :) I changed the 'i' to a 'dev' and after zthreebus0 at
> mainbus0 it kept on going, but not very far. I get lots of hd types
> which were depreciated, then it went to fsck where it right away comes
> back with:
> /dev/rsd6a CANNOT SEEK: BLK 16
> /dev/rsd6a UNEXPECTED INCONSISTENCY run fsck manually. 
> manually didn't help either. 

  Is /dev/rsd6a your root partition?  If it is, I don't know what would
be happening.  I first suspected a problem doing DMA, but if that were
the case, the root fs should never have gotten mounted in the first place.

  The DOS type fields in the RDB are handled a bit differently now.  'BSDR'
still maps to partition 'a', and 'BSDS' maps to partition 'b'.  The other
values ('BSD[DEFGH]') are mapped to a single partition type and assigned
to the partitions in the order they appear in the RDB.  Most people probably
have their partitions set up as 'BSDR', 'BSDS', 'BSDD', 'BSDE'...  This
setup should still work, but if the partitions are in a little different
order, things won't map so good.  On one of my disks I have the partitions
as 'BSDR', 'BSDH', 'BSDD', 'BSDE', 'BSDF', 'BSDG', 'BSDS' [the last partition
was slightly larger than the second, so I exchanged them - they originally
were in order].  This results in the 'BSDH' partition being assigned to 'd'
and the 'BSDD' partition assigned to 'e'.  As a result, /etc/fstab is no
longer correct.

> Also I keep on getting: can not map ld.so errors....
> cp complains about wrong arguments. 
> When I try to go into mulit user mode lots of errors come flying along
> the screen until it says:
> init getty repeating too quickly on port /dev/ite0, sleeping.
> (Actually I had this error a couple of weeks ago when I was running
> old binaries with a new kernel) 
> 
> Does this mean that I need to have the rest of the source tree
> recompiled in order to use the new kernels?

  Yep - more syscall changes have been done making binaries and libraries
incompatible.  I haven't rebuilt the new stuff yet, as the kernel still isn't
functional enough for my to really use.

Michael

-- 
Michael L. Hitch			INTERNET:  osymh@montana.edu
Computer Consultant			BITNET:  OSYMH@MTSUNIX1.BITNET
Office of Systems and Computing Services
Montana State University	Bozeman, MT	USA

------------------------------------------------------------------------------