Debian PowerPC/Joys & Woes
Hi,
First, some good news. We have Debian GNU/Linux running on our
PowerCenter 132, with X, GNOME, MH, sendmail, etc. all
installed. It's great to be running Linux on this system -- when
things work, the machine is way faster than it ever was under
MacOS, and it's especially wonderful to be able to use a real
e-mail system again.
But the installation was far from easy, documentation seems to be
hard to come by, and system still feels too flaky to really
trust.
We are writing to do three things:
1. Describe our experiences, so that other people who attempt
a similar installation have an idea of what to expect
2. Give people an opportunity to tell us that we did the
install wrong, and tell us how we *should* have done it
3. Ask about the status of Debian on the PowerPC platform
The Machine
-----------
The system is a PowerComputing PowerCenter 132 (132 MHz 604e
processor), 80 MB of RAM, 4 MB VRAM (built-in Platinum
framebuffer). There are two internal SCSI hard disks (for MacOS)
and one external (for Linux), as well as a SCSI CD-ROM drive.
(At the moment, we also have a SCSI CD-ROM recorder.)
The machine does not have a direct connection to the Internet.
Instead, it is on a small LAN with access to another machine
which shares its 28.8 Kb modem connection using a SOCKS proxy
server.
The Install
-----------
After installing LinuxPPC R5, and not being very happy with the
result, we decided to try Debian, despite the ``unstable'' status
of the potato release. We spent several hours reading Web pages,
USENET posts, and mailing list archives and decided that the way
to install Debian/PowerPC appeared to be as follows (from the
Linux on PowerPC FAQ-O-Matic,
<http://www.dartmouth.edu/~jonh/lppc-serve/cache/572.html>):
1. Obtain all necessary packages.
2. Create and format partitions for root, /usr, and so forth.
3. From a LinuxPPC install, untar the base2_2.tgz file and run
chroot to switch into running the Debian system.
4. Run dselect to configure unconfigured packages.
5. Quit back into LinuxPPC.
6. Edit various configuration files.
7. Reboot into Debian.
8. Use dpkg/dselect to install packages.
Our first problem occurred at step 7. We couldn't boot into
Debian because the base2_2 filesystem assumes that you only have
two SCSI disks on your system (sda and sdb). Since this machine
has three SCSI hard disks, and all the Linux partitions are on
the third (sdc), we had to copy device files from the LinuxPPC
system to get things working.
Once the device files were in place, we could reboot into Debian.
The initial configuration script ran fine, but the last part of
the script -- where you're supposed to be able to choose from
sets of predefined packages based on the role of the system --
failed, because the data file for this step contained no useful
information (perhaps it was a placeholder file?).
So we decided to install packages by hand, using dselect and/or
dpkg. Since our 'Net connection is slow, we opted to use
packages from CD-ROMs burned from the then current distribution
(July 10, 1999, from ftp.debian.org). Making the CDs was a bit
of an adventure, since the packages don't fit on a single CD, and
so we had to read up on how to make a multi-CD set -- not too
hard with a little help from Perl; the only tough choice was
trying to decide what packages to put on the first CD and what
packages to put on the second, since we wanted to have the things
we were most likely to need on a single CD.
Once dselect was told about the CD-ROMs, it decided to update the
ncurses package, which broke much of the system (including dpkg
and dselect) because the ncurses package on the CD-ROM depended
on newer C libraries than those included in the base system
(specifically, it wanted to call __register_frame_info, which
wasn't in our libc), and never mentioned this fact.
We restored the old version of the ncurses library from the
base2_2.tgz file; installed the newer version of the C libraries
with dpkg, and then updated the ncurses library.
We were now able to install packages using dselect and dpkg.
Dselect was such a pain (requiring hand-selection of hundreds of
packages) that we wrote a script to install every required,
recommended, and important package using dpkg. At this point we
ran into some residual effects of the Perl naming transition (a
set of CD-ROMs we burned the previous week were completely
useless because of the package name changes).
Once we had most of the packages in place, the system worked,
more or less, except for X.
We discovered that the 2.2.9 and 2.2.10 kernels provided in
Debian packages didn't support our machine very well. Most
important, the video driver for the Platinum video in our machine
was badly broken, and did not work well enough to start X. We
initially solved the problem by copying Xpmac from the LinuxPPC
distribution and booting using the No Video Driver option in
BootX. Eventually, we found down a patched version of the 2.2.10
kernel source from the vger CVS archive that included fixes for
the Platinum video driver (among other things). Once we had a
working kernel video driver, we could run XF68_FBDev, although
figuring out a proper XF86Config was `interesting', since there
wasn't much useful documentation -- the XF86 documentation
doesn't really apply to XF68_FBDev.
In the end, we used a ``Modes "default"'' line in the Display
subsection of the Screen section of XF86Config. This wasn't
ideal, because it made the X server start in whatever mode the
frame buffer was in when the server was started, and, even with
the updated Platinum device driver, Linux boots with the frame
buffer fairly poorly configured (weird color scheme with random
colors for text (red in the first virtual terminal and other
colors in other virtual terminals), and with X starting in some
kind of interlaced mode). We ended up putting a call to `fbset
--all 1024x768-75' in an /etc/rc.boot script (as well as another
script that calls `clock -s' to set the clock, as the hwclock.sh
command fails on Power Macintosh machines).
So we finally got X up and running, and from there most things
have worked. As we've worked with the machine and found pieces
missing, we've installed them from the CD-ROMs.
Rough Edges
-----------
There are still a number of problems, including various nasty
errors with Emacs and XEmacs (there are errors such as
``Arithmetic range error: "truncate", 238608659.55555555'' that
show up at various times when opening files, attempting to run
the customization routines, etc., as well as dumping core when
run in a terminal), various GTK applications (ranging from one or
two error messages to hundreds), Window Maker (touching the clip
is a sure way of crashing the window server), sound, and so on.
Perl is still hit and miss, as well -- some modules and libraries
are present, some aren't (and, as a result, lots of applications
that depend on Perl fail in various ways).
We are also unable to use the apt-get command -- with or without
socksify, it attempts to connect to http://http.us.debian.org and
fails.
It's also clear that some packages get compiled for the PowerPC
without ever being tested. For example, cdrecord just doesn't
work at all on a stock Debian/PowerPC system because it uses
shared memory for its buffer and the stock 2.2.10 (and earlier)
kernels include a very small limit on the amount of shared memory
in the system. The fix is a simple change to a kernel header
mentioned in the cdrecord documentation (and recently
incorporated into the latest vger kernels), but we were left with
the feeling that no one had ever actually tried to run the
program on a PowerPC machine. Even with this kernel
modification, cdrecord still won't work because the base2_2.tgz
doesn't include devices for the Generic SCSI device driver (sg0,
sg1, etc.). base2_2.tgz is also missing the loop device, which
is very useful when checking CD images before burning them.
Lingering Questions
-------------------
We're left wondering the following:
- What can we do to help make things better?
We're happy to put in some time, writing documentation,
tracking down problems and submitting bug reports. But it's
very hard to know where to begin -- is a given problem
something wrong with the application, with the kqernel, with
the libraries we have installed, or due to some other aspect
of our installation? (As a case in point, emacs dumps core
when it quits if it isn't using X (e.g., ``emacs -nw --help''
triggers the bug); it actually dies inside chunk_free in the
C library; but whether the culprit is emacs, libc or a broken
Debian installation is unclear.)
- Where are the people who have Debian running on PowerPC
machines, who understand what's going on, how development is
progressing and so on, hanging out? Are they documenting
things? And where is that documentation?
For example, we *know* that some people somewhere must
actually use the vger CVS kernel source repository, yet it is
not at all easy for the uninitiated to figure out the command
necessary to check out the source tree. The documentation on
the cvs.on.openprojects.net web site would have you believe
the command is `cvs -z3 checkout kernel', which doesn't work.
If you guess that you could type `cvs -z3 checkout linux',
you end up with a bleeding edge 2.3.x kernel rather than a
stable series kernel.
It turns out that the commands to get the latest 2.2.x kernel
from the vger repository are:
setenv CVSROOT
:pserver:anonymous@cvs.on.openprojects.net:/cvs/linux cvs
login cvs -z3 checkout -rlinux_2_2 linux
We discovered the correct incantation by chancing on an FTP
site with a checked-out copy of the 2.2.x branch and
examining the Repository, Root and Tag files in the CVS
directory.
- Is there a better way to install the system that would
install all the necessary packages, including ones we might
not think about? If so, should we reinstall the system?
- What are the correct settings necessary to use apt-get in
order to even find out about updated packages?
- What do we need to do to get reliable versions of basic tools
such as Emacs?
- Should we be submitting formal bug reports for everything
that doesn't work? (We don't want to nag at people if all of
these things are known problems.)
- Is there some secret storehouse of documentation we just
aren't seeing?
Thanks for your time, and, hopefully, answers or suggestions.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Behind the counter a boy with a shaven head stared vacantly into space,
a dozen spikes of microsoft protruding from the socket behind his ear.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
C.M. Connelly c@eskimo.com SHC, DS
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Reply to: