Revision as of 17:46, 10 July 2019 by Netfreak (talk | contribs) (→‎Tips)

May also be written as NeXTStep or NEXTSTEP. This is an operating system from NeXT originally designed for their m68k hardware.



3.0 or 3.2 (I can't remember which): Hyper3B
3.3: Lightning9I
4.2: Lantern5V


Reset root password

You need to interrupt the bootloader when the machine is turned on so you see a "boot:" prompt or something similar depending on the type of computer. Type "-s" without the quotes and hit enter. If this is NeXT hardware, type "bsd -s" without the quotes. When the system drops you into a single mode root shell, type "sh /etc/rc &" to start the normal services. Now do "passwd root" and enter your new password. Reboot the system.

Basic TCP/IP Config

Create /etc/resolv.conf and add your desired nameserver, so something like "nameserver" and save the file. Go to NextAdmin directory and open, click Local in the menu, use local domain only and readable, set your desired IP/router/netmask info and reboot.

NIS Client

You have to convince lookupd to look for information via NIS:

% nidump -r /locations/lookupd /
name = lookupd;
LookupOrder = (CacheAgent, NIAgent);
MaxThreads = 12;
    name = hosts;
    LookupOrder = (CacheAgent, NIAgent, DNSAgent);
    ValidateCache = NO;
}, {
    name = users;
    LookupOrder = (CacheAgent, NIAgent, YPAgent);

However, I forget whether 3.3 is recent enough to do this type of
configuration.  If not, you might try enabling the YPDOMAIN in
/etc/hostconfig and/or niloading a /etc/passwd file with just a "+" in
it to enable YP-based passwd lookups.

>If not, you might try enabling the YPDOMAIN in
>/etc/hostconfig and/or niloading a /etc/passwd file with just a "+" in
>it to enable YP-based passwd lookups.
There's no need to load /etc/passwd into NetInfo, the login program looks in
the flat file for information.

The line in /etc/passwd should be a "+:", I think (that's the way I'm using

and if there are any NIS groups, adding the same line to the end of
/etc/group would be a good idea.

So, the steps are as follows for 3.3:

Make sure there's a line YPDOMAIN=DOMAIN in /etc/hostconfig
Make sure NIS login and group lookup is enabled by editing /etc/passwd and
Reboot, or set domainname and run ypbind.

PCMCIA Support

: My question is what PCMCIA card is known to work ( besides the
: impossible to find Xircom for which drivers are available at NexTanswers.) 
: If  someone has been able to make the 3C589 ( of which I see many 
:variations ) work, what has to be done ?
for us, after chosing the right(!) interrupt (experiment a little bit
there), any 3Com589 card did - the last one we used was a version 'D'
(iirc, it might also be 'E').

The important part is to add the 'letter' behind 589 to the drivers'
id-strings (something like manufactuerer="3Com", type="589D") in the
/private/drivers/i386/"589-driver".config directory. I don't have a
version of these notebooks available, but it was quite trivial.

Not so trivial was to find the right interrupt. With the "wrong", so
allowed ones, the card was detected but simply wouldn't work (i.e. it
wouldn't send, iirc). That was a decision between an IRQ either below or
above IRQ8 (so 3, 4, 5(used by PCIC-driver), 7, or 9, 10, 11), only one
group worked (for us); I think it were the 'lower ones' and I decided
to use '3', swapping it for the second serial port, but I'm not sure.

: Hmmm, I may did something wrong, but I am not able to get a 589E to run.  
: It is some kind of 'Megahertz', up to D the cards work fine.
No, caveat emptor, my memory could play me a trick; I'm just sure a
'bunch of 589 cards' did work, not of the up to 'E' statement. For
certain I also do know it of the 'D' version, as I've put them into
to Toshibas (a Tecra 750 and a Satellite 4000) successfully.

Change Hostname

To just change the hostname, you can edit the file /etc/hostconfig.

But pay attention that the "netinfo" database also keeps information
about the host around (like names and their IP-numbers etc.). So you
should 'actualize' these data, too (it should suffice to change/adapt
the entries under the 'machines' section).

If you're really included in a (complex) netinfo domain setting (not just
one machine or just 'standalone-configured' machines), you should not
do this, but ask the netinfo-domain manager for help.


The easiest way is probably to use the "Local" config mode in
Otherwise, you'll need to change /etc/hostconfig, /etc/hosts, and the
corresponding NetInfo entries.

Printing over AppleTalk

I have a Nextstation hooked into the school network here, and I would
REALLY like to print to the local LaserWriter NTR.
CAPer shows it, and I can print up the test page, but I can't print
anything from printer selected), and is

What I would like is to print from the "Print..." menu over the 
Ethernet/appletalk to the printer.

Is this even possible?


If CAPer can show it in the network chooser and print to it (guess you used 
the top 'test' button which performs a direct PAP connection and pumps over 
the testpage) everything should be set up to print from any app. Just follow 
the instructions (It is in the CAPer README in the Info menu):

1. Create a new 'dummy' printer using /NextApps/, call it 
what you want, select the correct PPD and set it to use the serial interface 
(CAPer will change this, it is only for setup)

2. Start CAPer, start the Appletalk services, wait to establish network, open 
the Network Chooser, select the printer entity in your zone. A panel opens, 
on the top you will see the name of the printer entity at the bottom you will 
see the in 1. created printer name (Under Local Printers).

3. You now have to connect the 'Entity' to you 'Queue', select the in 1. 
created printer name, press the 'connect' button to connect it. Press the 
lower 'test' button (the one under the connect button) to test your queue 
setup. If a testpage comes out everything should be fine.

4. If you queue 'hangs' for some reason, do a 'lpc restart YOUR_QUEUENAME' 
(where YOUR_QUEUENAME is your name from 1.) as root in a shell.

Zip Drives and NeXT

The ZIP drive can do everything a normal drive can do: You can use the drive as a normal external removable disk drive. And for the adventurous, you can even build a bootable version of NEXTSTEP on a single ZIP disk and _boot_ from it! Yep, this ZIP drive'll even work with YOUR NeXT. They can be connected to just about any hardware running NEXTSTEP. This includes NeXT hardware, Intel-based hardware, Suns, Hewlett Packard machines, even the NeXT You Own. And forget about disktab and fstab entries - you won't need to add one!

SCSI Interfacing

Hooks right into your current SCSI bus, just like real hardware. ZIP drives have a pair of SCSI-1 interface ports. The ports on the rear of the unit are DB25F Macintosh-style SCSI connectors. To connect to your SCSI chain, you'll need either a DB-25 to Mini SCSI-II external cable (p/n DCA 2200, $25 from Mac Warehouse), or a standard Mac to Centronics external cable. You may set the ZIP drive to SCSI target id 5 or 6 only. Yes, you read that right - only 5 or 6. The selector switch on the back of the unit has only 2 positions; it's not a rotary or thumbwheel switch, so you have only these choices.

Yet, it does have a nice feature - external switchable termination! (given that you might otherwise need a Macintosh SCSI terminator). Would that all drive cases offered this.

Reformatting a Zip Disk

Reformatting a ZIP disk is as easy as reformatting a floppy. If you can't do that, you can't do this.
Select the drive and click on the Workspace -> Disk -> Initialize menu entry of the workspace. You'll have the option of reformatting to Macintosh or NEXTSTEP only; Currently, DOS-formatted ZIP disks work fine under NEXTSTEP 3.3 or later, but for some reason you're not allowed to reformat a NeXT-formatted ZIP disk for the DOS filesystem. [Quite frankly, that's a FEATURE, not a bug. :) ]

So, what's a person to do? The following, of course! (Kindly contributed by Frederic Stark):

Bring up a panel to insert the disk:

% disk /dev/rsd?a (? = scsi controller #)

Re-format the disk, brute-force style:

% sdformat -i? -v -f (? = scsi controller #)

Eject the disk:

% disk -e /dev/rsd?a (? = scsi controller #)

Re-insert the disk into the ZIP drive.

Depending on your karma, you should now be able to 
reformat the disk as a NeXT disk.

What's that? You can't reformat the ZIP disk that came with your Drive? It's write protected? Sure is! Why _do_ they do that? No one seems to know, but it'd sure make for a real good "Unsolved Mysteries"... :) Anyway, one way to use this disk is to hook your ZIP up to a Macintosh, run the "special" MAC ZIP software and change it. Don't have a Mac? Of course you don't! Timothy J. Luoma writes in to remind us that if you're running on Intel, you can always invoke Alexander Wilkie's ziptool utility to remove the write protection from that stubborn Zip with finesse. For you NeXT folks, you might try some 3rd-party formatters like sdformat, but keep in mind you might end up just having to chuck the disk in frustration! Before you do, though, try the sdformat procedure described above. We'd love to hear from you if you succeed!


Make: Don't know how to make /usr/include/sys/signal.h

You'll find this file under the path name /usr/include/bsd/sys/signal.h. The problem is that Makefile contains an incorrect absolution path name to signal.h (line 36):

SIGNAL = /usr/include/sys/signal.h

Change it to read:

SIGNAL = /usr/include/bsd/sys/signal.h

and then say "make".

Boot Issues

That works, once I'm in the ROM Monitor I tell it to bsd(0,0,0)sdmach rootdev=sd0
which boots the CDROM, after I tell it to reinstall it looks for the drive and bombs because it
tries to install to the CDROM. I also used p and told it not to boot en. But when I tell it to boot
sd t boots my CDROM again. I'm beginning to think that harddisk is bad.
        Once it has rebooted it no longer tries to boot from network, but it still doesn't find a device to
boot from and gives me a "blk0 boot:" prompt. I guess I don't really know what the prompt is asking
for because sd, sd0, sd0a, and /dev/sd0 or variations of that don't work..  

Well, I have finally installed NeXTStep.. I installed it on my 100MB harddisk, sd1a. Now I cannot
get it to boot, with the boot device set to sd (from prefs) it boots the CD, or tries if I remove
it, with it set to fd it will boot a floppy.. but I don't know how to get it to boot my harddisk..
I've tried bsd(0,0,0)mach rootdev=sd1a, bsd(0,1,0)mach rootdev=sd1.. and many other combinations.
Does someone know what to set to boot it?


You must set the device SCSI ID order of HD to be lower than 
that of the CD.  Long ago I tried to coax installs on floppyless systems by putting the CD-ROM lower 
than the SCSI drive.  It will install but won't boot -even after you swap SCSI ID's.  I didn't dig 
much deeper and this was long ago as I thought this might be a way to install on the older floppyless 
systems.  I suspect that one would have to do some manual file tweaking..  Even so

rootdev must be device 0 AFAIK..


I also went down this path some years ago.  The install script that
gets run when you boot from CD-ROM is called
/NEXTSTEP_3.3/private/etc/rc.cdrom .  Under normal conditions, after
installing lots of stuff on the hard disk, it prepares for the reboot
by creating "on the fly" a special /private/etc/fstab file on the HD.
This file would normally contain two entries:
        /dev/sd0a / 4.3 rw,noquota,noauto 0 1
        /dev/sd1a /NEXTSTEP_INSTALL ro,noquota 0 2
Then when the reboot happens, the HD gets mounted as / and the
CD-ROM gets mounted as /NEXTSTEP_INSTALL and the installation 
procedure continues.

However, if the device numbers are swapped initially, the install
goes fine, but the new fstab file also has the devices swapped, i.e.,
it becomes
        /dev/sd1a / 4.3 rw,noquota,noauto 0 1
        /dev/sd0a /NEXTSTEP_INSTALL ro,noquota 0 2
Now if you try to reboot, it again boots from CD-ROM and restarts
the installation from the beginning.  If you change device numbers and
reboot, it boots from the HD but then attempts to mount the HD as
/NEXTSTEP_INSTALL and the CD-ROM as /.  This also causes the boot to

It might be possible to continue the installation at this point by
NOT changing the device numbers but using a special boot command:
    bsd(1,0,0)sdmach rootdev=sd1a
However, I think I may have tried this and found that it also doesn't
work.  I'm not sure though.

Another way to recover (short of starting all over) is to somehow get
booted into single-user mode, remount the HD in read-write mode (if
necessary), and edit /private/etc/fstab.  Then swap the device numbers
and reboot normally.  I don't remember any more how I managed to get
into single user mode with the messed-up fstab file.  I think I
unplugged the CD-ROM, booted into single-user mode, found that / was
mounted read-only, and remounted it read-write so that I could fix

It's nice to know you can do these things in an emergency, but the
best advice is, set the CD-ROM to a higher device number than the HD
and avoid the problem altogether.

Error: Cannot grab ptys from subprocess.

after I did a restore from a tape without restoring the file
permissions, I get "Error: Cannot grab ptys from subprocess." I did
that restore on a blank disk with no OS installed. The error occurs
 in Open Sesam when I try to launch an application as root, when I try
to dial in Gatekeeper etc. It only happens when I am logged in as a
normal user, I don't have that problem as root. So there must be a
permission for a file or device that is not set correct, but there are
so many in my NeXTstep 3.3pl1 system...  So can someone give a hint to
solve this problem?


Going by my system (which seems to work :-), you could run, as root:

    chown root.wheel /dev/pty[pq]?
    chown root.tty /dev/tty[pq]?
    chmod 666 /dev/[pt]ty[pq]?

Another alternative might be to delete them, and in /dev/ run "MAKEDEV
pty", though since I've never done that, I'm not sure how it would
work out.  [I'd suggest doing it at a single-user prompt, though.]

If that's not the problem, then it may be something to do with the
permissions of Open Sesame or Gatekeeper, rather than the devices.
Open Sesame uses rsh, which uses ptys, so it could also be an rsh


Try "/dev/MAKEDEV std" to rebuild and fix permissions on the device files 
(including the pty's).  Otherwise, you're probably missing a setuid bit on 
the OpenSesame binary itself....

loginwindow issues

> I've got a problem when I boot my NextCube (NS 3.0):
> At the end of the booting session, a "console" window appears, instead
> of the loginwindow.
> I tried to launch the loginwindow by hand, but nothing happens. I tried
> also to launch the WindowServer, but I've got a Memory Fault.
> The strange thing is that I've done nothing on config files. I thought
> my disk was corrupted, but fsck didn't find an error.
> Has anyone got a clue about this ? Do I need to re-install the system ??

That's pretty strange that it just started doing that.  Control over this
is in the /etc/ttys file.  The first two data lines should look like this:

# console       "/usr/etc/getty std.9600"       NeXT            on secure

console /usr/lib/NextStep/loginwindow   NeXT            on secure window=/usr/li
b/NextStep/WindowServer onoption="/usr/etc/getty std.9600"

(I seperated them because the second line is long)

It's very important that the first console line be commented out.  I think
uncommenting it will make that other console appear rather than the

If something is wrong here and the path isn't the loginwindow or is
something has happened to the loginwindow permissions-wise or if it has
gotten corrupted, that could explain why it isn't launching.

You might want to try recopying the loginwindow from your CD if you have
it.  But otherwise, a reinstall may be the easier than tracking down the
real problem, which you may not be able to fix anyway.

See Also