This document pertains to the NeXTSTEP operating system, which is no longer a supported product of Apple Computer. This information is provided only as a convenience to our customers who have not yet upgraded their systems, and may not apply to OPENSTEP, WebObjects, or any other product of Apple Enterprise Software. Some questions in this Q&A document may not apply to version 3.3 or to any given specific version of NeXTSTEP.
Q: Can I boot from a release CD-ROM disc and not be required to initialize or upgrade the hard disk drive?
A: Yes. You will have the ability to view, copy, move, etc. files, run programs, and perform other similar operations. While you can't boot a full NEXTSTEP environment (Workspace Manager, et al.), you can boot single-user from the CD-ROM installation disc.
Intel (i386) architecture Insert the CD-ROM disc and the boot floppy and boot the system. On the i386 architecture, booting starts from the floppy drive and continues to the CD-ROM.
At the boot: prompt type: boot: mach_kernel -s Follow any instructions (it may appear as though an install or upgrade is being performed; be patient) until the UNIX command line prompt is displayed. If you are asked which disk to install NEXTSTEP to, then you must have made a mistake at the boot prompt.
NeXT (m68k) architecture Use <Command><Command><~> after power-on to get to the ROM monitor and type the following:
For Non-Turbo systems with internal floppy Insert the boot floppy and type: NeXT> bfd -s For Non-Turbo systems with SCSI floppy Insert the boot floppy and type: NeXT> bsd(n,0,0) sdmach -s rootdev=sdn Where n is the unit number of the floppy drive. In this scenario, it may be helpful to have the CD-ROM drive set to a higher SCSI address than the SCSI floppy.
For Turbo systems Turbo systems have the ability to boot directly off the CD-ROM drive without assistance from the floppy drive. NeXT> bsd(n,0,0) sdmach -s rootdev=sdn Where n is the unit number of the CD-ROM drive.
All architectures Mounting a hard disk
Note that when booted single user from a CD-ROM, the file system is mounted read-only. Certain functions may not be available. This state can be somewhat alleviated by mounting /tmp on another available disk. Use the -n option with the mount command to prevent writing to /etc/mtab (which fails, obviously). As an example:
# mount -n /dev/<device> /tmp
where <device> is the disk you wish to mount (eg. sd0a, hd0a).
Once in single-user mode, you can still run the CD-ROM build disk scripts by running the rc scripts: # sh /etc/rc
Copying & Editing.
Under Release 3.3, you can use ditto(8) to perform a copy of an entire directory, preserving links and setuid and setgid modes. pico(1) is a simple text editor that ships with 3.3 for those that find vi(1) confusing. See the man pages for information on these commands.
Q: From where does a netboot server (bootpd) get its ``served kernel'' information?
A: The netboot server gets its kernel information from two sources:
* NetInfo and
* /etc/bootptab.
(Yes, from both. Even if NetInfo is running, the file is consulted.)
There are two types of bootpd information: global (i.e., for all netboot clients) and local (i.e., for a specific client). The global information is read from the file /etc/bootptab; the local information comes from NetInfo (the /machines/client directory).
There are two pieces of global information: the tftpboot root directory, and the default kernel to be served. [What's tftpboot? It's the file transfer mechanism used for netbooting -- trivial file transfer protocol boot.] All kernels which can be booted must be located in the tftpboot root directory, which is typically /private/tftpboot on our system. Any pathname given, either for the default kernel or for a per-client kernel, is relative to the tftpboot root directory; further, that directory is considered as the root directory for the tftpboot process, so a path like /sdmach will be interpreted as /private/tftpboot/sdmach. (Why is this done? Security: it prevents booting arbitrary files from the boot server.)
Then there's the local information: a host type, ethernet address, IP address, and bootfile. These are all obtained from NetInfo. Note that, although the host type appears in bootptab, it is not present in NetInfo; if an niload(8) is done, it MUST have the value 1 (else niload will yield an error). If you nidump bootptab, a 1 will be provided in the field.
Now, the stage is set for explaining how the netboot sequence occurs, regarding the boot protocol.
The following paragraph describes the boot sequence from the server's perspective:
1. A client sends a BOOTP broadcast, asking for the file boot (the name is in the PROM). This is the request for the ``blk0 loader,'' also known as the ``bootstrap loader.'' The server notices same.
2. The server then checks in NetInfo to determine if the ethernet address in the BOOTP request is known. The NetInfo hierarchy is searched, starting with the local domain, looking for a /machines entry with an en_address property whose value matches the address of the broadcaster.
3. If the ethernet address is known, the server responds to the client with information including the path to the bootstrap loader. This path is comprised of two components: the directory, and the file name. The directory is determined from /etc/bootptab (yes, even if NetInfo is running); this is the ``tftpboot root'' directory. The file name was specified by the broadcaster (the client) in 1, above, as boot.
4. A request from the client to transfer the bootstrap loader is received; the loader is sent back, using TFTP.
5. Another BOOTP request is received, this time for the pathname to the kernel. The path is sent, determined from a combination of NetInfo and /etc/bootptab. Specifically, the tftpboot root directory (at the top of the tree from which kernels can be obtained) is found in bootptab, as is the default kernel to be sent. The kernel to be sent can be overridden in NetInfo: the bootfile property in the client's directory in the /machines directory specifies this. (Domains are searched on the server, starting with the server's local domain, continuing up the NetInfo domain hierarchy.) It can also be overridden by the client, in the boot command specified [e.g., ben()new_mach]; note that any explicit path given for a kernel will be relative to the tftpboot root directory.
Transfer of the kernel, using TFTP, completes this phase of the boot sequence.
One other note. This notion of ``tftpboot root'' is a bit unusual. A chroot(2) is only effected during the actual transfer. If a path such as ../MyMach (e.g., ben()../MyMach) is given for the kernel, strange things will result. Specifically (assuming the normal tftpboot root) /private/MyMach (that is, /private/tftpboot/../MyMach) must exist, and MyMach must exist in the tftpboot root directory. It is the latter of these which will actually be TFTPed to the client. Note also that the kernel file name shouldn't have any dash characters (-) in it: the dash is used by the PROM's boot command to denote arguments to be passed to the booted kernel.
Q: I'm booting a NetBoot client--or, rather, trying to. But it keeps looping through the reboot, getting only as far as allocating a swapfile. What's wrong?
A: One cause of this could be that the client's private partition is not exported correctly. The private partition must be exported with root access for the client. Even when /etc/exports indicates a proper entry, if a parent directory of the client's private partition is a) on the same filesystem, and b) exported without root access for the client, then the client's private partition is not exported with root access for the client (note that exports information is stored in the NetInfo database in Release 3 and later; see the NetInfo exports directory and NFSManager.app).
A situation where this readily occurs is when you're trying to use a machine with one partition on the disk as the NetBoot server. This is not a supported configuration. In this situation, the exports file might look like:
If the disk has only one partition then the clients' partitions is not exported with root access for the client. To fix this, change the exports file to:
/ -access=rhino:cockatoo,root=rhino:cockatoo
If you want to leave the explicit lines for the two client partitions, that causes no harm, and might help avoid a problem if you ever set things up on a two-partition disk.
Q: The commands w and netstat return "no namelist" on a netbooted client. What's going on?
A: The w command prints a summary of the current activity on the system, including what each user is doing, The netstat command symbolically displays the contents of various network-related data structures. Both of those commands examine the system namelist kept in the file /mach (the kernel). The kernel namelist contains the current system addresses. On a netbooted client, /mach references the path /clients/client/tftpboot/mach. If this file is not present, any command that uses the kernel's namelist cannot complete successfully and returns a "no namelist" error.
To fix the problem, make a symbolic link to the kernel like this:
* On the netboot server, launch the Terminal application as root
* Run the following command:
![[Index]](http://enterprise.apple.com/NeXTanswers/images/index.gif)
![[Download]](http://enterprise.apple.com/NeXTanswers/images/Download.gif)
