Previous Next Table of Contents


7.1 What is SILO ?

SILO (the Sparc Image LOader) is a program running from the PROM on your SPARC machine whose job is to load the operating system. Currently, SILO can load Linux, SunOs or Solaris. It is also capable of loading the Linux kernel from various filesystems - ext2 or UFS.

Another feature of SILO is its ability to create Linux CD-ROMs bootable with the boot cdrom command (this is particularly useful for Linux distributions)

7.2 SILO Installation

Under the boot, etc and sbin subdirs you will find all the programs already compiled and ready to run on UltraLinux. Those three directories should be probably copied to your boot, etc and sbin on your root partition to make things easy. Then you just run /sbin/silo and if /boot doesn't contain the old.b file yet, your old loader (usually SunOs or Solaris) will be copied there and SILO will be installed. Bootblocks will be installed after the label of the disk which contains your second.b and silo.conf (both have to be on the same physical disk), e.g. if second.b is on /dev/sda5 and silo.conf on /dev/sda1, bootblocks will be installed into /dev/sda. In case you are creating a new root file system (e.g. your current root filesystem is nfs and you are setting up an ext2 root filesystem in /mnt), then you should run SILO after installing boot, etc and sbin directories into /mnt/boot, /mnt/etc and /mnt/sbin with the -r parameter, e.g. /mnt/sbin/silo -r /mnt


Due to a bug in some version-2 PROMs, all the files which SILO can load must be below a magic boundary of 1 GB from the start of the disk (not from start of the partition). The easiest way is to put your root filesystem completely inside the first gigabyte (and if you want to boot other OS on the same harddisk, put their root partitions under that boundary as well). Then just make sure you always leave the images you want to boot in those partitions. (To check if a file is safely located, there is a short program called silocheck which takes a file name as its paramater and returns 0 exactly if the file resides below the 1 GB boundary.)

The first loader pumps you into the second one very quickly, printing the letters SILO after some actions have been performed. If it prints only some of these letters and then dies, it means some error occurred, e.g. if it prints SIL it means that it loaded a second stage loader, but with wrong magic. Then SILO prints a boot: prompt. If you give SILO arguments on the PROM command line already, SILO will try to load it (image params). This image can be either a full name (described later), an alias or a label of some image in case you have silo.conf. Otherwise SILO refers to your silo.conf file, which is similar to the x86 lilo.conf with some additions and omissions (some are not needed, others are not implemented). At the boot: prompt, you can:

where the "default" is the image marked as default=image, or the first one. The last option is the only one if you have no silo.conf, and gives you much more freedom at the expense of more typing.

The full image path name depends on the PROM version. We describe versions prior to 2.0 as "old", while 2.0 and later are "new". The old ones have {promname} whereas the newer PROMs have {prompath;}{partition_number}, i.e., the new ones accept

{prompath;}{partition_number}/kernelname {kernel-args}
{prompath;}{partition_number}[beg-end] {args}
whereas the old ones accept
{promname}/kernelname {kernel-args}

{prompath;} and {promname} are optional. If not given, they default to the device specified in the main section of silo.conf (before the first image keyword) or the boot device if none is specified.

With old PROMs, the devices are specified as dev(X,Y,Z) (e.g. sd(0,3,1)) where dev is the device (usually sd), X is the controller, Y is the unit number and Z is the partition number. Note that partitions are numbered from 0, whereas in Linux, partitions which are numbered from 1. (For example, sd(0,3,1) denotes /dev/sda2). Also, note that on many systems the "first" disk (sda) is unit 3.

With new PROMs, the devices are specified in the "open boot PROM" format. For example, /iommu/sbus/espdma/esp/sd@1,0 (terminated by a semicolon) denotes target 1, LUN 0. Then the partition can be specified. If it isn't, it defaults to the partition specified in the optional

line in the main section of silo.conf.

For all PROMs, you specify a path to the image starting with a slash (/), starting for the root of the specified partition. Alternatively, you can load portions of physical disk by typing [B-E] instead of /kernelname where B is the offset of the first 512 byte block to load, and E is the last one. Thus [1-16] will load 7680 bytes starting at offset 512. On newer PROMs, if the partition number is omitted, it defaults to 0, i.e. the whole device.

In all cases, kernel arguments are optional.

During the installation, SILO saves the original boot loader under a user specified file name, so, when SILO prompts for a kernel name it is possible to load the original boot loader, either by adding it to your silo.conf or by typing its path on your SILO command line. Assuming the original boot block is stored in bootold.b/ on partition 4, it can be accessed by having silo.conf containing:

        other = 1
                bootblock = 4/boot/old.b
old PROMs need:
        other = sd(0,3,0)
                bootblock = sd(0,3,3)/boot/old.b
or by typing
bootblock = /boot/old.b
on your SILO command line.

There is a magic image name halt that gets you back to the PROM, and "help" displays some help text.

If you want to uninstall SILO, restore the original blocks by running e.g.

dd if=/boot/old.b of=/dev/sda bs=512 seek=1 count=15

SILO will warn you if there are any problems, but you should make sure that:

You start either the first, or the third (usually the whole disk), or any other partition on cylinder 0 in your partition table. It is highly recommended, that your first partition (sda1) starts on cylinder 0 (beginning of the disk) and that third partition (sda3) is of type WHOLE_DISK and spans the entire disk, as these conventions are frequently assumed. If you do not, you have to make sure that whenever you use fdisk to change a partition which starts at 0 (which usually includes deleted partitions) to something else, you must rerun /sbin/silo on that disk. If you keep sda1 and sda3 starting at offset 0, you don't need to do that.

SILO from 0.6.5 up supports loading of Solaris kernels without using the saved boot loader. Either put into your silo.conf something like

image = 4/kernel/unix
        label = solaris-single
        literal = "-s"
(the name is relative to /platform/your_platform_name_here/ in case of Solaris 2.5+), the keyword solaris says that the kernel needs special handling (otherwise it won't be loaded). On the command line, you can either type solaris anywhere among parameters, or if the name is /kernel/unix , you don't have to type anything. You should have your Solaris ufsboot in either /ufsboot or /platform/your_platform_name_here/ of the partition you're booting Solaris from.

7.3 Creating a bootable CD-ROM

SILO may be used to create a bootable CD-ROM. Currently, it supports booting on Sun4c, Sun4m, Sun4d and Sun4u machines.

A CD-ROM is booted on SPARC by issuing the following commands in the PROM (depending on PROM version - v0 is PROM with major versions 0, found on Sun4c only, v2 is PROM with major versions 2 or 3, found on some newer Sun4c and all Sun4m and Sun4d machines) and the same applies to P1275 PROMs found in the 64-bit UltraSPARC machines:


b sd(0,6,0)


boot cdrom
(cdrom is actually an alias to something like /iommu/sbus/espdma/esp/sd@0,6:d)

As Solaris has different kernels for each architecture, the PROM boots by default from different "partitions" on the CD depending on the architecture of the machine (that's e.g. the :d in the cdrom alias on v2 PROM). That partition table is stored in the first 512 bytes of the CD (with exactly the same format as partition tables on SPARC disks), so you can use the fdisk program to look into that partition table. UltraLinux at the moment uses one kernel image for all architectures and if in the future the need of different kernel images arises, SILO will have other means of supporting it. UltraLinux bootable CD-ROMs have a partition table with only one partition which covers the whole iso9660 image of the CD. Other partitions are set up, so that they start at offset 0 (like the first one) and have size of 0, ie. are disabled. The only value PROM looks at is starting offset, so that it will boot on all machines correctly. In the boot process PROM finds start of the boot partition (in SILO case it is always 0) and loads 7680 bytes from offset 512 in that partition. Fortunately iso9660 has first 32 KB reserved for OS use, so that the partition table and bootblock can be safely stored there. As SILO is longer in size than those 32 KB (even though it is compressed), it puts its first stage loader in there and puts its second stage loader somewhere in the iso9660 filesystem.

That's why the procedure is actually so complicated. First you need to put all the files which will be stored in the iso9660 filesystem in some tree. Run mkisofs or your favourite user interface to it and then let SILO work its magic on the raw iso9660 image. Because SILO doesn't understand the iso9660 format yet (it understands ext2fs and ufs only), it will create a list of block starts for each image you would like to load from the CD (kernel, message text, initial ramdisk image, etc.).

Step by step:

You should first prepare the tree you'd like to have on the CD. The only requirement is that you put boot/* files from the SILO distribution into /boot in the tree, edit the appropriate /etc/silo.conf file in the tree and maybe also put sbin/silo into /sbin/silo in the tree, so that users get the same version of SILO which created the CD.

To edit /etc/silo.conf in the tree, you should know which files you would like SILO to load at run-time from the CD. This includes executable images (like the Linux kernel), messages (for use with message= option in silo.conf - these messages are displayed when SILO comes up), initial ramdisk images. (Note that SILO will be still able to load images which the user has on disks, so you shouldn't include them.) You should put these names in a list and assign them tags from !cd1 to !cd30.

Let's say you will need to load the following files during run-time:


Then the files get tags like this:

!cd1 = /boot/vmlinux-2.1.89.gz
!cd2 = /etc/welcome.msg
!cd3 = /boot/initial.ramdisk.gz
!cd4 = /boot/vmlinux-smp-2.1.89.gz
!cd5 = /boot/vmlinux-2.1.92.gz

Now you edit the silo.conf file as you need. The only difference between the usual on-disk silo.conf and silo.conf on the CD is that you replace all the paths to files on the CD (and their PROM disk paths) with their respective tags. The files you would like to load from the user's disks can be described in the same way, but it is usually not a wise idea to do so. The location of the user's disks differs from machine to machine and you cannot use the default boot-on disk, as the boot-on disk is the CD, so you don't know which disk will be root for the user. If the user desires so, he'll still be able to use the SILO command line.

Here is an example how a silo.conf may look like:


Refer to the detailed description below for more information on the format of silo.conf.

The next step is to make the iso9660 filesystem (either on a raw partition, such as /dev/sdb1, or into a file (e.g. ~/sparcbootable.iso). How to do this is outside the scope of this document, there are many programs which can do it. You can use the CDWtools, which is a shell and dialog interface to mkisofs and related programs.

If you have the iso9660 raw image in a file, the kernel should support the loopback device and you should have the losetup utility somewhere available. Then you should mount the iso9660 image somewhere and run sbin/silo with the following arguments:

-r /mount_point_of_iso9660_image -c /raw_iso9660_image 
-l comma,separated,list,of,files,you,used,in,silo,conf,as,!cdX,from,1,to,last,number,used

Examples for the above shown list of SILO loadable files and with iso9660 raw image on raw partition /dev/sdb1:

/sbin/mount /dev/sdb1 /mnt
sbin/silo -r /mnt -c /dev/sdb1 -l /boot/vmlinux-2.1.89.gz,/etc/welcome.msg,\
/sbin/umount /mnt

The same for iso9660 image on ~/sparcbootable.iso

/sbin/losetup /dev/loop0 ~/sparcbootable.iso
/sbin/mount /dev/loop0 /mnt
sbin/silo -r /mnt -c ~/sparcbootable.iso -l /boot/vmlinux-2.1.89.gz,/etc/welcome.msg,\
/sbin/umount /mnt
/sbin/losetup -d /dev/loop0

This step performs the following:

Now it's time to burn the CD, cross your fingers and see what happens.

7.4 Command line options

-r root_path

Change root to root_path before performing any actions.

-i primary

Use primary as the first stage loader (instead of /boot/first.b)

-b secondary

Use secondary as the second stage loader (instead of /boot/second.b)

-C config

Use config as the configuration file (instead of /etc/silo.conf. The file must reside on the same physical disk (not necessarily the same partition) as the second stage loader.

-S backup

Save old bootblock into file backup.

-s backup

Save old bootblock into file backup if it doesn't exist yet

-o backup

Save old bootblock into file backup if it doesn't exist yet and sdX1 doesn't start on cylinder 0.

-p PROM-ver

Force PROM version to PROM-ver (0 or 2). By default, SILO tries to auto-detect the PROM version.


Always overwrite the bootblock.


Print the PROM device name of the bootblock to stdout.


Show SILO version.

-c image

Use image as the device/file image for bootable CD-ROM preparation.

-l file1, file2, ...

Map file1 to !cd1, file2 to !cd2, etc. (up to !cd30) for references in the silo.conf file. If -r is used, the files are meant relative to root_path, otherwise relative to the current directory. This should be used only in conjuction with the -c and -r options.


Force CPU type to UltraSPARC


Force CPU type to non-UltraSPARC

7.5 silo.conf format

The silo.conf file contains variable assignments with the following syntax:

/etc/lilo.conf begins with a possibly empty global options section. Many global options can also be set from the command line, but storing permanent options in the configuration file is more convenient.

Global options:


Sets the name of the device (e.g. a hard disk partition) that contains the boot sector. If DEVICE is omitted, the boot sector is read from (and possibly written to) the device that is currently mounted as root.


Defines the partition on which files will be searched for.


Uses the specified image as the default boot image. If DEFAULT is omitted, the image appearing first in the configuration file is used.


Specifies the number of tenths of a second SILO should wait before booting the first image. This is useful on systems that immediately boot from the hard disk after enabling the keyboard. SILO doesn't wait if TIMEOUT is omitted or if TIMEOUT is set to zero.


Specifies a file containing a message that is displayed before the boot prompt. No message is displayed while waiting for a modifier key ([Shift], etc.) after printing "SILO ". In the message, the 0xFF character ([Ctrl L]) clears the local screen. The size of the message file is limited to 65535 bytes. The map file has to be rebuilt if the message file is changed or moved.


Prints the message string before loading the kernel image.


Waits for a keypress before loading the kernel image.

Additionally, the kernel configuration parameters APPEND, INITRD, RAMDISK, READ-ONLY, READ-WRITE, ROOT and the general per-image options LOCK, OPTIONAL, PASSWORD, RESTRICTED, and SINGLE-KEY can be set in the global options section. They are used as defaults if they aren't specified in the configuration sections of the respective images. See below for a description.

Per-image options:

(the following options apply to the preceding image)


Specifies a second name for the current entry.


By default, SILO uses the main file name (without its path) of each image specification to identify that image. A different name can be used by setting the variable LABEL.

Each (kernel or non-kernel) image description begins with a special variable which is followed by optional variables. The following variables can be used for all image descriptions that describe a Linux kernel:


Appends the options specified in string to the parameter line passed to the kernel. This is typically used to specify parameters of hardware that can't be entirely auto-detected, e.g.

     append = "hd=64,32,202" 


Specifies the file that will be loaded at boot time as the initial RAM disk.


like APPEND, but removes all other options (e.g. setting of the root device). Because vital options can be removed unintentionally with LITERAL, this option cannot be set in the global options section.


Specifies the size of the optional RAM disk. A value of zero indicates that no RAM disk should be created. If this variable is omitted, the RAM disk size configured into the boot image is used.


Specifies that the root file system should be mounted read-only. Typically, the system startup procedure re-mounts the root file system read-write later (e.g. after fsck'ing it).


specifies that the root file system should be mounted read-write.


Specifies the device that should be mounted as root. If the special name CURRENT is used, the root device is set to the device on which the root file system is currently mounted. If the root has been changed with -r , the respective device is used. If the variable ROOT is omitted, the root device setting contained in the kernel image is used. It can be changed with the rdev program.

All kernel per-image options but LITERAL can also be set in the global options section as defaults for all kernels.

If one of RAMDISK, READ-ONLY, READ-WRITE or ROOT is omitted from the configuration file and the corresponding value in the kernel image is changed, SILO or the kernel will use the new value.

Previous Next Table of Contents