Gentoo Linux Handbook Page --

1. Silicon Graphics Machines -- Setting Up arcload

On SGI machines, we use the arcload boot loader. In previous releases, we also provided arcboot, however it has been officially declared obsolete, in favour of arcload.

Note: The SGI volume header filenames are limited to 8 characters, and there may be no more than 16 files contained in a single volume header.

Installing arcload

arcload was written for machines that require 64-bit kernels, and therefore can't use arcboot (which can't easily be compiled as a 64-bit binary). It also works around peculiarities that arise when loading kernels directly from the volume header. So, now you know what this is about, we can proceed with the installation:

Code Listing 1.1: Merging arcload and dvhtool

# emerge arcload dvhtool

Once this has finished, you should find the arcload binary in /usr/lib/arcload. Now, two files exist:

sashARCS: The 32-bit binary for Indy, Indigo2 (R4k), Challenge S and O2 systems
sash64: The 64-bit binary for Octane/Octane2, Origin 200/2000 and Indigo2 Impact systems

Use dvhtool to install the appropriate binary for your system into the volume header:

Code Listing 1.1: Placing arcload in the volume header

(Indy/Indigo2/Challenge S/O2 users)
# dvhtool --unix-to-vh /usr/lib/arcload/sashARCS sashARCS

(Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000 users)
# dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64

Note: You don't have to use the name sashARCS or sash64, unless you are installing to the volume header of a bootable CD. For normal boot from hard-disk, you may name them something else if you wish.

Now just use dvhtool to verify they are in the volume header.

Code Listing 1.1: Checking arcload is present in the volume header

# dvhtool --print-volume-directory
----- directory entries -----
Entry #0, name "sash64", start 4, bytes 55859
#

Now, the arc.cf file has a C-like syntax. For the full detail on how one configures it, see the arcload page on the Linux/MIPS wiki. In short, you define a number of options, which you enable and disable at boot time using the OSLoadFilename variable.

Code Listing 1.1: An example arc.cf

# ARCLoad Configuration

# Some default settings...
append  "root=/dev/sda3";
append  "ro";
append  "console=ttyS0,9600";

# Our main definition. ip28 may be changed if you wish.
ip28 {
        # Definition for a "working" kernel
        # Select this by setting OSLoadFilename="ip28(working)"
        working {
                description     "SGI Indigo2 Impact R10000\n\r";
                image system    "/working";
        }

        # Definition for a "new" kernel
        # Select this by setting OSLoadFilename="ip28(new)"
        new {
                description     "SGI Indigo2 Impact R10000 - Testing Kernel\n\r";
                image system    "/new";
        }

        # For debugging a kernel
        # Select this by setting OSLoadFilename="ip28(working,debug)"
        # or OSLoadFilename="ip28(new,debug)"
        debug {
                description     "Debug console";
                append          "init=/bin/bash";
        }
}

Starting with arcload-0.5, arc.cf and kernels may reside either in the volume header, or on a partition. If you wish to utilise this newer feature, you may instead place the files in your /boot partition (or / if your boot partition is not separate). arcload uses the filesystem driver code from the popular grub bootloader, and thus supports the same range of filesystems.

Code Listing 1.1: Placing arc.cf and kernel in the volume header

# dvhtool --unix-to-vh arc.cf arc.cf
# dvhtool --unix-to-vh /usr/src/linux/vmlinux new

With this done, now all that's left is to set some options in the PROM. See the section on Rebooting the System.

1. Cobalt MicroServers -- Setting Up CoLo

Installing CoLo

On Cobalt servers, these machines have a much less capable firmware installed on chip. The Cobalt BOOTROM is primitive, by comparison to the SGI PROM, and has a number of serious limitations.

There's a 675kB (approximate) limit on kernels. The current size of Linux 2.4 makes it nearly impossible to make a kernel this size. Linux 2.6 is totally out of the question.
64-bit kernels are not supported by the stock firmware (although these are highly experimental on Cobalt machines at this time)
The shell is basic at best

To overcome these limitations, an alternative firmware, called CoLo (Cobalt Loader) was developed. This is a BOOTROM image that can either be flashed into the chip inside the Cobalt server, or loaded from the existing firmware.

Note: This guide will take you through setting up CoLo so that it is loaded by the stock firmware. This is the only truly safe, and recommended way to set up CoLo.

Warning: You may, if you wish, flash it into the server, and totally replace the original firmware -- however, you are entirely on your own in that endeavour. Should anything go wrong, you will need to physically remove the BOOTROM and reprogram it yourself with the stock firmware. If you are not sure how to do this -- then DO NOT flash your machine. We take no responsibility for whatever happens if you ignore this advice.

Okay, with the warnings over now, we'll get on with installing CoLo. First, start by emerging the package.

Code Listing 1.1: Emerging colo

# emerge colo

With that installed (I hope you read those messages ;-) you should be able to look inside the /usr/lib/colo directory to find two files, colo-chain.elf: the "kernel" for the stock firmware to load, and colo-rom-image.bin: a ROM image for flashing into the BOOTROM. We start by mounting /boot and dumping a compressed copy of colo-chain.elf in /boot where the system expects it.

Code Listing 1.1: Putting CoLo in its place

# gzip -9vc /usr/lib/colo/colo-chain.elf > /boot/vmlinux.gz

Configuring CoLo

Now, when the system first boots up, it'll load CoLo which will spit up a menu on the back LCD. The first option (and default that is assumed after roughly 5 seconds) is to boot to the hard disk. The system would then attempt to mount the first Linux partition it finds, and run the script default.colo. The syntax is fully documented in the CoLo documentation (have a peek at /usr/share/doc/colo-X.YY/README.shell.gz -- where X.YY is the version installed), and is very simple.

Note: Just a tip: when installing kernels, I usually create two kernel images, kernel.gz.working -- a known working kernel, and kernel.gz.new -- a kernel that's just been compiled. You can either use symlinks to point to the curent "new" and "working" kernels, or just rename the kernel images.

Code Listing 1.1: A basic default.colo

#:CoLo:#
mount sda1
load /kernel.gz.working
execute root=/dev/sda3 ro console=ttyS0,115200

Note: CoLo will refuse to load a script that does not begin with the #:CoLo:# line. Think of it as the equivalent of saying #!/bin/sh in shell scripts.

It is also possible to ask a question, such as which kernel & configuration you'd like to boot, with a default timeout. This configuration does exactly this, asks the user which kernel they wish to use, and executes the chosen image. vmlinux.gz.new and vmlinux.gz.working may be actual kernel images, or just symlinks pointing to the kernel images on that disk. The 50 argument to select specifies that it should proceed with the first option ("Working") after 50/10 seconds.

Code Listing 1.1: Menu-based configuration

#:CoLo:#

lcd "Mounting sda1"
mount sda1
select "Which Kernel?" 50 Working New

goto {menu-option}
var image-name vmlinux.gz.working
goto 3f
@var image-name vmlinux.gz.working
goto 2f
@var image-name vmlinux.gz.new

@lcd "Loading Linux" {image-name}
load /{image-name}
lcd "Booting..."
execute root=/dev/sda5 ro console=ttyS0,115200
boot

See the documentation in /usr/share/doc/colo-VERSION for more details.

1. Setting up for Serial Console

Okay, the Linux installation as it stands now, would boot fine, but assumes you're going to be logged in at a physical terminal. On Cobalt machines, this is particularly bad -- there's no such thing as a physical terminal.

Note: Those who do have the luxury of a supported video chipset may skip this section if they wish.

First, pull up an editor and hack away at /etc/inittab. Further down in the file, you'll see something like this:

Code Listing 1.1: inittab Configuration

# SERIAL CONSOLE
#c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102

# TERMINALS
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

# What to do at the "Three Finger Salute".
ca:12345:ctrlaltdel:/sbin/shutdown -r now

First, uncomment the c0 line. By default, it's set to use a terminal baud rate of 9600 bps. On Cobalt servers, you may want to change this to 115200 to match the baud rate decided by the BOOT ROM. This is how that section looks on my machine. On a headless machine (e.g. Cobalt servers), I'll also recommend commenting out the local terminal lines (c1 through to c6) as these have a habit of misbehaving when they can't open /dev/ttyX.

Code Listing 1.1: Example snippet from inittab

# SERIAL CONSOLE
c0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102

# TERMINALS -- These are useless on a headless qube
#c1:12345:respawn:/sbin/agetty 38400 tty1 linux
#c2:12345:respawn:/sbin/agetty 38400 tty2 linux
#c3:12345:respawn:/sbin/agetty 38400 tty3 linux
#c4:12345:respawn:/sbin/agetty 38400 tty4 linux
#c5:12345:respawn:/sbin/agetty 38400 tty5 linux
#c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Now, lastly... we have to tell the system, that the local serial port can be trusted as a secure terminal. The file we need to poke at is /etc/securetty. It contains a list of terminals that the system trusts. We simply stick in two more lines, permitting the serial line to be used for root logins.

Code Listing 1.1: Enabling root logins on serial console

(/dev/ttyS0 -- the traditional name for the first serial port)
# echo 'ttyS0' >> /etc/securetty

(Lately, Linux also calls this /dev/tts/0 -- so we add this
too)
# echo 'tts/0' >> /etc/securetty

1. Rebooting the System

Exit the chrooted environment and unmount all mounted partitions. Then type in that one magical command you have been waiting for: reboot.

Code Listing 1.1: Exiting the chroot, unmounting all partitions and rebooting

# exit
cdimage ~# cd
cdimage ~# umount /mnt/gentoo/boot /mnt/gentoo/dev /mnt/gentoo/proc /mnt/gentoo
cdimage ~# reboot

Note: Cobalt Users: The rest of this section covers the setting up of the SGI PROM so that it boots arcload off disk and loads Linux. This is not applicable to the setup of Cobalt servers. In fact, all your work is done -- there is no configuration needed for the first boot up, you can skip to the next section: (Finalising your Gentoo Installation)

1. Tweaking the SGI PROM

Setting generic PROM settings

Now that you've installed the bootloader, you're ready to reboot the machine.

Code Listing 1.1: Rebooting

(Exit the chroot environment)
# exit

(Unmount the drives)
# umount /mnt/gentoo/boot
# umount /mnt/gentoo

(Reboot)
# reboot

When you are rebooted, go to the System Maintenance Menu and select Enter Command Monitor (5) like you did when you netbooted the machine.

Code Listing 1.1: Configuring the PROM to Boot Gentoo

1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor

Option? 5
Command Monitor. Type "exit" to return to the menu.

(Set some options for arcload)

(Provide the location of the Volume Header)
>> setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)

(Automatically boot Gentoo)
>> setenv AutoLoad Yes

(Set the timezone)
>> setenv TimeZone EST5EDT

(Use the serial console - graphic adapter users should have "g" instead of "d1" (one))
>> setenv console d1

(Setting the serial console baud rate. This is optional, 9600 is the          )
(default setting, although one may use rates up to 38400 if that is desired.  )
>> setenv dbaud 9600

Now, the next settings depend on how you are booting the system.

Settings for direct volume-header booting

This is covered here for completeness. It's recommended that users look into installing arcload instead.

Note: This only works on the Indy, Indigo2 (R4k) and Challenge S.

Code Listing 1.1: PROM settings for booting off the volume header

(<root device> = Gentoo's root partition, e.g. /dev/sda3)
>> setenv OSLoadPartition <root device>

(To list the available kernels, type "ls")
>> setenv OSLoader <kernel name>
>> setenv OSLoadFilename <kernel name>

(Declare the kernel parameters you want to pass)
>> setenv OSLoadOptions <kernel parameters>

If you wish to try a kernel without messing with kernel parameters, you may do so using the boot -f PROM command:

Code Listing 1.1: Booting without changing environment variables

(Booting a kernel, "new", with additional options)
# boot -f new root=/dev/sda3 ro

Settings for arcload

arcload uses the OSLoadFilename option to specify which options to set from arc.cf. The configuration file is essentially a script, with the top-level blocks defining boot images for different systems, and inside that, optional settings. Thus, setting OSLoadFilename=mysys(serial) pulls in the settings for the mysys block, then sets further options overridden in serial.

In the example file above, we have one system block defined, ip28 with working, new and debug options available. We define our PROM variables as so:

Code Listing 1.1: PROM settings for using arcload

(Select arcload as the bootloader:- sash64 or sashARCS)
>> setenv OSLoader sash64

(Use the "working" kernel image, defined in "ip28" section of arc.cf)
>> setenv OSLoadFilename ip28(working)

Starting with arcload-0.5, files no longer need to be placed in the volume header -- they may be placed in a partition instead. To tell arcload where to look for its configuration file and kernels, one must set the OSLoadPartition PROM variable. The exact value here will depend on where your disk resides on the SCSI bus. Use the SystemPartition PROM variable as a guide -- only the partition number should need to change.

Note: Partitions are numbered starting at 0, not 1 as is the case in Linux.

Code Listing 1.1: Telling arcload where to find arc.cf

(If you wish to load from the volume header -- use partition 8)
>> setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(8)

(Otherwise, specify the partition and filesystem type)
>> setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(0)[ext2]

All Done

Now you're ready to enjoy Gentoo! Boot in your Gentoo installation and finish up with (Finalizing your Gentoo Installation).

Updated May 2, 2008

Donate to support our development efforts.