This is not a fun process, and it provides very little in the way of reward. I've been using Linux since 1994, and I've used it on a number of different architectures, not just Intel and ARM. I've worked with 'big iron' and a variety of UNIX workstations. I knew that trying to resurrect turn-of-the-millenium hardware was going to be a challenge, but I thought I was experienced enough to make it work, and work reasonably well. I knew that there would be but I thought it was going to be a fun exercise with a sense of accomplishment at the end.
That is not what I experienced. At all.
I started with what NetBSD describes as the “notoriously difficult” Power Macintosh G3 (Beige). After spending dozens of hours over weeks of time (with no real success), I ended up putting that aside and switching to a Power Macintosh G4 (Digital Audio). I still experienced plenty frustration, but on that one I eventually was able to figure out how to actually accomplish my goal of booting an actual Linux install – at least kind of, anyway.
Here's the thing: even then, what was I left with? A 32-bit-only big-endian-only machine based on an orphaned CPU family, with a single core running at less than 1GHz, with less than 1GB of RAM, that consumes north of 100 watts at idle… It's big, it's noisy, it's power-hungry and it can't run modern software. Yes, even that latest-and-greatest G5 you might have – in fact, especially that G5 you might have.
In short, a decade-old $35 Raspberry Pi 3B+ out-performs this thing, has much better software support, and consumes 1/10 of the power. Linux on a Power Mac just does not make any sense whatsoever.
These machines were designed to run Mac OS 9 or OS X. They are adequate at running those operating systems. Stick with that: you'll be much happier and the machine might actually be able to do something… mildly productive.
I can hear you now: “But OS X 10.5 and older won't run any modern software!” Well, no 32-bit PowerPC system will run modern software, no matter what up-to-date version number might be attached to the Linux distro you install. When even the tiniest systems today are all 64-bit, more and more software is simply not supporting 32-bit. You're going to be stuck with old, obsolete versions – just like if you stuck with OS X…
I mean it: you will not be able to run modern software. What's the most important program you can run on a computer today? Well, how are you reading this right now? That's right: with a web browser. But you won't have one on a PowerPC system… That's right: even if you're running Debian 12, you can't install Chromium or Firefox. The closest I could find to a modern browser is Evolution – and that's assuming you can get a graphical environment in the first place.
My guess is that this is not the first time you've heard this reasoning. You've probably already found a bunch of other posts of varying age echoing these same thoughts, yet still offering instructions on how you, too, can fall into the same tarpit that they did. But you're thinking something like, “It can't be that bad… They're just young Gen Alphas that have never had to struggle… I'm sure I can do better…” Which is why I gave you my credentials in the beginning. I've been facing these struggles for far longer than I'd care to admit. I remember the agony of trying to hit exactly the right X config to work with my video card and still sync with my monitor, the frustration of dealing with IRQ and DMA conflicts, IP networking where even having a link light and an 'up' interface didn't actually mean anything was working right, and all of that stupid nonsense we've left long behind…
Well, I'm here to tell you. This is going to throw an entirely new set of frustrations at you, where your old skills won't really help you – but it will give you the flashbacks of that terrible past.
Do yourself a favor: if you're looking for a challenge, go grab a RISC-V board and play with that. Fedora just added RISC-V for Fedora 42. It's new enough that it's still a bit of a struggle to make it work. You get to be forced to use a serial console and everything! But when you're done, you'll have a modern CPU with plenty of power and RAM that costs about a dime a day to operate. Seriously. I wish I had…
What? You're still here? OK, then. Let's keep going. But don't say I didn't warn you.
What makes this process so difficult? A lot of it comes down to the conflicting and cobbled-together nature of the entire PowerPC environment. And nothing illustrates this more than the history of the Macintosh system firmware.
For those who might already know much of the history or simply want a brief tl;dr: if you want anything approaching a smooth process, make sure you are working with a NewWorldROM-based Macintosh. That would be any machine starting with the Blue-and-White Power Macintosh G3 or newer. Any of the 'beige' machines are going to make your life miserable, up to and including the last beige G3's. That includes machines that have CPU upgrades: the problem is not the CPU, it's the motherboard and its firmware.
Now, for the history lesson: in the early Macintosh computers (the ones based on Motorola 68k processors), a great deal of the operating system is built into the system's ROM, what PC people would call the BIOS (or UEFI today). That's how they could cram an entire GUI operating system onto a 400k floppy and still have space left over: there's a fair bit of that capability built into the hardware itself!
During the time Apple continued to develop new designs based on that basic original 68k architecture, the original firmware (called the Macintosh Toolbox) largely came along as well. However, when Apple moved to PowerPC processors, they couldn't just stick with the same firmware as before: literally everything was different. To address this, Apple chose to adopt an existing firmware (now) called Open Firmware. However, the Mac OS operating system still fully expected to be able to use the Macintosh Toolbox, and that meant that nearly all functionality was still going to come from it. On those early machines, Open Firmware really only had one job to do: perform the absolute minimum amount of hardware initialization and then turn control over to the Macintosh Toolbox, which would then give the classic Mac OS the environment it expected.
This environment is what we now call the OldWorldROM environment. Open Firmware is there, but if you were a classic Mac OS user, you would literally never know it. In fact, on the earliest Power Mac systems you can literally only interact with Open Firmware via an exernal serial console! That's how little Open Firmware was expected to do: you literally couldn't get to it… By the time you get to the last of the OldWorldROM machines (the beige G3's), Open Firmware was slightly (and I do mean slightly) more capable, but practically it still had only one job: get the system into the PowerPC-adapted Macintosh Toolbox, and then use that to handle booting into classic Mac OS.
Of course, we don't want to run Mac OS. We want to run Linux. Well, that's a problem: these computers simply were not designed to run anything else. “But they can run Mac OS X, and that's not classic Mac OS!” And you're right. And in order to do that, Apple had to do two things: one, dynamically patch a bunch of bugs and limitations in the Open Firmware on OldWorldROM systems – but only just the absolute bare minimum needed for OS X; and two, carefully design OS X to fit within the limitations of systems designed to boot classic Mac OS. That meant using a partition table and filesystem that was compatibile with classic Mac OS. By working both sides of the problem, Apple was able to bring OS X to these machines. But even then, it's a fragile and noticably-limited process – and they controlled all of the pieces!
With Linux, we get none of those advantages. We are still severely limited by the incredibly basic Open Firmware capabilities on the OldWorldROM machines. And, we don't get the luxury of using an operating system designed around the Macintosh Toolbox expectations. So it ends up being an epic struggle.
If you want to avoid that, you need to start with a machine with a NewWorldROM. After running into their own difficulties supporting their new operating system with their old ROM, Apple, finally improved this (somewhat) with the Blue-and-White Power Macintosh G3. The Open Firmware system was updated to 3.0, which expanded it enough to allow it to manage the boot process instead of the Toolbox. That means that it finally had enough capabilities to actually be able to boot from things like CD's and USB sticks. (Theoretically, the earlier ones should, too; but practically they don't: there just isn't enough capability to make it work.)
And for trying to boot Linux on these machines, it's absolutely night and day: NewWorldROM-based machines can actually boot from the install CD like you would expect. That's only one hurdle out of the way, but it's a big one. So unless you really like the concept of building out a huge framework of extra hardware and network systems just to boot your Linux install… stick with a NewWorldROM system.
In the (distant) past, that might actually be an interesting question with multiple useful answers. Today… not so much. Here are the only distros I can find that have images that have been updated in the past, say, five years:
Link: https://www.adelielinux.org/
There's two options to work with: a Live CD and and Install CD. If you navigate to the download page, you'll be able to choose what type of image you want. I ended up with 1.0 Beta 6 for PPC / Desktop / XFCE. I was under the impression that you could also install from that image, but I couldn't find a way to do it, in text or graphics mode, logged in as root or live. But it's a great way to quickly get a feel for what Linux on a PowerPC system is like.
Here's what I did for the Live CD:
I know I've said this a LOT, but I really, really mean it: BE PATIENT!. I tried booting the CD multiple times, each times freezing in the kernel in less than a second. I waited for a fair bit: 30-60 seconds? I had zero evidence of anything happening. One time I left it that way while I wrote down some notes. I looked back after about two minutes: it was actually loading! You just need to be patient… (And no: the CD activity light was not lit at all…) Even after the text console starts up (and implies you need to log in), keep waiting. It will eventually load a graphical environment. Again, when you think you haven't waited long enough, keep waiting even longer. Like literally 5-7 minutes to get to a desktop. (And yes, the CD light does eventually blink, so you can use that to have an idea that things are still percolating.)
Short answer: there's not much you can do. For one thing, there's still no Web browser… (Maybe just sticking with the Live CD to see there's not much there might just save yourself a lot of grief?)
But I also wanted to try an actual install. More digging and stumbling around eventually led me to the Full Directory Listing: https://distfiles.adelielinux.org/adelie/current/iso/. There's an “inst” image instead of “live”, so I tried that. (Here's a link to the exact image I used, using a non-current path that might actually stick around: https://distfiles.adelielinux.org/adelie/1.0-beta6/iso/adelie-inst-ppc-1.0-beta6-20241223.iso)
I followed the exact same burn and boot process as the Live CD.
As part of my digging, I found a number of pages that stated that the text-based installer was harder to use but more reliable, so I tried to figure out how to use that one. But I could find no way to start the installer: all I got was a shell, and I couldn't find any kind of install command. I then tried the normal graphical boot, and this time I got an installer!
This will take a long time and the installer gives zero feedback. You can check the link light and see that the Ethernet is busy, but that's about it. I moved to a different text console and set up some items so I could see what was going on. The nice thing about a live CD is there are some decent tools here! I could use tmux to create panes for “top”, “vmstat 1” and “tail -f /var/log/horizon/executor.log”. Unfortunately, the log is buffered, so you won't be able to use it to keep an eye on what's going on line-by-line, but it does give you periodic updates to let you know where you might be in the process…
In the end, it took about 20 minutes to complete. Click Finish to reboot.
Sigh. I get the question-mark-floppy on reboot… Open Firmware doesn't like the disk configuration… Seems this is a previously-reported problem, with no solution (yet): https://git.adelielinux.org/adelie/horizon/-/issues/403 If it changes, I'll continue to try.
An honorable mention to NetBSD: MacPPC is still a well-supported architecture. If you want UNIX but it doesn't have to be Linux, you might want to check it out…
“But wait!” you might say. “I see PowerPC distros! RHEL, Fedora, Ubuntu, all kinds of distros have PowerPC versions!” And you would not be wrong. But they don't have versions that will work on an Apple Power Mac.
Why not? Because all modern PowerPC distributions aren't really PowerPC distributions at all. They might have “PPC” in the name, but that's really in name-only. Back in the day, when idea of the PowerPC processor was being formulated, there were three companies involved: Apple, IBM and Motorola (the “AIM Alliance”). Each brought something to the table, but the company that brought the biggest chunk of the design was IBM. They had a processor they used in their relatively new RS/6000 line called POWER. It was a behemoth of a processor designed for high-end appliations that would never be practical for computers designed for normal people. But the three companies took the logical design of that processor and made relatively small changes to create the PowerPC processor.
(Side note: That is also a big reason why the PowerPC design never really worked well for Apple: it was originally designed for very high-end systems from the beginning, and IBM never really stopped focusing on that. Motorola tried to keep adapting the chip for more pedestrian applications, but their capabilities were falling further and further behind, so they wanted to focus on even smaller chips useful in embedded applications like cars and electronics. Apple was stuck in the middle: they wanted powerful chips to compete with Intel but ones that could still be used in things like laptops and all-in-one designs. But neither of the companies responsible for the CPU design would (or could) deliver that. In the end, Apple chose performance, and that's how you end up with the G5: a monstrous power-hungry processor with really good performance, but just isn't practical under a desk – let alone on your lap… Hence the switch to Intel chips. (And ironically, also the reason for the switch to their own chips when Intel couldn't deliver the performance/power balance they needed a decade or so later…))
After Apple abandoned the PowerPC, there really wasn't anyone using the PowerPC processor. During this time, IBM had continued to develop their POWER architecture and used it in their RS/6000 computers and had even migrated their AS/400 systems to POWER from its original custom CISC processor. New PowerPC designs simply continued to be simplified versions of POWER designs, possibly with certain other elements added to it: AltiVec was a Motorola addtion, for example. However, by the mid-2000's Motorola had already divested their semiconductor division, and the new organization (Freescale) was actually having more success with re-pacakged 68k-based processors than they were with PowerPC! With Apple gone, IBM basically just stuck with POWER, and by 2006 the PowerPC architecture was completly replaced by the POWER architecture from which it had been derived.
However, while the PowerPC chip and design is dead, the name sticks around. IBM would probably prefer that everyone simply call anything related to this design POWER, but that isn't what has happened. For the Linux world, their interest in these chips started wwith the appearance of commodity systems based on the PowerPC processor. And when people ported Linux to them, they called it the “PowerPC port”. Over time, as the PowerPC architecture evolved, the Linux port evolved with it, keeping the PowerPC name.
There have been two major shifts in the PowerPC architecture – including its transition back to POWER – over its history. The first was adding 64-bit capabilities. Just like in the Intel/PC world, the shift to 64-bit was somewhat slow. In the case of PowerPC, the first – and only – 64-bit capable processor was the G5 (techncally the IBM PowerPC 970). (OK, technically the PowerPC 620 was also 64-bit, but it was expensive, buggy and slow, and for all intents and purposes, never really existed.) But even after the CPU's were theoretically capable of 64-bit, it took even longer for operating systems to support it, let alone application software. Even into the 2010's most computers were running 32-bit operating systems with 32-bit programs: there just wasn't a compelling reason to upgrade at that time. And seeing as in the PowerPC space there was exactly one processor that could even run 64-bit code (the G5), 64-bit PowerPC code just never really took off: it just isn't practical for those few machines.
The other major shift has to do with what is called “endianness”. When processors combine multiple 8-bit bytes to create larger multi-byte values (such as 32- or 64-bit values), what order do they put those bytes? Does each sucessive memory location store the more significant bits or the less significant ones? There are two choices: big-endian and little-endian. For most of computer history, most CPU's used “big-endian” until a little chipmaker called Intel designed an electronic calculator back in the early 1970's, where they chose to use little-endian because it made the design a little simpler – and cheaper. That design concept was reused and expanded, until it became the dominant computer architecture we know today: the x86 architecture.
Why is this important? Normally, it doesn't matter how the CPU stores its data, big or little. You ask the CPU for a number, it goes and gets you a number. No problem. But sometimes programmers like to play tricks: they like to use a single number for multiple purposes and go behind the CPU's back. That works fine, as long as the prorammer knows how the number is stored in memory. And he probably does – for his own machine, anyway. But what happens when someone moves his program to a different CPU with a different endianness? Bugs happen. But subtle bugs that aren't at all clear what's going on – and what's worse, bugs that don't exist on the programmer's computer!
Back in the day, this wasn't that much of a problem. Practically, the only oddball computers were the PC's: they used little-endian, and everyone else used big-endian. And there wasn't much moving of software from PC's to larger computers. But as the Internet appeared and PC's evolved to be both incredibly powerful and nearly ubiquitoius, the separation betwen PC's and everyone else disappeared. And the bugs became more of a problem.
It would be nice if we could have simply told programmers to pay better attention to their coding. But that wasn't likely to happen. And seeing as most software is developed for PC's first, it became harder and harder for all the other systems to keep up. By the early 2000's, IBM had been experiencing this first-hand for a couple of decades. So they modified the POWER architecture to be bi-endian: it's actually capable of letting the programmer tell it how they want their memory to be organized. Of course, up to that point, all the POWER (and PowerPC) code was big-endian, because that's what the POWER (and PowerPC) processors had always used – as had the Mortorola 68k processors. So just like with 64-bit support, it took time for that capability to be used. And by that time, PowerPC was already obsolete. So all Apple PowerPC devices are strictly big-endian.
(Technically, many of the PowerPC processors in Apple Macintosh systems are capable of bi-endian operation. However, none of the other hardware or software within the computer (includig things like Open Firmware!) will work in anything but big-endian. If you try to switch to little-endian, there is a very high degree of likelihood you will completely disable your computer – possibly to the point of requiring physical changes to the motherboard/firmware before the comoputer will be able to operate.)
However, by the end of the 2010's, IBM (and everyone else!) waved the white flag: all systems switched over to little-endian. The CPU's, firmware, operating system and application code now all run in little-endian. That allows code that was originally developed on PC's to be ported to any other system and avoid the subtle and practically-impossible-to-reprouce bugs that switching endianness creates.
(By the way, ARM processors faced exactly the same difficulties, and came to exactly the same conclusion: they too switched from big-endian to little-endian (technically bi-endian, but with little-endian as the default).)
And that's exactly what curent “PowerPC” distributions target: 64-bit little-endian machines, or “PPC64le”. While 'PowerPC' might be in the name, practically they have zero to do with PowerPC: they won't run on 32-bit processors (which is what all PowerPC processors besides the G5 are), and they require top-to-bottom suport for little-endianness, which even POWER systems did not fully and completely support until POWER8, so about 2014 or so.
Long, long, long after Apple (and the rest of the world) had moved beyond PowerPC…
So, we come full circle to the frustration that is modern code on vintage PowerPC systems. PowerPC is a 32-bit architecture in a world of 64-bit, and requires big-endian in a world fully converted to little.
It's not an attractive position to be – and yet you still want to try? OK, it's your funeral. Let's go.
So, after all of that whinging about how horrible the support is and how terrible the process is, I'm now going to give you a process that actually makes this easy. Here is the process to install Debian 12 on a Power Mac G4 (Digital Audio/Quicksilver). In fact, at this moment, if you have the right system and the right CD image, it's not much harder than installing Linux on a PC. Not too much, anyway.
Of course, you get the benefit of skipping all the false-starts I made… (Plus I started with an OldWorldROM beige G3 and you're not – by the time I gave up and moved to this machine I was literally weeks in…)
https://tenor.com/view/congrats-happy-for-you-cool-gif-12931500636737268570
But you're going to have to make some sacrifices, too. For one thing, this procedure is only simple because it sticks mainly to the defaults. You can't get fancy with anything if you want it to actually work. And that includes things like partitioning: this process is going to use the entire disk. “But I want to dual-boot into OS X and Linux! I want to triple-boot into Mac OS 9 too! I want! I want!”
Not if you want it to be simple. One of the many, many web pages I read for this gave some sage advice: when you do this the first time, you need to use the entire disk. Only once you figure everything else out can you then go back and try to make it work with other partitions. I wish I had listened to that wise advice when I first started: it might not have cost me a day and a half or so… Learn from my huberis. Start simple.
What if you don't have a spare disk lying around? Get one. PATA drives aren't that hard to come by… And if you don't have one, let me suggest an inexpensive alternative: a PATA-to-CompactFlash adapter and a high-speed CF card. You can get both on Amazon for less than $30, depending on how large a CF card you want. Heck: Graphite G4's came standard with 10GB hard drives – 16GB CF cards are like $20… But do yourself a favor: be ready to blow away the entire hard drive.
Also, what video card you use will make a difference. I have been able to make an ATI RADEON 7000 PCI card work for video (with acceleration disabled…), but not an Nvidia GeForce2 MX with Nuveau drivers. If you only want a text console either is fine, but if you want a graphical desktop, you're going to need the ATI card – or leave the path of enlightenment and figure it out for yourself the hard way. The problem is: you can't just chuck any old PCI (or AGP) card into these systems. Because of the wonder of Open Firmware, you need to have Open Firmware-specific firmware on the card. If you don't, Open Firmware won't see it – and you won't be able to use it. (Theoretically, once Linux boots it will be able to use it, but getting Linux onto that machine in the first place without a monitor is an exercise left to the reader.) If all of my threatening warnings and the fact you only have an Nvidia adapter isn't enough to stop you, you will likely want to acquire a Mac-compatible ATI card. Such items were actually sold at retail and if you hunt long enough (and spend enough money) you can occasionally find them on eBay. See far below for some details on what makes them different and how you might be able to turn a card with PC firmware into one with Mac firmware. (A warning: it likely involves desoldering a chip and soldering a replacement in its place… Seriously. Really, you just just stop now…)
OK, if you just so happen to have all of the right hardware, it's now time to select the right image. Your initial thought might be to just get the latest Debian netinst image and go. Of course, you don't actually expect it to be on the normal Debian download page (and it's not), but you can just get it from the debian cdimage site (https://cdimage.debian.org/debian-cd/current/), right? Nope. It's not there – just that PowerPC-interloper called PPC64le…
So, you might start working your way backward in time to see where you might be able to get an installer. 11? Nope. 10? Not even close. 9? Not quite. That's right: all the way back to Debian 8 (Jesse), released in 2018. (Hey, it could be worse, right? SPARC and Itanium got dropped after Debian 7…)
OK, so those are official releases. Aren't there unofficial releases (called “ports” in Debian)? Yes there are. So you might be tempted to go check them out next (https://www.debian.org/ports/). Unfortunately, it says the same thing: dropped after Debian 8. Bummer.
But if you keep digging and keep searching and keep hoping… You might eventually manually dig down and find, miracle of miracles, the super-secret unofficial Debian 12 netinst ISO! (https://cdimage.debian.org/cdimage/ports/12.0/powerpc/) And as of early-2025, Debian 12 is the current version! Wow! Ready to go!
Yeah, that's what they want you to think… So, with they joy of a child in your heart you download the image and burn it to a CD and chuck it into your what-passes-for-modern Power Mac… Fast forward most of an hour later and the install fails. There's a mirror problem. There's a package problem. There's a GRUB problem. There's an HFS problem. Problem, problem, problem… After beating on those those for a few hours I made some progress, but you never end up with a finished install. (Turns out that the package-signing key for ports expired in early-2025, so all ISO images before that date can't download packages! That's a bit of a problem for a network-based installer… There's an annoying workaround I figured out – you guessed it – after a few hours of effort. And the GRUB install won't properly handle existing HFS partitions – which is exactly why I and everyone else told you to erase the entire disk!)
Where's that smooth process I promised? It's coming: I'm just giving you a tiny taste of the pain you're still in for – even with a tried and tested process…
So after even more searching and digging, you find the snapshots. (https://cdimage.debian.org/cdimage/ports/snapshots/) I'm not really sure exactly what these are. Given that there are a bunch of architectures in each folder I'm assuming it's not something driven by any given architecture. I'm guessing it's a periodic respin of the netinst images in general, and in true Debian fashion these refreshes are dutifully archived for posterity. (Which is truly one of my favorite features of Debian – without that it would not be posssible to frustrate yourself to no end trying to resurrect a long-obsolete computer…)
And finally we are nearing the station. At the moment, the latest snapshot is 2025-04-01, and sure enough there's a powerpc ISO! Finally, that was the image that got the job done! Here's the link for future reference: https://cdimage.debian.org/cdimage/ports/snapshots/2025-04-01/debian-12.0.0-powerpc-NETINST-1.iso That link should stay stable over time. Only after I found that link and got the image to work did I later find a more encouraging link for the future: https://cdimage.debian.org/cdimage/ports/current/ I suspect that this link will have the latest snapshot ISO in one consistent location. Yup, another one of those things I spent hours (and a good half-dozen discs) to sort out – so you don't have to.
OK, now that we have an image, we need to burn it. For reference, I'm using CDBurnerXP version 4.5.8.7128 on a Windows PC with an Asus USB CD/DVD Burner. I'm using actual CD-R discs, and I'm burning them at Maximum, using method Disk-at-once PQ. I don't think that really matters for a NewWorldROM with reasonably capable CD/DVD drives, but it can very much matter for machines with old drives – especially SCSI drives. In fact, some users report having to burn at 4x speed to get certain drives to read the discs properly. Also, on a related subject: I suggest that you verify the disc as part of the burn: those optical discs are getting old, and there's a very real chance that there's a problem with the disc itself… (Ask me how I know… Add on another couple of hours for that one…)
You will be presented with the (text-based) Debian Installer. If you're capable of doing this task at all then you should be able to work your way through the installer without step-by-step instructions. But here's a few notes to keep in mind:
Hopefully, when it's done, it'll ask you to reboot and you'll see a beautiful GRUB menu appear! (Well, you'd think it was beautiful too if you struggled as hard as I did to get that far!) Let it run and you should get a login prompt – likely a text-mode console if you took my suggestions. I really hope you took my suggestions.
Here's a few notes on various failures I had during my numerous attempts that might help you if you run into similar problems:
If you select the LXQt desktop enviornment, the computer will boot into Linux, but the boot will either freeze during systemd service startup or you will get a black screen with a mouse pointer. In either case, there won't be any tty consoles to use, either. In short, the computer is completely stuck. You can still <CTRL><ALT><DEL> to reboot but that's it. A quick analysis showed that the sddm service is failing to run correctly. I didn't dig that far into it: I found that I could modify the GRUB menu boot entry to boot into text mode (append a “3” to the linux line), and then from there use “startx” to start the desktop GUI. (“startlxqt” did not work because of missing libraries.) Like I said, not recommended for the “easy” process, but if you're dead-set on using LXQt know that it's possible to run it so maybe worth additional effort if you want.
On one of my installs (Before I fixed the mirror problem), I completed the install using only the files on the netinst CD. That worked to get me into a working Linux environment, but it's pretty minimal. From there, I tried to install a few things via “apt install”, which worked. I also did an “apt upgrade”. However, when I rebooted, I had no network. “ip link” showed the link being DOWN. Logs showed that the DHCP client did not work with the specified interface, and it seems systemd was using the correct interface name. I did not easily find out why that was the case – I ended up finding a workaround that was good enough first. Running “dhclient” from the command line successfully brought the interface up, and adding “auto <ifname>” to /etc/networking/interfaces (above the hotplug line) for that interface brought up the interface properly on a reboot. On future installs (with the latest snapshot and proper mirrors) this was never a problem, so hopefully you won't have it at all.
With netboot ISO images before January, 2025, when you select a mirror it will tell you that it's invalid. Looking at the log you see something about NO_PUBKEY: 3AF65F93D6FBC5B9. That wasted a number of hours of my life… Turns out that the key used to sign ports packages expired in January, 2025 https://lists.debian.org/debian-release/2024/01/msg00397.html and a new key pair was needed. A new key package was created and ISO images were updated. Of course, if your image predates that… the mirrors won't work. But you can get around it by manually installing the updated package. When you get to the mirror question:
That will update the keys and the mirrors will once again work.
There's another way to do this: continue without a mirror. In that case, the installer will use only the few packages on the CD, but it should complete. Once you're into the completed install, you can add the following to /etc/apt/sources.list :
Another solution: install without mirrors, edit sources.list to add lines manually and add [trusted=YES] or whatever.
Now that you've got a Linux console, things are going to work pretty much like any other Linux system – just with an awful lot more rough edges and missing features. You likely already have your own basic setup tasks that you perform: go ahead and try them here. Here's a rough outline of the things I've done:
Here's my personal documentation for the D-I install portion:
Command to get preseed config from initial install:
debconf-get-selections --installer > debian12.custompart.preseed.cfg
Command to get preseed config from current state:
debconf-get-selections > debian12.custompart-aptinstall.preseed.cfg
Check syntax of preseed file:
debconf-set-selections -c preseed.cfg
# NOTE: mac-fdisk isn't installed on Debian 12 by default:
# Check out partman or apt install mac-fdisk
mac-fdisk -l /dev/sda > os-fdisk.txt
dd if=/dev/sda1 of=os-sda1.img
dd if=/dev/sda2 of=os-sda2.img
dd if=/dev/sda of=os-sda-35000blocks.img count=35000
cd /mnt/boot/grub ; tar czvf /mnt/root/root/os-boot-grub.tgz *
cd /mnt/root/etc/grub.d ; tar czvf /mnt/root/root/os-etc-grubd.tgz *
# Make sure you grab any install log files
===== Power Macintosh G3 (Beige): Good luck... =====
This is an overview and walkthrough based on my extensive frustration with trying to boot NetBSD on a first-model Power Macintosh G3 233MHz: the beige desktop one, not the blue-and-white tower. However, everything you need to know is probably not in this document, especially if you're trying to work with a different machine or model. Here are the resources I found most valuable. They are long, they are detailed, they are confusing, and it is absolutely essential that you read each and every one of them to actually understand what is happening. This walkthrough will hopefully help you to avoid a number of pitfalls, but nothing will replace understanding these documents.
* NetBSD/macppc homepage: [[https://wiki.netbsd.org/ports/macppc/]]
* This is the parent of most of the Macintosh PPC-specific NetBSD information. Most of it is focused on dealing with Open Firmware, because that is by far the most difficult part of this already-difficult process.
* NetBSD/macppc Model Support: [[https://www.netbsd.org/ports/macppc/models.html]]
* This lists supported models and tells you specific details about that support. The big things to focus on here are the particular version of Open Firmware your machine might have, and any particular issues unique to that model. Fun fact: the Beige G3 is described as "notoriously difficult to boot." Yay me!
* NetBSD/macppc FAQ: [[https://www.netbsd.org/ports/macppc/faq.html]]
* Once again, this is mostly focused on dealing with OF issues. This document contained the most beneficial information that helped me to address many gotchas. Unfortunately, it's not organized in a way that makes it practical to use as a guide. However, it is **essential** that you keep referring to this document as you continue to make progress: as you learn important details additional information from the FAQ will make more sense and help you make further progress. Hopefully, anyway.
* Installation procedure for NetBSD/macppc 10.1: [[https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.1/macppc/INSTALL.html]]
* This is similar to the FAQ. It seems like it **should** be something that will guide you along, but there's just too many different machines with too many different issues for this guide to be immediately useful. Once again, you will need to review this document a **bunch** of times, each time learning just a little bit more.
The beige G3's are the last generation of OldWorldROM machines: machines that have an actual silicon Mac Toolbox ROM chip inside of them, with a history all the way back to the original Macintosh 128k.
However, when Apple migrated to the PowerPC architecture, they adopted a much larger and more complex architecture than what they had with the old 68000-series designs, based on PrEP/CHRP. This includes an additional low-level firmware layer: Open Firmware. Open Firmware is a very complex boot management system originally designed by Sun Microsystems for their much more advanced UNIX system hardware and adapted by Apple for their PowerPC machines. However, up to the time that the beige G3's were designed, Apple OpenFirmware machines had practically only one job: boot classic Mac OS via the Macintosh Toolbox found in the on-board OldWorldROM. Most of the capabilities of Open Firmware were not needed, and therefore Apple really only tested and polished very few OF functions -- the very few needed to initialize the most basic hardware and pass control to the Toolbox.
However, if you want to boot an OS **besides** classic Mac OS, you need more capability. Unfortunately, there's very little available: you're going to run into a **lot** of rough edges. This document records my trials and tribulations to be able to boot NetBSD on this machine. If you're trying to do the same on a first-model beige G3, hopefully you can use this to perform the task with a lot less time and effort than I did. If you're working with a different-model G3, it might give you some suggestions of things to try on your own machine.
On the Beige G3, there are at least two different hardware versions, with two different firmware versions. The first model contains a ROM card labeled Version A, which identifies itself as Open Firmware 2.0f1. That is the version I have. The biggest issue for this ROM (besides the general lack of useful OF features) is that this device will not boot from secondary IDE devices: they must be primary. So you're limited to two bootable IDE devices: the primary IDE device on each of the two controllers. The second model G3 contains a ROM card labeled Version B, and identifies itself as Open Firmware 2.4. This machines supposedly does allow booting from secondary IDE devices. But I don't have that machine and can't confirm this.
Please note, though, that the Blue-and-White G3's are significantly different than the Beige G3's. They do have Open Firmware, but it is an even-newer version: 3.0 or higher. In addition, they are the first of the NewWorldROM machines. They do **not** have a permanently-burned silicon ROM with the original Macintosh Toolbox. Because these machines were designed in a world where Macintosh OS X was now a thing, they needed to be much more capable. So instead, they have a flash-based ROM that loads the Toolbox and other low-level code from the hard drive at boot. On one hand, these machines still have Open Firmware and much of the mechanics documented here are similar, though not identical. In addition, the OF in these machines is a lot more capable. On the other hand, it's much easier to "brick" these machines if you pzut the wrong setting. It's even possible to corrupt the on-board flash in such a way that only Apple can reflash the firmware, which is not likely to happen for a decades-old machine... Be careful what you change and how you change it!
I want to specifically call out one such setting that is extremely likely to brick your machine: "little-endian". PowerPC's can run in two different modes (little-endian and big-endian). Until the mid-2010's or so, PowerPC processors were always used in big-endian mode: they default to that on startup, and all software designed specifically for them assumed it. However, Intel processors (and throughout most of history, *only* Intel processors) have always been little-endian. Once it became clear that Intel processors would rule the world, everyone decided to switch to little-endian to make software (and data) compatibility easier. (Mismatched assumptions between data endianness can create subtle bugs when porting between systems.) That means that even modern PowerPC/POWER systems expect and require little-endian, and what few modern PPC e.g. Linux distributions there are available are all little-endian.
So, you might be tempted to play with that setting and switch your Power Mac into little-endian mode. Don't. Literally every aspect of the machine assumes big-endian, and if you switch that, the CPU will be unable to run **any** of its firmware, and therefore won't be able to connect to anything: no keyboard, no video, no serial, nothing. For systems that have hard-burned firmware and only used battery-backed RAM for storing settings, you **MIGHT** be able to get back up and running by pulling the PRAM battery and waiting 15 mimutes. Maybe. I'm to scared to brick my machine to find out. For flash-based machines (like the Blue-and-White G3 and anything newer), there's no way to alter the flash settings without forcibly removing the flash and reprogramming it somewhere else -- assuming you even have an uncorrupted copy of the flash contents to put in place. Assuming you don't (and trust me, you don't), you can't fix it. So don't mess with that setting!
So, now that you're sufficiently warned/scared, let's get going! To get into the Open Firmware console: While the chimes are playing at boot, hold down <OPTION><COMMAND><O><F>. Keep holding: with an external PCI video card this will take a long time. On my system with a PCI ATI RADEON 7000 card (with Mac firmware version 208) it takes a full 50 seconds. However, without that card it only takes a few seconds, so you have to start right as the chimes are playing. Hold down until you see a white screen on the monitor connected to the internal video port. You must hold down all the way until the white screen appears (or until the monitor powers on and off again) otherwise it will *not* boot into the OF console.
NOTE: Don't use the Apple 12" Display (the worst Macintosh monitor Apple ever made), which runs at 512x384! It won't work: the system will enter the Open Firmware environment, but the monitor will stay black and the keyboard will not respond. It will seem that the computer is frozen, and all you can do is reboot the machine and not try to enter Open Firmware. That alone cost me several days of attempts... You'll need a better monitor. In my case, I ended up using a DB15 to VGA adapter with 10 DIP switches and an old square LCD flat panel with a native 1280x1024 resolution. I have the DIP switches set to 14679 (ON), which is the setting for an Apple 21" monitor with on-the-fly switching and separate sync signals. I also tested it with 1467 (ON) (Apple 13" RGB @ 640x480 fixed) and 1267 (Apple 19" @ 1024x768 fixed) with that same flat panel and they all worked fine. See your adapter's manual for similar settings.
Please note that a few models only support serial consoles -- they will never allow you to use the screen and ADB keyboard for the OF console! In the end, the serial console is better anyway, but if your machine only supports serial you will need to start working with it from the beginning. Keep reading for the details after we work with the screen and keyboard for a bit first.
Once you're in the OF console, you can do only a few things. The first thing you might want to do is to document the current (and default) settings. Use the following command:
printenv
This will list all of the current OF variables (settings), as well as the default value if available.
To see a list of all devices that the firmware can see, use the following command:
dev / ls
This is the combination of two commands: "dev /" and "ls". "dev" is kind of like "cd" for UNIX filesystems. It takes you to a point in the device tree. In this case "dev /" takes us to the top (root) of the tree. "ls" then lists all devices at and below that point. In this case, it shows us all devices because we are at the root of the tree.
To show where you are in the tree, you can type "pwd" (just like UNIX filesystems: 'print working directory').
In OF, device names can be long. For example, here is the device name for the keyboard on my system:
/pci@80000000/mac-io@10/via-cuda@16000/adb@0,0/keyboard@0,0
To make commonly-used devices easier to work with, OF has a collection of aliases you can use. You can see the list of aliases with the following command:
devalias
You will note that there is an entry for the keyboard:
kbd /pci/mac-io/via-cuda/adb/keyboard
You will also note that this does not include the items I listed above that included things like @10 or @0,0. Those extra identifiers allow you to identify specific aspects of a piece of hardware and are not always needed. One of the 'fun' aspects of working with Open Firmware is figuring out when those elements are needed or not... There's a lot of rebooting involved... :)
Recording this information from the on-screen console will be difficult. It literally might be best to use a digital camera and record the output. However, if you're going to be doing any heavy-duty OF configuration, you very much may want to use a serial console. This will allow you to use a different machine connected to the Mac via its serial port. In my case, I'm simply using a PC with a USB to Serial adapter and PuTTY connected to the modem port of the Macintosh. The cable I'm using into the Macintosh is a "hardware handshake" serial cable that goes from 8-pin mini-DIN to DB-25. I then use a DB-25 to DB-9 converter, and then a null-modem cable. You will need to figure out how exactly to properly connect to the serial port for your cabling. I suggest that you don't start this process from the OF console. Rather, use something like ZTerm under a classic Mac OS ([[https://macintoshgarden.org/apps/zterm]])and make sure you have a proper serial connection. The OF console will use 38400 bps, 8 bits, 1 stop bit and no parity (38400/8/1/N), so you might as well use that in ZTerm and PuTTY in advance as well.
There's lots of reasons why you want to start from a nice terminal running under classic Mac OS. Not only is the environment a lot easier to work with, but you may find that there are hardware issues that prevent you from doing this easily. It's much easier to figure this out when each attempt doesn't require a lengthy reboot. For example, most PPC Macintoshes comes with two serial ports: one labelled Modem and one labelled Printer. However, in a number of models, there is an internal telephone modem that is using the Modem port. If that's the case, you won't be able to use that port. You'll have to use the printer port instead. Again, figure out all of these details by using relatively-friendly terminal software rather than struggling to try to make all of this work within the decidedly-unfriendly confines of the OF console. If you can get text to type back and forth between your Macintosh and another computer in a terminal, you can be confident that at least there aren't any hardware issues that will prevent the OF console from working as well.
Once you've got a serial connection between the Macintosh and something else, you can now try to use the serial console with Open Firmware. I'm going to assueme that you are using the Modem port. Open Firmware uses the label "ttya" for that port. If you have to use the Printer port, you will need to use the label "ttyb" instead.
Boot into the on-screen OF console. If you're using the Modem port, the command you need is actually given to you in the OF boot text. Use the command:
TTYA IO
When you type it correctly, the screen will go black and you will see the following in your serial console:
<code>
ok
0 >
Yes, like much of Open Firmware, that command seems to be case-sensitive. If you type it in all lowercase, the screen will turn of and you'll get a prompt on your serial console, but you won't be able to type on either the ADB keyboard or the serial console!
Unfortunately, that command cannot be used if you need to use the Printer port (or any other type of hardware). Nor does using “TTYB IO” work: you get an “unknown word” error. However, there is a different way to switch to the serial console that will work for the Printer port (as well as other hardware devices). You can use the following commands:
" ttya" output " ttya" input
Note that the space after the first quotation mark is required! This will switch the output and input individually and immediately after you execute the command. That means that after the first command the screen will go black and the output will now be on the serial console, but you will still need to use the ADB keyboard for the next command. After the second command you will need to use the serial console to type additional commands – the ADB keyboard will be ignored. The nice thing about this command is that you can use other input and output devices here. So if you need to use the Printer port, you would type:
" ttyb" output " ttyb" input
and you will now be able to use a serial console connected to the Printer port.
If your serial console did not work, it's OK: simply reboot the system and use the keystroke to enter the OF console. You will return to your original settings and you will see your console on the screen again. None of these commands for switching to a serial console so far are permanent. That means that if you reboot and re-enter the OF console, it will use the internal screen and ADB keyboard, just as it did before. You will need to re-run the proper commands to re-enter the serial console. That means that if you make a mistake, it's no problem: just reboot and you'll be back to where you were. Later, we will see how to make these changes permanent if you wish.
In any case, you can now control the OF console from your serial console. This adds one big advantage: it will hopefully give you the ability to copy and paste the contents of your console! This will allow you to save your current settings. A brief word about copying and pasting, though: copying text from your serial console and pasting them into e.g. Notepad will work juts fine. However, pasting text into our serial console works terribly. The serial ports on Macintosh computers are different than standard PC serial ports (RS-485 vs RS-232), which creates a mismatch from the beginning. We are making it even worse by adding zero flow control, which means that it's very easy to overwhelm the Macintosh serial port. So when you try to paste text, it's very likely only small bits of it will make it through. Sadly, you're going to have to type everything, no matter how long or ugly the text might be…
I would suggest taking the time to save your original settings. I did this by connecting with a serial console, performing the following commands, and then copying and pasting the resulting output to another document:
printenv dev / ls devalias
Below is the resulting output. Note that I did this right after performing a rest of the OF settings. Also, I have a couple of additional PCI cards installed: an ATI RADEON 7000 with Mac firmware v208, and an AsanteFAST 10/100 Ethernet card.
0 > printenv VARIABLE CURRENT DEFAULT little-endian? false false real-mode? false false auto-boot? true true diag-switch? false false fcode-debug? false false oem-banner? false false oem-logo? false false use-nvramrc? false false real-base -1 -1 real-size 100000 100000 virt-base -1 -1 virt-size 100000 100000 load-base 4000 4000 pci-probe-list -1 -1 screen-#columns 64 64 screen-#rows 28 28 selftest-#megs 0 0 boot-device /AAPL,ROM /AAPL,ROM boot-file diag-device fd:diags fd:diags diag-file input-device kbd kbd output-device screen screen oem-banner oem-logo nvramrc boot-command boot boot ok 0 > dev / ls Children of the node: FF8295C8: / [AAPL,Gossamer MacRISC] Node Adr Node Name Compatible FF82A9B8: /cpus@0 FF82AAD0: /PowerPC,750@0 FF82AEE8: /l2-cache@0,0 FF82B560: /chosen@0 FF82B690: /memory@0 FF82B7D8: /openprom@0 FF82B898: /AAPL,ROM@FFC00000 [AAPL,ROM] FF82BAE0: /options@0 FF82BF80: /aliases@0 FF82C2F0: /packages@0 FF82C378: /deblocker@0,0 FF82CAA0: /disk-label@0,0 FF82D018: /obp-tftp@0,0 FF82F288: /mac-files@0,0 FF82F9A8: /mac-parts@0,0 FF830108: /aix-boot@0,0 FF830558: /fat-files@0,0 FF831B70: /iso-9660-files@0,0 FF8324D8: /xcoff-loader@0,0 FF832DA0: /terminal-emulator@0,0 FF832E38: /pci@80000000 [grackle] FF834120: /mac-io@10 [heathrow] FF8352F8: /mesh@10000 [mesh] FF836E20: /sd@0,0 [sd] FF837A30: /st@0,0 [st] FF8386F8: /bmac@11000 [bmac] FF839F90: /escc@13000 [escc CHRP,es0] FF83A128: /ch-a@13020 [ch-a CHRP,es2] FF83A7B8: /ch-b@13000 [ch-b CHRP,es3] FF83AE48: /davbus@14000 FF83AF30: /sound@0,0 [awacs screamer] FF83B020: /swim3@15000 [swim3] FF83C1D8: /nvram@60000 [nvram] FF83C2D0: /ide@20000 [heathrow-ata] FF83E028: /disk@0,0 FF83E0D8: /ide@21000 [heathrow-ata] FF83FE30: /disk@0,0 FF83FEE0: /via-cuda@16000 [via-cuda] FF840DC0: /adb@0,0 [adb] FF840ED8: /keyboard@0,0 FF841800: /mouse@1,0 FF841AC0: /pram@0,0 FF841B70: /rtc@0,0 [rtc] FF842038: /power-mgt@0,0 [power-mgt] FF842A70: /ATY,RV100Parent@D FF864BF8: /ATY,RV100ad_A@0,0 [ATY,RV100ad] FF865E38: /ATY,RV100ad_B@0,0 [ATY,RV100ad] FF867038: /pci1011,9@F [pci1011,9] FF867358: /ATY,mach64_3DU@12 FF842340: /perch@0 [Whisper] ok 0 > devalias pci /pci@80000000 mac-io /pci/mac-io kbd /pci/mac-io/via-cuda/adb/keyboard mouse /pci/mac-io/via-cuda/adb/mouse screen /pci/ATY,mach64_3DU ttya /pci/mac-io/escc/ch-a ttyb /pci/mac-io/escc/ch-b scsi /pci/mac-io/mesh scsi-int /pci/mac-io/mesh ide0 /pci/mac-io/ide@20000 ide /pci/mac-io/ide@20000 ata-int /pci/mac-io/ide@20000 ide1 /pci/mac-io/ide@21000 enet /pci/mac-io/bmac swim /pci/mac-io/swim3 fd /pci/mac-io/swim3 ok 0 >
Note that the current settings match the default settings, and the nvramrc variable is blank. That is what you would see with a factory-default configuration. If you look through the PCI devices you will see that there is a “/ATY,mach64_3DU@12” device, which is the on-board RAGE II device, and a “/ATY,RV100Parent@D” device (and children), which is the PCI RADEON 7000 device. There may be other differences to yours, including the type of “Personality Card” added to your system: mine has only the basic “Whisper” audio card, as opposed to the “Wings” or “Bordeau” cards that were also available.
You can use other devices besides the serial port for your console. For example, you might want to use the screen that is attached to a PCI video card. In order to do this, you need to know the device name. This can be determined by the list of devices you created with the “dev / ls” command above. Look down through the list of devices and see if you can find the device you're looking for. In my case, I see the “/ATY,RV100Parent@D” device I mentioned above. That would be a good place to start looking.
Notice that this device is indented. It's listed 'inside' of the “/pci@8000000” device. Therefore, it's complete name is actually “/pci@80000000/ATY,RV100Parent@D”. As was mentioned before, the items after the @ are not always needed, and they're annoying to type. Let's try to select that device with the following command and simplified device name:
dev /pci/ATY,RV100Parent
If you don't have a PCI video card, you can try the same thing using the onboard video card you do have. The device will, of course, be different, but the process will work the same.
Once you've selected that device, you can get an idea of what you can do with it by using this command:
words
That will list all of the words (actions) that this device will handle. We won't use these actions directly, but other OF commands will. In this case, what we want to see is an “open” word. That tells us that the device can be 'opened' in order to be used in some way. If you've selected a device and there isn't an 'open' word, this is likely a device you can't do anything with.
So what can we do with this device? Well, it's a video output device, so we can output video In this case, we can use it as the output of our OF console. Let's see if we can get it to display something with this command:
" /pci/ATY,RV100Parent" output
If you ran that command, your serial console went dead, yet nothing happened on the display you were hoping to see. The command didn't work – and worse, it seems to have crashed the computer. In my case, not even <CONTROL><COMMAND><POWER> would reboot the computer: I had to power-cycle it.
So obviously that command didn't work. Maybe I stripped away too much of the actual device? Let's try the entire device string this time:
" /pci@80000000/ATY,RV100Parent@D" output
Nope, same thing. Frozen console with blank screens.
Unfortunately, that's how it goes with the OF console. Nothing is logical, nothing is straightforward, and nothing is easy. And when you make a mistake, more often than not the next step is to reboot and try something different. (Or, sometimes, just to try it again: sometimes a command works only if you do it more than once! How's that for mystery?)
If you'd like a taste of what I went through in making this walkthrough, take some time and see if you can figure out the proper command on your own. It's easier to make the onboard video work, so you might want to start with that… Switch to the serial console, then try to switch the output back to the onboard video. If you make that work, then try to switch the input back to the keyboard… And if you have a working PCI vdeo card and you really like punishment, try to make that work as well!
For the rest of you sane people, here's how to do it. To switch back from serial output to onboard video output, here is the command:
" /pci/ATY,mach64_3DU" output
In this case, the device is straightforward: “/pci” without the @80000000, followed by “/ATY,mach64_3DU” without the @12 and the video will be displayed on the internal screen. However, you could have also used the complete device name:
" /pci@80000000/ATY,mach64_3DU@12" output
It works the same. Sometimes you can get rid of the extra information, sometimes you can't. Figuring out which is which is very much an exercise for the reader… As a hint, when there is only a single item that shares a specific device name, you can probably leave off the extra information after the @.
For the keyboard, it's a similar process, but with a lot more items in the device path:
" /pci/mac-io/via-cuda/adb/keyboard" input
The serial console's keyboard will be ignored, and now you'll need to use the ADB keyboard – which will still show up on the serial console screen!
It's a similar process for that PCI video card: finding the proper device path. Here's the answer for my RADEON 7000:
" /pci/ATY,RV100Parent/ATY,RV100ad_A" output
Remember that we mentioned that there is one more set of device names, which you can see from the output of the “devalias” command. Certain devices are commonly used, and are given a much easier alias to work with. Look at the output of the “devalias” command and no doubt a couple of them will stand out to you. For example, there is an alias “screen” for the output device “/pci/ATY,mach64_3DU” and “kbd” for “/pci/mac-io/via-cuda/adb/keyboard”. That allows you to use much shorter commands:
" screen" output " kbd" input
These aliases can work in other contexts where you might need to use a much longer full device path.
Now that you have an idea of how to work with device paths and aliases (and can switch the input and output at will), let's keep going.
Once you have a record of your current settings, you might at some point want to reset everything to factory defaults. This might not be the first thing you want to do: it's entirely possible that specific (and needed!) changes were made to your firmware settings that you will want to record first! This is especially true of the nvramrc setting, which I do not know how to modify directly. However, once you start making changes to your own OF settings, there is a very high degree of likelihood that you will need to reset the OF settings anyway – when you accidentally misconfigure something.
One way of resetting the OF settings is the standard “Reset PRAM” keystroke: during the chimes, hold down <OPTION><COMMAND<P><R>. Keep holding down the keys until you hear the chimes a second time. Apple recommends allowing this to cycle *several* times (I've read as many as three chimes after holding down the keys). However, that's usually because of a hardware change that can take a few cycles to get fully reset. When you're just trying to reset from changes to settings from the OF console, I have found that a single cycle is sufficient.
Likely you've done this keystroke before: it's kind of a required and expected part of Macintosh maintenance. And in a world where all your system's Open Firmware needs to do is load the classic Mac OS, there's likely very little that this will hurt. However, if you have never done this before, there is a very small risk that your system may not be able to boot properly, especially if you are running OS X on an OldWorldROM system. There are likely mandatory OF changes that are required for OS X to boot. Most likely the System Disk tool has and will be able to return those settings, but no one can guarantee what will happen. Please do this at your own risk!
Another way to reset to factory defaults from within the OF console is with the following command:
set-defaults
Many online resources mention reset-nvram followed by set-defaults, but reset-nvram is not implemented in the 2.0 firmware. However, set-defaults seems to do a complete job of resetting the settings for 2.0 firmware. For newer OF firmware, you may need both commands. In either case, once you've reset the settings you might want to then reboot to use the now-clean settings. Use this command:
reset-all
The system will reboot into the chimes, and if you wan to enter the OF console, use the <OPT><CMD><O><F> keystroke again.
At this point, I have a freshly-reset Open Firmware. However, if we want to boot something besides classic Mac OS, we need some additional changes to the OF settings. We need to use the System Disk tool in order to make these changes.
Despite it's name System Disk is not itself a disk (floppy or optical). it is a classic Macintosh program (that will only run on Mac OS 9) that is designed to select the System Disk we want to boot into. Normally, we would use the System Disk control panel for that: why do we need this extra program? Because the control panel will only allow us to select classic Mac OS systems, not OS X systems. So Apple provided the System Disk tool to allow classic Mac OS users to actually select and boot into OS X. Without it, it is impossible for many PPC systems to boot OS X.
One of the things that this utility does is add additional capability to the factory-supplied Open Firmware. It does this by adding a bunch of code to the nvramrc variable. (Open Firmware includes an entire programming language – Forth – that allows additional functionality to be added, even to burned-in-ROM firmware!) And we need that functionality. So we need the System Disk tool. You can get it from here: http://download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/English-North_American/Macintosh/System/Mac_OS_X/System_Disk_Utility.smi.bin
Once we've downloaded it, unpacked it and mounted the resulting disk image, we will see the System Disk program. Feel free to copy that to your hard drive: you'll likely need it in the future. Any time you reset the OF settings, you will need to use the System Disk tool to put back its changes. In any case, run the program. You will be shown a list of partitions on your hard drive – but you will also see a partition listed as “Power User (Open Firmware)”. Basically, that won't select any partition to boot from, but it will allow us to still make the necessary changes to our OF settings. Select “Power User” and click “Advanced Options”.
From here, we can change a few OF variables: Boot Device, Boot File, Boot Command, Input Device and Output Device. For my OF configuration, which was factory reset, I see the standard defaults:
Notice that it's using the device aliases “kbd” and “screen” for input and output, and “/AAPL.ROM” for the boot device. That is the OldWorldROM Macintosh Toolbox built into my Beige G3. And that's all that Open Firmware is expecting to ever do on this machine: simply turn control over to the Toolbox as quickly and invisibly as possible.
However, we want to do more with Open Firmware, so we'll need to make some changes. For now, let's keep the changes to a minimum. For one thing, I'd rather use the serial console than the screen and keyboard, so let's change the settings to always use the serial console. Click the “Configure Manually” checkbox at the end of the Input/Output line, and make the following changes (using the correct device names for your system):
Also, having to hold down the keys to enter Open Firmware is cumbersome. For now, let's enter Open Firmware each time we boot. We can do that by checking the box “Stop Boot at Open Firmware prompt”. Now click OK to return to the main System Disk screen.
From here, we need to actually save the changes by clicking on the “Save” button. Now we can simply exit the System Tools program and reboot the computer. When we so, we will hear the chimes, and a little later we will enter the Open Firmware console automatically, and via the serial console. I'm going to take a moment and run the “printenv” “dev / ls” and “devalias” commands and record the output below:
Open Firmware, 2.0f1
To continue booting the MacOS type:
BYE<return>
To continue booting from the default boot device type:
BOOT<return>
For Open Firmware serial I/O type:
TTYA IO<return>
ok
0 > printenv
VARIABLE CURRENT DEFAULT
little-endian? false false
real-mode? false false
auto-boot? false true
diag-switch? false false
fcode-debug? false false
oem-banner? false false
oem-logo? false false
use-nvramrc? true false
real-base -1 -1
real-size 100000 100000
virt-base -1 -1
virt-size 100000 100000
load-base 600000 4000
pci-probe-list -1 -1
screen-#columns 64 64
screen-#rows 28 28
selftest-#megs 0 0
boot-device /AAPL,ROM /AAPL,ROM
boot-file
diag-device fd:diags
diag-file
input-device ttya kbd
output-device ttya screen
oem-banner
oem-logo
nvramrc
hex
: $D find-device ;
: $E device-end ;
: $L BLpatch ; : $R BRpatch ;
: $X execute ;
: $p 0 to my-self property ;
: $a " /chosen" $D $p $E ;
: &c " ata-enable" $call-parent ;
10 buffer: km
dev kbd
get-key-map km swap move
$E
: ck 0 do swap dup 3 >> km + c@ 1 rot 7 and << and or loop ;
: bootr 0d word count encode-string " machargs" $a
0 0 1 ck if 0 and else f 3d 0 2 ck if 40 or then then
if bye else 1e 0 do ['] boot catch drop 1f4 ms loop then bye ;
: myboot boot-command eval ;
dev enet
' open constant $M
: $M2 $M 710 - $X ;
: rl@ -7D9D40 $X ;
: chstat begin $M2 $M 14f8 - $X -7D6C20 $X rl@ 400 and 0= until ;
: bmstat begin $M2 $M 13F0 - $X rl@ 100 and until ;
: xmt1 get-msecs $M 720 - ! chstat $M A00 - $X bmstat chstat ;
' xmt1 ' WRITE 10 + l!
62 ' READ 7 - c!
: READ { _p _n ; _a } begin _p _n bead -> _a _a 2+
if _p c@ 80 and 0= else 1 then until _a ;
$E
dev /packages/obp-tftp
: $M over + ['] noop $L ;
: $O ['] open + ;
: $M1 dup 24 - -1720 $O $X 6 move 14 + ;
-5BC $O ' $M1 $L
0 $O E8 $M EC $M F0 $M F4 $M F8 + ' true $L
$E
dev /packages/mac-parts
: $M -7E89E0 $X 8000 alloc-mem 7F00 + 4 -7E89E0 $X ;
' load 268 - ' $M $L
' load 160 + ' 0 $L
$E
dev ide0
: open use-ata-interface 0 &c -1 ;
: set-device-ID set-drive-select ;
: reset-atapi-bus reset-ata-bus ;
' reset-ata-bus 2c + ' 2 $L
$E
dev ide1
: open use-ata-interface 0 &c -1 ;
: set-device-ID set-drive-select ;
: reset-atapi-bus reset-ata-bus ;
' reset-ata-bus 2c + ' 2 $L
$E
dev scsi
: $M ['] do-cmd + ;
: $M2 5 us -5f0 $M $X ;
: $M3 -710 $M f over $X $X ;
: $M4 1 ms ;
-1AC $M ' $M2 $L
100 $M ' $M3 $L
120 $M ' $M4 $L
124 $M ' 1 $L
$E
ff000000 dup dup 400 28 do-map 4+ w@ 10 and 0=
if 90b7 f3000032 w! then
unselect-dev
boot-command boot boot
ok
0 > dev / ls
Children of the node:
FF8295C8: / [AAPL,Gossamer MacRISC]
Node Adr Node Name Compatible
FF82A9B8: /cpus@0
FF82AAD0: /PowerPC,750@0
FF82AEE8: /l2-cache@0,0
FF82B560: /chosen@0
FF82B690: /memory@0
FF82B7D8: /openprom@0
FF82B898: /AAPL,ROM@FFC00000 [AAPL,ROM]
FF82BAE0: /options@0
FF82C610: /aliases@0
FF82C980: /packages@0
FF82CA08: /deblocker@0,0
FF82D130: /disk-label@0,0
FF82D6A8: /obp-tftp@0,0
FF82F918: /mac-files@0,0
FF830038: /mac-parts@0,0
FF830798: /aix-boot@0,0
FF830BE8: /fat-files@0,0
FF832200: /iso-9660-files@0,0
FF832B68: /xcoff-loader@0,0
FF833430: /terminal-emulator@0,0
FF8334C8: /pci@80000000 [grackle]
FF8347B0: /mac-io@10 [heathrow]
FF835988: /mesh@10000 [mesh]
FF8374B0: /sd@0,0 [sd]
FF8380C0: /st@0,0 [st]
FF838D88: /bmac@11000 [bmac]
FF83A620: /escc@13000 [escc CHRP,es0]
FF83A7B8: /ch-a@13020 [ch-a CHRP,es2]
FF83AE48: /ch-b@13000 [ch-b CHRP,es3]
FF83B4D8: /davbus@14000
FF83B5C0: /sound@0,0 [awacs screamer]
FF83B6B0: /swim3@15000 [swim3]
FF83C868: /nvram@60000 [nvram]
FF83C960: /ide@20000 [heathrow-ata]
FF83E6B8: /disk@0,0
FF83E768: /ide@21000 [heathrow-ata]
FF8404C0: /disk@0,0
FF840570: /via-cuda@16000 [via-cuda]
FF841450: /adb@0,0 [adb]
FF841568: /keyboard@0,0
FF841E90: /mouse@1,0
FF842150: /pram@0,0
FF842200: /rtc@0,0 [rtc]
FF8426C8: /power-mgt@0,0 [power-mgt]
FF843890: /ATY,RV100Parent@D
FF865A18: /ATY,RV100ad_A@0,0 [ATY,RV100ad]
FF866C58: /ATY,RV100ad_B@0,0 [ATY,RV100ad]
FF867E58: /pci1011,9@F [pci1011,9]
FF868178: /ATY,mach64_3DU@12
FF8429D0: /perch@0 [Whisper]
ok
0 > devalias
pci /pci@80000000
mac-io /pci/mac-io
kbd /pci/mac-io/via-cuda/adb/keyboard
mouse /pci/mac-io/via-cuda/adb/mouse
screen /pci/ATY,mach64_3DU
ttya /pci/mac-io/escc/ch-a
ttyb /pci/mac-io/escc/ch-b
scsi /pci/mac-io/mesh
scsi-int /pci/mac-io/mesh
ide0 /pci/mac-io/ide@20000
ide /pci/mac-io/ide@20000
ata-int /pci/mac-io/ide@20000
ide1 /pci/mac-io/ide@21000
enet /pci/mac-io/bmac
swim /pci/mac-io/swim3
fd /pci/mac-io/swim3
ok
0 >
If you compare this to the previous settings, you'll see a few differences. At the top you'll see the entire Open Firmware boot text – because we started directly in the serial console. You'll also see that the current “input-device” and “output-device” variables are “ttya” instead of “kbd” and “screen”. And you'll see that there is now a bunch of content in the “nvramrc” variable. That is the extra functionality added to Open Firmware by the System Tools program!
OK, that's great, but now what? Are we stuck in Open Firmware? If we reboot the computer, it will enter Open Firmware no matter what. How do we get out of this?
The easiest way to leave is given to us at the beginning of the boot message. If we want to boot into classic Mac OS, simply type the following command:
bye
(Notice that this one wasn't case-sensitive.) This will forcibly continue into the classic Mac OS boot process. There's also a different command:
boot
This is described as booting into the default boot device. This will execute whatever boot command we have previously stored within the Open Firmware settings. However, in our case, we allowed System Tools to use the default Boot Device, Boot File and Boot Command settings, which just so happen to also boot us into a classic Mac OS system. So for now, “bye” and “boot” will perform the same boot process.
But we don't want it to stay that way forever. The whole point of this process is to get our computer to boot something other than classic Mac OS. If we wanted to boot an OS X system, we simply could have used the System Disk tool to select our OS X partition and let it automatically configure the boot variables for us. However, if we want to boot something besides classic Mac OS or OS X, we need to figure out the boot variables on our own.
And that's even harder than what we've done so far…
So hard, I don't yet know how! Next time on “As the Apple ripens…”
So, the simplest thing to boot off of is a floppy. And the only thing I can find that boots off of a single flopy is… the NetBSD 1.4 install floppy. (
Here's the output of “words” from with no dev selected:
boot-command nvramrc oem-logo oem-banner output-device input-device
diag-file diag-device boot-file boot-device selftest-#megs screen-#rows
screen-#columns pci-probe-list load-base virt-size virt-base real-size
real-base use-nvramrc? oem-logo? oem-banner? fcode-debug? diag-switch?
auto-boot? real-mode? little-endian? assign-addresses make-properties
probe-pci probing-pci? eject dir boot $boot
reload load go init-program loadmapsize loadsize
loadaddr nvunalias $nvunalias nvalias $nvalias nvrecover
nvrun nvstore nvquit nvedit set-defaults set-default
nodefault-bytes setenv $setenv printenv nv-free see
(see) +dis dis (dis) disassemble dis_ptr
release-virt claim-virt release-real claim-real release-mem claim-mem
(is-user-word) is-remove is-install fb8-install io output
input get-screen-alias make-screen-alias prop-match
prop-search (prop-search) next-dev first-peer? $open-package find-package
end-package begin-package unselect-dev select-dev devalias alias-this-node
$devalias (my-node-name) show-devs dev find-device interpose
open-dev apply execute-device-method ihandle>phandle pop-package
push-package close-dev close-package open-package mac-address free-virtual
dump-device-tree .properties ls pwd finish-device
new-device set-args peer child get-inherited-property
get-my-property get-package-property delete-property next-property aapl,connector
aapl,slot-name aapl,interrupts reg model built-in compatible
device-type device-name decode-bytes decode-string decode-phys decode-int
encode-file encode-cat encode-bytes encode-string encode-pci-reg encode-reg
encode-phys encode-3ints encode-2ints encode-int encode+ property
device-end fb8-draw-logo fb8-write fb8-draw-character fb8-toggle-cursor
fb8-delete-characters fb8-insert-characters fb8-insert-lines
fb8-delete-lines fb8-blink-screen fb8-invert-screen
fb8-erase-screen fb8-reset-screen >font set-font
default-font draw-logo delete-lines insert-lines delete-characters
insert-characters invert-screen blink-screen erase-screen toggle-cursor
reset-screen draw-character background-color foreground-color
#columns #lines line# column# inverse-screen? inverse?
fontbytes char-height char-width font-adr window-left window-top
screen-width screen-height frame-buffer-adr alarm user-abort
fcode-end fcode-version2 fcode-version1 forget diagnostic-mode?
gc-board-regs-pa memory-test-suite mask blpatch
brpatch forth environment? help external headers
headerless rl! rl@ rw! rw@ rb!
rb@ shut-down reset-all .of-regs .registers $callback
callback %sdr1 %sprg3 %sprg2 %sprg1 %sprg0
%fpscr %mq %dsisr %dar %xer %cr
%ctr %lr %srr1 %srr0 %ir %iv
%r31 %r30 %r29 %r28 %r27 %r26
%r25 %r24 %r23 %r22 %r21 %r20
%r19 %r18 %r17 %r16 %r15 %r14
%r13 %r12 %r11 %r10 %r9 %r8
%r7 %r6 %r5 %r4 %r3 %r2
%r1 %r0 do-translate do-unmap do-map __m_
_i_g w___ state-valid init-nvram bye kbd
ttya screen install-console probe-all quit byte-load-file?
byte-load-file rom-@ supress-banner banner enable-alarms disable-alarms
noshowstack showstack default-status status dl eval
evaluate { -> ( \ dumpl
dump h# d# o# b# >number
.( abort" " ." s" <s">
<s",> sifting $sift sub$ cstr= $=
control ascii char [char] words (words)
endof of endcase case ?leave +loop
loop ?do do again until repeat
while begin then else if to
to-reg c; end-code (end-code) label code
(code) filler field struct 2constant constant
defer buffer: value variable immediate ]
[ recurse recursive ; : does>
(does>) create $create alias parse-2int parse-3hex
parse-2hex parse-1hex parse-nhex parse-ints right-parse-string
left-parse-string null? [compile] postpone compile
compile, literal, literal ['] (word) '
parse-word parse source map-low $call-parent my-address
my-space my-unit my-args my-parent ?my-self $call-method
call-package find-method behavior body> $find find
canonical >in #tib -trailing accept .s
? .b .o .d .h .x
u.h .r u.r h. u. s.
(u.) (.) #s # u#> u#s
u# 0+ sign #> <# hold
chara? pad upc-hex? (holdp) $number digit
lcc upc between lcc-z lcc-a upc-z
upc-a upc-9 upc-0 binary octal decimal
hex span base spin-every _spin-every (spin
_spin tab-to spaces space cr (cr
linefeed carret lines/page #out #line ms
us _kbd-ihandle _pmu-ihandle _cuda-ihandle _mmu-ihandle _mem-ihandle
_mmu-callback _callback _cpu _mmu _mem _stdout
_stdin _aliases _chosen _options _ciwords _nv-bad?
sccad sccac $c, 3drop 3dup erase
blank bounds unaligned-w! unaligned-w@ unaligned-l! unaligned-l@
lpoke lpeek wpoke wpeek cpoke cpeek
abort stdout stdin even not fcode-revision
noop fm/mod // */mod */ sm/rem
mu/mod (msigns) dnegate s>d xa1+ /x*
word key? key type emit get-usecs
get-msecs spin . expect /x /n
/l /w /c true false cold-load
[']rom-c@ swizzle-c@ byte-load (byte-load) free-hdrs roll
alignd align allot c, w, l,
, (latest) instance instance? >body >flags
?instance last! last@ last? my-self active-package
global-words state? state free-mem alloc-mem ferror
(vfind) pack cntlz real? swizzle? little?
xbflips xwflips xlflips lwflips lwflip lbflips
lbflip wbflips wbflip bwjoin wbsplit bljoin
lbsplit wljoin lwsplit tib set-token get-token
@startvec (dl) scc-write scc-read comp filll
fill move count bell bs bl
invert xor or andc and min
max within u>= u> u<= u<
>= > <= < <> =
0>= 0> 0<= 0< 0<> 0=
>>a >> rshift << lshift abs
negate um/mod u/mod /mod mod u2/
2/ / um* m* /w* 2*
* d- - d+ + aligned
/n* /l* cells /c* chars 4-
cell- na1+ 4+ la1+ cell+ 2-
2+ wa1+ 1- ca1+ 1+ char+
xa+ na+ la+ wa+ ca+ 8
4 3 2 1 0 -1
r@ r> >r depth nip tuck
pick 2swap swap -rot 2rot rot
2drop drop 2over over ?dup 2dup
dup on off +! ^tlbie ^sync
^icbi ^dcbf ^dcbi xb! xw! xl!
xd! xb@ xw@ xl@ xd@ 2!
l! ! w! c! 2@ l@
@ <w@ w@ c@ j i
cache-flush cache-zero <isi-int> <dsi-int> virt_base real_base
unmap-page map-page iabr! dabr! hid1! hid1@
hid0! hid0@ sdr1! sdr1@ sr@ sr!
unloop leave exit execute alloc-here here!
here code! clear (abort) throw catch
msr! msr@ sprg3! sprg3@ dec! dec@
tb! tb@ rtc@ <pvr1@> l2cr@ pvr@
phys@ bat3l@ bat3u@ bat2l@ bat2u@ bat1l@
bat1u@ bat0l@ bat0u@ sync@ invokenub@ my-self+
rmyself! (alarm
(libbytesize1 depends on libbytesize-common (=2.11-1) but isn't found)