Before you start, make sure to back up every file that is now on your system. The installation procedure can wipe out all of the data on a hard disk! The programs used in installation are quite reliable and most have seen years of use; still, a false move can cost you. Even after backing up be careful and think about your answers and actions. Two minutes of thinking can save hours of unnecessary work.
Even if you are installing a multi-boot system, make sure that you have on hand the distribution media of any other present operating systems. Especially if you repartition your boot drive, you might find that you have to reinstall your operating system's boot loader, or in some cases (i.e., Macintosh), the whole operating system itself.
Besides this document, you'll need
dselect Tutorial, and the
Linux for SPARC Processors FAQ.
If your computer is connected to a network 24 hours a day (i.e., an Ethernet or equivalent connection -- not a PPP connection), you should ask your network's system administrator for this information:
If your computer's only network connection is via a serial line, using PPP or an equivalent dialup connection, you are probably not installing the base system over a network. You don't need to worry about getting your network setup until your system is already installed. See Setting up PPP, Section 7.22 below for information on setting up PPP under Debian.
There is sometimes some tweaking to your system that must be done prior to installation. The x86 platform is the most notorious of these; pre-installation hardware setup on other architectures is considerably simpler.
This section will walk you through pre-installation hardware setup, if any, that you will need to do prior to installing Debian. Generally, this involves checking and possibly changing firmware settings for your system. The ``firmware'' is the core software used by the hardware; it is most critically invoked during the bootstrap process (after power-up).
OpenBoot provides the basic functions needed to boot the SPARC architecture. This is rather similar in function to the BIOS in the x86 architecture, although much nicer. The Sun boot proms have a built-in forth interpreter which lets you do quite a number of things with your machine, such as diagnostics, simple scripts, etc.
To get to the boot prompt you need to hold down the Stop key (on older type 4 keyboards, use the L1 key, if you have a PC keyboard adapter, use the Break key) and press the A key. The boot prom will give you a prompt, either ok or >.
You can use OpenBoot to boot from specific devices, and also to change
your default boot device. However, you need to know some details
about how OpenBoot names devices; it's much different from Linux
device naming, described in Device Names in Linux, Section 4.3. Also, the command
will vary a bit, depending on what version of OpenBoot you have. More
information about OpenBoot can be found in the
Sun OpenBoot Reference.
Typically, with newer revisions, you can use OpenBoot device such as
``floppy'', ``cdrom'', ``net'', ``disk'', or ``disk2''. These have
the obvious meanings; the ``net'' device is for booting from the
network. Additionally, the device name can specify a particular
partition of a disk, such as ``disk2:a'' to boot disk2, first
partition. Full OpenBoot device names have the form
In older revisions of OpenBoot, device naming is a bit different: the
floppy device is called ``/fd'', and SCSI disk devices are of the form
disk-lun)''. The command show-devs in newer
OpenBoot revisions is useful for viewing the currently configured
devices. For full information, whatever your revision, see the
Sun OpenBoot Reference.
To boot from a specific device, use the command boot device. You can set this behavior as the default using the setenv command. However, the name of the variable to set changed between OpenBoot revisions. In OpenBoot 1.x, use the command setenv boot-from device. In later revisions of OpenBoot, use the command setenv boot-device device.
Many people have tried operating their 90 MHz CPU at 100 MHz, etc. It
sometimes works, but is sensitive to temperature and other factors and
can actually damage your system. One of the authors of this document
over-clocked his own system for a year, and then the system started
gcc program with an unexpected signal while it
was compiling the operating system kernel. Turning the CPU speed back
down to its rated value solved the problem.
gcc compiler is often the first thing to die from bad
memory modules (or other hardware problems that change data
unpredictably) because it builds huge data structures that it
traverses repeatedly. An error in these data structures will cause it
to execute an illegal instruction or access a non-existent
address. The symptom of this will be
gcc dying from an