Please keep in mind that a careful reading of the NetBSD/mac68k 1.5 install documentation will save you the trouble of asking most of these questions.
If you are having upgrade difficulties and the INSTALL notes do not seem to be helping, you can also take a look at Mark Andres' (email@example.com) Upgrade HOWTO:
4MB RAM is an absolute minimum, but we expect the machine to be virtually unusable with only 4MB. Recommended minimum is 8MB. You can't have too much RAM. Preferred size is 16MB or more.
You can probably cram the basics (i.e. base and etc distribution sets) into 80 MB or less, but here are some words of wisdom from Bill Studenmund (firstname.lastname@example.org):
100 meg would get you going for a root partition, but depending upon the toys, you'll want more. My setup is ~100 Meg for my root partition, and ~350 Meg for my USR partition. I actually have the whole installation in my root partition (NetBSD is much more svelte than some of the pro UN*X's we have in lab :-) ), with my kernel compilations, ghostscript work, and more in the usr partition.
If you want to get into kernel compiling, you probably will need more space.
Check out the NetBSD/mac68k 1.5 install documentation for further recommendations and the uncompressed sizes of the NetBSD distribution sets.
No, but you should have one. NetBSD will hang without warning when it runs out of memory and encounters no swap partition.
One often used method for determining how much swap space you need is to take the amount of available RAM and double it. It has also been recommended that your total memory (RAM + swap) be at least 20 MB. Thanks to David W. Rankin Jr. (email@example.com) who adds:
When I ran 1.0 on a IIsi with 5 megs and 12 megs of swap, the weekly cron jobs would kill the machine. Of course, that's an 80 meg drive, so it's not like you have to make a filesystem versus swap tradeoff. :)
Moreover, if you happen to have any small unused SCSI drives around, it never hurts to have your swap space on a disk that's not used by anyone else.
Please note that NetBSD does not require that you have twice as much swap as you do RAM (e.g. if you have 40MB of RAM, you probably don't need 80 MB of swap). Under NetBSD, swap is additive, so your total memory equals RAM plus swap. Therefore, you could have more RAM than swap if you so desire (you will not be able to get a full crash dump unless your first swap partition is at least as large as physical memory, though). However, NetBSD does not gracefully handle running out of swap, so be sure to give yourself enough to handle your normal load of processes.
As of NetBSD 1.3, swap devices are configured dynamically at boot time and
can be specified on arbitrary partitions. All you have to do is record
your swap devices in
/etc/fstab. Make sure that you have at least
one swap device or NetBSD will not configure any at boot time. Please see
the swapctl (8) manual page for more details.
No. If the partitioning software allows it, you can allocate all space on a drive to BSD partitions. Note, this drive will not show up on your desktop. Therefore you will need the booter either on a bootable floppy or on a Mac OS partition on another drive.
No. The "Build Devices" menu in the Installer utility will create
/etc/fstab for you with the appropriate entry for a swap
partition. When you boot into NetBSD,
/etc/rc will execute the
swapctl command and mount your swap partition.
Please note that versions 1.1a through 1.1c of the Installer create a
possibly incorrect version of
/etc/fstab putting swap on sd0b.
The solution is to obtain Installer 1.1d or later.
"Trap not implemented error"when I try to use it?
You are probably using version 1.0 of the Installer utility. If you give it a larger memory partition, i.e. increase its preferred memory size in its Get Info box to about 1500K, it should run just fine. Unfortunately, this version of the program was compiled with a memory size that is too small.
You will probably want to get a copy of version 1.1 or later of the Installer utility, which has slightly greater functionality. The current version is available at:
Please keep in mind that this version of the Installer will not run on System 6.0.x or earlier.
When the Installer fails, it sometimes leaves the filesystem corrupt, so before you reinstall, redo the "Mkfs" for safety's sake.
Thanks to Steve Brown (firstname.lastname@example.org) for updating the Installer utility (and providing the above answer).
(NOTE: It appears that even the newest installer utility may crash on particularly large archives. Doubling its preferred memory size should still alleviate this problem.)
If you are using Mkfs 1.2 or later (Mkfs 1.45 is the latest version at this time) then just about any formatting/partitioning software should work. Even if it doesn't support making A/UX (or NetBSD) partitions. The newest Mkfs gives you an option for converting a partition into a NetBSD compatible type. See the Q&A below on creating additional partitions with Mkfs 1.2 or later for more information.
If you are using and older version of Mkfs then any hard drive utility software that is capable of creating A/UX 2.0 partitions should suffice. Please note that A/UX 3.0 type partitions are not compatible with NetBSD/mac68k. Two commercial packages that have been recommended in the past are FWB's Hard Disk Toolkit and LaCie's Silverlining.
According to information posted to the mailing list, Alliance Power Tools' APS 2.x.x formatter is in fact a re-packaged version of the commercial product SCSI Director. As such, ftp sites for this product will no longer be listed.
There is also a patch to allow Apple's HDSC Setup program to be used with non-Apple drives. A patched version of the program is available at (this version seems to unavailable at the moment -- email@example.com).
In addition, there is another patched version, called HDSC Setup 3.0.1 (A/UX) available at http://www.euronet.nl/users/ernstoud/hdsetup.html .
Information for patching Apple HDSC Setup 7.3.5 yourself can be found at http://www.euronet.nl/users/ernstoud/patch.html .
HDSC Setup's A/UX auto-setups will create an Eschatology partition, which you will probably want to delete. The Apple drivers which it installs are reportedly faster than many commercial ones.
Information on Apple's HDSC Setup contributed by:
Information on the APS formatter contributed by Monroe Williams (firstname.lastname@example.org).
Thanks also to Ben Cottrell (benco@ucsee.EECS.Berkeley.EDU) for additional information about partitioning software.
From Bill Studenmund (email@example.com):
It's a matter of taste. The reasons for having different partitions is two-fold. Some partitions, like /var or /tmp or /home, you want independent so as to keep them independent from everything else (so filling up one doesn't mean the whole machine's out of disk space.
Now the above's a matter of style. My home machine does NOT have separate /home, /tmp, and /var partitions. All our workstations in lab do. You'll do fine w/o them separate, especially if you are the only user.
The other reason for separate partitions is so that if you have a power loss, only part of the disk gets sick. If part of your system is not changing w/ time, if the power goes down, you won't get a (or MUCH less of a ) corrupted file system. It's like on my Mac OS side, all my applications (which rarely change) are on one partition, and my data files are on the other. If my machine crashes, I only need to sick Norton on the data partition. :-)
It really depends upon what you want to do. I have one partition with most of the system in it (oh, this also makes the install easier - install just to the root partition), and my play space for compiling separate.
Your system must have at least one partition of type "A/UX root" or "Root
slice 0" (or "root&usr"), but any remaining filesystem (i.e. not swap)
partitions can be of type "A/UX User" (or perhaps "A/UX Usr slice 2") in
addition to "A/UX Root" or "A/UX root&usr", regardless of whether or
not you will be using them for your
/usr hierarchy. Apparently
partitions with "root" in the name fall at lower positions in the disklabel
(i.e. e and f) than do partitions with only "usr" (i.e. g and h).
"Free Unix slice" partitions and other partitions will not work
Another important fact is that A/UX 3.0 filesystems apparently will not work with NetBSD. You need to use an A/UX 2.0 partition instead.
Thanks to Ben Hockenhull (firstname.lastname@example.org) and Steve Ihde (email@example.com) for providing this information.
However, the above has been made almost obsolete by the latest version of Mkfs. According to Bob Nestor (firstname.lastname@example.org):
Code has been added to allow any Partition, other than the Partition Map and Driver Partition(s), to be converted into NetBSD Root & Usr Partitions, NetBSD Swap Partitions, Mac OS HFS Partitions, or into Apple_Free Partitions. This should make it possible to use any Disk Formatter to prepare a NetBSD volume, even if that Formatter does not support creation of AU/X partitions. An Apple_Free Partition is one that is allocated but not in use. It won't show up under Mac OS so it's a good way of reserving disk space for future allocation and use. Selecting any type of BSD partition (AU/X, NetBSD, Root or Swap) for change and doing the change without modifying the Partition Type will cause the Partition Name to be re-written as a NetBSD Partition Name. No changes are made to Apple_HFS Partitions unless the user specified a Partition Type other than Apple_HFS. There is no check for an improper use of an active Mac OS HFS partition when converting to a NetBSD type. The user is warned about converting any HFS partition that is mounted, but failure to heed the warning can lead to possible disk corruption, system crashes or worse. Some disks and/or partitions may not format correctly and the program may hang. This may be related to having a block count not evenly divisible by the block-per-cylinder value. For some reason running with the debug statements enabled seems to get around this and allow formatting of the partition. An attempt is made to pull up the Mac OS Disk Partition Name from the info recorded in the partition itself. The Partition Map Block associated with the Disk Partition does not always contain the Mac OS Partition Name. This is an optional field entry in the Map Block and not all Formatters take the time to initialize it. Also, the Disk Partition Name for a Mac OS Partition can be changed under Mac OS and this is not reflected in an updated Map Block. Some disk formatters complain if they don't recognize the "standard" Partition Names that they use when initializing the disk. This shouldn't be much of a problem, but it's annoying (and frightening) when one uses their disk formatter to re-partition a disk that's been touched by this version of Mkfs. NetBSD can be pretty anti-social when faced with disk partitions it thinks it should be able to mount and use when they aren't properly formatted. Therefore it's pretty good practice to not create a NetBSD Root & Usr Partition without running Mkfs on it. This is probably a place with Apple_Free partitions can be put to good use since NetBSD doesn't recognize them as FFS disks.
Recent updates to Mkfs (i.e. 1.4 or later) now allow it to properly create NetBSD "Root&Usr" and "Usr" partitions in addition to the "Root" partitions it created before. The Installer should recognize all of these partition formats correctly now.
You can obtain the latest version of Mkfs from: ftp://ftp.NetBSD.org/pub/NetBSD/arch/mac68k/
Keep in mind that NetBSD can only handle 8 total NetBSD partitions on a single disk, although the number of useful partitions is limited to about 6 (i.e. partitions a, d, e, f, g, and h; b is reserved for swap and c is used to indicate the raw disk).
Although the Mac OS-based Installer utility can install the gzipped tar archives in which the binary snapshots are distributed, there is an often much faster method for doing so.
First, you need to obtain the snapshots and put them in a place that you
can access them from NetBSD. There are a variety of ways you can do this.
You can directly transfer them to your NetBSD filesystem via ftp (or
zmodem, if you are using a serial connection), or you can transfer them to
your Mac OS filesystem via whatever method you choose (be sure to use binary
mode for transferring the snapshots or they will be corrupted), and then
copy them into your NetBSD partition using either the
hfs utility or
the hfsutils package. You can also just cpin the files using the
Installer, but I believe that the hfs programs are faster (and probably
more in the NetBSD spirit as well). Remember that these programs must be
run as root in order for them to be able to access your Mac OS partitions.
Second, it is probably best to install the snapshots in single-user mode,
so either boot up in single-user mode, or else do a
shutdown now to
bring your system back down to single-user. If your filesystem is not
mounted read-write at this point, it needs to be, so do a
mount -a to
mount all of the filesystems in /etc/fstab read-write.
Now it is time to actually install the snapshots. Make sure that you are in the root directory, and for each snapshot except for etc.tar.gz, use the following command:
tar --unlink -xvzpf file.tar.gz
unlinkoption will allow you to overwrite currently open files like the shell and
zoption gunzips the archive, and the
poption preserves the permissions of the files in the archive.
For etc.tar.gz, you will probably want to untar it in the
/usr/tmp directory instead. There, you can examine the files and
see which ones you need to update. Just copy them to the
directory by hand. If you do not do this, any changes you have made to the
configuration of your machine will be erased.
Keep in mind that you probably do not need to install current binary
snapshots if you are not running on netbsd-current kernels. If you do, you
may experience quirks in those programs such as
which directly access kernel memory because your binaries will be out of
sync with your kernel.
Thanks to the following people for helping with this answer:
Since the kernel is NetBSD, it is very important that you install a new kernel in the right way. Kernel files may distributed in one of three ways:
You might consider booting the new kernel from Mac OS, single-user mode, just to make sure that it recognizes your hardware properly. Taking the plunge can sometimes be scary.
You will probably want to be root when following this procedure if you are doing it from the NetBSD side.
The first thing you need to do (after transferring the new kernel file to your machine), is to backup your currently working kernel. There is no guarantee that any particular new kernel will work on your machine, so do not eliminate your old one until you are sure that the new one works.
Next, you need to extract the kernel (if necessary) and copy it into your root directory. The Mac OS Installer utility should handle installing a gzipped tar archive directly (in fact the Installer only "installs" tar and gzipped tar archives), the other two formats should be copied into your NetBSD partition if it is not already there. To extract the gzipped tar archive from within NetBSD, use the following command:
tar xvzpf filname.tar.gz
Now, you will probably want to rename your new kernel to
if it is not already called this. The reason for doing so is that many
programs expect to be able to access the kernel by opening this file, and
if you have your kernel named something else, these programs will fail. If
you choose to use another name instead, remember to change the name of the
kernel in the Booter utility.
If you are in NetBSD, you must now reboot your machine to use the new kernel. If you are in the Mac OS, the new kernel will automatically be used when you next boot.
Thanks to Scott Reynolds (email@example.com) for tips on this answer.
Error on SCSIRead(), #5. What's wrong?
This is an indication that an error of type 5 (a phase error) occurred. In the past, it has been a result of a bug in the earlier Installers (often they are trying to read the disk label off of a CD-ROM drive). It occurs in the Mkfs utility as well. If this is the case, it is harmless, and it is safe to ignore this particular error message. Newer versions of the Installer may have fixed this particular bug, although it may still exist in the latest version of the Mkfs utility.
However, recent reports indicate that the most recent version of the Installer (1.1g as of this writing) still has difficulties with partitions on large drives (i.e. greater than 1GB in size). The problems seem to occur most often on Quantum Fireball drives (I don't believe that it is limited to them), but the key factors seem to revolve around having partitions (often large partitions) located on the upper portion of the disk (i.e. beyond the first 1GB of the disk) and writing large distribution sets to these partitions (smaller sets often complete, but the base distribution set will often die). A similar bug in the Installer was fixed a while ago, but this one appears to be slightly different.
If this problem still persists after increasing the amount of memory you have allocated to the Installer, there are a couple of workarounds. The best workaround is to have your NetBSD partitions at the start of the disk (or as close to it as possible). If this doesn't work, try the following procedure from Mark Andres (firstname.lastname@example.org):
When you install base.tgz, you will probably get most of the files installed before it gives up the ghost. IIRC, the most recent victim got as far as /usr/share/man/something before it stopped. Tar is in /usr/bin, so it should have already been installed. Here is what you do. 1) Install base.tgz as far as you can. 2) Install kern.tgz (or the SBC kernel), etc.tgz, and any other tarballs that you can get get. 3) Use the mini-shell under the installer to cpin the remaining tarballs as well as base.tgz. If you don't have enough space on your / file system, you will need to install it on another file system. 4) Boot into single-user, run fsck -f, and mount your partitions using mount -a. 5) Use tar to install the remaining tarballs. You need to be in / and then do tar --unlink -zxvpf /path/to/base.tgz Do the same for the other tarballs and you should be able to have a complete NetBSD system.
A totally revamped installation procedure may be required before this bug is fixed.
Thanks also to Stephen Brown (email@example.com), Charles Sebold (firstname.lastname@example.org), and Stuart McLuckie (email@example.com) for their help in answering this question.
Older versions of the Installer (and the NetBSD kernel) only check the first 8 partitions for NetBSD-style partitions. If you have a lot of partitions on your drive (including the partition map and driver partitions), it could be that your NetBSD partition falls beyond the first 8. So, the Installer won't recognize it. Try re-ordering the partitions on your drive and see if that fixes the problem.
I believe that more recent versions of the kernel actually search the first 32 partitions, so be sure to upgrade your kernel to at least the 1.2 distribution version.
If you do not wish to reorder most of your partitions, you can make sure that you have one partition low enough in your partition map to access it via the Installer, and then copyin any files you want to install on other partitions. From there, you can boot into NetBSD and unarchive the files directly into their partition(s).
Keep in mind that NetBSD can only handle 8 total NetBSD partitions on a single disk (and only 5 of these are useful).
This is probably because you have a rather large hard drive (usually larger than 1GB in size) and tried to run Mkfs on a particularly large partition. From Bob Nestor (firstname.lastname@example.org):
Mkfs has a problem addressing any disk block above a certain point. It only uses a 6-byte CMD for talking to the SCSI Manager which limits it to 21-bits for block address. When it exceeds this is happily truncates the numbers causing them to wrap down to lower numbered blocks.So, it is quite possible that Mkfs'ing a large partition will destroy other partitions on your drive, including the partition map and the driver partition, rendering your drive virtually useless (you would have to re-initialize it). The problem seems to manifest itself only when accessing partitions beyond the first gigabyte of the drive.
This problem also occurs in the Installer utility.
Fortunately, there is an easy solution: get the latest version of each utility. They are available at:
A slightly more complex solution is to make sure that none of your NetBSD partitions lie above the first gigabyte of your hard disk.
This problem is a result of version 1.1c of the Installer having been compiled with FPU instructions built in. The problem will only show up on machines without an FPU. Since 1.1c was recompiled to remove this problem and 1.1d does not have this problem, upgrading to version 1.1d or later is probably the easiest solution, but another possible solution is to install Software FPU.
Thanks to Steven Campbell (email@example.com) for pointing out this problem and Stephen C. Brown (firstname.lastname@example.org) for fixing it.
This problem (and some minor incompatibilities with some formatters) have been fixed as of Mkfs 1.45. Please obtain a copy of the latest version and try it instead. A description of the reasons behind the problem (and the now obsolete work-arounds) follow below.
From Bob Nestor (email@example.com):
Mkfs 1.2 made the assumption that the disk Partition Map was something like 20 entries in size and used anything that looked like it might be a valid entry. Mkfs 1.4 uses the size of the Partition Map as recorded in the Partition Map itself. Unfortunately there is a little known bug in the way some disk formatters create the Partition Map when they format the disk. Some, but not all, formatters have an off-by-one error in sizing the Partition Map. The latest Apple HD Formatter exhibits this as I recall. Certain 3rd party disk formatters catch this and report the disk as damaged, but correctable. We could "fix" mkfs to handle this off-by-one error and use the block following the Partition Map if it appears to look like a Map Entry, but this seems a little dangerous as the data usually found in this area is the SCSI Disk Driver for Mac OS. If this Partition gets damaged and the disk is the primary boot disk, the Mac ROM will abort the boot process with Death Chimes even *BEFORE* allowing one to boot off the floppy! Having done this to myself when I was working on mkfs I decided not to inflict the same harsh lesson on others by not "fixing" the Partition Map off-by-one error in mkfs. Maybe that wasn't the right decision, but it seemed correct at the time.
Another work-around, as many have reported, is to create a minimum-sized Mac OS Partition at the end of the disk. This forces the creation of a Partition Map entry at the end of the Partition Map which, if we have the off-by-one error, won't be seen by mkfs. This is also a good place to put the Booter and friends.(Putting a 1 kB Scratch partition at the end of the disk will also work if you don't want to sacrifice disk space --Colin)
In Mkfs 1.2 the Partition Map was only read, never written, so going off the end never really was too serious. In mkfs 1.4 we now have the ability to "zap" Mac OS Partitions into NetBSD type partitions. To do this the corresponding Partition Map entry block needs to be re-written. Writing a block on the disk's SCSI Driver Partition because of a bad Partition Map is a real possibility and in fact happened once to me during testing. Making mkfs work with Partition Map entries that are known to be valid was an easy way of protecting against this error.
The reason for this is that NetBSD believes it has received a BREAK signal, which is the traditional way to invoke the debugger. If you wish to disable this feature, you need to turn comment out the line
in your kernel configuration file, run config, and recompile the kernel.
newfsto format my partition, why does the Installer crash when I try to install on it?
The Installer only recognizes level 1 ffs filesystems. By default,
newfs creates a level 2 ffs filesystem. A level 2 filesystem has some
functionality which the level 1 filesystem does not have. See the newfs(8)
man page for more details on the differences.
There are two possible solutions here. One is to reformat your partition
using the Mkfs utility (this will wipe out anything you have on your
partition, though). The other is to use
hfs or the hfsutils package
to copy binaries in and install them from the NetBSD side as described
A relatively up-to-date list of all changes (including those in -current) is available here:
Each NetBSD release directory should have a similar file covering the changes up through that release.
fsck. What's wrong?
Two possibilities. One is that you need to change all references to
/etc/fstab to read
ffs instead. The other
possibility is that you didn't overwrite the old version of
/sbin/fsck_ffs. Follow the procedure in
the NetBSD/mac68k 1.5
documentation for upgrading from within NetBSD to avoid this
unimplemented traperror when I try to install to my 2GB disk?
Apparently, the Installer has difficulties writing large amounts of data to
large partitions. As a workaround, you can either use multiple smaller
partitions, or else you can use the Installer to install as much as you
can, hope it manages to install
tar, and then copy in the archive and
install the rest of it from within NetBSD. The first option might be the
better way to go on this one, however.
Thanks to Paul Forgey (firstname.lastname@example.org) for this workaround.
/etc/rc.conf is not configured. Multiuser boot aborted.?
As mentioned in the upgrading section of the INSTALL doc, you need to edit
/etc/rc.conf to your liking and set the line the proper
line like so:
This will enable you to complete a multiuser boot. This file didn't exist under NetBSD 1.2, and it contains a number of useful features you may wish to enable. Please read it carefully and check the rc.conf(5) man page for information on the various options. If you have trouble editing the file, please read the NetBSD/mac68k 1.5 install documentation for detailed instructions.
The version of the Installer program that shipped with NetBSD 1.5 was not updated in time to build the new devices that are required. You have a couple of options for working around this. The first option is to download the latest version of the Installer and used it to "Build Devices" once again. The latest version is available here:
The second option is to boot into single-user mode and do the following:
Either solution should create the necessary device files and eliminate the annoying
mount -rw / cd /dev sh ./MAKEDEV all
/dev/ttyE0: No such file or directory.message that you are probably getting. Please do not attempt to edit
/dev/ttysto change the console line back to
/dev/ttye0as this device is no longer used under 1.5.
Table of contents of this chapter, General table of contents
Beginning of this Chapter