> On Wed, Apr 05, 2000 at 05:31:12PM +0200, Erik Bertelsen wrote:
> > On Wed, Apr 05, 2000 at 03:03:05AM +0000, NetBSD Mailing list wrote:
> > > Previously discussed:
> > > 
> > > > > root file system type: ffs
> > > > > <At this point output to the monitor ceases, but the kernel continues to
> > > > > function>.
> 
> 
> > 
> > However, in my case the machine does not boot fully. Some kernel messages
> > continue to come on the console once in a while (I don't recall which right
> > now). But apparently the machine has started rc processing, but not completed
> > it, as telnets to the machine gets 'connection refused' indicating that
> > IP is actually running on the ethernet, but inetd has not started.
> > 
> 
> To add to my problem: Using the older (1.4V) kernel makes the system boot normally,
> but a current kernel (up to yesterday's sup) shows two differences:
> 
>  - the console output stops about the time the kernel is about to start or has
>    started init. This has been observed by other persons as well.
>  - secondly rc processing starts, but stops prematurely. I did some experiments and
>    the result is that with no screen output the system ends up in single-user mode
>    and I can actually halt or reboot the system using the keyboard. Booting the
>    older kernel still works, so the difference is with the kernel.

On further checking and investigation, I am seeing this as well.  After a short
flurry of disk I/O after typing ^D to a presumed invisible prompt to enter the
desired shell (using "boot -f" instead of "auto" making it boot single-user),
all activity stops.  This is the apparent hang somewhere in /etc/rc*.  By
typing ^C here, booting continues.   After a while, I can log in to a presumed
login: prompt, and shut the system down (still nothing on the screen).

Additionally, I have now compiled and run a GENERIC kernel.  The same problem
exists, so it is definately not any kind of hacking I've done to customise
a kernel.  There is a definate problem with kernel code itself.

> I'll report further in a few days (maybe not before well after the week-end) if I
> can pin-point the problem and/or solution.

As will I.  I'll be resorting to sifting through the cvs commits, although I'm
not certain what files I should be looking at.

More to come :)

--skots
--
Scott G. Akmentins-Taylor     InterNet: staylor@mrynet.com
MRY Systems			        staylor@mrynet.lv
    (Skots Gregorijs Akmentins-Teilors -- just call me "Skots")
		----- Labak miris neka sarkans -----