System i is somewhat different from System p and JS20 in that earlier System i systems used a different kernel and had a different boot mechanism. Power5 and later System i systems effectively work like a System p box - it uses the same kernel, the same device drivers, and boots the same way.
This page will give some of the differences between Power5 System i (i5) and earlier models of System i (such as the Power4 825 or earlier 270s) and serve as an archive of FAQs for the earlier models (Pre-Power5).
What's different between Power5 and earlier models of System i?
Lots of things. First, linux on the i5 uses the pSeries kernel. Second, with no primary partition and using an HMC, the LPAR fucntions at least seem different. Third, many of the device drivers are different - instead of the viodasd, viocd, etc, you use a vscsi driver that everything is based off. Fourth, only R5R3 runs on the i5, which has some of it's own differences.
What do you mean, pSeries kernel?
The i5 runs the same kernel as used on the p5, and earlier pSeries models. The reason is that the hypervisor from the old iSeries and the old pSeries is now converged, and instead of running the LPAR functions from a primary partition, an HMC is used. So the partitions look more like a pSeries linux partition. You'll most notice this when you see the Open Firmware messages on the console as you boot your partition.
So to run linux on the i5 now, a at least passing knowledge of Open Firmware is a good thing. For more information on Open Firmware, see:
How did the device drivers change?
Instead of having a separate device driver for each type of virtual resource, there is a single virtual scsi driver that they're all based on. This is the ibmvscsic driver that shows up in your lsmod.
The vscsi driver doesn't include the virtual ethernet drivers. For virtual ethernet, the driver has separated into two different drivers: iseries_veth for all iSeries models before POWER5, and ibmveth, which is for all POWER5 machines.
The ibmvscsic and ibmveth modules are not just used on iSeries anymore - this virtualization technology can now be used on p5, too.
Why do I have these reservation conflict messages in my logs?
If you see a number of messages like this in your /var/log/messages file and dmesg:
sr 1:1:1:0: reservation conflict.
sr 1:1:1:0: reservation conflict.
sr 1:1:3:0: reservation conflict.
sr 1:1:3:0: reservation conflict.
Then you have a CD/DVD drive(s) that is available through vscsi but the device is varied off. You can work around this in either of two ways: Ensure all optical devices are varied on (wrkcfgsts *dev) or restrict those optical devices from your Linux partition.
Note that both regular optical devices and virtual (ie, ISO catalogs) are included in this.
Pre-Power5 (270, 825, etc) System i FAQs
What is this talk about the A and B slots?
The boot terminology may seem familiar to OS/400 gurus - the same basic ideas are behind it. You have 4 slots or sides per partition - labeled A, B, C, and D. Each of these slots (except D) can contain a kernel and a command line, and to boot Linux you must have a kernel in at least one. These slots are roughly equivalent to entries in a lilo.conf file, and similarly you select one and then have a program load it and start it. In the case of Linux on iSeries, that program is the hypervisor which also does much more.
What's the Linux IPL boot process?
The OS/400 hosting partition keeps four special areas of memory for each of its guest partitions. These memory areas are labeled A through D and are used to hold boot images (when working with Linux, "boot image" and "kernel image" are equivalent). Each slot or image has two parts, the kernel and the cmdline (command line, containing the boot parameters). Whenever a Linux partition is started, either by an IPL (varying on) or a reboot command issued inside the Linux partition, the Linux partition uses the contents of these IPL slots to boot the guest partition. The contents will also remain the same even after a reinstall of Linux unless you or the install program explicitly changes them. The IPL slots are not in the memory of the Linux partition, so the contents remain even when the partition is varied off. These slots are accessible from the Linux partition through the /proc/iSeries/mf interface.
A Linux partition can be varied on from the hosting partition using a boot image from either the A, B, or C slots, depending on the circumstances. You can set a NWSD to either boot directly from the A or B slots, or from a PReP partition or a stream file.
When the IPL source is set to NWSSTG, the OS/400 hosting partition searches the guest partition's storage for a bootable PReP boot partition. It transfers the entire contents of this PReP partition to the C slot, and uses the C slot as the boot image. Similarly, if the IPL source is STMF, the OS/400 hosting partition loads the contents of the stream file into the C slot and uses the contents of the C slot as the boot image. In the case of both NWSSTG and STMF vary ons, the text in the IPL Parameters field of the NWSD is copied into the cmdline part of the C side.
The A and B sides use the text in the A or B cmdline part of the slot for a command line. This is accessible through the proc interface on Linux, or through option '14' in the 'Work with Partition Configuration' screen in SST. Similarly, the kernel is also accessed directly form the A or B slot. The D slot is reserved for special purposes.
Where should I put my kernel?
First, your distribution may use the kernel slots slightly differently. In that case, follow your distribution's recommendations, because their documentation and tools will be designed to work with their customization of the slots.
Remember that the A and B sides are specific to a LPAR (Logical Partition) configuration, not a NWSSTG. The A and B sides are not saved on an OS/400 save file save of a NWSD/NWSSTG. Additionally, the A and B sides (the kernel and the command line) are not automatically deleted or changed if you reinstall Linux, unless you or your distribution's install program explicitly does so (most distributions do this, or give you the option to have this done). Note that besides having different kernels in the different slots, you can also (or instead) have different command lines in different slots.
Slot A: Use this slot for known good kernels or a recovery image. When an test kernel fails, you will still have a good kernel image ready here (and possibly other places, too). It's common for distributions to put a recovery command line here.
Slot B: Use this slot for testing new kernels. If the test kernel fails, change IPL source to A or NWSSTG and vary on the guest partition to return to a good Linux kernel. If the untested kernel succeeds, you may also copy it to A and/or the PReP boot partition.
Slot C: If your IPL Source is NWSSTG or STMF, OS/400 will load a kernel and command line (from the NWSD IPL Parameters) into the C slot, and then boot that. Let the OS/400 hosting partition use this slot for loading kernels from NWSSTG or stream files.
Slot D: Reserved (don't use).
PReP boot: This is a good place to keep a known good kernel or the kernel from the original install since it's part of the NWSSTG. Keep in mind that the PReP boot command line is set in the NWSD screen, and would be shared with an IFS (STMF) kernel, and so needs to be manually maintained.
IFS (STMF): This is a good place to store copies of your kernels, because you can actually 'see' the kernels, and you can store multiple different kernel (with different names) in IFS. You can also easily maintain several NWSDs running the same kernel by booting them all off the same kernel in IFS.
Advanced users: Since the kernel and command line in the C slot are replaced every time you IPL your NWSD, this is a great place to try a test kernel - if it fails, just Vary Off/On the partition. See the examples below for more details.
Can we use the reboot command in Linux to restart our partition?
Yes, you can use the reboot command from Linux to restart (reboot) Linux. However, when a reboot command is issued in Linux, an IPL does not occur and OS/400 does not realize the reboot took place. Check 'General background/What are the advantages of using OS/400 V5R2, from a Linux perspective?' for details on where a reboot is appropriate, compared to an IPL. To specify which IPL slot should be the boot image, the file /proc/iSeries/mf/side is used. This file simply contains the name of the IPL slot to use to reboot the system: 'A', 'B', 'C', or 'D'. Remember if you did not originally IPL using NWSSTG or STMF there is not going to be a kernel in the 'C' slot.
Examples (must be root) of rebooting with different kernels:
Situation: We have IPL'd the Linux partition from NWSSTG and want to reboot using the same kernel.
- cat /proc/iSeries/mf/side
C
- reboot
Situation: We have IPL'ed the Linux partition from NWSSTG. We have compiled a new kernel and already put it in the A slot (this process described below). Now we want to boot using this new kernel to see if it works.
- echo 'A' > /proc/iSeries/mf/side
- reboot
Situation: We have IPL'd the Linux partition from the B side. We have just downloaded a kernel and installed it to the /boot directory. We now want to load it to the C slot and reboot using it so we can see if it works:
- dd if=/boot/vmlinux.new of=/proc/iSeries/mf/C/vmlinux bs=4k
532+1 records in
532+1 records out
- cat /proc/cmdline > /proc/iSeries/mf/C/cmdline
- echo "C" > /proc/iSeries/mf/side
- reboot
Note: We used bs=4k, which sets the transfer block size to 4k. Since the default transfer block size is 1 byte, this is much faster! 4k is the largest supported block size.
Note: Remember that you also need associated modules in /lib/modules. That is generally true of any Linux kernel, not just iSeries specific ones.
Situation: We have IPL'ed from NWSSTG. We want to use that same kernel to boot up into a maintenance mode:
- cat /proc/cmdline
root=/dev/hda1
- echo "root=/dev/hda1 single" > /proc/iSeries/mf/C/cmdline
- echo "C" > /proc/iSeries/mf/side
- reboot
(In this specific situation the second command is only precautionary, side should already be set to C.)
What about putting a kernel into NWSSTG?
After a kernel has been verified to work properly, it's a very good idea to back it up to NWSSTG. That way, if a system failure occurs and the IPL slots in memory are lost, you may still IPL the guest partition from NWSSTG and get a good kernel. Run 'fdisk -l' to check that which is your PReP boot partition and that it's set bootable (a bootable partition is marked by an asterisk, use the 'a' in fdisk command to set it active). You write the kernel to the PReP boot partition much like you would to a slot, with the dd command.
Example:
Situation: Our PReP boot partition is the second partition on the first drive. We have a known good kernel and want it on the virtual disk so we can IPL from NWSSTG:
- fdisk -l
Disk /dev/hda: 255 heads, 63 sectors, 1275 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 1 1148 9221278+ 83 Linux
/dev/hda2 1149 1263 923737+ 82 Linux swap
/dev/hda3 * 1264 1265 16065 41 PPC PReP Boot
- dd if=/boot/vmlinux.good of=/dev/hda3 bs=4k
532+1 records in
532+1 records out
Note: Make sure you are dd'ing to the correct (PReP boot) partition! To see which is your PReP partition from Linux, run the command 'fdisk -l'. The PReP partition is the one of type PReP (or type 0x41).
The kernel slots /proc/iSeries/mf/<A|B|C>/vmlinux have write-only permission on current kernels - do not use these as inputs.
Notice also that we used bs=4k, which sets the transfer block size to 4k. Since the default transfer block size is 1 byte, this is much faster! 4k is the largest supported block size.
Why did my dd fail?
Did you use a block size greater than 4k? 4k is the largest supported block size on 2.4 kernel based distros, such as SLES8 and RHEL3.
Why is my dd so slow?
Do you have small fractions of processors on the primary and/or the Linux partition? Having small processor amounts on these partitions will affect the speed of the dd to the slots.
