Bug#486549: The single partition present on a CMS minidisk is not supported (s390/s390x only)
> All the above is complete Greek too me because I don't
> have any context.
>
> And it sounds like you already did the hard part: you
> managed to get it
> working. That means you are the expert now. Tell us *in
> detail* what is
> missing and what manual steps were required to get it
> supported. Then
> *maybe* someone will step up and do the actual integration.
>
Here is my DASD configuration. All devices are 3390 ECKD minidisks
in a virtual machine under z/VM:
vdev format and intended usage
---- ---------------------------------------------------------------
0200 CMS FORMATted and RESERVEd minidisk - to be mounted as /
0201 cdl minidisk - to be mounted as /boot
0202 CMS FORMATted and RESERVEd minidisk - to be mounted as /home
0203 CMS FORMATted and RESERVEd minidisk - to be used as a swap disk
0200, 0202, and 0203 were FORMATted and RESERVEd in advance under the CMS
operating system with a block size of 4096 bytes. 0201 was not formatted.
I got along just fine until the step "Partition Disks". During the
previous step, "Configure DASD", I selected the four devices listed
above, but I told it NOT to format 0200, 0202, and 0203, lest the CMS
formatting be destroyed. I DID tell it to format 0201; so it ran
dasdfmt on that device.
When I got to the "Partition Disks" screen, here is what I saw:
----------
┌────────────────────────┤ [!!] Partition disks ├─────────────────────────┐
│ │
│ This is an overview of your currently configured partitions and mount │
│ points. Select a partition to modify its settings (file system, mount │
│ point, etc.), a free space to create partitions, or a device to │
│ initialize its partition table. │
│ │
│ Help on partitioning │
│ │
│ DASD 0.0.0200 (ECKD) - 1.5 GB s390/zSeries DASD │
│ DASD 0.0.0201 (ECKD) - 55.3 MB s390/zSeries DASD │
│ > 55.2 MB FREE SPACE │
│ DASD 0.0.0202 (ECKD) - 368.6 MB s390/zSeries DASD │
│ DASD 0.0.0203 (ECKD) - 368.6 MB s390/zSeries DASD │
│ │
│ Undo changes to partitions │
│ Finish partitioning and write changes to disk │
│ │
│ <Go Back> │
│ │
└─────────────────────────────────────────────────────────────────────────┘
<Tab> moves between items; <Space> selects; <Enter> activates buttons
----------
As you can see, the installer recognized the free space on 0201; so the
installer can create a cdl partition on this minidisk with fdasd. But
the implicit partitions associated with the CMS minidisks are not
recognized. Therefore the installer cannot create a file system on them
or assign a mount point.
Now, how did I circumvent this? Well, there's more than one way to skin
a cat. One way is to install to regular cdl minidisks, then copy the data
manually to CMS minidisks once the install is finished. It works, but it
requires almost twice as much disk space, takes a lot of time to copy the
data, and is error prone. I have recently worked out a better way,
as documented below:
Run the installer in expert mode. After you have invoked the "Partition
disks" step and seen the above screen, tab to "Go Back" and press Enter.
(Do not skip this step! Some important utilities are downloaded when you
select "Partition disks" that you are going to need, even though the step
does not complete.) When you get back to the installer main menu, select
"Execute a shell" and press Enter. At the shell prompt, type the
following command:
cat /proc/dasd/devices
This gives you the association between DASD device addresses and Linux
device nodes. In the following discussion, I will assume that 0200
corresponds to dasda, 0201 corresponds to dasdb, 0202 corresponds to
dasdc, and 0203 corresponds to dasdd. Now issue the following commands:
mke2fs -j -b 4096 -L TLS200 /dev/dasda1
fdasd -a -l TLS201 /dev/dasdb
mke2fs -j -b 4096 -L TLS201 /dev/dasdb1
mke2fs -j -b 4096 -L TLS202 /dev/dasdc1
mkswap /dev/dasdd1
mkdir /target
mount -t ext3 /dev/dasda1 /target
mkdir /target/boot
mount -t ext3 /dev/dasdb1 /target/boot
mkdir /target/home
mount -t ext3 /dev/dasdc1 /target/home
swapon /dev/dasdd1
exit
and resume the install. Skip the "Partition disks" step and select
"Install the base system" as the next step. The installer will complain
that this step depends on the "Partition disks" step, which has not
completed. Tab to "Go Back" and press Enter. The installer will complain
again. Again tab to "Go Back" and press Enter. After the second
"Go Back" the installer will proceed with installing the base system,
even though a prerequisite step was bypassed.
>From here on out, execute the steps in sequence up through (but not
including) "Finish the installation". When you reach this point,
run "Execute a shell" again.
>From the shell prompt, create the file /target/etc/modprobe.d/dasd using
the nano editor. The file should look like this:
options dasd_mod dasd=0.0.0200-0.0.0203
This file forces the dasd_mod module to bring these four devices online
first and to assign them the first four available device names: dasda
for 0200, dasdb for 0201, dasdc for 0202, and dasdd for 0203. If you
want to use the high performance dasd driver for CMS minidisks
(dasd_diag_mod), the file should look like this instead:
options dasd_mod dasd=0.0.0200(diag),0.0.0201,0.0.0202-0.0.0203(diag)
This performs the same function as above but also specifies that devices
0200, 0202, and 0203 are to use the dasd_diag_mod device driver.
This driver can only be used for CMS minidisks; so 0201 is not included.
Note that the /boot partition cannot be a CMS minidisk. (Not yet anyway.)
The dasd_diag_mod driver can only be used when Linux is running as a VM
guest. However, if you're using CMS minidisks, you're probably running
as a VM guest. How else would you get CMS minidisks?
Next, use the nano editor to edit /target/etc/fstab. Create a file that
looks like this:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/dasda1 / ext3 defaults,errors=remount-ro 0 1
/dev/dasdb1 /boot ext3 defaults 0 2
/dev/dasdc1 /home ext3 defaults 0 2
/dev/dasdd1 none swap sw 0 0
If you want to use the high performance dasd_diag_mod driver, you have two
more files to edit: /target/etc/initramfs-tools/modules and
/target/etc/modules. List the following three modules in order from top
to bottom:
dasd_diag_mod
dasd_eckd_mod
dasd_mod
The order is important. The order in /target/etc/initramfs-tools/modules
doesn't really matter, but the order in /target/etc/modules is crucial.
If you list the modules in the wrong order, you won't be able to mount
the permanent root file system. If you don't want to use the
dasd_diag_mod driver you don't have to edit these two files. Now type
chroot /target
update-initramfs -k all -u -v
The "-k all" switch means update all installed initrd images in /boot.
At this point you should only have one, but it is a good practice to
request an update of all of them whenever a significant file changes.
update-initramfs will automatically re-run zipl after
it finishes rebuilding the initial RAM disk image.
Now type
exit
exit
to return to the installer main menu. The first "exit" exits the
shell created by chroot. The second "exit" returns to the installer
main menu. Now run the "Finish the installation" step.
The installer will complain that
"Partition Disks" has not been run. Tab to "Go Back" and press Enter.
The installer will run "Finish the installation" anyway. On the
"Installation complete" pop-up menu, press Enter with the cursor on
"<Continue>" (the default). Your network console will lose connectivity
and your system will halt. Now switch back to the virtual machine
console and type
#CP IPL 0201
to IPL the new system's /boot partition.
Note: last time I checked, the dasd_diag_mod module is not available in
stock etch kernels (2.6.18). Recent stock lenny kernels (2.6.24)
do have it.
To use the dasd_diag_mod module in etch, you must build a custom kernel
and enable the use of this module during kernel configuration.
I attended a Linux for System z installation class last week. We installed
the Suse distribution. Suse's installer supports CMS minidisks and the
dasd_diag_mod driver just fine. It would be nice if the Debian installer
did too.
However, while I'm comparing installers, I would like to say one thing.
I am very glad that Debian's installer is curses-based instead of
graphical. Suse's installer is graphical. And I hate it! A graphical
installer for a mainframe just doesn't make sense. It's a tremendous
amount of overhead, and it's totally
unnecessary. You can burn expensive mainframe cycles like nobody's
business by just moving the mouse around all day! Debian's installer
only requires an SSH client. It's very efficient, and very effective.
I hope you stick to this architecture! Don't listen to those whiners
who want a graphical installer. It would be a big development effort
with no real benefit, especially for a mainframe. I believe in the KISS
philosophy: Keep It Simple, Stupid!
> But even better: run the installer at medium priority,
> figure out exactly
> what needs to happen in which phase, add that in manually
> and see if it
> works. Send us the resulting patches.
>
> More than 90% of the installer is shell script! Which means
> it has an
> extremely low barrier of entry. If you run into a step that
> is performed
> by something that is not shell, fine: tell us what should
> be happening at
> that point. But even then it should often be possible to
> create a
> temporary solution by using some shell code around or next
> to the C
> program.
>
> Here is some solid basic info that can help you get started
> with the
> installer: http://d-i.alioth.debian.org/doc/internals/
>
Not only do I not know C, but I've never written a shell script --
not even so much as a "Hello World!" program. I REALLY don't think you
want me working on the Debian installer as my first-ever shell script.
I have some programming experience in other languages and on other
platforms. But I am a complete novice when it comes to shell scripts.
On Linux, I'm an end user, a system administrator, and an installer.
But I'm not a programmer.
Based on my experience in the Linux for System z installation class
last week, it appears to me that, for all practical
purposes, Suse is the de-facto "IBM distribution" for Linux for System z.
IBM officially supports Red Hat and Suse. But everyone in the class
ran Suse at their shop and no-one ran Red Hat. The general consensus
of the system programmers is that Red Hat support on the System z platform
is very poor. Some installations used to run Red Hat, but when they
couldn't get Red Hat to fix problems in a timely manner, they switched to
Suse. IBM's proprietary software which is written for Linux on System z
is available only in rpm format. And of course, no source code is
available.
That means that System z shops which run Debian are probably going for an
all-open-source solution. Which is good. But those shops are in the
minority right now. It takes a while for the corporate culture to shift.
Reply to: