On Mon, May 17, 2010 at 12:33:15PM -0400, Stephen Powell wrote: > 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.
you can use modprobe config here again see man modprobe.conf and the softdep line. > 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. it is necessary nowadays to have udev running when people put modules in there due to firmware requirements. thus you cannot rely on initramfs-tools second guessing module requirements anymore indeed. > 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? no it is, just the location is a bit unusual conf/modules. > 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. that should be fine, but again i'm not a s390 porter, so not familiar with this specific case. anyway modprobe ordering seems the way to go. thanks -- maks -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
