This is really quite simple. All you need to do is to obtain a copy of the Booter utility (as of this writing 1.11.1 is the latest version, older versions may work, however) and a kernel file, preferably raw (i.e. not gzipped or tarred). The latest version of the Booter utility should be capable of handling gzipped kernel files. Both can usually be obtained by anonymous ftp from ftp.macbsd.com or ftp.NetBSD.org. In the Booter, select Options->Booting. In the Boot Options dialog that appears, select the radio button which says "Mac OS File" for the kernel location. Clicking on the "Set..." button will present you with a standard open file dialog. Select the location of the kernel file. Then click OK, and select Options->Boot Now. You should see a list of things scroll by in the Booter window, and the screen should go entirely white. A series of bootstrapping messages should go by. If you manage to get to the line:
boot device: sd0
root device (default sd0a):
If the bootstrap never leaves the Mac OS booter, then try disabling the options in the booter about video interrupts, etc. Another possibility is that you have corrupted the kernel file while decompressing it. If this is the case, the booter will probably hang at the line:
Set _mac68k_vrsrc_vec to {0x0 0x0 0x0 0x0 0x0 0x0 }.
You should be able to ungzip the distribution files and re-tar them into smaller chunks. Then re-gzip them.
Literally speaking, it is "the teachings of the end of the world".
In this context it is a type of partition for older versions of A/UX. Apple must have meant it in good humor as a sign to administrators to prepare their systems for disaster. The eschatology partition is supposed to allow the system to automatically recover critical system files whenever the system goes down. It's part of the A/UX "autorecovery" process. It was supposed to work by maintaining backup copies of these critical files for you on two separate partitions -- Eschatology and Eschatology2. In five years of college with hundreds of other students with A/UX machines, I've never once heard of an incident where autorecovery kicked in and did its thing.
It's the new name for an Eschatology partition. I believe Apple renamed Eschatology to Autorecovery starting with A/UX 2.0.
No.
If for any reason your formatting software forces you to create an "Eschatology", "Eschatology2", or "Autorecovery" partition, remove the partition and try to increase the size of other partitions you have alloc- ated to re-claim the space.
Those files are in BinHex format. They need to be converted back to binary form, or "de-BinHexed". There are numerous utilities to perform this conversion under Mac OS (such as Stuffit Expander or BinHex 4.0), or you can use the mcvert program on many unix systems to de-BinHex them:
mcvert base10.hqx
Verify this checklist before going any further:
Make sure that you have the latest version of the Booter (1.11.1 as of this writing).
If you are trying to boot a IIsi using a PDS/NuBus video card, be aware that you probably need to be using internal video in some way. More on this below in the Q&A on booting a IIsi with a video card .
If you are trying to boot NetBSD on a full installation (i.e. you are not
just testing a raw kernel file from the Mac OS), make sure that you make
devices using the Installer utility. Also, make sure that your swap
partition exists before making devices so that the Installer will create
the proper /etc/fstab entries.
Please note that versions 1.1a through 1.1c of the Installer create a
possibly incorrect version of /etc/fstab putting all of your
partitions on sd0. The solution is to obtain Installer 1.1d or later
(version 1.1g is current as of this writing).
If none of the above work, there are two possibilities: one is that NetBSD/mac68k does not currently support your machine. The other is that the kernel you are trying to boot does not support your machine or your hardware. You should probably try a different kernel. Check out the Meta-FAQ for a list of useful web and ftp sites where you might find additional kernels:
http://www.macbsd.com/macbsd/macbsd-docs/meta-faq/
Perhaps of some help (depending on how recently it was updated) is the machine-status document, which should tell the status of NetBSD-current on your machine. It is located at:
http://www.macbsd.com/macbsd/macbsd-docs/machine-status/
Finally, it's quite possible that the most helpful resource is Mark Andres' (mark@ratbert.aisol.net) MacBSD Kernel Page:
http://www2.giganet.net/~mark/NetBSD/kernels.html
In the words of Allen Briggs (briggs@macbsd.com):
Your problem is that you're not using internal video. The IIsi only has 1MB soldered on the motherboard in bank A and the memory map looks different depending on whether or not the video is enabled. NetBSD does not correctly handle the case where the kernel does not fit into the first chunk of physical RAM.
With internal video enabled, the part of bank A not used for the display is mapped to follow bank B and bank B is mapped to 0x0. With internal video disabled, bank A is at 0x0 and bank B is mapped to follow bank A (at 1MB). The IIci is the same, but most people have more than 1MB in bank A of their IIci so it's not a problem.
You can work around this by either attaching a display to the internal video port, or putting a display adapter (or a paper clip in the right place) that makes the circuitry think that there's a monitor attached.For more information on this solution, see the Q&A below on booting without a monitor .
This is another symptom of the above problem.
Yes. You need to zap the PRAM by holding down Command-Option-P-R while booting into the Mac OS. For some reason, the AV Macs (i.e. Quadra 840AV and Quadra/Centris 660AV) are more susceptible to this problem than other classes of machine. However, zapping the PRAM seems to cure most of the problems.
Thanks to Dave Huang (khym@bga.com) for this information.
Yes. The security distributions merely contain Kerberized versions of utilities such as telnet in addition to DES decryption code. A standard NetBSD distribution is shipped with cryptographic encryption code which is sufficient for a working NetBSD system.
If you simply are wondering if you can run without a secr distribution because you cannot find one, it can be found in the "mac68k/binary/security" subdirectory of the NetBSD release distribution tree.
In the words of Chris G. Demetriou (cgd@NetBSD.org):
"NetBSD, in general, is meant as a "stable research platform" -- that is, a system that can be used for commercial, home, and research work... what _you_ do with it is up to you. In general, those of us working on NetBSD are trying to improve the system in whatever way we can -- support for more hardware, stability, performance, documentation..."
Yes. Mark Andres (mark@giganet.net) has an excellent HowTo describing how he set up Japanese support on his system:
http://www2.giganet.net/~mark/NetBSD/japanese.html
No. This is probably not a good idea. You should get the copy of MODE32 which works with your system. It is recommended that you use the version called MODE32 (7.5), since earlier versions may not work well with System 7.1 or later. After installing MODE32, be sure to set your machine to 32-bit addressing mode in the Memory control panel. I believe that this version can be found in the following location at http://download.info.apple.com/.
It allows you to have a kernel in the Mac OS HFS file system which the Booter will boot off of instead of booting off of a kernel file in the NetBSD FFS filesystem. This highly useful feature allows you to test kernels on your machine before actually going to the trouble of performing the entire NetBSD installation. If a kernel will actually work on your machine, then booting it from the Mac OS will get you all the way through the boot process until it has to change the root device. So if you are interested in running NetBSD on your machine for the first time, this option is a good one to try.
The problem stems from the fact that Apple decided clock interrupts should have the lowest priority (they are usually the highest on UN*X systems). As a result, under a heavy interrupt load (like lots of serial activity), it tends to miss clock update interrupts, thus causing the machine to lose time. Apparently, this is also a problem under Mac OS, but it doesn't show up as severely as under NetBSD.
However, Richard Todd (rmtodd@servalan.servalan.com) notes:
The battery-backed-up clock that keeps time when the machine is off is considerably more accurate than the one that supplies clock interrupts. Every time you reboot, the kernel clock gets re-initialized from the battery-backed-up clock, so you get correct time.
What can you do about this? If you are connected to the Internet, the best
thing you can do is to run xntpd. As the Network Time Protocol (NTP)
daemon, xntpd contacts Internet time servers and synchronizes you system
clock with them. As of the 1.3 release, xntpd has been integrated into
NetBSD. For more information on how to use xntpd, please see the
xntpd(8) manual page.
A more permanent solution which doesn't require a network connection doesn't exist at the moment. Basically, a kernel task which reads the PRAM clock every so often and that sets the Real Time Clock with this value would have to be created.
Most people just live with the problem or reboot once in a while.
If you are using Booter 1.8 or later, you must be running System 7 or later system software. System 6.x.x no longer works. The problem appears to be in the booter, but no one really seems to care.
The latest version of the Installer (i.e 1.1d or later) also requires System 7 or later.
In addition, many extensions distributed with later versions of Mac OS may cause problems. It' generally a good idea to boot with extensions off if at all possible.
No. Contrary to popular opinion, all machines on which NetBSD will run on the local console will still boot just fine in color mode. However, you will be restricted to using the console, since dt will not run in color and color X support is available on a limited number of machines. NetBSD might be slower in 4- or 8-bit mode, though (and I doubt anyone ever uses 2-bit mode). So, it is still probably best to boot in 1-bit mode. Just in case you are wondering, this can be achieved by choosing black-and-white in the Monitors control panel before booting into NetBSD.
A simpler solution (and the one I'd recommend) is to select "Options->Monitors" in the Booter (versions 1.10.3 and later) to pull up the Monitors Preferences dialog box. Then check the "Change Monitor Depth" box and select the "B&W" radio button. This will cause the Booter to automatically switch to 1-bit mode prior to boot. When you return to Mac OS, your color settings should be restored. If you have multiple monitors, though, or for some reason need to use an older version of the Booter, you may need an extra program to change the depth(s) for you.
Thanks to Nigel Pearson (nigel@ind.tansu.com.au) for the above information.
Keep in mind that there is currently absolutely no support for 16-bit or 24-bit color. NetBSD may even having trouble booting in 16- or 24-bit mode. Please remember to have your color depth set no higher than 8 bits per pixel.
You can press Command-. (period) if you are fast enough. Once the screen has changed color, there is no going back. After that point, the only way to stop the boot is to hit the Restart button (or Control-Command-Power if your machine supports it). This is also true if the Booter should hang during boot. If you do halt the boot, it is usually a good idea to quit the Booter and restart it. Otherwise it might hang if you try to boot again.
mesg y to turn messages on but I do a finger on myself and it says messages off... am I missing something?The reason for this is that you probably did not enable messages on the
console itself when you first logged in, and now you are using dt or X. If
you put mesg y in your .login file, I think it will fix the
problem (either that or remember to do that command on the console before
you start X or dt).
From Allen Briggs (briggs@puma.macbsd.com):
By person... When you do 'config GENERIC' in a clean source tree, the first kernel you build will be #0. Each time you attempt to link the kernel, that version gets incremented by one.
So, the number itself does not matter that much. In general check any available README's to see what is different about a particular version of a particular kernel.
The black Apple chip in the socket marked 68851 is most likely the AMU (Address Management Unit), which is used to translate 24-bit addresses from the Mac OS into 32-bit addresses used by the memory subsystem. It isn't enough to actually run MacBSD (if MacBSD will boot fine, then you actually have a 68851 MMU or else are running a processor upgrade).
The only source I've seen which sells the 68851 is DMS:
http://www.datamem.com/main.htm
Although there are quite possibly others. Please keep in mind that this is not an endorsement of this company (but I do hear that it does have fairly low prices).
The term GENERIC refers to a kernel that is configured to run on just about any machine supported by the machine architecture; in this case, a GENERIC kernel should boot any machine supported by NetBSD/mac68k. The term originated from a line in the kernel configuration file which specified that the root device was "generic" as well as a configuration option. This option and that format of the configuration line is no longer used, but the name will probably stick for a while.
Since these kernels tend to include support for all the available device drivers and many models of machines that you are not using, you are encouraged to compile your own custom kernel. Check out the Kernel HOWTO for more information on doing this.
ftp://ftp.macbsd.com/pub/NetBSD/utils/dt/dt-1.1.5.tar.gzSince this particular question seems to have come up fairly often recently, I decided to add this answer:
Please do not mail the mailing list itself with this kind of request.
You can either read the instructions which were mailed to you when you joined the list, or you can send mail to "majordomo@NetBSD.org" with the following command in the body of your email message:
unsubscribe port-mac68k userid@hostname.domain
Once again, sending this of request to the mailing list tends to bring ridicule rather than help, so please read the directions.
Table of contents of this chapter, General table of contents