> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
