Re: where does the first boot pause when calcluating the ssh keys?

Joel Rees wrote:
> 
> I've been playing around with trying to get 3.3 installed on my performa
> 550, and it gets to this point and stops:
> 
>     root on sd1a swap on sd1b
>     WARNING: / was not properly unmounted
>     PRAM time does not appear to have been read correctly.
>     PRAM: 0x83da4f80, macos_boottime 0x3ed5b153
> 
> (Copied out by hand. If that's not enough information, I can try
> using my performa 630 as a dumb terminal and capturing the boot log over
> the weekend.)
> 
> Although there is no further output, it does echo keypresses to the
> screen.
> 
> I left it that way for an hour and a half this morning before I had to
> cut the power, get the box out of the kids' way, and come to work, but
> there was no sign of disk activity, and no further output.
> 
> So, I'm wondering, is this where the box is supposed to be calculating
> the keys for ssh, or am I looking at what happens when you try to
> install in a box w/out FPU, or is this likely to be the SCSI driver
> issue, or am I looking at something else?

No, that's not where the ssh keys are generated...there is a pretty
clear message on the screen about "Generating DSA key..."  and so
forth...  Plus, if you are willing to do "bad" things, you can hit
CTRL-C for each key being generated and the key generation will quit,
and the boot will progress (but things like ssh won't work...)

When you DO get to the key generation, you will have plenty of waiting
time, so make sure you can leave the machine for a LONG time... 8)

I can think of a few things...

1) It *might* be doing an fsck at that point. (I think that's
wrong...but I'm working off memory here).  Macintosh systems, with a
few exceptions, have no disk activity light, it is often hard to tell
when they are busy doing disk activity vs. when they are busy doing
processor activity.  I highly recomend disk activity light
modifications, so you can TELL when something is happening...
2) you didn't indicate the specs of your machine, I see it is a
68030.  There *could* be a problem with 030 machines (I have a couple
different 030 mac68ks, neither works with OpenBSD any more, though I
have *no* firm reason to believe it is a 68030 issue, though they are
of similar vintage to your system (IIsi, LCIII).  The systems I have,
though, panic or freeze much earlier in the boot process, so I'm not
convinced this is it...
3) Memory starvation?  Could you have a very small amount of RAM (4M
stock? 8M?) that's causing the thing to get into one of those "low RAM
hangs", where the system is waiting for another task to release memory
to it, but nothing does so it hangs iindefinitely?  More memory would
be the solution here.  Quite some time back, I verified the LCII would
boot with a 2G drive and 6M of RAM, if I recll properly, but that was
a properly shut down drive, no fsck was needed.  fsck has to store
some data in RAM, and swap isn't running at that point if I recall
properly, so you DO have to have enough memory to get fsck completed. 
No idea how much, though.

I'm not confident any of them is your problem, however...  


OOps!! uh, you have drive sd1a in use -- that indicates you have TWO
drives on the system!  OpenBSD/mac68k has some issues with multi-drive
machines, that very well could be your problem -- though usually, I
saw that as a panic, but maybe the symptoms changed since I last
looked...  THAT one, I have a little more confidence in.

Nick.
-- 
http://www.holland-consulting.net