 |
Installation Instructions, Part 3: A New World
Unless you edited /mnt/etc/passwd above, the root password is
still blank. (Which has security implications, of course, but if
you didn’t know that sort of stuff you wouldn’t have read this far.)
 Your new system has a JTL
directory at /usr/src/jtl, and your previous collection of archives in
/archive. You’ll probably want to start by rebuilding the base
packages, optimised for your CPU (recall that those on the install CD
were optimised for i386). In /usr/src/jtl, type “make base” (which
remakes everything that came on the installation CD). JTL will
optimise for your CPU by default, you don’t need to set JTL_ARCH.
If JTL doesn’t work out
how to optimise for your CPU (which is likely, for instance, if you
have an Athlon or Duron) you can override the default optimisations by
setting JTL_ARCHFLAGS in /etc/jtl.conf (see the Makefile for how that
works).
If you rebuild init or
glibc (which “make base” does), don’t forget to run “telinit -u”, or
rc.shutdown won’t be able to cleanly unmount /.
The basic installation
includes only enough programs to compile the rest of the system: if
anything could possibly be left out and compiled later, it has
been. So once you’ve recompiled the base packages, you should start
adding to your collection of tarballs, and making further packages:
- If you didn’t go “make base” then you need to
“make gcc”, as the one on the installation CD is a C compiler
only, not C++.
- “make kde” might be a popular choice, or “make evolution galeon”,
or both. Making KDE takes 17.5 hours on a Celeron 366, or about
two weeks on a Sun Ultra 1.
- You’ll almost certainly want packages such as man, time,
which, nfs-utils, apache, console-data, perl and python.
- For a server you might also want imapd, samba, exim,
and procmail.
- There’s a good amount of audio/video stuff in JTL,
including amarok, lame, mplayer, transcode, and ogle.
Alternative Installation Methods
Bootable NFS root: As well as the i386.iso CD image, the
“make sub” procedure described above leaves you with a directory
i386-root, which is suitable for use as a bootable NFS root. It
also sets you up a /tftpboot directory, using PXELinux, suitable
for most BIOS “network boot” settings. In order not to overwrite
any existing settings, it sets it up under i386-root, so
you’ll want to copy that to the right place on your boot server.
See the PXELinux/SysLinux web pages for more on NFS booting, which
would double the size of this document if I described it all here.
Once you’ve got it working, you can go on to Part 3 of the standard
instructions.
Chroot jail: To see what life would be like on a JTL system,
you could visit one temporarily by “chroot i386-root /bin/sh”. This
is also handy for testing new JTL makefiles, i.e. seeing whether they
specify enough dependencies to build correctly on an “empty” system.
JTL-for-non-x86: Everything described so far assumes that
your Linux machine is x86-based. And, indeed, that’s the only
platform that making JTL install CDs has been tested on. But in
theory, it should work for other architectures too; that’s the
big advantage of compiling from sources. A machine of any architecture
should be able to compile a native JTL for another machine of the same
architecture.
JTL-for-sparc32: JTL has one further
trick up its sleeve. If, instead of “sub” you make
“sparc-bootstrap”, JTL will attempt to cross-compile a Sparc Linux
bootable root from x86.
(It builds an x86-to-sparc32 cross-compiler first.) This means
that JTL-for-x86 can be contagious to sparc32-based
machines (such as the Sparcstation 4, but not Ultrasparcs), in a kind of
species-jump vCJD kind of
a way. Again, this leaves you with the barest minimum of software
(not even an editor, this time) and you should be prepared to spend a
considerable time compiling before you have a usable system.
The bootable sparc32 root
is left in the directory “sparc-root”. Currently the only way to get a
Sparcstation to boot it, is via NFS boot. You’ll need to set up rarpd,
tftpd, and NFS on your server; various web
pages will help with that, but note that the “rarp” command
doesn’t work on modern Linuxes, and you really do need to use rarpd
and /etc/ethers. Copy the “sparc-root” directory to
/tftpboot/<sparcstation-IP-address> on your server. Then
just type “boot net” at the Sparcstation’s PROM prompt. Once you’ve
got NFS booting working, JTL can make all the tools (silo, elftoaout)
that you’ll need to install Linux to boot from the Sparcstation’s
winchester.
Stop me if I’m bragging, but the
very first time I tried cross-compiling a sparc32 userland and
NFS booting it, the whole hella thing came all the way up multiuser. How cool is
that?
Sparc32 hardware that was the stuff
of dreams when I were a lad, is now available for essentially no money on Ebay.
It’s a cheap and stylish way to test software portability to big-endian
platforms, though the performance that wowed us back in the days of sun3,
seems really quite feeble nowadays.
JTL-for-sparc64: The “sparc64-bootstrap” target works like
“sparc-bootstrap”, but for 64-bit Ultrasparc-based machines (Ultra 1,
and most if not all subsequent Sun gear). The userland is wholly
64-bit, which makes this port a teensy bit experimental (X and glibc
need patches to even compile).
The userland is left in the
directory “sparc64-root”, and needs to be NFS-booted by the Ultrasparc in the
same way as described for sparc32 above.
Sparc64 hardware such as
the Ultra 1 and Ultra 2 can be had for under fifty pounds on
Ebay, though even machines like the Ultra 5 -- scarcely usable in
today’s terms -- still go for real
money. Again, it’s useful for testing software portability to
big-endian LP64 platforms.
JTL-for-alpha: The “alpha-bootstrap” target works like
“sparc-bootstrap”, but for machines based on the DEC Alpha. This was the most
recent target I got booting, and not all packages build yet.
The userland is left in the
directory “alpha-root”, and needs to be NFS-booted by the Alpha in the
same way as described for sparc32 above.
The JTL
holotype for Alpha is a DEC Multia using a 166MHz 21066. These are
so feeble that they’ve dropped off the bottom of Ebay: I saw a dual-CPU
533MHz 21164 going for under £30 the other day. Alpha is important,
though, as it “completes the square” of all four target
combinations of 32 and 64-bit, little and big-endian.
JTL-for-ARM: The “arm-bootstrap” target works like
“sparc-bootstrap”, but for ARM-based machines such as Empegs and
RiscPCs. GCC has known bugs on ARM and will not compile certain
packages unless optimisation is turned off (you might want to edit the
JTL Makefile on your x86 machine first). This doesn’t currently
work -- the userland builds successfully, but all its binaries
segfault when run on an actual RiscPC.
The toolchain built is a
soft-float one.
JTL-for-powerpc: Currently this target is just
theoretical, and the compiled userland hasn’t been tested. Again,
you’d start out by NFS-booting it. Early IBM RS/6000
powerpc32 gear can easily be had from Ebay – though some RS/6000 kit
comes in the same cases as IBM 486 PCs from the same era, and so doesn’t look
anything like as cool as the obviously-not-a-PC sparc and alpha boxes.
Building from Cygwin: You’re a sick man for even thinking of it.
But you might be able to get it to work. Try it.
When The Kernels Don’t Work, They Just Make It Worse
The “.config” files for the kernels used for bootable CDs and for NFS
booting, are kept in the jtl/patches directory. To edit them (perhaps
to add more SCSI drivers, or drivers for an ISA network card):
tar xzf linux-2.4.18.tar.gz
cd linux
cp jtl/patches/linux-2.4.18-config-bootable-cd .config
make oldconfig
make menuconfig (or xconfig or whatever)
make oldconfig
cp .config ../jtl/patches/linux-2.4.18-config-bootable-cd
But It Doesn’t Have Program Foo, Which I Use Every Day
So figure out how to compile and install it, and send me a
Makefile so I can integrate it into the next version of JTL.
If you’re a vi user, you’ll have to figure out how to compile
and install vi using only xemacs. Ha ha, de ha ha, har.
Programs which can be installed by a simpleminded “untar ;
configure; make; su; make install” only need very simple
Makefiles, as most of the work is done by the generic “_gnu”
target; look at Make.pkgconfig for an example. Note that JTL
installs everything to /usr by default, not /usr/local.
JTL does have patches for a few particularly vital or
intransigent programs, but try to avoid relying on a patch when
adding further packages to JTL. Patches get out-of-date quickly,
whereas evilness in Makefiles (and some of the existing ones,
particularly ncurses, are tangibly evil) tends to be more durable.
If you submit a Makefile, I’d appreciate it if you donated that
Makefile to the public domain (rather than claiming copyright
on it), as I have done with all the Makefiles I wrote.
Special Prize For The Package Whose Build System Caused Most Grief
Awarded to ncurses.
Licensing And Legal Issues
JTL will build many different packages, which between them have
many different licences. It is up to you to obtain and use those
packages in accordance with those licences. Just because JTL
includes a makefile for a given package, doesn’t mean you’re
necessarily allowed to build or use it.
For example, JTL will build libdvdcss for you, if you have
obtained a libdvdcss source tarball and if you tell JTL to build
it (or a package which depends on it). JTL itself contains no
CSS code whatsoever, nor links to where any may be found. Only
if you already have it, will JTL be able to build it.
As another example, JTL will build several packages which are
capable of reading or writing GIF images using LZW compression.
If you live in a country where software patents are enforceable,
then you may require a patent licence from Unisys to obtain or
use any of these packages. JTL itself contains no LZW code
whatsoever.
As a third example, JTL will build several packages which use
“strong crypto”. Such packages may be illegal to export, or
require a special government permit, or may even be illegal
to own at all. JTL itself contains no cryptographic code
whatsoever.
Those parts of JTL which I did write -- the Makefiles, and
one or two (not all) of the patches -- are placed in the public
domain. As a request (not a demand), if you use them for
anything else, it’d be nice if you mentioned somewhere that your
creation was based on, or included, parts of JTL.
Other Projects That Are, Frankly, Pretty Similar To JTL
If Sourceror Linux, Gentoo Linux, or Linux From Scratch had been around when I
started, I might not have bothered. Gentoo, in particular, has
a lot more packages than I do. But I believe they all still have a binary
download for the installation CD, and I don’t believe they can cross-compile
themselves.
 All Rites Reversed --
Copy What You Like |
