1.6 2005-02-14
Silicon Graphics Machines -- Setting Up Arcboot Installing arcboot

Previously in this guide, we showed you how to make a kernel, then copy it to the volume header using dvhtool. There were two main flaws with this system:

  • This is not supported on all SGI systems
  • It requires a significantly larger volume header

In order to boot the machine, a bootloader, arcboot was developed for this purpose. Instead of putting the kernel directly into the volume header, we leave it in /boot (which resides on a EXT2/3 partition), and tell arcboot (which sits in the volume header in place of the kernel) where to find it. So our first step, is to emerge some tools that we'll use later... 

# emerge dvhtool arcboot

That should have installed two tools, arcboot which sits in the volume header and loads kernels for us, and dvhtool which helps us put arcboot into the volume header.

The magic binary we want, hides in /usr/lib/arcboot -- on IP22 systems (Indy, Indigo 2, Challenge S), it'll be called arcboot.ip22. Other systems should be similar. We first copy this file into the volume header. 

# dvhtool --unix-to-vh /usr/lib/arcboot/arcboot.ip?? arcboot

We then verify the presence of the file in the volume header. 

# dvhtool --print-volume-directory
----- directory entries -----
Entry #0, name "linux", start 4, bytes 3262570
Entry #1, name "newlinux", start 6377, bytes 7619627
Entry #3, name "arcboot", start 21260, bytes 51448
#
You'll notice that in my case, I've got two old kernels sitting around there, linux and newlinux. This is a hangover from before we started using arcboot. Their presence doesn't matter -- just so long as arcboot is present, everything is fine. Configuring arcboot

If you've ever set up the Linux Loader (lilo) before, you'll find that arcboot employs a similar syntax in its configuration file. Bear in mind though; arcboot expects to find its configuration file existing on an EXT2/3 partition as /etc/arcboot.conf. The easiest way around this is to make sure /boot is an EXT2/3 partition and that there's a file called arcboot.conf inside the /boot/etc directory. An example config can be found in /etc/arcboot.conf.sample 

(Create the /boot/etc directory)
# mkdir /boot/etc

(Put our configuration into the target directory)
# cp /etc/arcboot.conf.sample /boot/etc/arcboot.conf

(Create a symlink back to /etc)
# ln -s /boot/etc/arcboot.conf /etc/arcboot.conf

(... and a symlink in /boot pointing to itself)
# (cd /boot; ln -s . boot)

You can then edit /etc/arcboot.conf to your own preference. Personally, I prefer to set up two kernel images: new, a freshly built image that may or may not work; and working, a proven trustworthy kernel image. My arcboot.conf looks a bit like this. 

# arcboot.conf
#
# copyright 2002 Guido Guenther <agx@sigxcpu.org>
#
label=working
        image=/vmlinux
        append="root=/dev/sda3"

# backup version
label=new
        image=/vmlinux-new
        append="root=/dev/sda3"

Once that is set up, there's then just some little tweaks that you need to do within the SGI PROM to make this magic work. This is covered in, not the next section (that's for Cobalt servers) but the following section Rebooting the System.

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 limit on kernels. The current size of Linux 2.4 makes it damn near 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.

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. 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. 

# 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. 

# 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. 

#:CoLo:#
mount hda1
load /vmlinux-working.gz
execute root=/dev/hda3 ro console=ttyS0,115200
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 is the configuration I use on my Cobalt server: 

#:CoLo:#

lcd "Mounting hda1"
mount hda1
menu "Which Kernel?" 50 Working working New new
lcd "Loading Linux" {menu-option}
load /vmlinux.gz.{menu-option}
lcd "Booting..."
execute root=/dev/hda5 ro console=ttyS0,115200
boot

The above script asks the user which kernel he/she would like to boot (either New or Working), then loads vmlinux.gz.new or vmlinux.gz.working depending on the selection. If a selection is not made within 5 seconds (50/10ths of a second) it boots the first option.

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.

Those who do have the luxury of a supported framebuffer 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: 

# 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. 

# 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. 

(/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
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. 

# exit
cdimage ~# cd
cdimage ~# umount /mnt/gentoo/boot /mnt/gentoo/proc /mnt/gentoo
cdimage ~# reboot
Cobalt Users: The rest of this section covers the setting up of the SGI PROM so that it boots arcboot 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
Tweaking the SGI PROM

When you are rebooted, go to the System Maintenance Menu and select Enter Command Monitor (5). If you want to test your new Gentoo installation, you can just run boot -f <kernel name>. To have your system permanently boot into the Gentoo installation, you need to set some variables in the SGI PROM: 

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.

(<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>

(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

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