Oops! I accidentally sent the e-mail prematurely. Allow me to continue ...
and (2) it specifies the device driver used for each disk as follows: Device Device Name Driver ---------- ------------- /dev/dasda dasd_diag_mod /dev/dasdb dasd_eckd_mod /dev/dasdc dasd_diag_mod /dev/dasdd dasd_diag_mod I run Debian GNU/Linux in a virtual machine under IBM's z/VM operating system, of course. Otherwise, the DIAG driver cannot be used. The way the module dependencies work, the modules must be loaded in the following order: (1) dasd_mod (no dependencies on another module) (2) dasd_diag_mod (dependency on dasd_mod) (3) dasd_eckd_mod or dasd_fba_mod (both have a dependency on dasd_mod) Although strictly speaking neither dasd_eckd_mod nor dasd_fba_mod have a dependency on dasd_diag_mod, nevertheless dasd_diag_mod must be loaded *before* either dasd_eckd_mod or dasd_fba_mod if a dasd of that type is to use the DIAG driver. To guarantee this I have the following lines in /etc/initramfs-tools/modules: dasd_mod dasd_diag_mod in that order. Neither dasd_eckd_mod nor dasd_fba_mod are listed here, since they are loaded as needed by the hot plug system (i.e. udev). I do not use sysconfig-hardware "touch files" (i.e. /etc/sysconfig/hardware/config-ccw-0.0.0200, /etc/sysconfig/hardware/config-ccw-0.0.0201, etc.), since I have had trouble in the past getting one of these devices varied offline dynamically if they are brought online at boot time via this method. Instead, I bring the devices online at boot time via the dasd option passed to the dasd_mod module via the /etc/modprobe.d/dasd file. All of this has been working flawlessly through a number of releases until now. All of a sudden, nothing works. The boot process times out waiting for the permanent root file system and drops me into an ash shell while the initial RAM filesystem is still mounted as /. I investigated and found that /etc/modprobe.d/dasd was not included in the initial RAM filesystem. That's a problem! Seeing that all other files that were included in /etc/modprobe.d had an extension of .conf, I renamed /etc/modprobe.d/dasd to /etc/modprobe.d/dasd.conf, rebuilt the initial RAM filesystem, re-ran zipl, and rebooted. This time it tried to bring the devices online but got errors of the form: dasd: 0.0.0200 Setting the DASD online failed because of missing DIAG discipline dasd: 0.0.0200: Setting the DASD online failed with rc=-19 0.0.0201 (/dev/dasdb) was the only device that it could get online. I knew immediately what was the cause of this: dasd_diag_mod was not loaded soon enough. By the time it dropped me into an ash shell, dasd_diag_mod was loaded, but at the time that dasd_eckd_mod was trying to bring the devices online, dasd_diag_mod was not loaded. The modules listed in /etc/initramfs-tools/modules must be loaded *before* udev is allowed to do its thing. The message udev: starting version 154 occurs in the log before Begin: Loading essential drivers ... done. To further complicate matters, it appears that the entire /etc/initramfs-tools directory, including /etc/initramfs-tools/modules, is absent from the initial RAM filesystem. How would it even know what modules need to be loaded as "essential drivers" if this file is not present? A new kernel, linux-image-2.6.32-5-s390x, was also included in the upgrade; so perhaps this is part of the problem as well. Previously, I was using linux-image-2.6.32-3-s390x. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1715772729.195258.1274113995407.javamail.r...@md01.wow.synacor.com