Re: Debian libata transition (bug in initramfs-tools?)
On Sat, 2010-12-11 at 20:24 -0800, Gordon Farquharson wrote: Hi Ben On Mon, Dec 6, 2010 at 20:32, Ben Hutchings b...@decadent.org.uk wrote: Would the solution then be to require people to (temporarily) set MODULES=most before upgrading? That should work around the bug unless the system is short of RAM (less than about 64 MB). If this can't easily be fixed in initramfs-tools then we could mention that in the release notes. Building with MODULES=most on the GLAN Tank does fix the problem, as expected, so adding a note in the release notes for users of the GLAN Tank to change MODULES=dep to MODULES=most before installing the new kernel and udev packages will work nicely. We can do that if we have to, but since not everyone reads release notes thoroughly I would prefer to make initramfs-tools get this right. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Debian libata transition (bug in initramfs-tools?)
Hi Ben On Mon, Dec 6, 2010 at 20:32, Ben Hutchings b...@decadent.org.uk wrote: Would the solution then be to require people to (temporarily) set MODULES=most before upgrading? That should work around the bug unless the system is short of RAM (less than about 64 MB). If this can't easily be fixed in initramfs-tools then we could mention that in the release notes. Building with MODULES=most on the GLAN Tank does fix the problem, as expected, so adding a note in the release notes for users of the GLAN Tank to change MODULES=dep to MODULES=most before installing the new kernel and udev packages will work nicely. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- 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/aanlktimz8kt6airmha6zkrthagczc3lxpezjs_4bb...@mail.gmail.com
Re: Debian libata transition (bug in initramfs-tools?)
On Sun, 2010-12-12 at 04:30 +, Ben Hutchings wrote:
On Sat, 2010-12-11 at 20:24 -0800, Gordon Farquharson wrote:
Hi Ben
On Mon, Dec 6, 2010 at 20:32, Ben Hutchings b...@decadent.org.uk wrote:
Would the solution then be to require people to (temporarily) set
MODULES=most before upgrading?
That should work around the bug unless the system is short of RAM (less
than about 64 MB). If this can't easily be fixed in initramfs-tools
then we could mention that in the release notes.
Building with MODULES=most on the GLAN Tank does fix the problem, as
expected, so adding a note in the release notes for users of the GLAN
Tank to change MODULES=dep to MODULES=most before installing the new
kernel and udev packages will work nicely.
We can do that if we have to, but since not everyone reads release notes
thoroughly I would prefer to make initramfs-tools get this right.
Now that I've re-read the code, I think initramfs-tools will already
find the right hardware driver in the new kernel, and it only misses the
high-level disk driver, sd_mod.
If you still have a copy of the broken initramfs, please could you send
a list of its contents ('lsinitramfs' will provide that).
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a digitally signed message part
Re: Debian libata transition (bug in initramfs-tools?)
Hi Ben
On Sat, Dec 11, 2010 at 20:45, Ben Hutchings b...@decadent.org.uk wrote:
Now that I've re-read the code, I think initramfs-tools will already
find the right hardware driver in the new kernel, and it only misses the
high-level disk driver, sd_mod.
If you still have a copy of the broken initramfs, please could you send
a list of its contents ('lsinitramfs' will provide that).
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
I found it. I had made a copy of it in the home directory on the GLAN
Tank. (Good thing too, because I forgot to CC the mailing list in my
previous email.)
.
conf
conf/initramfs.conf
conf/modules
conf/arch.conf
conf/param.conf
conf/conf.d
conf/conf.d/resume
conf/conf.d/driver-policy
etc
etc/modprobe.d
etc/modprobe.d/blacklist.conf
etc/modprobe.d/fbdev-blacklist.conf
etc/modprobe.d/aliases.conf
etc/udev
etc/udev/udev.conf
sbin
sbin/udevadm
sbin/blkid
sbin/modprobe
sbin/rmmod
sbin/udevd
bin
bin/losetup
bin/sync
bin/poweroff
bin/cat
bin/ipconfig
bin/pivot_root
bin/resume
bin/minips
bin/true
bin/mkdir
bin/run-init
bin/chroot
bin/umount
bin/busybox
bin/nfsmount
bin/mount
bin/nuke
bin/false
bin/mkfifo
bin/ls
bin/sleep
bin/cpio
bin/uname
bin/dd
bin/sh.shared
bin/fstype
bin/gunzip
bin/ln
bin/reboot
bin/gzip
bin/halt
bin/dmesg
bin/sh
bin/kill
bin/readlink
bin/insmod
bin/mknod
init
lib
lib/modules
lib/modules/2.6.32-5-iop32x
lib/modules/2.6.32-5-iop32x/modules.symbols.bin
lib/modules/2.6.32-5-iop32x/modules.devname
lib/modules/2.6.32-5-iop32x/modules.alias.bin
lib/modules/2.6.32-5-iop32x/modules.softdep
lib/modules/2.6.32-5-iop32x/modules.alias
lib/modules/2.6.32-5-iop32x/modules.dep.bin
lib/modules/2.6.32-5-iop32x/modules.order
lib/modules/2.6.32-5-iop32x/modules.dep
lib/modules/2.6.32-5-iop32x/kernel
lib/modules/2.6.32-5-iop32x/kernel/fs
lib/modules/2.6.32-5-iop32x/kernel/fs/ext3
lib/modules/2.6.32-5-iop32x/kernel/fs/ext3/ext3.ko
lib/modules/2.6.32-5-iop32x/kernel/fs/mbcache.ko
lib/modules/2.6.32-5-iop32x/kernel/fs/jbd
lib/modules/2.6.32-5-iop32x/kernel/fs/jbd/jbd.ko
lib/modules/2.6.32-5-iop32x/kernel/drivers
lib/modules/2.6.32-5-iop32x/kernel/drivers/ide
lib/modules/2.6.32-5-iop32x/kernel/drivers/ide/ide-core.ko
lib/modules/2.6.32-5-iop32x/kernel/drivers/ide/ide-gd_mod.ko
lib/modules/2.6.32-5-iop32x/kernel/drivers/ide/ide-cd_mod.ko
lib/modules/2.6.32-5-iop32x/kernel/drivers/scsi
lib/modules/2.6.32-5-iop32x/kernel/drivers/scsi/scsi_mod.ko
lib/modules/2.6.32-5-iop32x/kernel/drivers/ata
lib/modules/2.6.32-5-iop32x/kernel/drivers/ata/libata.ko
lib/modules/2.6.32-5-iop32x/kernel/drivers/ata/pata_artop.ko
lib/modules/2.6.32-5-iop32x/kernel/drivers/cdrom
lib/modules/2.6.32-5-iop32x/kernel/drivers/cdrom/cdrom.ko
lib/modules/2.6.32-5-iop32x/modules.symbols
lib/libblkid.so.1
lib/udev
lib/udev/ata_id
lib/udev/hotplug.functions
lib/udev/edd_id
lib/udev/scsi_id
lib/udev/path_id
lib/udev/usb_id
lib/udev/firmware.agent
lib/udev/rules.d
lib/udev/rules.d/50-udev-default.rules
lib/udev/rules.d/60-persistent-storage.rules
lib/udev/rules.d/91-permissions.rules
lib/udev/rules.d/80-drivers.rules
lib/ld-linux.so.3
lib/libc.so.6
lib/libselinux.so.1
lib/libm.so.6
lib/libgcc_s.so.1
lib/libuuid.so.1
lib/klibc-LdXccGC4Q9Yh2poCpyoOF0jSTtc.so
lib/libdl.so.2
scripts
scripts/nfs
scripts/functions
scripts/init-bottom
scripts/init-bottom/udev
scripts/init-bottom/ORDER
scripts/init-top
scripts/init-top/udev
scripts/init-top/keymap
scripts/init-top/blacklist
scripts/init-top/ORDER
scripts/init-top/all_generic_ide
scripts/local-premount
scripts/local-premount/resume
scripts/local-premount/ORDER
scripts/local
--
Gordon Farquharson
GnuPG Key ID: 32D6D676
--
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/aanlktimdu14o_g1gswb20zswkphzxkgw9hxlcnqdo...@mail.gmail.com
Re: Debian libata transition (bug in initramfs-tools?)
On Sat, 2010-12-11 at 21:25 -0800, Gordon Farquharson wrote:
Hi Ben
On Sat, Dec 11, 2010 at 20:45, Ben Hutchings b...@decadent.org.uk wrote:
Now that I've re-read the code, I think initramfs-tools will already
find the right hardware driver in the new kernel, and it only misses the
high-level disk driver, sd_mod.
If you still have a copy of the broken initramfs, please could you send
a list of its contents ('lsinitramfs' will provide that).
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
I found it. I had made a copy of it in the home directory on the GLAN
Tank. (Good thing too, because I forgot to CC the mailing list in my
previous email.)
[...]
lib/modules/2.6.32-5-iop32x/kernel/drivers/scsi
lib/modules/2.6.32-5-iop32x/kernel/drivers/scsi/scsi_mod.ko
lib/modules/2.6.32-5-iop32x/kernel/drivers/ata
lib/modules/2.6.32-5-iop32x/kernel/drivers/ata/libata.ko
lib/modules/2.6.32-5-iop32x/kernel/drivers/ata/pata_artop.ko
[...]
As I thought, all the right modules are there *except* sd_mod.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a digitally signed message part
Re: Debian libata transition (bug in initramfs-tools?)
* Gordon Farquharson gordonfarquhar...@gmail.com [2010-12-07 12:53]: That makes sense because I think that the installer is configured to run in low memory mode for this system (tbm would know for sure). The system has 128 MB of RAM. It has nothing to do with RAM but with flash. Some ARM machines have too little flash to fit a ramdisk built with most. The solution was to use dep on all ARM machines. (I don't actually like this solution since not all ARM machines should use dep; this device is one example). This situation seems like a corner case because the user base for this system is very small (I only use the one I had for testing Debian). Unless there are other systems that may be affected, I think that a All other ARM machines we support use either USB or SATA and therefore are not affected. -- Martin Michlmayr http://www.cyrius.com/ -- 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/20101210150338.gl5...@jirafa.cyrius.com
Re: Debian libata transition (bug in initramfs-tools?)
Hi Ben On Mon, Dec 6, 2010 at 20:32, Ben Hutchings b...@decadent.org.uk wrote: You should really use the 'reportbug' command to send bug reports. I wasn't sure that it was a bug, so I thought I'd start a discussion before filing a bug report. I'm happy to submit a proper bug report if required. Also, it is tricky to use reportbug on a system that doesn't boot :-) Can you not reboot into the previous kernel version? Booting into the previous kernel required removing the hard drive from the machine and installing it in a USB enclosure. The box is headless, and the name of the kernel and initramfs files are hard coded in the bootloader (Redboot) in the system flash memory. So, you either need to copy new kernel or image files to the hard drive that have the required names, or have prepared and copied a recovery kernel image and initramfs to the hard drive. With the latter option, you have to interrupt the boot loader and manually enter the boot commands to load the recovery kernel and initramfs. Also, you can't just use the vmlinuz files in /boot because the kernel image needs to be prepended with 8 bytes of data. So, in short, it was a pain. (You did ask :-) ) Right. I assume you have configured initramfs-tools with MODULES=dep, and it worked out the required modules for the *running* kernel not the newly installed kernel. That would be a bug. You are correct: MODULES=dep. I have never changed, so I guess it was set like that when I installed lenny. There is an option for this at installation time, but it is not the default. I think it might be automatically selected for systems with little RAM, though. That makes sense because I think that the installer is configured to run in low memory mode for this system (tbm would know for sure). The system has 128 MB of RAM. Would the solution then be to require people to (temporarily) set MODULES=most before upgrading? That should work around the bug unless the system is short of RAM (less than about 64 MB). If this can't easily be fixed in initramfs-tools then we could mention that in the release notes. This situation seems like a corner case because the user base for this system is very small (I only use the one I had for testing Debian). Unless there are other systems that may be affected, I think that a note in the installation instructions should be sufficient, unless of course there is an easy fix. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- 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/aanlktikzlnsuna+auwu5agpgospa63-juv77y6c...@mail.gmail.com
Debian libata transition (bug in initramfs-tools?)
(I'm sending this email to debian-kernel because the Debian kernel team is listed as the maintainer for initramfs-tools.) I was testing the upgrade from lenny to squeeze on an old arm-based device (the GLAN Tank). This system has a Acard ATP865-B IDE interface chip, so the aec62xx driver was used with lenny. For squeeze, the pata_artop driver will be used. Once I had upgraded the kernel and udev, I rebooted the machine, and found that I was not able to access the hard drive (see the relevant portion of the boot log below). The hard drive is detected by pata_artop, but there is no block driver loaded. I believe that this problem is because some of the required modules (e.g., sd_mod.ko) were not included in the new initramfs. [2.33] udev[45]: starting version 164 [3.31] SCSI subsystem initialized [3.66] PCI: enabling device :00:02.0 (0045 - 0047) [3.67] scsi0 : pata_artop [3.67] scsi1 : pata_artop [3.68] ata1: PATA max UDMA/100 cmd 0x90c0 ctl 0x90d0 bmdma 0x9000 irq 28 [3.69] ata2: PATA max UDMA/100 cmd 0x90c8 ctl 0x90d4 bmdma 0x9008 irq 28 [3.88] ata1.00: ATA-5: ST380021A, 3.05, max UDMA/100 [3.88] ata1.00: 156301488 sectors, multi 0: LBA [3.91] ata1.00: configured for UDMA/100 [3.91] scsi 0:0:0:0: Direct-Access ATA ST380021A 3.05 PQ: 0 ANSI: 5 Begin: Loading essential drivers ... [4.50] Uniform Multi-Platform E-IDE driver [4.57] ide-gd driver 1.18 done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Waiting for root file system ... done. Gave up waiting for root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/disk/by-uuid/36cfb6a0-b8bd-4097-9a48-ea1c113cd3c4 does not exist. Dropping to a shell! (initramfs) cat /proc/modules ide_gd_mod 20384 0 - Live 0xbf083000 ide_core 76559 1 ide_gd_mod, Live 0xbf062000 pata_artop 3906 0 - Live 0xbf05c000 libata 135592 1 pata_artop, Live 0xbf026000 scsi_mod 79418 1 libata, Live 0xbf00 After doing upgrading the kernel and udev (and some other packages) from lenny to squeeze, /conf/modules in the (squeeze) initramfs contained: (initramfs) cat conf/modules pci:v1191d0009sv1191sd0009bc01sc80i00 ide_disk aec62xx pci:v1191d0009sv1191sd0009bc01sc80i00 unix I imagine that initramfs-tools created this file when I upgraded the kernel and udev, but I'm not sure why the aec62xx driver (the old IDE driver) was listed in the file, although I suspect that initramfs-tools found this module by walking through /sys because that driver was loaded when the initramfs was created. However, even though the aec62xx driver is listed in /conf/modules, it is not included in the initramsfs, because is is not built with the squeeze kernel. /lib/modules/2.6.32-5-iop32x/kernel/drivers/ata: total 220 -rw-r--r--1 00 212608 Nov 26 15:37 libata.ko -rw-r--r--1 0010884 Nov 26 15:37 pata_artop.ko /lib/modules/2.6.32-5-iop32x/kernel/drivers/ide: total 208 -rw-r--r--1 0040564 Nov 26 15:37 ide-cd_mod.ko -rw-r--r--1 00 133576 Nov 26 15:37 ide-core.ko -rw-r--r--1 0036424 Nov 26 15:37 ide-gd_mod.ko The pata_artop module did get included in the initramfs. However, to access the disk, one seems to needs some other modules including sd_mod.ko, and these were not included in the initramfs. That the modules weren't included seems like a bug in the upgrade process, because the new initramfs that should obviously contain all the necessary libata-based drivers required to access the disk. Does the behavior I observed match what you would expect to happen with initramfs-tools for the upgrade, and is it something that can be fixed? Also, would this problem apply to all systems that only have PATA hard drives? Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- 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/aanlktin-2xowaahddi=f4g771gzue8tdoihuaxd-f...@mail.gmail.com
Re: Debian libata transition (bug in initramfs-tools?)
On Mon, Dec 06, 2010 at 11:42:30AM -0800, Gordon Farquharson wrote: (I'm sending this email to debian-kernel because the Debian kernel team is listed as the maintainer for initramfs-tools.) You should really use the 'reportbug' command to send bug reports. [...] After doing upgrading the kernel and udev (and some other packages) from lenny to squeeze, /conf/modules in the (squeeze) initramfs contained: (initramfs) cat conf/modules pci:v1191d0009sv1191sd0009bc01sc80i00 ide_disk aec62xx pci:v1191d0009sv1191sd0009bc01sc80i00 unix I imagine that initramfs-tools created this file when I upgraded the kernel and udev, but I'm not sure why the aec62xx driver (the old IDE driver) was listed in the file, although I suspect that initramfs-tools found this module by walking through /sys because that driver was loaded when the initramfs was created. However, even though the aec62xx driver is listed in /conf/modules, it is not included in the initramsfs, because is is not built with the squeeze kernel. Right. I assume you have configured initramfs-tools with MODULES=dep, and it worked out the required modules for the *running* kernel not the newly installed kernel. That would be a bug. [...] Does the behavior I observed match what you would expect to happen with initramfs-tools for the upgrade, and is it something that can be fixed? Also, would this problem apply to all systems that only have PATA hard drives? Thankfully, no. The default configuration of initramfs-tools has MODULES=most which means that all the available PATA and SATA drivers will be included in the initramfs. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20101206200629.go8...@decadent.org.uk
Re: Debian libata transition (bug in initramfs-tools?)
Hi Ben Thanks for the prompt reply. On Mon, Dec 6, 2010 at 12:06, Ben Hutchings b...@decadent.org.uk wrote: On Mon, Dec 06, 2010 at 11:42:30AM -0800, Gordon Farquharson wrote: (I'm sending this email to debian-kernel because the Debian kernel team is listed as the maintainer for initramfs-tools.) You should really use the 'reportbug' command to send bug reports. I wasn't sure that it was a bug, so I thought I'd start a discussion before filing a bug report. I'm happy to submit a proper bug report if required. Also, it is tricky to use reportbug on a system that doesn't boot :-) Right. I assume you have configured initramfs-tools with MODULES=dep, and it worked out the required modules for the *running* kernel not the newly installed kernel. That would be a bug. You are correct: MODULES=dep. I have never changed, so I guess it was set like that when I installed lenny. So, is this a fixable bug? /mnt/disk/etc/initramfs-tools/conf.d # cat driver-policy # Driver inclusion policy selected during installation # Note: this setting overrides the value set in the file # /etc/initramfs-tools/initramfs.conf MODULES=dep Does the behavior I observed match what you would expect to happen with initramfs-tools for the upgrade, and is it something that can be fixed? Also, would this problem apply to all systems that only have PATA hard drives? Thankfully, no. The default configuration of initramfs-tools has MODULES=most which means that all the available PATA and SATA drivers will be included in the initramfs. Would the solution then be to require people to (temporarily) set MODULES=most before upgrading? Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- 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/aanlktinwjjcgj5rul+squhz7c-32n7jdzhcvbdpmc...@mail.gmail.com
Re: Debian libata transition (bug in initramfs-tools?)
On Mon, 2010-12-06 at 12:28 -0800, Gordon Farquharson wrote: Hi Ben Thanks for the prompt reply. On Mon, Dec 6, 2010 at 12:06, Ben Hutchings b...@decadent.org.uk wrote: On Mon, Dec 06, 2010 at 11:42:30AM -0800, Gordon Farquharson wrote: (I'm sending this email to debian-kernel because the Debian kernel team is listed as the maintainer for initramfs-tools.) You should really use the 'reportbug' command to send bug reports. I wasn't sure that it was a bug, so I thought I'd start a discussion before filing a bug report. I'm happy to submit a proper bug report if required. Also, it is tricky to use reportbug on a system that doesn't boot :-) Can you not reboot into the previous kernel version? Right. I assume you have configured initramfs-tools with MODULES=dep, and it worked out the required modules for the *running* kernel not the newly installed kernel. That would be a bug. You are correct: MODULES=dep. I have never changed, so I guess it was set like that when I installed lenny. There is an option for this at installation time, but it is not the default. I think it might be automatically selected for systems with little RAM, though. So, is this a fixable bug? /mnt/disk/etc/initramfs-tools/conf.d # cat driver-policy # Driver inclusion policy selected during installation # Note: this setting overrides the value set in the file # /etc/initramfs-tools/initramfs.conf MODULES=dep Does the behavior I observed match what you would expect to happen with initramfs-tools for the upgrade, and is it something that can be fixed? Also, would this problem apply to all systems that only have PATA hard drives? Thankfully, no. The default configuration of initramfs-tools has MODULES=most which means that all the available PATA and SATA drivers will be included in the initramfs. Would the solution then be to require people to (temporarily) set MODULES=most before upgrading? That should work around the bug unless the system is short of RAM (less than about 64 MB). If this can't easily be fixed in initramfs-tools then we could mention that in the release notes. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
