Gentoo on an AlphaStation 250 4/266 -- easy to do

[jf]

Hello, I thought I would share my experiences bringing up Gentoo Linux
on an AlphaStation 250 4/266. It was straightforward and works well.

About the machine

The machine (mae as in Mae West) is an AlphaStation 250 4/266, an early
90's workstation, pretty spiffy in its day, now relegated to serving
our webpages. We had happily been running the Redhat 7.1 distribution
with a 2.2 kernel compiled with iptables turned on. We also had
compiled-from-source versions of qmail, apache, perl, and postgresql
to support our website which uses Mason.

Unfortunately, we had a disk crash which wiped out the Redhat system
(our "important" filesystems are backuped up nightly with rsync onto
a separate disk; we didn't lose any data). Rather than reinstall the
now obsolete RH 7.1, we cast about for something more up to date. RH
apparently no longer creates alpha distributions; we tried the SuSE 8.1
Linux distribution -- the CD would boot, but the system would fail
halfway through the packages download for no apparent reason. We run
Gentoo on a couple of PCs and are pleased with the results, so we gave
Gentoo a shot.

Getting Started

If one pokes around the Gentoo web and ftp sites, there is some sketchy
documentation suggesting it ought to be possible to get Gentoo running
on an alpha. We started with the latest alpha iso,
1.4_rc1/gentoo-alpha-1.4rc1-test4.iso.bz2 which unfortunately does not
come with any stage-tarballs, so we also downloaded and burned a CD
with the uncompressed and untarred stage1-alpha-1.4-r1.tbz2.

Thus armed, we booted off the CD from SRM. For PC people, SRM is
essentially a bit of ROM code that runs after the alpha
bios-equivalent runs. It lets you boot from an arbitrary device,
although disks do require a BSD disklabel rather than a partition
table. You can read about SRM and download updates (it's really in
flash memory) from http://www.alphalinux.org/.

Even though our network card is a tulip (DECchip 21040), it is
apparently too old for the tulip driver. Instead we had to use the
de4x5 driver.

Installing Gentoo

From this point, we more or less followed the instructions in the x86
Gentoo Installation guide for configuring the network, setting the
time, creating and mounting filesystems. We used fdisk to partition
the hard drives with a BSD labels. We also made sure we didn't
allocate the first two cylinders to any partition; aboot, the
secondary boot loader, will be written there (see below).

We extracted the stage-1 tarball, chrooted to the new system and
sync'd the portage tree as normal. In make.conf in addition to picking
our preferred USE options, we added 'alpha' and '-x86'. The default
CHOST was "alpha-unknown-linux-gnu" which we kept; and set CFLAGS to
"-mcpu=ev45 -03 -pipe". There is no -march flag for alpha
machines. You can determine your cpu by cat'ing /proc/cpuinfo.

The stage1 and stage2 directions worked as advertised although it did
take quite a while to compile up everything. We set the timezone,
built metalog, and emerged the kernel sources.

Building the Kernel

We used make menuconfig to configure. Under 'General Setup', we set
the 'Alpha system type' to Avanti. /proc/cpuinfo lists your hardware's
system type. We also checked 'Use SRM as bootloader' because we do. We
also compiled in the drivers for our network card (de4x5), and disk
controller (SYM53C8XX) rather than making them be
modules. Interestingly, we originally compiled up the kernel without
VGA console support -- the system would boot and was available via the
network, but nothing at all was displayed on the console after the
kernel got control. Sure it makes sense, but it took a while to figure
out. We also had to enable support for frame buffer devices, and the
TGA driver in particular. With the frame buffer support, the kernel
boot parameter "video=tga:mode:1280x1024,fun:SUN12x22" will let much
more of the boot verbiage be visible.

Even though we configured for an Avanti, there was still a hardwired
gas flag -Wev5 in /usr/src/linux/arch/alpha/Makefile which we changed
to -Wev45. It probably doesn't matter.

Finally one says 'make boot' rather than 'make bzImage' to compile an
alpha kernel; And the resulting image, arch/alpha/boot/vminlux.gz, is
copied to /boot.

We emerge'd aboot, the secondary boot loader. From the user's
perspective, it works a lot like grub. You write it onto the first
part of the hard disk (on the cylinders you reserved when you
partitioned the boot disk) using swriteboot (part of the package) and
then you edit /etc/aboot.conf which contains command line arguments
for various kernels you'd like to boot. Aboot understands ext2/3
filesystems so you can specify kernels by filename.

The system was ready to go. We rebooted, set SRM variables to
autoreload, boot the disk device with aboot installed, and use kernel
line of our choice from /etc/aboot.conf.

Once the system was up and running, we finished the steps in the
installation instructions.

Packages

Unfortunately people seem pretty lax about including the alpha keyword
in their ebuilds. The list of packages we emerged and what
ACCEPT_KEYWORDS had to be specified is attached below. It has,
however, been a delight to "install" some of the less popular, but
much nicer (at least for us) packages such as QMail and Mason and have
them work right out of the ebuild-box. It was so easy, that we also
switched from Bind to djbdns.

Closing

The Gentoo alpha system has been up and running flawlessly for over
two-weeks now: qmail, pure-ftpd, apache, postreqsl, djbdns, and mason.

Package Listing

The ebuilds are grouped by facility. If a token 'x' occurs
after a package name, it means an ACCEPT_KEYWORDS=x had to supplied
for to do the emerge. It should also be noted that a particular
emerge might have needed a keyword because it depended on a package
that required it. The packages are listed roughly in the order we
emerged them.

QMail and friends
qmail ~alpha
ezmlm-idx x86
qmail-pop3d x86
cdb x86
* We compiled and used all these programs on our old RH 7.1 system
several years with no problem. The source code has been very stable
they've been running for two weeks now on our new Gentoo system;
we think they should really be unmasked for 'alpha'

djbdns ~alpha
* This has been flawlessly running now for three weeks. Dan
Bernstein, who also wrote the QMail code, produces solid code; we
feel comfortable recommending that this too be unmasked for
'alpha'.

emacs ~alpha
* This too we've used for years and years on the old system; it
works fine on the new system. Go for 'alpha'.

posgresql
* This required bumping the kernel.shmmax paramater to 41943040 on
our 128K machine in /etc/sysctl.conf

Apache
apache
mod_perl
mod_ssl x86
* mod_ssl is working fine for us at the moment, but we used
apache-ssl on the old system. It should still be upgraded to at
least '~alpha'.

Ftp
vsftpd x86
* vsftpd had no 'alpha' or '~alpha' keyword so we tried 'x86'
Everything compiled perfectly with no errors or even warnings,
however the program didn't work. It would run, but the messages
from clients quickly became garbled. We were in a hurry, so we
just moved on. It should probably stay without any alpha keyword.

pure-ftpd ~alpha
* This compiled and has been working so far. It is even easier to
configure than vsftpd.

ncftp ~alpha
* This too is a program we used on the old system for many years,
and is working fine on the new system. We'd vote for moving it up
to 'alpha'.

Mason
Apache-DBI
DBD-Pg
MIME-tools
IO-Zlib ~alpha
ImageSize ~alpha
DateManip ~alpha
HTML-Mason ~alpha
* Mason is another great system and it so nice to have package for
it. And Emerges beat CPAN any day. Again, we've been using these
things on our old system for years and they are working on the new
system -- they ought to be unmasked to 'alpha'.

Miscellaneous
aspell
aspell-en
curl ~alpha
lynx
ntp
unzip

[taviso]

[twistd roach]

I agree...I've had very good luck with gentoo on the same system. Quite stable too actually.