Bug#284141: initrd-tools: no SCSI should not be a fatal error
On Fri, Dec 03, 2004 at 11:10:35PM +, Michael Shields wrote: Package: initrd-tools Version: 0.1.74 Severity: normal mkinitrd contains the lines: 8 | 11) if [ ! -d /proc/scsi ]; then echo $PROG: Cannot determine SCSI module 2 exit 1 fi This makes it impossible to upgrade from a custom kernel with no SCSI support to a standard Debian kernel. It would be better if mkinitrd instead left out all SCSI modules when /proc/scsi was missing. Actually no. /proc/scsi is (a) not present on all 2.6 kernels (only if legacy /proc/scsi/ support is enabled) (b) even if it is enabled on mainline kernels only drivers who actually have a -proc_info method show up there. Debian kernels have a totally broken patch that Herbert added to make mkinitrd still work. So mkinitrd simply must not rely on /proc/scsi at all when running on 2.6 kernels.
Bug#284221: utter lack of acenic drivers on i386, hppa
On Sat, 04 Dec 2004, Matthew Wilcox wrote: On Sat, Dec 04, 2004 at 01:01:33PM -0500, Kyle McMartin wrote: * ACENIC firwmare, driver disabled: . drivers/net/acenic_firmware.h So there's a good reason why you're unable to use these cards. ITYM good reason to switch to Ubuntu, Gentoo or Fedora. HTH. agreed. beside debian-legal having no consensus on that issue, don't latest gr allow to ship those for at least sarge? -- maks kernel janitor http://janitor.kernelnewbies.org/
Bug#284294: mkinitrd module detection using hotplug algorithm
Package:initrd-tools Version:0.1.74 Severity: wishlist Hi, This is a proposal to improve mkinitrd by reusing code from the hotplug project to determine which modules are needed on the initrd image to support block devices. It is an alternative to an earlier proposal to make devices in sysfs point to the module that implements their driver. It improves on the original proposal in the following ways: - no kernel changes required, so will work with older 2.6 kernels - can cope with differences between modules in running kernel and new kernel; as an example, it understands that a USB stick in 2.6.8 needs usb-storage, but in 2.6.9 will need the ub module. The original proposal and the problems motivating it are discussed in: - http://marc.theaimsgroup.com/?l=linux-scsim=109570145108639w=2 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=263169 The method is simple: mkinitrd runs under an old kernel on some hardware, and it needs to find the minimal set of modules needed to boot a new kernel on that hardware. Sysfs describes the hardware, complete with device identifiers, and a module map provided with the new kernel describes which modules are needed to operate a particular piece of hardware. Finally, modules.dep shows which support modules must be loaded before a module can be loaded. Hotplug uses this same information to load modules for a new device into a running kernel. In fact hotplug and mkinitrd are two sides of the same coin: hotplug finds modules for available hardware given a running kernel, and mkinitrd finds modules for some kernel given available hardware. So I copied the module table processing from hotplug and adapted it to use tables from a different kernel. After that, it's only a matter of identifying which hardware devices are used to implement block devices; essentially that's just /sys/block/*/device/. One little twist: if you're using for example a USB stick, you need not only the USB driver, but also the PCI driver for the bus that the USB host is attached to. The pathname of the device in /sys/devices identifies all such parent devices. The attached script implements this method, and seems to give more or less correct answers on a machine with SATA drive (although I wonder about the location of ide0 in sysfs): [EMAIL PROTECTED]:/dat/tmp$ uname -r 2.6.8-1-686 [EMAIL PROTECTED]:/dat/tmp$ sh joke4 === /sys/block/hda devno 3:0 at: /sys/devices/ide0/0.0 needs: === /sys/block/sda devno 8:0 at: /sys/devices/pci:00/:00:1f.2/host0/0:0:0:0 needs: ata_piix === /sys/block/sdb devno 8:16 at: /sys/devices/pci:00/:00:1d.7/usb5/5-4/5-4.3/5-4.3:1.0/host7/7:0:0:0 needs: ehci-hcd usbcore usbcore usb-storage recommended module load order: /lib/modules/2.6.8-1-686/kernel/drivers/scsi/libata.ko /lib/modules/2.6.8-1-686/kernel/drivers/scsi/scsi_mod.ko /lib/modules/2.6.8-1-686/kernel/drivers/scsi/ata_piix.ko /lib/modules/2.6.8-1-686/kernel/drivers/usb/core/usbcore.ko /lib/modules/2.6.8-1-686/kernel/drivers/usb/host/ehci-hcd.ko /lib/modules/2.6.8-1-686/kernel/drivers/ide/ide-core.ko /lib/modules/2.6.8-1-686/kernel/drivers/usb/storage/usb-storage.ko [EMAIL PROTECTED]:/dat/tmp$ sh joke4 2.6.10-rc2-e === /sys/block/hda devno 3:0 at: /sys/devices/ide0/0.0 needs: === /sys/block/sda devno 8:0 at: /sys/devices/pci:00/:00:1f.2/host0/0:0:0:0 needs: ata_piix === /sys/block/sdb devno 8:16 at: /sys/devices/pci:00/:00:1d.7/usb5/5-4/5-4.3/5-4.3:1.0/host7/7:0:0:0 needs: ehci-hcd usbcore usbcore ub recommended module load order: /lib/modules/2.6.10-rc2-e/kernel/drivers/scsi/libata.ko /lib/modules/2.6.10-rc2-e/kernel/drivers/scsi/scsi_mod.ko /lib/modules/2.6.10-rc2-e/kernel/drivers/scsi/ata_piix.ko /lib/modules/2.6.10-rc2-e/kernel/drivers/usb/core/usbcore.ko /lib/modules/2.6.10-rc2-e/kernel/drivers/usb/host/ehci-hcd.ko /lib/modules/2.6.10-rc2-e/kernel/drivers/block/ub.ko [EMAIL PROTECTED]:/dat/tmp$ I'm looking for comments: could this approach be made to work, and if so what would be the best way to go about moving from this proof of concept to something that could be used as part of a complete mkinitrd? Regards, Erik # # Given a kernel version (default the running kernel) # print an ordered minimal list of all files that must # be loaded into that kernel in order for all block # devices to be operational. # # A large part of this script is copied from the hotplug package, # http://linux-hotplug.sourceforge.net/ # # This software may be used and distributed according to the
Bug#282195: kernel-image-2.6.9-1-686: Some other info on this problem
On Sat, Dec 04, 2004 at 03:21:59AM +0700, Jean Christophe ANDRÉ wrote: Hi, May be I'm wrong, but I think you can not load iptables modules once you have already loaded the ipfwadm one (saw it in your lsmod). Ok, you are right. But now the problem is: who have loaded ipfwadm module? With the old kernels all work ok. I'm trying to find where is the error. Bye (and tnx) -- - |Marco Nenciarini| Debian/GNU Linux Developer - Plug Member | | [EMAIL PROTECTED] | http://www.prato.linux.it/~mnencia | - Key fingerprint = FED9 69C7 9E67 21F5 7D95 5270 6864 730D F095 E5E4 signature.asc Description: Digital signature
Bug#284221: utter lack of acenic drivers on i386, hppa
* maks attems: On Sat, 04 Dec 2004, Matthew Wilcox wrote: On Sat, Dec 04, 2004 at 01:01:33PM -0500, Kyle McMartin wrote: * ACENIC firwmare, driver disabled: . drivers/net/acenic_firmware.h So there's a good reason why you're unable to use these cards. ITYM good reason to switch to Ubuntu, Gentoo or Fedora. HTH. agreed. beside debian-legal having no consensus on that issue, don't latest gr allow to ship those for at least sarge? Some people claim that redistributing the Linux source code (or binaries derived from it) is a GPL violation. If this is true, it's not a DFSG/Social Contract issue at all.
Bug#284356: incompatability with modules from -2 version of same package
Package: kernel-image-2.4.27-1-386 Version: 2.4.27-6 Severity: grave Tags: d-i Loading a module from the -2 version of this package when the -6 version of the kernel is running fails for at least all the ide chipset modules and for the ide generic module, with many missing symbols: ~ # uname -a Linux donkey 2.4.27-1-386 #1 Wed Dec 1 19:43:08 JST 2004 i686 unknown ~ # modprobe generic insmod: /lib/modules/2.4.27-1-386/kernel/drivers/ide/ide-core.o: unresolved symbol blk_init_queue_R140d40ee insmod: /lib/modules/2.4.27-1-386/kernel/drivers/ide/ide-core.o: unresolved symbol proc_symlink_R7165fa10 insmod: /lib/modules/2.4.27-1-386/kernel/drivers/ide/ide-core.o: unresolved symbol remove_proc_entry_R0a4291c8 insmod: /lib/modules/2.4.27-1-386/kernel/drivers/ide/ide-core.o: unresolved symbol devfs_mk_dir_R9c2c983a insmod: /lib/modules/2.4.27-1-386/kernel/drivers/ide/ide-core.o: unresolved symbol blk_cleanup_queue_R741c7da6 insmod: /lib/modules/2.4.27-1-386/kernel/drivers/ide/ide-core.o: unresolved symbol add_gendisk_Rf957a44e insmod: /lib/modules/2.4.27-1-386/kernel/drivers/ide/ide-core.o: unresolved symbol end_that_request_first_Rafbe0bbc insmod: /lib/modules/2.4.27-1-386/kernel/drivers/ide/ide-core.o: unresolved symbol devfs_register_blkdev_R7e5f30a4 insmod: /lib/modules/2.4.27-1-386/kernel/drivers/ide/ide-core.o: unresolved symbol blk_queue_bounce_limit_Re74e8980 insmod: /lib/modules/2.4.27-1-386/kernel/drivers/ide/ide-core.o: unresolved symbol mem_map_Rc7a5c379 Since I uploaded udebs for d-i built from this new kernel build, this has broken netboot installs on i386 using the daily builds, since such a netboot install boots the -6 kernel, then downloads -2 udebs from testing. It seems that unless this imcompatability is fixed, we won't be able to update d-i in testing to use the new kernel without breaking netboot and floppy installs using the d-i rc2 images. This proably also breaks third party modules in debian that are built against version -2, doesn't it? I think that this is a bug in this build of the kernel. If the changed symbols are for some reason unavoidable, the kernel package name should be changed to kernel-image-2.4.27-1-386. Of course that would suck and leave us with d-i problems and so I hope you can just fix it.. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages kernel-image-2.4.27-1-386 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities ii initrd-tools 0.1.74 tools to create initrd image for p ii modutils 2.4.26-1.1 Linux module utilities -- no debconf information -- see shy jo signature.asc Description: Digital signature
Processed: Re: Bug#284286: i386 install report
Processing commands for [EMAIL PROTECTED]: severity 284286 grave Bug#284286: i386 install report Severity set to `grave'. reassign 284286 kernel-image-2.6.8-1-386 Bug#284286: i386 install report Bug reassigned from package `installation-reports' to `kernel-image-2.6.8-1-386'. tag 284286 d-i Bug#284286: i386 install report There were no tags set. Tags added: d-i retitle 284286 incompatable symbols between -10 and -5 kernel versions Bug#284286: i386 install report Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#284397: booting with init=/bin/sh does not work with initrd-tools
Package: initrd-tools Version: 0.1.74 Severity: normal For some reason appending init=/bin/sh does not work with initrd-tools, which proceeds to run the /sbin/init in the initrd. However, if I boot with init=/bin2/sh, it works and I get a shell in the initrd before it (fails to) mount my root filesystem. No idea why it does that, but my goodness that's counterintuitive. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages initrd-tools depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii cpio 2.5-1.1GNU cpio -- a program to manage ar ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii dash 0.5.1-3The Debian Almquist Shell ii fileutils 5.2.1-2The GNU file management utilities ii util-linux2.12h-4Miscellaneous system utilities -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#272139: /linuxrc usage in initrd-tools
I was trying to debug a bug that turned out to be the sysfs bang bug in the initrd with the 2.6 kernel and I noticed that the reason it's falling back to sysfs in the first place seems to be because the linuxrc does not run (wasn't that removed from many kernels or not supported on all arches anyway; remember that d-i stopped using it last spring for various reasons), and so bin/root does not exist, and it always has to fall back to sysfs. Anyway, until this bug is fixed, I cannot do automated install testing on i386/2.6. I really don't understand what the delay is, we've had a tested, working patch for 2 months. -- see shy jo signature.asc Description: Digital signature
