Unix and the Mac

The Penguin Lockup Mystery

- 2002.05.13

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 SE/30if 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.


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

  1. added the ImageWriter
  2. disabled AppleTalk
  3. 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.


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 Color Classicagain (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. LEM

Go to the Unix & the Mac index.

About LEM Support Usage Privacy Contact

Custom Search

Follow Low End Mac on Twitter
Join Low End Mac on Facebook

Favorite Sites

Cult of Mac
Shrine of Apple
The Mac Observer
Accelerate Your Mac
The Vintage Mac Museum
Deal Brothers
Mac Driver Museum
JAG's House
System 6 Heaven
System 7 Today
the pickle's Low-End Mac FAQ


The iTunes Store
PC Connection Express
Macgo Blu-ray Player
Parallels Desktop for Mac

Low End Mac's Amazon.com store


Open Link