If you are self hosted on PA-RISC/LInux you should already have
palo on your system. Assuming you have apt configured
you can always run "apt-get update; apt-get install palo" to
obtain the latest released version.
If you need to build palo yourself, especially if you are cross-compiling on x86, skip to the end of this document. |
$ palo \ -c "5/vmlinux HOME=/ TERM=linux console=tty" \ -k path/to/vmlinux \ -I /dev/your-disk
On a self-hosted system, you can accomplish the same thing by placing
the following into /etc/palo.conf:
--commandline=5/vmlinux HOME=/ TERM=linux console=tty --recoverykernel=/boot/vmlinux --init-partitioned=/dev/your-diskand running palo. |
-k path/to/vmlinux designates a kernel to be stored along with the boot loader in the "F0" partition. You can omit this if you want, since you'll usually be booting a kernel from an ext2 partition instead. I like to have a kernel there just in case the ext2 one is lost for some reason. I call it a recovery kernel.
-c 5/vmlinux must be changed for your situation. The number, 5, is the partition number of your ext2 partition as reported by fdisk, the same number you use when you mounted the partition (e.g., "mount /dev/sdb5 /mnt"). "/vmlinux" is the path to your kernel executable within your ext2 partition. The special partition number "0" is used to load the "recovery" kernel which you placed into the "F0" partition with -k.
-I /dev/your-disk tells palo to initialize the palo boot parameters on the drive rather than preserving any existing parameters.
Use 'palo -?' or 'palo --help' for more information.
You now have a partitioned bootable disk, try it!
There is no need to run palo when you change the kernel in your ext2 partition because it is located dynamically by the palo boot loader when you boot. However there are probably some tasks which will again require palo.
Once you have a partitioned bootable disk, palo can be used to change the default command line or kernel or boot loader. The most common task is probably changing the "recovery" kernel:
The update (-U) feature is currently disabled, perhaps permanently. The usual method for maintaining your disk is to edit /etc/palo.conf and rerun palo. |
---|
./palo -k path/to/vmlinux -U /dev/your-diskor command line:
./palo -c "new command line" -U /dev/your-diskWhich will normally be done in a self-hosted environment by editing /etc/palo.conf and re-running palo. Hopefully you won't need to use palo very often.
./palo -k path/to/vmlinux \ -b iplboot \ -c '0/vmlinux ....' \ -C your-iso-image
-C tells palo to prepare a CD-ROM image. 'iplboot' and 'path/to/vmlinux' must be exactly the same files (same contents) you previously copied into the future root file system or palo will fail. I usually point those paths at the exact files in the directory from which I mastered the CD just to be sure.
CD-ROM support at the moment is a bit of a hack. Here's how it works.
palo currently treats CD-ROM as an unpartitioned sequential medium like tape or bootp. Unlike other unpartitioned media, there is no room to store the kernel and bootloader (iplboot) near the start of the (ISO-standard) medium, so palo requires you to put those files into the ISO file system. HP boot firmware requires the boot loader (iplboot) to be a multiple of 2k in length and be stored contiguously on a 2k boundary. Luckily the ISO file system meets all these criteria except for the mod-2k length, which is achieved by padding iplboot. The palo bootloader (iplboot) requires requires the kernel to be stored contiguously (except when booting from ext2), and the ISO file system works well for this too.
When you run palo, it locates the boot loader and kernel (optionally ramdisk) files in the ISO file system by doing a raw search through the ISO image. That's why the files in the ISO file system, and those named on the palo command line must be identical. Once found, pointers to those files are stored in the appropriate places in the boot headers.
Ideally palo and the boot loader would both understand the ISO file system, but that'll take more investment than I'm interested in supplying. If anyone pursues this, note that I've had good luck leveraging code from aboot, one of the Alpha boot loaders. I recommend starting with the ISO code from aboot-0.6 or later.
It may be possible to place a MS-DOS partition table on a CD-ROM therefore having an "F0" partition as on a hard disk, but I don't feel confident this would be understandable by, say, a Windows box.
The boot media management tool is called palo, just as on x86 the LILO boot media management tool is called lilo, though it's worth noting that palo doesn't usually need to be used every time you build a new kernel, as lilo does.
Offset (hex) Contents Why 0 0x80 These two bytes denote 1 0x00 a LIF volume to HP firmware f0-f3 IPL_ADDR disk offset to beginning of boot "IPL" loader. Must not be zero. Must be a multiple of 2kbytes. Big endian. f4-f7 IPL_SIZE Size of boot loader in bytes. Must be a multiple of 2kbytes. Big endian. f8-f11 IPL_ENTRY Offset from the beginning of the boot loader to its entry point. This really better be a multiple of 4bytes. Big endian. 1b0-1ff P-TABLE DOS partition table, managed by fdisk.Information about the kernel, command line, and ramdisk, is sandwiched between the LIF magic number and the IPL_ADDR. Check out struct firstblock in common.h for the details. The boot program must be located within the first 2 Gb of the boot medium (a limitation of older machines, which might not be permanent).
palo works with both un-partitioned (usually sequential) media such as tapes, and partitioned (usually random-access) media such as disks. The media format for un-partitioned media is described first since it is a subset of the format for partitioned media. In the remaining discussion, the term sequential is synonymous with un-partitioned, and random-access is synonymous with partitioned media. This restriction is not present in the palo software however.
On unpartitioned media, the partition table shown in the previous figure is unused and set to values which will not be mistaken for a partition table. The boot loader program is stored starting at 2kbytes from the beginning of the medium and is followed by the kernel file and optional ramdisk file.
On partitioned media, which is usually random-access, for example disks, the boot loader program must be stored in an area protected from disk management software, and often cannot be located at the first 2kbyte boundary as on sequential media. palo therefore places the boot loader, and optionally a kernel and ramdisk, in a special partition, created by fdisk, of type F0. HP-UX firmware requires the boot program to be stored on the boot medium starting on a multiple of 2kbytes, whereas the F0 partition might start on a 512-byte sector boundary. The boot program starts within the F0 partition on the first 2k boundary, which may be up to 3 sectors from the start of the partition.
The format of the boot loader, kernel, and ramdisk are identical to the sequential case except that some padding is added in order that somewhat larger kernels and boot loaders can be added later without re-writing the rest of the F0 partition (this feature may not yet be supported by palo however).
On partitioned media, palo can load a kernel from any ext2-formatted partition which falls within the first 2G of the medium, in addition to having a "sequential" kernel, perhaps best seen as a recovery kernel, within the F0 partition.
You can use "make DESTDIR=/ install" to install palo in the normal location. On x86 the cross compilers are usually in "/opt/palinux" so I use "make DESTDIR=/opt/palinux install". Note that the palo executable goes into "DESTDIR/sbin" which you may want to add to your $PATH.
Palo can also be built in the normal way as a Debian package though it cannot be cross-compiled as a Debian package.