My last pair of columns (Preparing Your Low-End
Mac for Linux and Installing Linux on Your
Low-End Mac) generated a small amount of email, but a typically
convoluted series of events meant that I was, for the most part, unable
to answer any of it. As with most things that go bad around here, it
was almost entirely my own fault.
You see, I've gotten into the habit of downloading my emails from my
ISP's mail server, reading them, and then holding off sending a reply
until a day or two later. The advantage of this is that the extra time
helps ensure that whoever wrote to me will usually get a more
meaningful and coherent reply than if I merely scribbled the first
thing that came to mind. So far so good.
Blame Windows
Another, less helpful habit concerns my PC - a rapidly aging model,
circa 1996, which I've progressively upgraded from a Pentium 120 MHz to
a Pentium Pro 200. For compatibility with the computer systems at work,
I maintain a Windows 95 installation on this machine and, through
laziness more than anything, have taken to using it for reading my
email as well. Anyone familiar with this not-so-latest and certainly
not-so-greatest of Billy G's offerings will probably be unsurprised
that this was to prove disastrous.
This being a column devoted to Unix on the Macintosh, chances are
that none of you are feeling particularly thrilled right now at the
prospect of hearing about my latest misadventures with Microsoft's
former pride and joy. Suffice it to say, therefore, that in between
receiving and replying to some of my email, I had my hard disk rendered
unbootable by (of all things) Microsoft's bundled hard disk repair
tool, ScanDisk. My own attempts to fix the problem, armed solely with a
MS-DOS boot disk, went from bad to worse, and I eventually ended up
having to wipe the whole drive.
Therefore, if you've written to me since last time only to receive
no reply, please don't think I've ignored you (I do make an effort to
reply to all my email), because chances are that your letter was one of
those that ended up disintegrating before my eyes.
Back to Macs & Linux
Continuing the theme of my PC adventures, it should have come as no
surprise when Debian Linux on
Iridium - my trusty 
if sometimes cranky SE/30 - also began acting up. This
problem, however, is more relevant to the stated subject matter of this
column, and you may end up running into something similar yourself, so
it's probably worth recounting here.
As most of you already know, it isn't possible for a 68K Mac to boot
directly into a Unix OS. Rather, the Mac must first be booted up with
it's native Mac operating system, after which you invoke your Unix
through a special loader program which, in the case of Linux, is called
Penguin. The most obvious drawback of this set up is that fact that the
boot up process is significantly lengthened whilst requiring your
manual intervention.
However, there is another, potentially more insidious flaw. This is
that the operation of your Unix session is rendered vulnerable to any
vagaries which may develop in your Mac OS set up. If, like myself, you
continue to use your Mac OS partition for day-to-day tasks rather than
as a dedicated tool for booting Unix, then you're at a greater risk of
this occurring simply because you'll eventually end up tinkering with
various basic settings of your Mac - and there's no guarantee that your
Unix will appreciate your handiwork.
As you've no doubt guessed, the problems I had in getting Iridium to
boot into Linux after several days of successful use proved to be a
salutary lesson on this latter point.
Printing from the Mac OS
Trouble arrived in the unlikely shape of an ImageWriter II. I've had this old
workhorse of a dot-matrix printer for some years now, and I find it
ideal for cheaply and reliably printing out draft-quality documents
such as all those Linux How-tos and even my draft scribblings of this
column.
As I'm usually short of desk space, the ImageWriter spends its
downtime disconnected from the Mac and hidden away in a cupboard. This
was where it was lurking when I once again found myself in need of its
services, and so it found itself being unceremoniously dragged out and
reconnected to its companion.
Because I'm constantly using the thing, I already had the
ImageWriter driver installed on Iridium's Mac OS partition, so getting
things up and running was a simple matter of plugging into the printer
port, opening up the Chooser, and making sure the ImageWriter was
selected as my default printer. There was only one surprise in store
for me, and that was the fact that AppleTalk was still switched on in
the Chooser.
Some months ago I had networked Iridium and one of my other old Macs
through their printer ports using the LocalTalk protocol, which Apple
thoughtfully built into almost every "beige" Mac made. Obviously I had
forgotten to turn it off afterwards, and as AppleTalk continued to hog
the printer port, searching in vain for a Mac on the other end, I had
to turn it off before I could get the ImageWriter working. Once I had
the printer up and running, I got my printouts and turned the Mac off,
thinking no more of it.
Back to Linux
It wasn't till the next time I went to use the Mac, a few days
later, that things became interesting. Having successfully installed
Linux on the old beast, I was naturally anxious to stretch its legs and
see what it could do, and what better way that to take it onto the
Internet? After all, reading email and Usenet postings along with the
occasional bit of simple text-based Web browsing seemed the perfect
non-demanding task for this system.
The broadband revolution, heady stuff though it may be, doesn't
exactly come cheap here in Australia, and so, for the time being, I
still rely on my 56K dialup connection. This isn't all bad, as dialup
connections are typically quite easy to set up under Unix - though it
did mean that I would have to remove Iridium from it's usual home to
one closer to the phone line. In addition to the aforementioned
ImageWriter, the SE/30 also spends its life in the company of a 2x SCSI
CD-ROM drive. However, neither device would be necessary on the
Internet, so I left them behind. I decided to place the SE/30 next to
my Internet-connected PC, as I would have ready access not only to the
phone line but to the PC's modem.
So I had Iridium connected to the modem, which was in turn connected
to the phone line, all my ISP's details (phone number, nameservers,
password, etc.) to hand on a sheet of paper, and an urge to get
connected. After all, how hard could setting up a simple dialup
connection be?
Iridium's boot up into Mac OS gave me premonitions - as the
extensions were loading, I received an error message that stated, "An
AppleShare system error has occurred. (Please run the Chooser to
activate AppleTalk)." Evidently, the AppleShare extension was unhappy
at losing it's AppleTalk driver, but clicking OK on the dialogue box
allowed things to proceed normally.
Lock Up
That being so, I thought little of it except to make a mental note
to disable the AppleShare extension at a later date. All that was left
was to fire up Linux. I opened the Penguin loader, told it to boot into
Linux, and watched the familiar sight of various debugging information
flash through the Penguin's window (called the Penguin Console). It got
to the point just before it shut down the Mac OS to load Linux when the
machine locked solid.
I've suffered my fair share of system crashes, sad Macs, and bombs,
but I've rarely seen a Mac lock up as solidly as Iridium did now.
Nothing - not even the interrupt button on the clip-on programmer's
switch - could provoke a reaction, leaving me with no choice but to hit
reset. When a second and third attempt to boot Linux went the way of
the first, it became pretty obvious that I had a problem on my
hands.
Troubleshooting
As you might expect from a program aimed at a largely technical
audience, the Penguin loader comes with a number of diagnostic and
debugging tools designed to give you some help in just these types of
situations. One of these tools is the log, which, as the name implies,
saves all the information that flashed across the Penguin Console
window to a text file which you can review later in the hopes of
pinpointing the problem.
The Penguin also allows you to choose how detailed a readout you
want to appear in the Penguin Console and therefore in the log file.
Setting the detail to it's maximum level and activating the log, I made
another test boot which resulted, yet again, in a hung machine.
Resetting the SE/30, I looked over the log file, and while I can't
claim to understand all of its contents, nothing seemed to be amiss,
and the log terminated normally in preparation for shutting down the
Mac OS in order to boot Linux, which is when the lockup would
occur.
As the log looked like it wouldn't be any help, it looked like it
would be up to me to find out what was wrong. In these types of
situations - when a previously well-behaved machine suddenly begins to
play up - one of the first things you should do is look at any changes
you might have made to the machine's set up since the last time things
worked as they should. In my case, since the last time I successfully
booted into Linux I had done three things
- added the ImageWriter
- disabled AppleTalk
- removed the Mac's external CD-ROM.
Of the three, the ImageWriter seemed to be the least likely suspect.
Linux, at least in the bootup phase, pays little attention to the
devices you might have hanging off your serial ports, and in any case,
the ImageWriter wasn't in the same room as the Mac at this point, let
alone connected to it. The ImageWriter driver was similarly exonerated,
as it had been installed on Iridium almost since the day I bought it
with no ill-effect.
The idea that removing the external CD-ROM was somehow responsible
for the crashes didn't exactly stretch the imagination. SCSI support
for Unix on 68K Macintoshes isn't all it could be, largely thanks to
Apple's historical unwillingness to release it's hardware
specifications. Therefore, it seemed quite possible that suddenly
removing a device from the Mac's SCSI chain could somehow have upset
the initialisation process. Given that Iridium hung just before Linux
itself was booted, any problems communicating with the SCSI chain would
seem to lie in the Penguin loader.
One of the Penguin's other diagnostic functions is the "Show SCSI
Info" option under the "Hardware" menu. This lists all SCSI devices
attached to the system and whether or not it was able to do so
successfully with Iridium's current set up seemed a good yardstick in
gauging whether or not it could cope with the altered SCSI chain. The
Penguin passed with flying colours, correctly identifying Iridium's
hard disk at SCSI ID 0 and reporting the other six available positions
on the SCSI chain as empty.
The SCSI chain was rapidly taking on the appearance of a dead end,
but I wanted to have one last go at the problem before moving on. It
was time to apply the second thing to do when your machine suddenly
begins acting up - having identified any changes you've made to its
configurations, begin unmaking them to see if that removes the problem.
In this instance, I had to go get the CD-ROM and reattach it to the
machine, but it was to no avail - any attempt I made to boot Linux
continued to lock the SE/30 solid.
Problem Solved
Having eliminated the first two candidates, I could now see that,
barring something I hadn't considered, the problem must have rested
with the fact I had switched off AppleTalk. As before, this was simple
enough to test by reactivating AppleTalk and seeing if that helped.
It did - so long as AppleTalk was switched on, Linux would boot
without complaint. If, on the other hand, AppleTalk was switched off,
any attempt to use Linux was practically guaranteed to freeze the
Macintosh solid.
In actuality, things were slightly more complicated than that. A
more accurate explanation was that if AppleTalk was switched off when I
first booted the Mac and I then went on to boot Linux with it still
off, the machine would crash. I could, however, boot the Mac with
AppleTalk switched off, turn it on in the Mac OS, and boot Linux
successfully. Similarly, I could boot the Mac with AppleTalk switched
on, turn it off, and then boot Linux.
Already I could see things were going to be messy.
Now that I had identified the problem, I could coax Iridium into
booting Linux by the simple expedient of leaving AppleTalk switched on.
On the other hand, I was sure that I had yet to find the root of the
problem. While I was preparing to install Linux in the first place, I
took care to read a good part of the available documentation, and none
of them suggested that AppleTalk must remain active in Mac OS in order
for Linux to boot.
Also, being forced to leave AppleTalk on constantly would, at least
until such time as I get a network card for Iridium, rob me of a serial
port, making it impossible to connect, say, a printer and modem at the
same time.
But What Caused It?
My first thought was that there was an extension conflict. I
particularly suspected the AppleShare extension because, as mentioned,
once I disabled AppleTalk, it would pop up an error message asking that
I turn it on again. However, rebooting the Mac with this extension
disabled solved nothing.
Next I tried more drastic action - rebooting with all extensions
disabled. If this had stopped the lockups, the next step would be to
restore the extensions one-by-one, trying to boot Linux each time one
was added until the culprit was uncovered. As it turned out however,
even with all the extensions disabled the perplexing lockups
continued.
One other thing I tried was disabling Mode32.
As you might have read last time, the SE/30, like the rest of the
initial generation of 68020 and '030 Macs, are considered 32-bit
"dirty." This means that the machine's ROMs, rather than being fully
composed of modern 32-bit coding, actually contains some antiquated
24-bit code which should have gone out with the original SE. Mode32 is
a free add-on designed to address this and make the machine fully
32-bit.
What made Mode32 such a likely suspect is the fact that, in order to
save memory, much of the Macintosh's AppleTalk driver lives in the
machine's ROM. Given that Mode32 works by replacing any 24-bit code in
the ROM with it's own 32-bit equivalent, it seemed plausible enough
that Mode32 was changing the AppleTalk driver in such a way as to
interfere with Linux's ability to boot. I was also mindful of the words
of the
"SE/30 Debian Install. Potato, Kernel 2.2.19, Penguin 17"
installation guide, which stated that you had to use a specific (yet
unnamed) version of the add-on for Linux to work.
Mode32 comes in two versions - 1.2, which comes as a control panel,
and 7.5, which is an extension. I use version 1.2, so even when I
disabled all extensions, Mode32 was still running, which lent weight to
the idea that it was behind all this. However, booting into Linux with
Mode32 disabled produced yet another of the increasingly over-familiar
lockups, exonerating my last suspect and leaving me fresh out of
ideas.
Having gotten nowhere on my own, it was time to read the available
material to see what they could do for me. I searched the documentation
I had to hand, namely that on the Debian CD, an updated version I
received from Debian's website,
and the aforementioned SE/30 installation guide. None held any answers,
and, at any rate, my best bet seemed to be to get a hold of the
documentation for the Penguin loader itself. This is surprisingly
absent from the Debian CD-ROMS, but it can be found at the Linux/m68k for Macintosh website,
which is a great starting place for anyone interested in running Linux
on a 68K Mac. This seemed to be more like what I was looking for, as it
advised to ensure that both Virtual Memory and RAM Disks were disabled
in the Mac OS before trying to boot Linux.
AppleTalk, however, failed to rate a mention, which made it
increasingly obvious that I was dealing with something outside the
normal scope of experience.
Usenet
If you've somehow become completely stuck with a Unix (or any
computer) problem to the point that none of the preexisting
documentation can help you, your best friend is likely to be Usenet.
For those unfamiliar with it, Usenet is a series of discussion boards,
known as newsgroups, accessible over the Internet. Usenet access should
come as part of your normal Internet account and can be used with
dedicated software such as NewsHopper in the Mac OS, or tin in Unix.
Alternatively, you can also access Usenet over the web using a system
reminiscent of web email at Google
Groups, but more on this later.
The point is that a lot of the traffic on Usenet is devoted to
technical discussions, and there's a good chance that someone there has
run into whatever problem you're facing and can offer advice. You'll
find most newsgroups dealing with computer operating systems, including
Unix, live under the comp.os.* heading, with the newsgroup for Linux on
68K computers being comp.os.linux.m68k.
One thing you should watch out for is to make sure you're not asking
a question which has been asked countless times before, as that is the
surest way to annoy others in the newsgroup. Many newsgroups have a
list of frequently asked questions (a FAQ), an archive of which lurks
at FAQs.org.
An even better tool for this kind of research comes courtesy of our
friends at Google. As I mentioned, while better known for it's search
engine, Google also plays host to the Google Groups service, which allows you
to use Usenet over the Web. What's even better about Google Groups is
that it also contains a huge, searchable archive going back 20 years of
pretty much everything ever posted to Usenet.
In my case, I searched through the archive for comp.os.linux.m68k,
using such terms as "AppleTalk +boot" or "AppleTalk +crash." From what
I read in the archive, it was plain to see that most people were using
Linux with AppleTalk switched off with no problems - and indeed doing
so was recommended. The Penguin loader itself even comes with the
option to automatically disable AppleTalk for you. Absolutely no one
complained of the problem I was having.
No one else had posted to Usenet complaining of this, but there's a
first time for everything. So under the title "Debian/AppleTalk
conflict on Mac" I described the problem at some length, asking if
anyone knew of it. It bears mentioning that comp.os.linux.m68k isn't
exclusively a Macintosh group. It covers all computers based on
Motorola's 680x0 processors, which includes such things as Amigas and
Ataris in addition to old Macs, so a lot of people there aren't going
to know what, say, an SE/30 or AppleTalk is. For this reason, it's
always a good idea to mention early on in your post, if not in the
title, that you are using a Macintosh.
The first thing I learned from the replies I received was that this
is a known issue, but no one as yet had anything approaching a reason
or solution for it. Given that this was so, it's quite possible that
there may be a number of causes, each of which just happens to produce
the same symptom of the machine crashing under a certain set of
conditions.
The advice I did receive suggested that I might be suffering some
problem with my network hardware. However, I don't yet have such a
thing installed in Iridium, so I was left back at square one as
clueless as ever.
Conflict Testing
It was time for some do-it-yourself experimentation.
By now, I was convinced that I was suffering some sort of conflict
in the bowels of either the system software (Mac OS), possibly still
connected with Mode32. I decided that my best bet was to try out
various combinations of Mac OS and Mode32 versions until I hit upon
something that worked. Currently I run System 7.1 Update 3 with Mode32
1.2. I also have the disks for plain System 7.1, System 7.0.1, and
System 7.5, as well as a copy of Mode32 7.5.
My plan was to sequentially install each of these versions of the
Mac OS system onto my machine and then try booting Linux - first
without Mode32, then with version 1.2, and finally 7.5. I should point
out that I would be skipping one particular combination, that being
System 7.5 and Mode32 1.2. This is because the two should never be
mixed, as doing so can result in file corruption in your Mac OS
partition.
Having done that, in order to see what effect using a 32-bit clean
machine would have, I would then try all the steps 
again (without the use of Mode32 of course) on one of my
Colour Classics.
Finally, I would download the current version of the Penguin (version
19; I use version 18) and do it all again.
First up to bat was System 7.1 Update 3, by simple virtue of the
fact that it was already parked there on Iridium's hard drive. For any
kind of experiment to mean anything, all outside influences must be
removed, and in this case, it meant stripping the System 7.1 Update 3
installation of all third party add-ons. First to go were all
extensions, save for the Update 3 component, followed by the third
party Control Panels - After Dark 2.0x, MountCache, and Mode32 1.2, the
latter of which would be reintroduced later as part this
experiment.
I had already tried booting Linux in similar circumstances before
with all extensions and Mode32 disabled, only to have it fail, so I was
really only doing it again to make up the numbers. Imagine my
surprise when Linux booted flawlessly.
Thinking the matter over, the only difference between my last
unsuccessful attempt to boot Linux from a clean installation of the Mac
OS and this later, successful, one was the fact that I had disabled
both After Dark and MountCache. At this point I could have saved myself
a lot of time and bother by scrapping the my planned experiment in
favour of discovering which of the two was causing the problem and
removing it.
However, I recalled the words of the Usenet posts I received in
reply to my initial plea for help saying that other people had had this
problem. Now, I use my Mac OS partition for many day to day things, but
I think it's fair to say that for most users of Linux on Macs, the Mac
OS partition merely serves as a means to an end - the bare minimum
necessary to boot Linux. This being so, it seemed pretty unlikely that
all those people were running into a conflict with either
After Dark or the somewhat obscure MountCache, given that their
slimmed down installations were unlikely to contain either item.
For this reason, I decided to go ahead with testing out the various
combinations of Mac OS and Mode32 versions, hoping to see if a similar
crash could be induced by a more fundamental problem. However, in the
interests of getting it done sometime this month, I did cut it back
somewhat, leaving out the tests on a 32-bit clean machine and with
Penguin 19.
I won't go into how much time all that testing took, but the result
was that every combination I tried successfully booted Linux -
clearly pointing the finger of blame at one of those two Control
Panels. But which one, and why?
The Culprit
The first question proved considerably easier to answer than the
second. A simple process of elimination - trying to boot Linux with
each enabled in turn - quickly pinpointed After Dark as the cause.
But why? The closest thing I got to an answer was from the
comp.os.linux.m68k group, a member of which suggested that After Dark
could be affecting one of the machine's video interrupts in such a way
as to prevent Linux taking over - crashing the machine.
This could well be the case; I certainly don't know enough about the
fundamentals of the Linux boot process to say otherwise. What I don't
understand is the AppleTalk connection - why the machine would boot
fine so long as AppleTalk was switched on, which should be completely
unrelated to the video hardware.
It could be that After Dark does interact with AppleTalk in someway
which is unknown to the user (or unknown to me at least).
The best example of such a program I can think of would be
Spectre Challenger. For those who haven't encountered it, Spectre
Challenger is a Mac OS game in which you steer a tank around a
wireframe 3D battlefield, shooting enemies and collecting flags to
advance to the next level. This game had an anti-piracy feature in
which it would silently scan any network your machine was on to ensure
no other machine was running the same copy of the program.
Now, I wouldn't expect After Dark to be doing something like this,
but it does provide a useful example of software interacting with
unexpected parts of your machine.
In the end, though, I don't know why this is happening, but the
solution to stopping it is simple: lose After Dark. At least it is for
me. It's quite possible that different versions of this popular screen
saver running under different versions of Mac OS on different machines
cause no problems; I can only speak from my own experience.
Also, while others had run into a similar problem, whether or not
the cause was the same remains unknown. I personally think it unlikely,
remembering that installing a somewhat arcane, noncommercial operating
system on poorly documented hardware gives plenty of chances for
something mysterious to go wrong.
What Next?
So what next? During this little adventure, I found that Iridium is
currently too slow for use as anything but a curiosity. Boot ups and
shutdowns - and I had to sit though a lot of them - are quite lengthy.
The login program, which provides the username and password prompt each
time you start Linux, also ran quite slowly, with a pause of some
seconds between the prompts. I often found myself typing the password
before the prompt appeared. This is not only annoying, as your login
attempt can fail for this reason, but also poses a security risk, as
this causes the password to be displayed on screen instead of being
hidden.
Most of this, I'm sure, lays at the feet of Iridium's RAM, or lack
of it, a notion verified by looking at the machine's RAM usage using
the free command. While 8 MB isn't exactly a paltry
figure by 68K Mac standards, I didn't help matters by loading the SE/30
down with all kinds of extras, most of which consume RAM by running
daemons (a sort of Unix equivalent to the Mac OS' extensions).
The answer here is simple - either trim things down or add more RAM.
I still want to test out all the extras I added to my Linux
installation as a way of gauging the machine's performance as a
general-purpose Unix workstation, so I'm going to go for the latter. To
that end, I now have 32 MB of 30-pin RAM just waiting to be
installed.
Once that's done, I'll try stretching the old workhorse's legs,
maybe getting an X-Windows session up and running. Once I do get
Iridium running in graphical mode, I'll look into putting a screen shot
here - something which someone wrote to me about in one of those emails
my PC ate for breakfast.
Soon I'll also set up faster companion machines for Iridium, one
will be a 33 MHz 68040 class machine, and the other will be a pre-G3
Power Mac. Also, I'll start trying my hand at the BSDs and various
other weird and wonderful Unix implementations you can find for the
Mac. 
