FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 05-17-2010, 03:39 PM
Stephen Powell
 
Default Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)

Package: initramfs-tools
Version: 0.94.4
Severity: serious

(Note: I opened this bug report with a severity of "serious", since it
prevents my system from booting. In my humble opinion this makes the
package unsuitable for release in a stable release. But I am not a
package maintainer nor the release manager; so you can argue with me about
the severity if you think it is warranted.)

I run Debian testing (Squeeze) on the s390 architecture. I just performed
an "aptitude update" and "aptitude full-upgrade" sequence, and among the
updates was a new version of initramfs-tools: 0.94.4. (I noticed that
Debian bug report 576603 was opened with a severity of "serious" with the
apparent goal of keeping the package from migrating from Sid to Squeeze,
and the bug has not been marked as resolved, nevertheless the package
did migrate to Squeeze within the past few days.)

The new package completely broke my system's ability to boot. Allow me
to explain the boot mechanism that the old version successfully accomplished,
and then explain how the new version fails. I have four different disks,
one partition each, that are mounted on four different mount points,
as follows:

Device Mount Point
0200 /
0201 /boot
0202 /home
0203 swap

I have a file called /etc/modprobe.d/dasd which contains the following
statement:

options dasd_mod dasd=0.0.0200(diag),0.0.0201,0.0.0202-0.0.0203(diag)

This accomplishes two things: (1) it guarantees the correspondence of
Linux devices names to s390 device numbers as follows:

Device

0200 /dev/dasda
0201 /dev/dasdb
0202 /dev/dasdc
0203 /dev/dasdd

and (2) it specifies the device driver used for each disk as follows:
--
.'`. Stephen Powell
: :' :
`. `'`
`-



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 738852436.193388.1274110769225.JavaMail.root@md01. wow.synacor.com">http://lists.debian.org/738852436.193388.1274110769225.JavaMail.root@md01. wow.synacor.com
 
Old 05-17-2010, 04:33 PM
Stephen Powell
 
Default 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
: :' :
`. `'`
`-



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1715772729.195258.1274113995407.JavaMail.root@md01 .wow.synacor.com">http://lists.debian.org/1715772729.195258.1274113995407.JavaMail.root@md01 .wow.synacor.com
 
Old 05-17-2010, 05:13 PM
maximilian attems
 
Default Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)

severity 582002 important
stop

On Mon, May 17, 2010 at 11:39:29AM -0400, Stephen Powell wrote:
>
> I run Debian testing (Squeeze) on the s390 architecture. I just performed
> an "aptitude update" and "aptitude full-upgrade" sequence, and among the
> updates was a new version of initramfs-tools: 0.94.4. (I noticed that
> Debian bug report 576603 was opened with a severity of "serious" with the
> apparent goal of keeping the package from migrating from Sid to Squeeze,
> and the bug has not been marked as resolved, nevertheless the package
> did migrate to Squeeze within the past few days.)
>
> The new package completely broke my system's ability to boot. Allow me
> to explain the boot mechanism that the old version successfully accomplished,
> and then explain how the new version fails. I have four different disks,
> one partition each, that are mounted on four different mount points,
> as follows:
>
> Device Mount Point
> 0200 /
> 0201 /boot
> 0202 /home
> 0203 swap
>
> I have a file called /etc/modprobe.d/dasd which contains the following
> statement:
>
> options dasd_mod dasd=0.0.0200(diag),0.0.0201,0.0.0202-0.0.0203(diag)

you need give it a .conf ending then it ends up in initramfs.
soon modprobe will not even look at your file without that ending.
this special needs to be reverted due to stable -> testing upgrade,
but will reappear soon.

> This accomplishes two things: (1) it guarantees the correspondence of
> Linux devices names to s390 device numbers as follows:
>
> Device
>
> 0200 /dev/dasda
> 0201 /dev/dasdb
> 0202 /dev/dasdc
> 0203 /dev/dasdd
>
> and (2) it specifies the device driver used for each disk as follows:

iam not familiar where this files comes from,
so please feel free to reassign to whomever who created it.
and/or maybe to release notes.

thanks

ps thanks for reminding me of 576603, will nuke that and get soonest
latest git out.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100517171353.GH13054@baikonur.stro.at">http://lists.debian.org/20100517171353.GH13054@baikonur.stro.at
 
Old 05-17-2010, 05:33 PM
maximilian attems
 
Default 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



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100517173305.GI13054@baikonur.stro.at">http://lists.debian.org/20100517173305.GI13054@baikonur.stro.at
 
Old 05-17-2010, 05:51 PM
Stephen Powell
 
Default Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)

I just tried a couple of things. First, I thought this might be
related to the new dependency-based boot sequencing. I tried
adding the line

CONCURRENCY=none

to /etc/default/rcS to disable parallel booting. But it didn't
do the trick. I then rebuilt the initial RAM filesystem and re-ran
the boot loader after making the above change. It still didn't
fix the problem. Then I booted the old kernel. It booted just fine.
But when I rebuilt the initial RAM filesystem for the old kernel with

update-initramfs -uk 2.6.32-3-s390x

and re-ran the boot loader, then the old kernel wouldn't boot either.
So this is not related to the kernel. It is definitely related to the
new version of initramfs-tools.

--
.'`. Stephen Powell
: :' :
`. `'`
`-



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1209128820.198253.1274118663770.JavaMail.root@md01 .wow.synacor.com">http://lists.debian.org/1209128820.198253.1274118663770.JavaMail.root@md01 .wow.synacor.com
 

Thread Tools




All times are GMT. The time now is 08:56 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org