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