Bug#505609: [SOLVED] Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
After examining the maintainer scripts, this does appear to be a bug in the maintainer scripts. I compared output of dpkg-reconfigure between two different systems: one running Etch and the other running Lenny. Both had lilo installed as the boot loader. In both cases, the contents of /etc/kernel-img.conf were as follows: -- # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes relative_links = yes do_bootloader = yes do_bootfloppy = no do_initrd = yes link_in_boot = yes -- Here is the output of dpkg-reconfigure on Etch: -- # dpkg-reconfigure linux-image-2.6.18-5-686 Running depmod. Finding valid ramdisk creators. Using mkinitramfs-kpkg to build the ramdisk. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.18.dfsg.1-13 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.18.dfsg.1-13 was configured last, according to dpkg) You already have a LILO configuration in /etc/lilo.conf Running boot loader as requested Testing lilo.conf ... Testing successful. Installing the partition boot sector... Running /sbin/lilo ... Installation successful. # -- Here is the output of dpkg-reconfigure on Lenny: -- # dpkg-reconfigure linux-image-2.6.26-2-686 Running depmod. Running mkinitramfs-kpkg. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.26-21lenny4 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.26-21lenny4 was configured last, according to dpkg) # -- Notice the absence of any information about running the boot loader in the Lenny output! The boot loader simply was not run, despite a request in /etc/kernel-img.conf to run it. I compared the two relevant maintainer scripts: /var/lib/dpkg/info/linux-image.2.6.18-5-686.postinst and /var/lib/dpkg/info/linux-image.2.6.26-2-686.postinst and quickly discovered the reason. The maintainer scripts for the 2.6.26 kernel define the $loader variable to be the null string. The 2.6.18 maintainer script defines the $loader variable to be lilo. To be specific, line 38 of /var/lib/dpkg/info/linux-image-2.6.26-2-686.postinst currently says: my $loader= ""; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo I changed it to say: my $loader= "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo The new output is as follows: -- # dpkg-reconfigure linux-image-2.6.26-2-686 Running depmod. Running mkinitramfs-kpkg. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.26-21lenny4 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.26-21lenny4 was configured last, according to dpkg) You already have a LILO configuration in /etc/lilo.conf Running boot loader as requested Testing lilo.conf ... Testing successful. Installing the partition boot sector... Running /sbin/lilo ... Installation successful. # -- There is no conflict with grub version 1 or grub version 2 here. If the user has either version of grub installed, then the user will set do_bootloader = no in /etc/kernel-img.conf. In the case of grub version 1, he will also add postinst_hook = update-grub postrm_hook = update-grub A similar change should be made to the preinst, prerm, and postrm scripts for consistency. The Squeeze and Sid scripts have the same problem. OK, I solved the mystery. Now someone on the kernel team actually has to fix it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/162468144.291167.1275665046115.javamail.r...@md01.wow.synacor.com
Bug#582002: [SOLVED] Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
On Mon, May 17, 2010 at 02:17:54PM -0400, Stephen Powell wrote: > On Mon, 17 May 2010 13:33:05 -0400 (EDT), Maximilian Attems wrote: > > > > you can use modprobe config here again see man modprobe.conf and > > the softdep line. > > That did the trick! I changed /etc/modprobe.d/dasd (now called > /etc/modprobe.d/dasd.conf) as follows: > >options dasd_mod dasd=0.0.0200(diag),0.0.0201,0.0.0202-0.0.0203(diag) >softdep dasd_eckd_mod pre: dasd_diag_mod >softdep dasd_fba_mod pre: dasd_diag_mod cool, nice! :) > I also removed the two lines from /etc/initramfs-tools/modules > >dasd_mod >dasd_diag_mod > > since they are no longer needed. yep. > I then rebuilt the initial RAM > filesystem and re-ran the boot loader (zipl). It's working now! > Thanks for your help. happy it boots. > 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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100517183159.gk13...@baikonur.stro.at
Bug#582002: [SOLVED] Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
On Mon, 17 May 2010 13:33:05 -0400 (EDT), Maximilian Attems wrote: > > you can use modprobe config here again see man modprobe.conf and > the softdep line. That did the trick! I changed /etc/modprobe.d/dasd (now called /etc/modprobe.d/dasd.conf) as follows: options dasd_mod dasd=0.0.0200(diag),0.0.0201,0.0.0202-0.0.0203(diag) softdep dasd_eckd_mod pre: dasd_diag_mod softdep dasd_fba_mod pre: dasd_diag_mod I also removed the two lines from /etc/initramfs-tools/modules dasd_mod dasd_diag_mod since they are no longer needed. I then rebuilt the initial RAM filesystem and re-ran the boot loader (zipl). It's working now! Thanks for your help. 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. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/964759525.199155.1274120274698.javamail.r...@md01.wow.synacor.com
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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1209128820.198253.1274118663770.javamail.r...@md01.wow.synacor.com
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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100517173305.gi13...@baikonur.stro.at
Processed: Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
Processing commands for cont...@bugs.debian.org: > severity 582002 important Bug #582002 [initramfs-tools] Modules not loading in the proper order (initramfs-tools: s390 architecture) Severity set to 'important' from 'serious' > stop Stopping processing here. Please contact me if you need assistance. -- 582002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582002 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127411884516447.transcr...@bugs.debian.org
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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100517171353.gh13...@baikonur.stro.at
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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1715772729.195258.1274113995407.javamail.r...@md01.wow.synacor.com
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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/738852436.193388.1274110769225.javamail.r...@md01.wow.synacor.com
