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 1, “GCC compiler”.
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 3, “Booting from network”).
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 2, “Kernel configuration” 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.
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.
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, Available boot solutions), 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:
A partition entirely contained within the first 2GB of your target device has
to be of partition type 'f0',
which is the reserved partition type for PALO boot loader.
There are two ways to use PALO: the old scheme (available on all versions),
in which that partition will only store configuration and recovery kernel;
and the new scheme (available since PALO 1.5), in which that partition will
be formatted as ext2 or ext3 and mounted in /boot.
In the first case, the partition does not need to be huge. This is were PALO will save its configuration, recovery kernel(s) - about 5MB each - and optional recovery ramdisk, so 32MB seem far sufficient.
Alternatively, in the second case, since you will use it as
/boot, you should size it decently.
100MB is a good cut.
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.
The hidden partition is deprecated. Don't use this for a new setup. Use the new scheme instead (see Section 3.3.2, “The new scheme: mounted partition”). 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.
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
[3].
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 2, “Kernel configuration”)
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[3], 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
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.1, “The old scheme: hidden partition”), 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
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!
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.
In the previous section (Section 3.3.1, “The old scheme: hidden partition”) 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[4].
[3] 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!
[4] 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.