Heya listians!

		I'm hoping for some help here, and yes, it's a long posting. In my
attempts to get netbsd-1.2/1.3 installed from my redhat 5.0 box to the
networked sun3/50, my sanity has been put at test, but it's ok, I sort
professional help and this is part of my therapy. 

 
   X, sun3, netbsd...linux, miniroot....and lusts of the mad;


 Someone once asked why......"It's just one of those things. Years ago
when we were growing up, the thought of having one's very own Sun
workstation, was like a flirting glimpse passed to the dark regions at
the back of one's mind....the idea was so unimaginable, so far fetched
and beyond reality. Who could have guessed just 10 or so years later,
these things would be available for frightfully small amounts of money,
you just *have* to get one...but that's not enough, and not the end of
it. Once you have it, you want it to work...and the dream of getting it
to work the way you *would've* if you were rich enough to buy one,
becomes a displaced reality.....and if it doesn't work, the drive to
complete the dream makes you not sleep for serveral days on end, comsume
enough coffee to shutdown (-h ;) your kidneys, and generally drive you
nuts thinking 'I was dreaming...of *THIS* nightmare??'...but you keep
going. Why? The 3/50 might only ever be a little more than useless to
me, if at best it's a fine 19" monochrome irc client :)....but it still
doesn't fade the impact of telling someone you own a Sun....[really?
wow!]"


   I started with a sunOS4.1.1 package that came with an xkernel,
xserver, blahblahblah, which was got (past of get) from the ftp server @
kipper.york.ac.uk ...sun3 install page or something. This is a fine
thing...to the point of being also easy. I had to compromise on the
bootparamd as supplied with that pack, because it refused to compile
here for reasons I'm too lazy to fight glibc over just now...the issue
rpc.bootparamd seems to work fine. The supplied set of binarys & friends
do not however. Everything is ok...the sunOS goes in, the kernel boots
and starts init, then complains heavily about missing a whole heap of
things before dumping a whole heap of nothing to nowhere in a big heap
of hurry before rebooting and doing it all over again....and again....

    It was then that I confidently (haha) downloaded the netbsd-1.2
sun3-port, and I say that because I have had netbsd-1.2 installed on an
i486 before, and it seemed to work OK. Come install time however, the
differences between then, and now, formed a rather large chasm.

  Using the same tftpd/bootparamd setup that was already going, relavent
substitution and links done, I had the netbsd-rd up on the sun. In real
truth, the first hurdle was edlabel, which is like to fdisk as a
lefthand drive car is to a righthand drive one :) That cuffufel out of
the way, the next problem....getting miniroot on sd0b, because the
blinking mount -r command WASN'T. I eventually found reference to a
syntax of    mount -o resvport   , which cured those blues, and led to
the next weirder ones...

    After booting miniroot from /swap, and initiating the install
script, you get on down and do the edlabel thang and all else various
and sundry leading up to the 'how are we gunna do this?' bit. Naturally,
I go for NFS install give it all the necessary info, it looks in the
<dir> where the sets.tgz are....and tells me there are NO sets to
install in <dir> ? Ok, lets do a manual check.... ls /mnt ....(gives
listing of all the install sets.tgz). I'm not convinced, so I try to tar
-zxvpf one of them to the /mnt2 (disk)...works like a charm!? What's
going on here? The files are obviously there, the mount is obviously OK,
the permissions are obviously OK..what's the non-obvious thing here that
stops it from seeing those files?

  The miniroot/install procedure seems none to gracious about a flunked
install process with no /dev/MAKEDEV at the end of it <grin>, and so you
gotta believe I can type the necessary commands in the dark. No way
would it work, so believing it was the install script itself, I decided
to do a 'half manual' install. In this, at the point where the install
script offers to drop you to the shell for any last minute
network/config changes, I chose [Y], and mounted everything manually,
and untgz'd the install sets to the drive, and then exited to return to
the install script.

   You can imagine my constination in finding that after doing that
manual untgz of the sets.tgz to the drive, the install script then FINDS
the NFS mounted sets?!?!?!?! All of them except the basexx.tgz. I figure
it's already been done, so it doesn't need to do anything else really
'cept finish-out, so I let it, and after a long while, am left with a
booting, functional (to a point) netbsd-1.2 on the sun3 :)

   But then X wouldn't run...at all. Couldn't find it's things that WERE
there anyhow, paths didn't work...sheesh. So I decided to upgrade to
netbsd-1.3/sun3.... 



 
 "I think you said 'X should work straight out of the box' on a thing
such
 as sun3/netbsd. That's funny....it's what I thought as well :) Well, it
 DOESN'T, ok!? Not yet anyhow."



...but read on...[snippets of notes to someone else]
 
 re: the mount command of '-o resvport'.....
 
 Ok, you replied something along the lines indicating you thought that
 was fixed in the later netbsd~sun3 ports, so considering I was actually
 toying with netbsd-1.2, I've downloaded the current (1.3) port,
 including the x????.tgz packages...the whole sha-bang..
 
 Noted changes;
 
  netboot still works, it seems now to (more) reliably strap it's NFS
 parameters (else, it's just more verbose ;), so to does the larger
 netbsd-rd....though the appearance of device 'md0' (??) seems
 undocumented in the install docs, however it's safe to ignore it and
 continue as per the install doc.
 
  The mount command now graciously accepts a single option of  -r  , so
 it seems true this is fixed in (at least) the netbsd-1.3 port.
 
 
  People must've optimized the networking code in the netbsd1.3 kernel,
  or somewhere...tranfer speeds I note are up 80% or so.
 
  Hahahaha!!!!  You gotta laugh, trying to boot the 1.3 miniroot image
  from /dev/sd0b gives this;

> error: kernel too big for Sun3/50
 
   ..hehehehe, last time I looked, sun3/50 was still part of the
 compatible hardwares list...or did I miss something??  %@@%%@$@!
 
 Okay...no-prob, substitute the 1.2 miniroot image for the 1.3 version
 with bloated kernel, and use that...and you guessed it, it works fine
up
 to the point of looking in the NFS mounted <dir> containing the install
 sets, to tell me there's no installable sets in that <dir>. Alright,
not
 quite de_ja_vu here...like I say, the netbooter seems to work better,
 and whereas previously at this point not even FTP install would work,
 this time it *does* actually do things correctly, and I'm able to login
 to the machine that is actually the NFS box anyways, and select ALL the
 install .tgz sets for install....and off it goes, or so I thought...
> 
  I notice a few gzip whines about broken pipe...the end of every
 x???.tgz archive actually. I've checked the archives on this linux box
 and they gzip -d fine without complaint....but funnily enough, unpak to
 the same content regardless. Weird.
> 
   Remember before I said 'install' couldn't find the sets.tgz even
 though they were there, but after manually unpakking them, then they
 **could** be seen by the install script...*EXCEPT* for base12.tgz?
Would
 you believe...the ftp install just did the same damn thing just 1metre
 to my left. Even though I have specified base (or xbase) .tgz to be
 installed, it just skips on by as though it doesn't exist...no errors,
 no warnings....and when it gets out the other side, it goes looking for
 /dev/MAKEDEV which it doesn't find of course, says curtly;
> 
>   ...something is wrong here...
> 
   goes on unabated and leaves you with nothing that boots. AGAIN, I'm
 surely impressed :-)
> 
   Okay, so I know this should go to a maillist (prolly will after you
 anyhow ;), but see this point...either *I'M* the only lunatic out there
 trying to meld a sun3/bsd (pizza;) box to a redhat box, or else anyone
 else who's running RHL (and perhaps other lin*xs'??)...and perhaps this
 is so in view of the mailing contents I've been seeing <vbg>...would I
 think have given up in pure frustration....I'm not so easily flustered.
> 
    I think therefore, especially in the light of seeing the miniroot
 kernel not fit for some reason in this sun3, and considering the
 torturous elements I've still to resolve even getting the port to
 install from a RHL linux box cleanly, the sun3 netbsd ports both
1.2/1.3 
 should carry a warning message waring redhat linux users who either;

 a> have a heart condition
 b> have a history of violent mental illness
 or
 c> are prone to bouts of manic depression
 
 , to not undertake the path set before them, as it could prove
dangerous
 to their, or other's health....or result in a lengthy jail sentence,
 loss of girlfriend/marriage, cost professional services for
counselling.
 ...etc etc.
> 
   Considering the extra functionality already noticed in the 1.3 port,
I
 can second_guess the new miniroot image probably fixes the NFS bug too
 (at a hunch)...pity the kernel doesn't FIT...(@%*$@%$ ;-) Oh well,
looks
 like I'm off to see what I can find out. I might diversify this sun3
 effort here and try and get netbsd on the h'drive the way it should be,
 and in the interim I'll setup a crosscompile env. (...again) and build
a
 linux m68k 2.1.xx kernel and see if I can't nfs that off with rather my
 native OS...dual OS :) I'd give up on the bsd thang altogether, but I
 hate it when 'they' win....<grin>....I'll persevere in memory of those
 poor, lost souls mentioned above who lost their lives (because there
was
 no 'linux-warning.txt' file to advise them :), and if I manage to
 untangle all this odd puzzle, I promise to write a so named addendum
for
 the same purpose...a fitting epitaph to save the young...
 

   Does anyone have any clues on this behaviour? Why does the new(er)
netbsd-1.3 miniroot fail because of 'kernel to big for sun3/50'
complaint? And why can't install 'see' the files that are there, but
then DOES see them if you manually untgz them first. And why does both
NFS install and FTP install elements of 'install' fail to pay any heed
to the existance of the ?base??.tgz files being there, even *when* you
can make it see the others?


   Now.....where's my rifle....
 

>   Db