52.7. IBM System z: Using initrd as a Rescue System

If the kernel of the SUSEŽ Linux Enterprise Server for IBM System z is upgraded or modified, it is possible to reboot the system accidentally in an inconsistent state, so standard procedures of IPLing the installed system fail. This most commonly occurs if a new or updated SUSE Linux Enterprise Server kernel has been installed and the zipl program has not been run to update the IPL record. In this case, use the standard installation package as a rescue system from which the zipl program can be executed to update the IPL record.

52.7.1. IPLing the Rescue System

[Important]Making the Installation Data Available

For this method to work, the SUSE Linux Enterprise Server for IBM System z installation data must be available. For details, refer to Section “Making the Installation Data Available” (Chapter 2, Preparing for Installation, ↑Architecture-Specific Information) from Architecture-Specific Information. Additionally, you need the channel number of the device and the partition number within the device that contains the root file system of the SUSE Linux Enterprise Server installation.

First, IPL the SUSE Linux Enterprise Server for IBM System z installation system as described in the Architecture-Specific Information manual. A list of choices for the network adapter to use is then presented.

Select 4 Start Installation or System then 3 Start Rescue System to start the rescue system. Depending on the installation environment, you now must specify the parameters for the network adapter and the installation source. The rescue system is loaded and the following login prompt is shown at the end:

Skipped services in runlevel 3:  nfs nfsboot

Rescue login:

You can now login as root without a password.

52.7.2. Configuring Disks

In this state, no disks are configured. You need to configure them before you can proceed.

Procedure 52.3. Configuring DASDs

  1. Configure DASDs with the following command:

    dasd_configure 0.0.0150 1 0
    

    0.0.0150 is the channel to which the DASD is connected. The 1 means activate the disk (a 0 at this place would deactivate the disk). The 0 stands for “no DIAG mode” for the disk (a 1 here would enable DAIG access to the disk).

  2. Now the DASD is online (check with cat /proc/partitions) and can used for subsequent commands.

Procedure 52.4. Configuring a zFCP Disk

  1. To configure a zFCP disk, it is necessary to first configure the zFCP adapter. Do this with the following command:

    zfcp_host_configure 0.0.4000 1
    

    0.0.4000 is the channel to which the adapter is attached and 1 stands for activate (a 0 here would deactivate the adapter).

  2. After the adapter is activated, a disk can be configured. Do this with the following command:

         zfcp_disk_configure 0.0.4000 1234567887654321 8765432100000000  1
        

    0.0.4000 is the previously-used channel ID, 1234567887654321 is the WWPN (World wide Port Number), and 8765432100000000 is the LUN (logical unit number). The 1 stands for activating the disk (a 0 here would deactivate the disk).

  3. Now the zFCP disk is online (check with cat /proc/partitions) and can used for subsequent commands.

52.7.3. Mounting the Root Device

If all needed disks are online, you should now be able to mount the root device. Assuming that the root device is on the second partition of the DASD device (/dev/dasda2), the corresponding command is mount /dev/dasda2 /mnt.

[Important]File System Consistency

If the installed system has not been shut down properly, it may be advisable to check the file system consistency prior to mounting. This prevents any accidental loss of data. Using this example, issue the command fsck /dev/dasda2 to ensure that the file system is in a consistent state.

By just issuing the command mount, it is possible to check whether the file system could be mounted correctly.

Example 52.1. Output of the Mount Command

SuSE Instsys suse:/ # mount
shmfs on /newroot type shm (rw,nr_inodes=10240)
devpts on /dev/pts type devpts (rw)
virtual-proc-filesystem on /proc type proc (rw)
/dev/dasda2 on /mnt type reiserfs (rw)
   

52.7.4. Changing to the Mounted File System

For the zipl command to read the configuration file from the root device of the installed system and not from the rescue system, change the root device to the installed system with the chroot command:

Example 52.2. chroot to the Mounted File System

SuSE Instsys suse:/ # cd /mnt 
SuSE Instsys suse:/mnt # chroot /mnt
   

52.7.5. Executing zipl

Now execute zipl to rewrite the IPL record with the correct values:

Example 52.3. Installing the IPL Record with zipl

sh-2.05b# zipl 
building bootmap : /boot/zipl/bootmap 
adding Kernel Image : /boot/kernel/image located at 0x00010000 
adding Ramdisk : /boot/initrd located at 0x00800000 
adding Parmline : /boot/zipl/parmfile located at 0x00001000 
Bootloader for ECKD type devices with z/OS compatible layout installed. 
Syncing disks.... 
...done
   

52.7.6. Exiting the Rescue System

To exit the rescue system, first leave the shell opened by the chroot command with exit. To prevent any loss of data, flush all unwritten buffers to disk with the sync command. Now change to the root directory of the rescue system and unmount the root device of SUSE Linux Enterprise Server for IBM System z installation.

Example 52.4. Unmounting the File System

SuSE Instsys suse:/mnt # cd / 
SuSE Instsys suse:/ # umount /mnt
   

Finally, halt the rescue system with the halt command. The SUSE Linux Enterprise Server system can now be IPLed as described in Section 3.9.10, “IBM System z: IPLing the Installed System”.