Bug#569589: Request for additional kernel modules in D-I for s390
Package: linux-kernel-di-s390-2.6
Version: 0.46
Severity: wishlist
I am requesting that three additional kernel modules be added to the
s390 version of the Debian Installer: vmcp, dasd_fba_mod, and dasd_diag_mod.
I am assuming that vmcp belongs in core-modules-* and the other two belong
in dasd-modules-*; but it is up to you how you want to package it.
When used as a pure installer to install on CKD DASD, these modules are
not needed. However, when used in a "rescue-like" mode to perform system
maintenance, such as copying data to CMS-format disks, these modules
are very useful.
When running in a virtual machine under z/VM, vmcp allows the root user
to issue commands to the CP component of z/VM, the hypervisor which
manages the configuration of the virtual machine that Linux is running in.
For example, the LINK or DETACH commands can be issued to dynamically
add disks to or remove disks from the environment. vmcp is not essential.
The alternative is to issue CP commands via "#CP" on the 3215 virtual console.
But vmcp is a great convenience as it allows CP commands to be issued from,
for example, a remote SSH client session.
dasd_fba_mod is essential to support FBA DASD. The only disk format
supported by the Linux kernel for use on FBA DASD is the CMS disk format,
and parted doesn't support the CMS disk format. Therefore, the installer
cannot install to FBA DASD. But data can be copied to FBA DASD after
installation to CKD DASD. However, when attempting to use the installer
in a rescue-like mode for this purpose, FBA DASD cannot be used, since there
is no dasd_fba_mod kernel module.
dasd_diag_mod is necessary when using the DIAG driver, which can be used
with either CKD DASD or FBA DASD. With CKD DASD, support for the DIAG
driver can be enabled after the fact. But according to "Device Drivers,
Features, and Commands, Development Stream (Kernel 2.6.32)", SC33-8411-04,
Chapter 3, DASD Device Driver, under the heading "Enabling DIAG calls
to access DASDs", the DIAG driver must be in use from the
beginning when it is used with FBA DASD. I quote:
Note: When switching between enabled and disabled DIAG calls on FBA-type
DASD, first re-initialize the DASD, for example, with CMS format or by
overwriting any previous content. Switching without initialization might
cause data-integrity problems.
If the goal is to use the DIAG driver to access data on an FBA DASD, then
the DIAG driver must be used from the beginning when making a file system
or swap space. Thus, when used in a rescue-like mode to perform this type of
system maintenance, kernel module dasd_diag_mod must be available.
I run the "generic" version of the installer, IPLed from the virtual
card reader in a virtual machine under z/VM by running the "DEBIAN EXEC"
script under the CMS operating system.
The way I use the installer to do this type of maintenance is to run the
installer in expert mode (debconf/priority=low), run all the steps of
the installation up through and including the display of the existing
partitions on the existing DASD, exit this menu without making any
partition changes or assigning mount points, (<Go Back>) and drop into
a shell. At that point, modprobe commands on vmcp, dasd_fba_mod, and
dasd_diag_mod all fail.
I do not run in true rescue mode (i.e. the rescue/enable=true
boot parameter is not set) because I do not want the installer to
attempt to mount my normal root partition as "/". I want to copy that
partition and chroot to the copy later. Once I am finished with my
maintenance activities, I type "exit" to return to the installer menu,
then I select "Abort the installation" to shut down.
An example procedure for copying data to CMS-format disks
can be found at http://www.wowway.com/~zlinuxman/diag250.htm. The
specific example here uses a separate server, but the procedure can be
adapted to use the installer in a "rescue-like" mode, provided these
three kernel modules are available. At present, they are not.
Reply to: