3.3. PALO management tool usage

Here we will show what can be done with the PALO boot media management tool. For in-depth information about palo usage, we strongly advise you to take a look at PALO's README file, which can be found in palo/ directory on http://cvs.parisc-linux.org/.

For the next two steps, you will need a compiler toolchain, see Section 5.1.

3.3.1. Making a lifimage with RAMDISK

First things first: when should you walk this way?

At an earlier stage of the PA/Linux project, the lifimage was very useful. In fact, simply putting this file in a boot server tree allows you to boot your PA box using the boot lan instruction without any further involvement (see Section 4.3). The main advantage of a RAMDISK is that it unpacks its own file system in RAM, and therefore is completely independent of the machine I/O capabilities (hard drives, etc). The main drawback is that you have to build your own RAMDISK if you have memory constraints or need some customized files. Now, let's see how to obtain a lifimage with RAMDISK.

We assume you got the latest source of the PA/Linux kernel tree (to which we'll refer below as the "linux/ directory"), and that you are somewhat familiar with kernel configuration. Check Section 5.2 for PA-RISC specific options. Mainly, you will need a (cross-)compiler, the linux/ directory and the PALO package installed. If you do not have it, run as root apt-get install palo. Everything can also be found at http://www.parisc-linux.org/. Go through the kernel configuration step. Then, run make palo and if PALO is installed, the following message should appear at the end of the compilation:

A generic palo config file (./palo.conf) has been created for you.
You should check it and re-run "make palo".
WARNING: the "lifimage" file is now placed in this directory by default!
					
So, edit the palo.conf file:

# This a generic Palo configuration file.  For more information about how
# it works try 'palo -?'.
#
# Most people using 'make palo' want a bootable file, usable for
# network or tape booting for example.
--init-tape=lifimage
--recoverykernel=vmlinux

########## Pick your ROOT here! ##########
# You need at least one 'root='!
#
# If you want a root ramdisk, use the next 2 lines
#   (Edit the ramdisk image name!!!!)
--ramdisk=ram-disk-image-file
--commandline=0/vmlinux HOME=/ root=/dev/ram initrd=0/ramdisk

# If you want NFS root, use the following command line (Edit the HOSTNAME!!!)
#--commandline=0/vmlinux HOME=/ root=/dev/nfs nfsroot=HOSTNAME ip=bootp

# If you have root on a disk partition, use this (Edit the partition name!!!)
#--commandline=0/vmlinux HOME=/ root=/dev/sda1
					
As you can see, the RAMDISK mode is the default. The string ram-disk-image-file should give to PALO the path of your RAMDISK file. You shouldn't change anything else to this file. After editing palo.conf, you can run make palo again. The result, a lifimage file, is waiting for you in the linux/ directory.

3.3.2. Making a lifimage with NFSROOT

This method is widely used because the kernel and the file system are directly accessible on your boot server. It is also very easy to test a new kernel. You just have to generate the kernel and put it in the correct directory. When starting up, the PA box will boot the new kernel by typing boot lan in BOOT_ADMIN. Finally, it is the only way to go for systems which I/O devices are not supported (such as E class, by the writing of this document).

Enabling NFSROOT support is easier than RAMDISK. You have to edit palo.conf to specify the boot server IP address instead of the string HOSTNAME. For instance, if your server has 10.10.10.2 as its IP address, then the palo.conf file should contain:

# This a generic Palo configuration file.  For more information about how
# it works try 'palo -?'.
#
# Most people using 'make palo' want a bootable file, usable for
# network or tape booting for example.
--init-tape=lifimage
--recoverykernel=vmlinux

########## Pick your ROOT here! ##########
# You need at least one 'root='!
#
# If you want a root ramdisk, use the next 2 lines
#   (Edit the ramdisk image name!!!!)
#--ramdisk=ram-disk-image-file
#--commandline=0/vmlinux HOME=/ root=/dev/ram initrd=0/ramdisk

# If you want NFS root, use the following command line (Edit the HOSTNAME!!!)
--commandline=0/vmlinux HOME=/ root=/dev/nfs nfsroot=10.10.10.2 ip=bootp

# If you have root on a disk partition, use this (Edit the partition name!!!)
#--commandline=0/vmlinux HOME=/ root=/dev/sda1
					
If you have another IP, this field must be filled in with the correct data. You shouldn't change anything else to this file. After having properly configured palo.conf, you can go into the linux/ directory and issue a make palo. The result, a lifimage file, is as usual waiting for you in the linux/ directory.

For advanced details on NFSROOT management, take a look at Bibliography for the appropriate HOWTOs.

3.3.3. Making a bootable partition

In this part, PALO can be seen as a LILO clone. palo is mainly a program that enables a PA box to boot a kernel present on its hard disk drive. This section is going to explain how to make it work.

After installing the PALO package, a copy of the default palo.conf can be found at /usr/share/doc/palo/palo.conf. We will explain here how to customize it to fit your needs.

To setup a bootable hard disk, you have to partition it properly (that is, if you want to use it as your primary boot device). This implies that this step can only be achieved either if you have already booted a minimal system on your PA-RISC box (from CD or network, see Chapter 4), or if you intend to prepare your hard disk using another computer than the target one (which can be useful to unpack and setup a downloaded file system for a slow box, for example). The point of this HOWTO is not to teach you how to use fdisk and friends, so here are the few things you HAVE TO know:

Warning

Beware! The vmlinux file that will be actually booted has also to be located within the first 2GB of the hard disk. We strongly recommend to either (in the old scheme) create a separate /boot partition at the beginning of the disk (unless you plan to boot recovery kernels every time), or use the new scheme and mount the PALO partition as /boot, because if ever your vmlinux binary gets physically stored past the first 2GB of the disk (like when filling up '/' with data), the box won't boot anymore.

In fact, this third usage of PALO is the most common as the default /etc/palo.conf makes it easy to configure.

3.3.3.1. The old scheme: hidden partition

The hidden partition is deprecated. Don't use this for a new setup. Use the new scheme instead (see Section 3.3.3.2). The hidden partition method is documented for the sake of posterity.

Here is the output of fdisk which represents the hard drive of a box with 16MB PALO space, 128MB swap space and about 1GB '/' partition:


bash# fdisk -l /dev/sda

Disk /dev/sda: 133 heads, 62 sectors, 1017 cylinders
Units = cylinders of 8246 * 512 bytes

	 Device Boot    Start       End    Blocks   Id  System
/dev/sda1   *         1         4     16461   f0  Linux/PA-RISC boot
/dev/sda2             5        34    123690   82  Linux swap
/dev/sda3            35       277   1001889   83  Linux
					

Now let's deal with PALO configuration. Here are the various parameters you can change:

  • recoverykernel is (as the name suggests) the path to the kernel you want to boot within a failsafe session, it will be stored in the 'f0-type' partition.

  • bootloader is the path to the iplboot boot loader utility which is created by PALO when you issue a make iplboot.

    Note

    Usually you don't want to change or even specify this.

  • init-partitioned is used to indicate the pre-partionned device where palo will write its boot parameters. The effect is immediate. It means that PALO is going to write on (and erase the content of) the 'f0' partition of this device, which has to exist.

  • commandline: the first digit is the number of your ext2/ext3 partition where the kernel file is located, as reported by fdisk. Logically, the next string is the absolute path to the kernel from the root of THIS partition [1]. The following space separated parameters (do NOT use any quotation mark!) will be passed to the kernel as its arguments. e.g.: HOME= and TERM= are environmental parameters passed to init when booting. They are not compulsory but they can be useful. root= tells the kernel which partition it must mount as the root file system while booting. It can be tricky when you have more than one disk, and is a mandatory argument. Maximum length for the commandline is 127 characters.

    You can also add console=, to force the designation of the output console. You should remember that console=ttyS0 is for a serial console and console=tty0 is for a STI (graphic) console. Support for the MUX console (if enabled in the kernel, see Section 5.2) has been added, using console=ttyB0. Recent versions of PALO auto detect the right console path (except for MUX), and can figure out whether a 32bit or 64bit kernel should be used. If not, please mail to the mailing list. Last but not least, if you are using Debian 2.6 kernels, you will also need to add initrd=X/path/to/initrd, following the same rules as for the kernel path[1], see above.

According the above fdisk example, we want to use /dev/sda3 as our root partition. Thus, the configuration file should look like that:

# The following arguments are set up for booting from /dev/sda, specifically
# mounting partition 3 as root, and using /boot/vmlinux as both the
# recovery kernel, and the default dynamically-booted kernel.
--recoverykernel=/boot/vmlinux
--init-partitioned=/dev/sda
--commandline=3/boot/vmlinux root=/dev/sda3
						

3.3.3.2. The new scheme: mounted partition

Following is a practical example using the new way of doing things, by using a formatted PALO partition. That scheme should be the preferred one for new installations.

Looking at the previous example (Section 3.3.3.1), very little things need to be changed. Essentially, if you had the need for a separate /boot partition, it will be gone in the scheme detailed below. The configuration for PALO will be a little bit different as well, but that's about it.

Here is the output of fdisk which represents the hard drive of a box with 100MB PALO space (which will be mounted as /boot), 128MB swap space and about 1GB '/' partition (bear in mind that the f0 partition must still be wholy contained within the first 2GB of the disk):


bash# fdisk -l /dev/sda

Disk /dev/sda: 133 heads, 62 sectors, 1017 cylinders
Units = cylinders of 8246 * 512 bytes

	 Device Boot    Start       End    Blocks   Id  System
/dev/sda1   *         1        26    100461   f0  Linux/PA-RISC boot
/dev/sda2            27        36    123690   82  Linux swap
/dev/sda3            37       277    917889   83  Linux
					

Now let's deal with PALO configuration. Contrary to the previous example, there are far less options to put in the configuration file, and the setup is a single step operation: the initialization step, which needs only to be done once.

To initialize for the first time the PALO partition as something the Linux system can understand (ext2 or ext3 filesystem), you need to run the following command (as root):


[user@machine ~/dir]> palo --format-as=N --init-partitioned=target_disk
					

Where N is either 2 for ext2 or 3 for ext3, and target_disk is the device which contains the PALO partition, /dev/sda in the current example. Continuing with this example, assuming we want an ext3 partition we would use:


[user@machine ~/dir]> palo --format-as=3 --init-partitioned=/dev/sda
					

Warning

Do NOT use mkfs or mke2fs to generate the filesystem on this partition. PALO marks blocks as used where the boot loader portion of PALO is stored on disk. These tools don't know about PALO boot loader!

Note

This needs to be run only once for it will erase any existing data on the f0 partition.

Finally, we need to tell PALO about the partition, how we want it to be used, and how we don't want it to be erased everytime PALO is being run. Thus, keeping in sync with our current example, the configuration file should look like that:

# The following arguments are set up for booting from /dev/sda, specifically
# mounting partition 3 as root and booting the vmlinux file in /dev/sda1, palo
# partition formatted as ext3.
--update-partitioned=/dev/sda --format-as=3
--commandline=1/vmlinux root=/dev/sda3
						

As one can see, since we will be storing our kernels directly on the f0 partition, we tell PALO to load them from it (hence the 1 in the commandline argument.

Note

In the previous section (Section 3.3.3.1) we dealt with the init-partitioned parameter. Here, we use update-partitioned instead, which, contrary to the former, tells PALO to not erase the content of the partition when run[2].

Notes

[1]

Example: /boot is mounted from a separate partition, which number is, say, 4 according to fdisk. From a Linux point of view, the absolute path of the file is /boot/vmlinux, but from a partition point of view, it is /vmlinux. Therefore, the commandline will start with "4/vmlinux". We hope that's clear enough!

[2]

The format-as switch is a bit misleading. When used with init-partitioned it is meant to tell which filesystem to format the new partition, but with update-partitioned, it is meant to tell PALO which filesystem is used on the already formatted partition.