6.5. S/390, zSeries: Using initrd as a Rescue System

If the kernel of the SUSE LINUX Enterprise Server for S/390 and zSeries 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.

6.5.1. IPLing the Rescue System

[Important]Making the Installation Data Available

For this method to work, the SUSE LINUX Enterprise Server for S/390 and zSeries installation data must be available. For details, refer to the chapter Making the Installation Data Available 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 S/390 and zSeries installation system as described in the Architecture-Specific Information manual. A list of choices for the network adapter to use is then presented.

Select 0 for no network. The installation program terminates and the following messages are printed:

Example 6.1. Output for No Network Adapter Selected

 
*** OK, NETWORK ACCESS WILL _NOT_ BE AVAILABLE. ***


You should be able to login via telnet/ssh now.
To restart network setup, enter:

netsetup

To continue the installation, enter:

./inst_source

bash: no job control in this shell
SuSE Instsys suse:/ #

This opens a root shell from which to issue all necessary commands directly.

6.5.2. Loading DASD Modules

To access the root device, load the required kernel modules. First, load the DASD modules. They consist of a middle layer module, dasd_mod, and a low-level module depending on the DASD type. Here, ECKD devices are assumed, so the module is called dasd_eckd_mod. The dasd_mod module requires the channel ranges of the DASDs to access (e.g., 0150) as an argument. The modules are loaded with the commands:

Example 6.2. Loading DASD Modules

 
SuSE Instsys suse:/ # insmod dasd_mod dasd=0150
Using /lib/modules/version/kernel/drivers/s390/block/dasd_mod.o
dasd: initializing...
debug: dasd: new level 3
dasd: Registered successfully to major no 94
dasd: initialization finished
SuSE Instsys suse:/ # insmod dasd_eckd_mod
Using /lib/modules/version/kernel/drivers/s390/block/dasd_eckd_mod.o
dasd(eckd): ECKD discipline initializing
[ ... ]
Partition check:
 dasda:VOL1/  0X0150: dasda1 dasda2
dasd(eckd): We are interested in: CU 3880/00
dasd(eckd): We are interested in: CU 3990/00
dasd(eckd): We are interested in: CU 2105/00
dasd(eckd): We are interested in: CU 9343/00

If the line Partition check is printed, all modules have been loaded properly and the DASD device is now available for mounting.

6.5.3. Mounting the Root Device

If the modules have loaded correctly, 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 6.3. 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)

6.5.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 6.4. chroot to the Mounted File System

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

6.5.5. Executing zipl

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

Example 6.5. 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

6.5.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 S/390 and zSeries installation.

Example 6.6. 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 system can now be IPLed as described in Chapter 1.7.11. “S/390, zSeries: IPLing the Installed System”.