NFS Install to NFS Mount of OpenStep on Cube

Started by rickfillion, February 15, 2012, 03:21:59 pm

Previous topic - Next topic

rickfillion

Hi!

This is my first post on this forum, it's quite nice to see that there's still an active community around NeXT hardware.  You've already helped me more than I could have imagined from the stuff I've read on here.

I'd like to give you a little rundown of what I've been trying to get OpenStep 4.2 onto this cube.  I'm sort of stuck now, and would love some help.

So I've got an 040 Cube (I think it's 040, it's got regular ethernet, no BNC), and this little guy is quite bare: No floppy, no CD drive, no Optical, no Harddisk.  I bought an HD for it, and as old a scsi CD drive as I could find, but I managed to lose both of them in my last move.

But that's fine, since the thing can't boot off of CD anyway, I've gotta do a network boot.  If I'm going to go through the trouble of setting up the network boot, I might as well just mount the CD via NFS and do the install via NFS.  Well good news, I've got that part working! (mostly)

Now I don't have a disk to install it to.  The OpenStep installer seems to be completely contained within /etc/rc.cdrom, which I found quite cute, the whole installer is a shell script.  That shell script looks for local hard disks, and bails when none are found.  It's a shell script so... copy CD contents to new directory (which I had to do anyways cause NFS didn't want to let me share the cd mount point).  Edit the shell script to bypass the the HD selection and lead it down the right path : mount a new NFS share, and do the install into that.  The main install really just being:
   ${DITTO} -T -arch ${ARCH} -bom ${RECEIPT_DIR}/${LANGUAGE}Essentials.pkg/${LANGUAGE}Essentials.bom -outBom ${HD}/${LANGUAGE}Essentials.bom / ${HD}

And that's when I hit my next problem.  The bom files contain file checksums and since I'm editing a file in /etc/, it's bailing right there.

OK Doki.. I could remove the bom arguments from that line (that's something I haven't tried yet).  But since doing the round trip over 10mbps is a little slow, instead I used my Mac to just ditto -arch from one NFS share to another.  I then deleted (moved to .bak) /NextCD and /etc/rc.cdrom, which from what I can tell are the two things that are used to detect that this is an installer vs an actual disk.

I can then boot and the installer doesn't come up. NetInfo has a bit of a freakout but I figure I can fix that later (i've gotta hit c).  But then I ended up hitting a similar issue as this guy:
https://groups.google.com/group/comp.sys.next.sysadmin/browse_thread/thread/cf34fb8b2b7c08f3/b2af1c165b146bb8%3Fq%3D%2522David%2BCowley%2522%23b2af1c165b146bb8&ei=iGwTS6eaOpW8Qpmqic0O&sa=t&ct=res&cd=39&source=groups&usg=AFQjCNFzshEuNj2t-XD3ST1piICfzFkcig?hl=en

The problem seemed to be as the 2nd responder said, about the /mach symlink.  It was present, but I guess something about it wasn't working out so well.  So I copied /mach_kernel over to /mach instead (I'm on NFS with a huge drive, I don't need to conserve space).  That got me over that problem, and now the WindowServer comes up.  Yay (that only took me dozens of hours :P ).

So things are looking good, but now when the window server comes up, it seems intent on running BuildDisk, which seems to fail.  When I telnet into the machine and check /var/adm/messages I see multiple of these:

Mar 19 06:51:39 nextcube mach: audio kernel server initialized
Mar 19 06:51:45 nextcube loginwindow[182]: netname look up success: NeXT 4.0 Pasteboard Server (1)
Mar 19 06:51:46 nextcube loginwindow[182]: running /NextAdmin/BuildDisk.app/BuildDisk
Mar 19 06:51:51 nextcube loginwindow[180]: Workspace exited (ts 0 cd 0 rc 1 sv 0 ss 1).
Mar 19 06:51:55 nextcube loginwindow[180]: exiting
Mar 19 06:52:02 nextcube mach: audio kernel server unloaded

It's just looping.

So now I'm wondering:
- Am I doing something wrong with my manual install, forgetting to clear some file, or something like that?  Is there a better way?
- Or is my install actually successful now (it's taken me quite a few tries to get it to this point), and maybe I just need to tweak some file to tell it to just not worry about disks?  I've removed the default entry for /etc/fstab and replaced it with my nfs mount.

Would love any advice or thoughts on this.  I've never touched NeXTstep or OpenStep before this, so I'm slightly out of my league.

Thanks!

Rick

Noth

You're doing this all wrong. NeXT designed the OS so that it *can* be installed via the network. Here are the steps to do this (short version, there are plenty of posts on this including mine in the SPARC forum):

1. setup an OpenStep VM on your iMac with VMware or whatever.  so long as you get a recognized network card in the VM.

2. setup the VM as the master NetInfo server, including for providing netboot. Make sure you don't require a password for netboot.

3. mount the image of the OpenStep install cd and share it over NFS using the NFSManager (make sure to use the correct name for the share, should be the same as the cd name).

4. boot the Cube with "ben" as the initial command and it should connect to the VM via tftp, get it's kernel, then mount the NFS share and get it's install stuff and it'll all be fully automatic, you'll get to setup the Cube HD and then the install procedes as it would off CD.

That's  it. Good luck! For more info do make sure you consult the NeXT Systen & Networking Manual.

P.S. are you sure you're not on a TurboCube (the lack of BNC seems to point to this)? If so you can boot on CD with a SCSI CD Drive.
NeXT Cube 040 (NeXTSTEP 3.3), SUN SparcStation5 (NeXTSTEP 3.3), SGI Indigo2 R10000 (IRIX 6.5.22), SGI VSW320 (Windows 2000/Slakware 9.1)

rickfillion

Quote4. boot the Cube with "ben" as the initial command and it should connect to the VM via tftp, get it's kernel, then mount the NFS share and get it's install stuff and it'll all be fully automatic, you'll get to setup the Cube HD and then the install procedes as it would off CD.


The cube doesn't have an HD though.  That's what seems to be tripping me up.  I can boot the installer fine via network.  But I can't seem to install it TO the NFS share.

And no, I'm not 100% sure that I'm not on a TurboCube.  I haven't been able to find a good way to determine that other than looking at photos of motherboards online.  Booting off of CD doesn't really help me though, it's the lack of HD that's causing me trouble, I can boot the installer via NFS just fine. :)

So yeah... absolutely it's clear that it can be installed VIA the network.  What I'm trying to figure out, is how to install it TO the network, as a box that will never see its own HD.

mikeboss

all 68040 based cubes have BNC *AND* RJ45 connectors, 68030 have *ONLY* BNC connectors. turbo mainboards have only four 72 pin SIMM sockets whereas the non-turbos have sixteen 30 pin sockets.

http://blog-imgs-42-origin.fc2.com/t/a/s/tasan/68030-1500x1480.jpg
http://blog-imgs-42-origin.fc2.com/t/a/s/tasan/68040-25-1480x1460.jpg
http://blog-imgs-42-origin.fc2.com/t/a/s/tasan/68040-33-1520x1480.jpg
October 12, 1988 Computing Advances To The NeXT Level

rickfillion

68040 non-turbo it is... not sure how I hadn't noticed the BNC.  I guess I was too focused on the fact that it had RJ45.

Thanks, that cleared it up.

Noth

Ah if you want to just have a netbooted environment, you install a VM, and follow the chapter on netbooting a client in the N&SA. You don't need to install to n NFS partition. It works because you should have a fatbinary install for your VM.

 "installing to NFS" is the wrong way to look at it and would require too much hacking to make it worthwhile I'd say.
NeXT Cube 040 (NeXTSTEP 3.3), SUN SparcStation5 (NeXTSTEP 3.3), SGI Indigo2 R10000 (IRIX 6.5.22), SGI VSW320 (Windows 2000/Slakware 9.1)

rickfillion

OK, that makes sense.

So then I guess my next question would then be : how do I do an install of OpenStep into a VM such that it doesn't strip all binaries to only x86 supported, since ditto is passed the -arch flag for all installed files?

Thanks for mentioning the Network and System Administration Manual.  I didn't know that such a thing existed, and I'll be sure to reference that for future stuff.

Noth

I've wondering about how to prevent the fatbinaries from being "lipoed" so maybe you need to create a custom install CD. That's going to be complicated... It would have to be done from a VM, because no OS has write to UFS/nextstep supported (linux can read from).

OR

 Install the vm, then replace all x86 binaries by the fatbinaries off the CD. That sounds much easier doesn't it ?
NeXT Cube 040 (NeXTSTEP 3.3), SUN SparcStation5 (NeXTSTEP 3.3), SGI Indigo2 R10000 (IRIX 6.5.22), SGI VSW320 (Windows 2000/Slakware 9.1)

gilles

linux kernels may be recompiled with UFS write access. but it takes very long time to recompile kernel+modules on "modern" OS...