Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
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
: :' :
`. `'`
`-
Reply to: