El JoPe Magnifico wrote:
> On Sun, 2 Aug 1998, Colin Wood wrote:
> > El JoPe Magnifico wrote:
> >>>>> got it to boot into single-user mode, with one small glitch:
> >>>>> the file system is mounted read-only rather than read-write.
> > 
> > If you follow the install doc precisely, root will be
> > mounted read/write when /etc/rc discovers that rc.conf hasn't been
> > configured yet and drops you into single-user mode.
> 
> Finally got it to mount read-write.  The reason it was going read-only
> was do to the bombing of the initial fsck during boot.  It was failing 
> with a "Bad system call" error because (as one person suggested) my
> binaries (from the snapshot as of a couple weeks ago) were out of sync 
> with the kernel I was using (1.3.2). After installing the matching 1.3.2
> base and etc packages, fsck successfully ran at boot, and the system 
> came up read-write as expected.  However (it's always somethin')...
> 
> I still get a "bad system call" error from vi and then a core dump, 
> and likewise with more. 

sounds like you missed something in your reinstall (or else something is a
bit corrupted).

> Other utils that were doing that (like fsck)
> are now working fine though.  I did the prescribed "export TERM=vt220"
> beforehand and /usr is on the same partition, so it's not that.  And
> to the best of my knowledge, my binaries and kernel are now in sync,
> albeit the 1.3.2 versions dated May 17th.  (So far, this is farther
> than more recent kernels have gotten.)  Ideas?  

what kind of system is this again?  if it's officially supported by the
1.3.2 distribution, you might try wiping the whole thing and reinstalling
1.3.2 (a pain, i know, but it would at least give you a known starting
point).

> Other oddities, questions and comments...
> 
> * I've read the FAQ and INSTALL docs til I'm blue in the face.  
>   I have the FAQ mirrored on my hard drive.  I have the INSTALL and 
>   relevant portions of the FAQ (installation at this point) printed out
>   and in my lap while trying to get my system up.  If I ask a question,
>   it's not because I was too lazy to read the FAQ.  I do realize y'all
>   have better things to do then answer stupid newbie questions.  =)

i'll try to keep that in mind ;-)

> * There are kern.tgz and kern_sbc.tgz dated June 3rd in the
>     /pub/NetBSD/NetBSD-1.3.2/mac68k/binary/sets 
>   directory, versus the two GENERIC kernels dated May 17th in the
>     /pub/NetBSD/NetBSD-1.3.2/mac68k/binary/kernel
>   directory.  Everything else in .../sets is dated May 16th.
>   So what are those kern and kern_sbc.tgz kernels in .../sets?
>   At least one of them is a different size from its counterpart
>   in .../kernel, so they aren't identical.  Functionally I haven't
>   found any difference (not that my system is particularly functional
>   right now), but I was wondering just in case.

this might be a result of some rather strange problems the installer
utility was having with the 1.3.2 kernels on some systems.  for some
reason, they really didn't like the gzipping.  so, scott repacked them
(i.e. re-gzipped) and they seem to install just fine now.  this being the
case, i'd stick with the june 3rd kernels and ignore the may 17th kernels.

> * On the same point, I'm getting conflicting responses about the
>   seriousness of having one's kernel and binaries being out of sync.
>   I suppose the answer is "it depends", but still... does one need 
>   to download (urgh) and reinstall (urgh) matching binaries every
>   time a new kernel is tried, in order to avoid these kinds of
>   complications? 

no.

>   Is there some kind of compatability notice
>   accompanying a given snapshot which indicates so? 

nope.

>   Just trying
>   to avoid unnecessary (and time-consuming) downloads.

basically, newer kernels should work with older binaries (assuming that
the newer kernels have been compiled with the necessary COMPAT* options,
which all GENERIC kernels are).  it is fairly likely that newer binaries
will break with an older kernel.  this is due to changes in the system
call interface.  newer binaries are linked against a new libc, and an old
kernel can't handle these new/moved system calls.  so, you can run a
-current kernel with a 1.3.2 userland, but not the other way around.  in
general, it is safer if you keep both in sync, tho.  otherwise, those
programs which have to access kernel memory structures will most likely
still break (i.e. ps, w, etc...)

> * The 19980725 kernel was still trying to mount my root&usr parition as
>   ext2fs instead of ffs and then dying with something like "ext2fs_baddir".
>   This was using the binaries from a couple weeks prior though.
>   Dumb question: is this something inherent to the kernel or to mount?

you got me on this one.  i don't have any ext2fs partitions, and i'm not
really running -current at the moment (although i guess that should change
sometime in the near future).  when is this mount occurring, before
running /etc/rc or during this process?  does you /etc/fstab refer to your
/ partition as 'ffs' or 'ext2fs'?

>   And I know, I know, I should try with the matching binaries from that
>   snapshot (whoops, or rather, both kernel and binaries from today's).

yeah, steve just put another one up, so you might try it, but keep in mind
that it is -current, and by nature may not be entirely stable....

i hope this helps some.

later.

-- 
Colin Wood                                 cwood@ichips.intel.com
Component Design Engineer - PMD                 Intel Corporation
-----------------------------------------------------------------
I speak only on my own behalf, not for my employer.