Bug#582002: marked as done (Modules not loading in the proper order (initramfs-tools: s390 architecture))
Your message dated Mon, 17 May 2010 14:59:38 -0400 (EDT)
with message-id <1630259876.200341.1274122778109.JavaMail.root@md01.wow.synacor.com>
and subject line Re: Bug#582002: [SOLVED] Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
has caused the Debian Bug report #582002,
regarding Modules not loading in the proper order (initramfs-tools: s390 architecture)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
582002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582002
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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
: :' :
`. `'`
`-
--- End Message ---
--- Begin Message ---
On Mon, 17 May 2010 14:31:59 -0400 (EDT), Maximilian Attems wrote:
> On Mon, May 17, 2010 at 02:17:54PM -0400, Stephen Powell wrote:
>>
>> I'll leave this problem record open though,
>> to remind you that files in /etc/modprobe.d which do not have an extension
>> of .conf need to be re-enabled (at least for a while longer) to prevent
>> migration problems. But my system is bootable again, now that I've made
>> the changes indicated above.
>
> #577981 is open for the transition no point in having two bugs for that.
> unless you want to reassign this bug to debian installer or the package
> that created aboves modprobe file, i'd say it can be closed.
>
> thanks
Closing per above.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--- End Message ---
Reply to: