Re: (was Bug#570350) Google Chrome
Ben Hutchings wrote: On Sun, Jun 27, 2010 at 06:50:57PM +0100, Berni Elbourn wrote: [...] PS: For future how does one build the official headers common package on Amd64? Do a full package build with 'pkg-buildpackage -B'. Ben. Wow. Thanks. Also it seems:- # fakeroot debian/rules binary does the job ... eventually :-) By the Way: 570350 is archived and can't be updated - should it be re-opened? -- 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/4c284f22.5020...@elbournb.fsnet.co.uk
Bug#586554: initramfs-tools fails to upgrade from 0.96.1 to 0.97
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Image Scan! for Linux upstream maintainer here. Care to point out why iscan is the culprit? I went through the logs but nothing ran a bell. If possible we'd like to get a fix out before squeeze goes stable ;-) - -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwoWmgACgkQt5qrxaZLMnLnxwCfQKqkpkkMgudcxtjK/LojCVFh BIsAn0L503g77eSxFqQ6Swvy4Jg/Baz1 =xJlH -END PGP SIGNATURE- -- 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/4c285a68.7030...@avasys.jp
Bug#586554: initramfs-tools fails to upgrade from 0.96.1 to 0.97
On Mon, Jun 28, 2010 at 05:16:40PM +0900, Olaf Meeuwissen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Image Scan! for Linux upstream maintainer here. Care to point out why iscan is the culprit? I went through the logs but nothing ran a bell. you are sending the message to the wrong recipient. we do not maintain that iscan software, nor their initramfs-tools hooks please nag them. -- 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/20100628083143.gy9...@baikonur.stro.at
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 28 Jun 2010, Ben Hutchings wrote: 2. Packages for boot loaders that need to be updated whenever the files they load are modified must also install hook scripts in /etc/mkinitramfs/post-update.d. Initramfs builders must call these scripts using run-parts after they create, update or delete an initramfs. The arguments given to these hook scripts are the kernel ABI version and the absolute path to the initramfs image. Please rename to more generic /etc/initramfs path. mkinitramfs is initramfs-tools specific. otherwise ack. 3. Initramfs builders must complete their work before returning from the kernel postinst hook script. [initramfs-tools currently uses a trigger to defer this because it can also be invoked twice, but this means it also has to know how to update specific boot loaders.] not twice but multiple times, if you upgrade together for example udev, lvm2, cryptsetup, mdadm and linux-2.6. 4. During a kernel package installation, upgrade or removal, various boot loader hooks may be invoked (in this order): a. A postinst_hook or postrm_hook command set by the user or the installer in /etc/kernel-img.conf b. A hook script in /etc/mkinitramfs/post-update.d c. A hook script in /etc/kernel/postinst.d or .../postrm.d To avoid unnecessary updates, the hooks invoked at step a and b may check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and do nothing in this case. [Is this sensible or is it too 'clever'?] what is the intent of that point? sorry you lost me here. 5. Kernel and initramfs builder packages must not invoke boot loaders except via hooks. If /etc/kernel-img.conf contains an explicit 'do_bootloader = yes', kernel package maintainer scripts should warn that this is now ignored. for backward compat and upgrade purpose from lenny, I think the must is wrong. 6. The installer must not define do_bootloader, postinst_hook or postrm_hook in /etc/kernel-img.conf. --- 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/20100628084532.ga23...@stro.at
Re: (was Bug#570350) Google Chrome
On Mon, 2010-06-28 at 08:28 +0100, Berni Elbourn wrote: Ben Hutchings wrote: On Sun, Jun 27, 2010 at 06:50:57PM +0100, Berni Elbourn wrote: [...] PS: For future how does one build the official headers common package on Amd64? Do a full package build with 'pkg-buildpackage -B'. Ben. Wow. Thanks. Also it seems:- # fakeroot debian/rules binary does the job ... eventually :-) By the Way: 570350 is archived and can't be updated - should it be re-opened? Yes, I noticed. I have reopened it now. 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: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 2010-06-28 at 10:45 +0200, maximilian attems wrote: On Mon, 28 Jun 2010, Ben Hutchings wrote: [...] 4. During a kernel package installation, upgrade or removal, various boot loader hooks may be invoked (in this order): a. A postinst_hook or postrm_hook command set by the user or the installer in /etc/kernel-img.conf b. A hook script in /etc/mkinitramfs/post-update.d c. A hook script in /etc/kernel/postinst.d or .../postrm.d To avoid unnecessary updates, the hooks invoked at step a and b may check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and do nothing in this case. [Is this sensible or is it too 'clever'?] what is the intent of that point? sorry you lost me here. I'm wondering whether this is a reasonable way to test whether a kernel package upgrade is in progress. 5. Kernel and initramfs builder packages must not invoke boot loaders except via hooks. If /etc/kernel-img.conf contains an explicit 'do_bootloader = yes', kernel package maintainer scripts should warn that this is now ignored. for backward compat and upgrade purpose from lenny, I think the must is wrong. [...] Do you mean that the boot loader might not get updated during a dist-upgrade? I think that even if the kernel or initramfs builder package is installed/upgraded before the boot loader package is upgraded to include hook scripts, the boot loader package will update the boot loader when it is upgraded. (And the boot loader package is sure to be upgraded in order to add those hook scripts.) 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
Bug#587418: linux-image-2.6.32-5-686: using old IDE driver fails, probably due to missing ide_pci_generic module
Package: linux-2.6 Version: 2.6.32-15 Severity: important The 2.6.32-5-686 kernel uses libata rather than the old IDE driver, which is fine I suppose, but I wanted to use the old IDE driver so I could still use hdparm for e.g. enabling/disabling DMA post-boot (I could go into why, but you probably don't want to know :-)). I eventually figured out how to do this, but it kept waiting for the root all the time. A bit of poking around later, I realised ide-pci-generic.ko was missing from the initrd, so I checked my real /lib/modules and sure enough, it was missing from the 2.6.32-5-686 tree. I could be wrong, but I think this means the old IDE driver is largely impossible to use without building a custom kernel. Since *most* old-IDE-driver-related kernel modules are still being built, I presume this was unintentional, so I'm reporting it as a bug. I can only guess at how general this problem is, so I'm reporting it for the particular package I've personally had the trouble with. -- Package-specific info: ** Version: Linux version 2.6.32-5-686 (Debian 2.6.32-15) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-1) ) #1 SMP Tue Jun 1 04:59:47 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=c5e95b09-66b2-4eb3-94d7-fe188b4eda1b ro nohz=off clocksource=notsc libata.dma=0 quiet ** Not tainted ** Kernel log: [3.063728] uhci_hcd :00:07.3: UHCI Host Controller [3.063811] uhci_hcd :00:07.3: new USB bus registered, assigned bus number 2 [3.063885] uhci_hcd :00:07.3: irq 11, io base 0xd800 [3.064284] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 [3.064295] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [3.064304] usb usb2: Product: UHCI Host Controller [3.064311] usb usb2: Manufacturer: Linux 2.6.32-5-686 uhci_hcd [3.064318] usb usb2: SerialNumber: :00:07.3 [3.067070] usb usb2: configuration #1 chosen from 1 choice [3.067921] hub 2-0:1.0: USB hub found [3.068190] hub 2-0:1.0: 2 ports detected [3.085946] 8139too Fast Ethernet driver 0.9.28 [3.087325] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 12 [3.087338] PCI: setting IRQ 12 as level-triggered [3.087355] 8139too :00:0f.0: PCI INT A - Link[LNKC] - GSI 12 (level, low) - IRQ 12 [3.090692] eth0: RealTek RTL8139 at 0xdc00, 00:30:bd:72:4a:3a, IRQ 12 [3.256550] ata1.00: ATA-6: ST380011A, 8.01, max UDMA/100 [3.256565] ata1.00: 156301488 sectors, multi 16: LBA48 [3.272541] ata1.00: configured for PIO4 [3.273110] scsi 0:0:0:0: Direct-Access ATA ST380011A8.01 PQ: 0 ANSI: 5 [3.372097] usb 1-1: new full speed USB device using uhci_hcd and address 2 [3.436443] ata2.01: ATAPI: _NEC DVD_RW ND-2510A, 2.18, max UDMA/33 [3.444387] ata2.01: configured for PIO4 [3.446631] scsi 1:0:1:0: CD-ROM_NEC DVD_RW ND-2510A 2.18 PQ: 0 ANSI: 5 [3.549170] sd 0:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) [3.549453] sd 0:0:0:0: [sda] Write Protect is off [3.549466] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [3.549640] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [3.550564] sda: sda1 sda2 sda3 [3.574244] usb 1-1: New USB device found, idVendor=0ace, idProduct=1215 [3.574260] usb 1-1: New USB device strings: Mfr=16, Product=32, SerialNumber=0 [3.574270] usb 1-1: Product: USB2.0 WLAN [3.574276] usb 1-1: Manufacturer: ZyDAS [3.574739] usb 1-1: configuration #1 chosen from 1 choice [3.578216] sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray [3.578233] Uniform CD-ROM driver Revision: 3.20 [3.580210] sda5 sda6 [3.590031] sr 1:0:1:0: Attached scsi CD-ROM sr0 [3.601410] sda7 sda4 [3.612601] sd 0:0:0:0: [sda] Attached SCSI disk [3.727737] sd 0:0:0:0: Attached scsi generic sg0 type 0 [3.731225] sr 1:0:1:0: Attached scsi generic sg1 type 5 [4.841688] PM: Starting manual resume from disk [4.841715] PM: Resume from partition 8:1 [4.841720] PM: Checking hibernation image. [4.855577] PM: Error -22 checking image file [4.855588] PM: Resume from disk failed. [8.614002] udev: starting version 157 [9.696246] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 10.992409] Marking TSC unstable due to TSC halts in idle [ 11.009206] processor LNXCPU:00: registered as cooling_device0 [ 11.011056] Switching to clocksource acpi_pm [ 11.039358] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1 [ 11.039431] ACPI: Power Button [PWRB] [ 11.040619] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 [ 11.040666] ACPI: Power Button [PWRF] [ 11.204012] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 11.378209] parport_pc: VIA 686A/8231 detected [ 11.378232] parport_pc: probing current configuration [ 11.378261] parport_pc: Current parallel
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
I took the liberty of adding debian-boot and debian-s390 to the CC list on this e-mail, since it affects the Debian installer and the s390-tools package, which contains the zipl boot loader, which has a design very similar to that of lilo. If this results in some people getting more than one copy of this e-mail, please accept my apologies; but I figured it was better to err on the side of caution in this case. I also added Joachim Wiedorn, the new lilo upstream maintainer (who also happens to be the Debian package maintainer for backup2l). On Sun, 27 Jun 2010 22:02:35 -0400 (EDT), Ben Hutchings wrote: I propose the following policy for squeeze and later releases. This affects all Linux kernel, initramfs builder and boot loader packages, and the installer. I regret that this is happening so late in the release cycle, but currently a kernel update can easily leave the system unbootable and this does need to be addressed before release and I want to do so in a way that is reasonably clean and maintainable. --- 1. Packages for boot loaders that need to be updated whenever the files they load are modified (i.e. those that store a block list) must install hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which will be called on installation/upgrade and removal of kernel packages, respectively. The arguments given to all kernel hook scripts are the kernel ABI version (the string that uname -r reports) and the absolute path to the kernel image. Currently, hook scripts invoked by a stock kernel maintainer script or a maintainer script from a kernel image package created by make-kpkg pass these exact same arguments. But a maintainer script for a kernel image package created by make deb-pkg passes only the first argument. Existing hook scripts rely on that difference to determine whether or not to take action. For example, the initramfs hook script provided by the initramfs-tools package tests the number of arguments and exits without doing anything if more than one argument is supplied. In other words, this hook script is designed to create the initial RAM file system for a kernel image created by make deb-pkg, and only for a kernel image created by make deb-pkg. It does nothing otherwise. Are you proposing to change this behavior? The environment variable DEB_MAINT_PARAMS will contain the arguments given to the kernel maintainer script, single-quoted. Is this environment variable provided by the maintainer scripts that come with kernel image packages created by make deb-pkg? (I honestly don't know. I've never used make deb-pkg.) Since these boot loaders should be updated as the last step during installation/upgrade and removal, hook scripts for boot loaders must be named using the prefix 'zz-' and no other packages may use this prefix or one that sorts later by the rules used by run-parts. A postrm hook script should warn but exit with code 0 if the boot loader configuration file still refers to the kernel image that has been removed. 2. Packages for boot loaders that need to be updated whenever the files they load are modified must also install hook scripts in /etc/mkinitramfs/post-update.d. Initramfs builders must call these scripts using run-parts after they create, update or delete an initramfs. The arguments given to these hook scripts are the kernel ABI version and the absolute path to the initramfs image. 3. Initramfs builders must complete their work before returning from the kernel postinst hook script. [initramfs-tools currently uses a trigger to defer this because it can also be invoked twice, but this means it also has to know how to update specific boot loaders.] 4. During a kernel package installation, upgrade or removal, various boot loader hooks may be invoked (in this order): a. A postinst_hook or postrm_hook command set by the user or the installer in /etc/kernel-img.conf b. A hook script in /etc/mkinitramfs/post-update.d c. A hook script in /etc/kernel/postinst.d or .../postrm.d To avoid unnecessary updates, the hooks invoked at step a and b may check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and do nothing in this case. [Is this sensible or is it too 'clever'?] 5. Kernel and initramfs builder packages must not invoke boot loaders except via hooks. If /etc/kernel-img.conf contains an explicit 'do_bootloader = yes', kernel package maintainer scripts should warn that this is now ignored. At the risk of flogging a dead horse, I would prefer to see do_bootloader = yes supported until Squeeze+1, both by the kernel maintainer scripts and by update-initramfs -u, particularly since we are so close to a freeze. But if you're going to drop support for it in Squeeze, then yes, a warning message is necessary. Both the kernel maintainer scripts *and* update-initramfs -u *must* issue a warning message if they find do_bootloader = yes specified in /etc/kernel-img.conf. In fact, since
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
Hello William, perhaps you have read the recent email from Ben (see below). It would be important to update the lilo package to support these recent requirements to prepare LILO for Squeeze before it will get stable. Do you have the intention to update the lilo package to integrate some scripts for these recent requirements? Have a nice day, Joachim (Germany) --- Ben Hutchings b...@decadent.org.uk wrote on 2010-06-28 03:02: I propose the following policy for squeeze and later releases. This affects all Linux kernel, initramfs builder and boot loader packages, and the installer. I regret that this is happening so late in the release cycle, but currently a kernel update can easily leave the system unbootable and this does need to be addressed before release and I want to do so in a way that is reasonably clean and maintainable. --- 1. Packages for boot loaders that need to be updated whenever the files they load are modified (i.e. those that store a block list) must install hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which will be called on installation/upgrade and removal of kernel packages, respectively. The arguments given to all kernel hook scripts are the kernel ABI version (the string that uname -r reports) and the absolute path to the kernel image. The environment variable DEB_MAINT_PARAMS will contain the arguments given to the kernel maintainer script, single-quoted. Since these boot loaders should be updated as the last step during installation/upgrade and removal, hook scripts for boot loaders must be named using the prefix 'zz-' and no other packages may use this prefix or one that sorts later by the rules used by run-parts. A postrm hook script should warn but exit with code 0 if the boot loader configuration file still refers to the kernel image that has been removed. 2. Packages for boot loaders that need to be updated whenever the files they load are modified must also install hook scripts in /etc/mkinitramfs/post-update.d. Initramfs builders must call these scripts using run-parts after they create, update or delete an initramfs. The arguments given to these hook scripts are the kernel ABI version and the absolute path to the initramfs image. 3. Initramfs builders must complete their work before returning from the kernel postinst hook script. [initramfs-tools currently uses a trigger to defer this because it can also be invoked twice, but this means it also has to know how to update specific boot loaders.] 4. During a kernel package installation, upgrade or removal, various boot loader hooks may be invoked (in this order): a. A postinst_hook or postrm_hook command set by the user or the installer in /etc/kernel-img.conf b. A hook script in /etc/mkinitramfs/post-update.d c. A hook script in /etc/kernel/postinst.d or .../postrm.d To avoid unnecessary updates, the hooks invoked at step a and b may check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and do nothing in this case. [Is this sensible or is it too 'clever'?] 5. Kernel and initramfs builder packages must not invoke boot loaders except via hooks. If /etc/kernel-img.conf contains an explicit 'do_bootloader = yes', kernel package maintainer scripts should warn that this is now ignored. 6. The installer must not define do_bootloader, postinst_hook or postrm_hook in /etc/kernel-img.conf. --- I'm particularly interested to hear whether there are any upgrade issues I have not addressed. Ben. signature.asc Description: PGP signature
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote: --- 1. Packages for boot loaders that need to be updated whenever the files they load are modified (i.e. those that store a block list) must install hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which will be called on installation/upgrade and removal of kernel packages, respectively. The arguments given to all kernel hook scripts are the kernel ABI version (the string that uname -r reports) and the absolute path to the kernel image. Currently, hook scripts invoked by a stock kernel maintainer script or a maintainer script from a kernel image package created by make-kpkg pass these exact same arguments. no. But a maintainer script for a kernel image package created by make deb-pkg passes only the first argument. no. Existing hook scripts rely on that difference to determine whether or not to take action. For example, the initramfs hook script provided by the initramfs-tools package tests the number of arguments and exits without doing anything if more than one argument is supplied. In other words, this hook script is designed to create the initial RAM file system for a kernel image created by make deb-pkg, and only for a kernel image created by make deb-pkg. It does nothing otherwise. Are you proposing to change this behavior? please get your facts right before spamming the world. kthxbye. -- 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/20100628164510.gb9...@baikonur.stro.at
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, Jun 28, 2010 at 01:35:20PM +0100, Ben Hutchings wrote: On Mon, 2010-06-28 at 10:45 +0200, maximilian attems wrote: On Mon, 28 Jun 2010, Ben Hutchings wrote: [...] 4. During a kernel package installation, upgrade or removal, various boot loader hooks may be invoked (in this order): a. A postinst_hook or postrm_hook command set by the user or the installer in /etc/kernel-img.conf b. A hook script in /etc/mkinitramfs/post-update.d c. A hook script in /etc/kernel/postinst.d or .../postrm.d To avoid unnecessary updates, the hooks invoked at step a and b may check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and do nothing in this case. [Is this sensible or is it too 'clever'?] what is the intent of that point? sorry you lost me here. I'm wondering whether this is a reasonable way to test whether a kernel package upgrade is in progress. currently it is easy to tell in /etc/kernel if you are invoked by linux-2.6 as it doesn't define KERNEL_PACKAGE_VERSION. make deb-pkg run-parts invocation doesn't pass at all the second stupid arg. for update-initramfs it shouldn't be necessary as the updates are trigger updated anyway. 5. Kernel and initramfs builder packages must not invoke boot loaders except via hooks. If /etc/kernel-img.conf contains an explicit 'do_bootloader = yes', kernel package maintainer scripts should warn that this is now ignored. for backward compat and upgrade purpose from lenny, I think the must is wrong. [...] Do you mean that the boot loader might not get updated during a dist-upgrade? I think that even if the kernel or initramfs builder package is installed/upgraded before the boot loader package is upgraded to include hook scripts, the boot loader package will update the boot loader when it is upgraded. (And the boot loader package is sure to be upgraded in order to add those hook scripts.) yes the bootloader might be Lenny one and thus no hooks to be run. in partial upgrades you get all kind of crazy pathes, thus it is better to handle the previsous distro. -- 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/20100628165728.gc9...@baikonur.stro.at
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 28 Jun 2010 12:45:10 -0400 (EDT), maximilian attems wrote:
On Mon, 28 Jun 2010 03:02:35 +0100 Ben Hutchings wrote:
The arguments given to all kernel hook scripts are the kernel ABI
version (the string that uname -r reports) and the absolute path to the
kernel image.
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
Currently, hook scripts invoked by a stock kernel maintainer script
or a maintainer script from a kernel image package created by make-kpkg
pass these exact same arguments.
no.
From a Squeeze system running a custom kernel created by make-kpkg:
-
debian3:~# dpkg-reconfigure linux-image-2.6.32-custom5b-s390x
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/S30initramfs 2.6.32-custom5b-s390x
/boot/vmlinuz-2.6.32-custom5b-s390x
^ ^
+-- 1st argument
+-- 2nd argument
-
From a Squeeze system running a stock kernel image:
-
r...@testdebian:~# dpkg-reconfigure linux-image-2.6.32-3-686
Running depmod.
Running update-initramfs: Generating /boot/initrd.img-2.6.32-3-686
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/S30initramfs 2.6.32-3-686
/boot/vmlinuz-2.6.32-3-686
^^
|+-- 2nd
argument
+-- 1st argument
-
Q.E.D.
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
But a maintainer script for a kernel
image package created by make deb-pkg passes only the first argument.
no.
The actual text of /etc/kernel/postinst.d/initramfs-tools:
-
#!/bin/sh
version=$1
bootopt=
# passing the kernel version is required
[ -z ${version} ] exit 0
# kernel-package passes an extra arg
if [ -n $2 ]; then
if [ -n ${KERNEL_PACKAGE_VERSION} ]; then
bootdir=$(dirname $2)
bootopt=-b ${bootdir}
else
# official Debian linux-images take care themself
exit 0
fi
fi
# avoid running multiple times
if [ -n $DEB_MAINT_PARAMS ]; then
eval set -- $DEB_MAINT_PARAMS
if [ -z $1 ] || [ $1 != configure ]; then
exit 0
fi
fi
# we're good - create initramfs. update runs do_bootloader
update-initramfs -c -t -k ${version} ${bootopt}
-
I admit that I have never personally used make deb-pkg, but
clearly the source code speaks for itself. This hook script is
expecting only one argument when invoked by make deb-pkg.
Q.E.D.
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
Existing hook scripts rely on that difference to determine whether or
not to take action. For example, the initramfs hook script provided by
the initramfs-tools package tests the number of arguments and exits
without doing anything if more than one argument is supplied. In other
words, this hook script is designed to create the initial RAM file system
for a kernel image created by make deb-pkg, and only for a kernel
image created by make deb-pkg. It does nothing otherwise. Are you
proposing to change this behavior?
please get your facts right before spamming the world.
OK, you're partly right on this one. Execution tracing shows that it
does nothing when invoked by a stock kernel maintainer script but
does create an initial RAM file system when invoked by a maintainer
script from a kernel image package created by make-kpkg. (By the way,
since this script is running under debconf, output from update-initramfs
should be redirected to standard error via 2.) I don't remember the
kernel-package logic being present in this script the last time I looked
at it.
(1) As far as I am able to determine, my original statements are correct,
with the exception of the correction made in the above paragraph.
If you can prove me wrong, please do so.
(2) This was not spam. Spam is unsolicited advertising.
This was a response to an RFC, to which I was explicitly
included as an adressee.
(3) All the addressees of my e-mail were legitimate stake-holders
in this process. This is not the world.
--
.''`. 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/1137353821.16101.1277752206454.javamail.r...@md01.wow.synacor.com
Bug#587418: marked as done (linux-image-2.6.32-5-686: using old IDE driver fails, probably due to missing ide_pci_generic module)
Your message dated Mon, 28 Jun 2010 20:39:55 +0100 with message-id 20100628193954.ga5...@decadent.org.uk and subject line Re: Bug#587418: linux-image-2.6.32-5-686: using old IDE driver fails, probably due to missing ide_pci_generic module has caused the Debian Bug report #587418, regarding linux-image-2.6.32-5-686: using old IDE driver fails, probably due to missing ide_pci_generic module 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 ow...@bugs.debian.org immediately.) -- 587418: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587418 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-2.6 Version: 2.6.32-15 Severity: important The 2.6.32-5-686 kernel uses libata rather than the old IDE driver, which is fine I suppose, but I wanted to use the old IDE driver so I could still use hdparm for e.g. enabling/disabling DMA post-boot (I could go into why, but you probably don't want to know :-)). I eventually figured out how to do this, but it kept waiting for the root all the time. A bit of poking around later, I realised ide-pci-generic.ko was missing from the initrd, so I checked my real /lib/modules and sure enough, it was missing from the 2.6.32-5-686 tree. I could be wrong, but I think this means the old IDE driver is largely impossible to use without building a custom kernel. Since *most* old-IDE-driver-related kernel modules are still being built, I presume this was unintentional, so I'm reporting it as a bug. I can only guess at how general this problem is, so I'm reporting it for the particular package I've personally had the trouble with. -- Package-specific info: ** Version: Linux version 2.6.32-5-686 (Debian 2.6.32-15) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-1) ) #1 SMP Tue Jun 1 04:59:47 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=c5e95b09-66b2-4eb3-94d7-fe188b4eda1b ro nohz=off clocksource=notsc libata.dma=0 quiet ** Not tainted ** Kernel log: [3.063728] uhci_hcd :00:07.3: UHCI Host Controller [3.063811] uhci_hcd :00:07.3: new USB bus registered, assigned bus number 2 [3.063885] uhci_hcd :00:07.3: irq 11, io base 0xd800 [3.064284] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 [3.064295] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [3.064304] usb usb2: Product: UHCI Host Controller [3.064311] usb usb2: Manufacturer: Linux 2.6.32-5-686 uhci_hcd [3.064318] usb usb2: SerialNumber: :00:07.3 [3.067070] usb usb2: configuration #1 chosen from 1 choice [3.067921] hub 2-0:1.0: USB hub found [3.068190] hub 2-0:1.0: 2 ports detected [3.085946] 8139too Fast Ethernet driver 0.9.28 [3.087325] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 12 [3.087338] PCI: setting IRQ 12 as level-triggered [3.087355] 8139too :00:0f.0: PCI INT A - Link[LNKC] - GSI 12 (level, low) - IRQ 12 [3.090692] eth0: RealTek RTL8139 at 0xdc00, 00:30:bd:72:4a:3a, IRQ 12 [3.256550] ata1.00: ATA-6: ST380011A, 8.01, max UDMA/100 [3.256565] ata1.00: 156301488 sectors, multi 16: LBA48 [3.272541] ata1.00: configured for PIO4 [3.273110] scsi 0:0:0:0: Direct-Access ATA ST380011A8.01 PQ: 0 ANSI: 5 [3.372097] usb 1-1: new full speed USB device using uhci_hcd and address 2 [3.436443] ata2.01: ATAPI: _NEC DVD_RW ND-2510A, 2.18, max UDMA/33 [3.444387] ata2.01: configured for PIO4 [3.446631] scsi 1:0:1:0: CD-ROM_NEC DVD_RW ND-2510A 2.18 PQ: 0 ANSI: 5 [3.549170] sd 0:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) [3.549453] sd 0:0:0:0: [sda] Write Protect is off [3.549466] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [3.549640] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [3.550564] sda: sda1 sda2 sda3 [3.574244] usb 1-1: New USB device found, idVendor=0ace, idProduct=1215 [3.574260] usb 1-1: New USB device strings: Mfr=16, Product=32, SerialNumber=0 [3.574270] usb 1-1: Product: USB2.0 WLAN [3.574276] usb 1-1: Manufacturer: ZyDAS [3.574739] usb 1-1: configuration #1 chosen from 1 choice [3.578216] sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray [3.578233] Uniform CD-ROM driver Revision: 3.20 [3.580210] sda5 sda6 [3.590031] sr 1:0:1:0: Attached scsi CD-ROM sr0 [3.601410] sda7 sda4 [3.612601] sd 0:0:0:0: [sda] Attached SCSI disk [3.727737] sd 0:0:0:0: Attached scsi generic sg0 type 0 [3.731225] sr 1:0:1:0: Attached scsi generic sg1 type 5 [4.841688] PM:
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, Jun 28, 2010 at 03:02:35AM +0100, Ben Hutchings wrote: 1. Packages for boot loaders that need to be updated whenever the files they load are modified (i.e. those that store a block list) must install hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which will be called on installation/upgrade and removal of kernel packages, respectively. It seems to me (particularly from the fact that you upgraded a grub2 bug report about this to important - GRUB 2 does not store block lists for kernels) that this is not limited to boot loaders that store block lists for the files they load: it also affects boot loaders that need to be updated whenever the *list* of files they load is modified. Can you confirm that my understanding is correct? 2. Packages for boot loaders that need to be updated whenever the files they load are modified must also install hook scripts in /etc/mkinitramfs/post-update.d. Initramfs builders must call these scripts using run-parts after they create, update or delete an initramfs. The arguments given to these hook scripts are the kernel ABI version and the absolute path to the initramfs image. Does the same apply here, or not? This is going to be quite a lot of calls to update-grub if so, although at least it's quite a bit faster now than it used to be ... 3. Initramfs builders must complete their work before returning from the kernel postinst hook script. [initramfs-tools currently uses a trigger to defer this because it can also be invoked twice, but this means it also has to know how to update specific boot loaders.] Is an initramfs guaranteed to be built before any of the boot loader hooks are executed? It seems like a waste of time calling boot loader hooks otherwise. (This may be implied by your design, but it was a little bit implicit if so.) 4. During a kernel package installation, upgrade or removal, various boot loader hooks may be invoked (in this order): a. A postinst_hook or postrm_hook command set by the user or the installer in /etc/kernel-img.conf b. A hook script in /etc/mkinitramfs/post-update.d c. A hook script in /etc/kernel/postinst.d or .../postrm.d To avoid unnecessary updates, the hooks invoked at step a and b may check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and do nothing in this case. [Is this sensible or is it too 'clever'?] Sensible, I think. There's no point running update-grub three times. -- Colin Watson [cjwat...@debian.org] -- 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/20100628221906.ga28...@master.debian.org
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 2010-06-28 at 18:57 +0200, maximilian attems wrote: On Mon, Jun 28, 2010 at 01:35:20PM +0100, Ben Hutchings wrote: On Mon, 2010-06-28 at 10:45 +0200, maximilian attems wrote: On Mon, 28 Jun 2010, Ben Hutchings wrote: [...] 4. During a kernel package installation, upgrade or removal, various boot loader hooks may be invoked (in this order): a. A postinst_hook or postrm_hook command set by the user or the installer in /etc/kernel-img.conf b. A hook script in /etc/mkinitramfs/post-update.d c. A hook script in /etc/kernel/postinst.d or .../postrm.d To avoid unnecessary updates, the hooks invoked at step a and b may check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and do nothing in this case. [Is this sensible or is it too 'clever'?] what is the intent of that point? sorry you lost me here. I'm wondering whether this is a reasonable way to test whether a kernel package upgrade is in progress. currently it is easy to tell in /etc/kernel if you are invoked by linux-2.6 as it doesn't define KERNEL_PACKAGE_VERSION. make deb-pkg run-parts invocation doesn't pass at all the second stupid arg. OK. Should we say that if the second argument is missing then the absolute path is /boot/vmlinuz-$version or /boot/vmlinux-$version according to architecture convention? for update-initramfs it shouldn't be necessary as the updates are trigger updated anyway. 5. Kernel and initramfs builder packages must not invoke boot loaders except via hooks. If /etc/kernel-img.conf contains an explicit 'do_bootloader = yes', kernel package maintainer scripts should warn that this is now ignored. for backward compat and upgrade purpose from lenny, I think the must is wrong. [...] Do you mean that the boot loader might not get updated during a dist-upgrade? I think that even if the kernel or initramfs builder package is installed/upgraded before the boot loader package is upgraded to include hook scripts, the boot loader package will update the boot loader when it is upgraded. (And the boot loader package is sure to be upgraded in order to add those hook scripts.) yes the bootloader might be Lenny one and thus no hooks to be run. in partial upgrades you get all kind of crazy pathes, thus it is better to handle the previsous distro. You're thinking of a system with lilo from lenny and initramfs-tools from squeeze? Yes, I see that would be a problem. How do we keep initramfs-tools working in this case while still allowing newer boot loader packages to avoid redundant updates? Could we say that initramfs-tools mustn't invoke boot loaders directly if /etc/initramfs/post-update.d exists and is non-empty? 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: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 2010-06-28 at 22:19 +, Colin Watson wrote: On Mon, Jun 28, 2010 at 03:02:35AM +0100, Ben Hutchings wrote: 1. Packages for boot loaders that need to be updated whenever the files they load are modified (i.e. those that store a block list) must install hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which will be called on installation/upgrade and removal of kernel packages, respectively. It seems to me (particularly from the fact that you upgraded a grub2 bug report about this to important - GRUB 2 does not store block lists for kernels) that this is not limited to boot loaders that store block lists for the files they load: it also affects boot loaders that need to be updated whenever the *list* of files they load is modified. Can you confirm that my understanding is correct? Sorry, I managed to lose this sentence during editing: 'Packages for boot loaders that can provide a menu of kernel versions should install kernel hook scripts in order to update that menu.' 2. Packages for boot loaders that need to be updated whenever the files they load are modified must also install hook scripts in /etc/mkinitramfs/post-update.d. Initramfs builders must call these scripts using run-parts after they create, update or delete an initramfs. The arguments given to these hook scripts are the kernel ABI version and the absolute path to the initramfs image. Does the same apply here, or not? This is going to be quite a lot of calls to update-grub if so, although at least it's quite a bit faster now than it used to be ... No. 3. Initramfs builders must complete their work before returning from the kernel postinst hook script. [initramfs-tools currently uses a trigger to defer this because it can also be invoked twice, but this means it also has to know how to update specific boot loaders.] Is an initramfs guaranteed to be built before any of the boot loader hooks are executed? It seems like a waste of time calling boot loader hooks otherwise. (This may be implied by your design, but it was a little bit implicit if so.) [...] This requirement and the naming requirements on hook scripts are intended to guarantee 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: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
Please reply to debian-kernel only. On Mon, 2010-06-28 at 11:16 -0400, Stephen Powell wrote: On Sun, 27 Jun 2010 22:02:35 -0400 (EDT), Ben Hutchings wrote: [...] The environment variable DEB_MAINT_PARAMS will contain the arguments given to the kernel maintainer script, single-quoted. Is this environment variable provided by the maintainer scripts that come with kernel image packages created by make deb-pkg? (I honestly don't know. I've never used make deb-pkg.) It has done since 2.6.31, though without single-quotes. I'll note that they may or may not be quoted, and recommend how to use this variable. [...] 5. Kernel and initramfs builder packages must not invoke boot loaders except via hooks. If /etc/kernel-img.conf contains an explicit 'do_bootloader = yes', kernel package maintainer scripts should warn that this is now ignored. At the risk of flogging a dead horse, I would prefer to see do_bootloader = yes supported until Squeeze+1, both by the kernel maintainer scripts and by update-initramfs -u, particularly since we are so close to a freeze. The release team has stated we are not close to a freeze. So we have a little time to sort this out. But if you're going to drop support for it in Squeeze, then yes, a warning message is necessary. Both the kernel maintainer scripts *and* update-initramfs -u *must* issue a warning message if they find do_bootloader = yes specified in /etc/kernel-img.conf. In fact, since the default value is yes, they should issue the warning message unless do_bootloader is *explicitly* set to no. I can put a one-time warning into linux-base. But the default for squeeze must be 'no'. It should not be necessary to create /etc/kernel-img.conf at all in squeeze. 6. The installer must not define do_bootloader, postinst_hook or postrm_hook in /etc/kernel-img.conf. Doesn't this conflict with point 4 (a)? Not at all. This means postinst_hook and postrm_hook are now strictly for use by the user. 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: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 2010-06-28 at 18:45 +0200, maximilian attems wrote: [...] please get your facts right before spamming the world. Max, this is rude and unjustified. 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
Bug#586554: initramfs-tools fails to upgrade from 0.96.1 to 0.97
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010年06月28日 17:31, maximilian attems wrote: On Mon, Jun 28, 2010 at 05:16:40PM +0900, Olaf Meeuwissen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Image Scan! for Linux upstream maintainer here. Care to point out why iscan is the culprit? I went through the logs but nothing ran a bell. you are sending the message to the wrong recipient. we do not maintain that iscan software, nor their initramfs-tools hooks please nag them. # I'd have to nag myself then. I maintain iscan. Let me put the question differently then. What exactly led to the conclusion that iscan's initramfs hooks are the culprit. There is nothing in the log that gives me any clues about why iscan is the culprit. The hook provided by iscan is so trivial (and has worked fine upto at leat 0.94.4) that I don't see what is wrong. - -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwpKesACgkQt5qrxaZLMnJP3wCgiSBSapcyBZO8E2GVg5qlhdfD dSQAniUBAj9VPxBENNs6T5drJ/gbb9xF =ZEYY -END PGP SIGNATURE- -- 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/4c2929eb.8020...@avasys.jp
Bug#586554: initramfs-tools fails to upgrade from 0.96.1 to 0.97
On Tue, Jun 29, 2010 at 08:02:03AM +0900, Olaf Meeuwissen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010???06???28??? 17:31, maximilian attems wrote: On Mon, Jun 28, 2010 at 05:16:40PM +0900, Olaf Meeuwissen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Image Scan! for Linux upstream maintainer here. Care to point out why iscan is the culprit? I went through the logs but nothing ran a bell. you are sending the message to the wrong recipient. we do not maintain that iscan software, nor their initramfs-tools hooks please nag them. # I'd have to nag myself then. I maintain iscan. Let me put the question differently then. What exactly led to the conclusion that iscan's initramfs hooks are the culprit. There is nothing in the log that gives me any clues about why iscan is the culprit. The hook provided by iscan is so trivial (and has worked fine upto at leat 0.94.4) that I don't see what is wrong. I haven't looked at the iscan hook script yet. The difference in initramfs-tools is that now the hooks are run under errexit and thus may abort. afair it has been determined that your hook script fails (mkinitramfs needs to be more explicit about what goes on). -- 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/20100628225506.gd9...@baikonur.stro.at
Bug#585655: linux-image-2.6-686: 2xwireless 360 gamepads arent working. Please can hardware works under LINUX for once ?
On Mon, 2010-06-28 at 08:59 +0200, yellow protoss wrote: Dear Ben Unfortunately daily life is also asking, so sorry that I cannot reply daily. So I tried a new solution: - REMOVE ALL USB DEVICES FIRST! 1.I plugged the USB-emetter1 and DID NOT plug hte USB-emetter2 into the PC tower Intel. Dmesg says :seen and up to js4 arrives in /dev/input 2.I pressed on the button of USB-emetter1 few sec. for establishing scanning 3. I press the main blincking of button of xbox360wireless-gamepad1 and get a confirmation that USB-emetter1 saw it and actived the connection 4.I pressed on the button of USB-emetter2 few sec. for establishing scanning Do you mean 1 or 2 here? 5. I press the main blincking of button of xbox360wireless-gamepad2 and get a confirmation that USB-emetter1 saw it and actived the connection 6. jstest /dev/input/js1 jstest /dev/input/js2 working, so ? Well I am finding that my USB microsoft Internet explorer keyboard was messing up all the programs. [...] How did you find that? I think the important change you made was removing the second USB wireless adapter. 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
Bug#570350: pid_ns child_reaper fixes for 2.6.26
I'm trying to fix a bug http://bugs.debian.org/570350 in Linux 2.6.26 as packaged in Debian, which is triggered by the sandbox mechanism in the Chrome/Chromium browser. This appears to have been fixed by Oleg's changes in 2.6.27: commit add0d4dfd660e9e4fd0af3eac3cad23583c9558f Author: Oleg Nesterov o...@tv-sign.ru Date: Tue Sep 2 14:35:48 2008 -0700 pid_ns: zap_pid_ns_processes: fix the -child_reaper changing commit 950bbabb5a804690a0201190de5c22837f72f83f Author: Oleg Nesterov o...@tv-sign.ru Date: Tue Sep 2 14:35:49 2008 -0700 pid_ns: (BUG 11391) change -child_reaper when init-group_leader exits I've attempted to cherry-pick and adjust these for 2.6.26; patches below. Do these look reasonable or are additional changes required? Ben. --- From: Oleg Nesterov o...@tv-sign.ru Date: Tue, 2 Sep 2008 14:35:48 -0700 Subject: [PATCH 1/2] pid_ns: zap_pid_ns_processes: fix the -child_reaper changing commit add0d4dfd660e9e4fd0af3eac3cad23583c9558f upstream. zap_pid_ns_processes() sets pid_ns-child_reaper = NULL, this is wrong. Yes, we have already killed all tasks in this namespace, and sys_wait4() doesn't see any child. But this doesn't mean -children list is empty, we may have EXIT_DEAD tasks which are not visible to do_wait(). In that case the subsequent forget_original_parent() will crash the kernel because it will try to re-parent these tasks to the NULL reaper. Even if there are no childs, it is not good that forget_original_parent() uses reaper == NULL. Change the code to set -child_reaper = init_pid_ns.child_reaper instead. We could use pid_ns-parent-child_reaper as well, I think this does not really matter. These EXIT_DEAD tasks are not visible to the new -parent after re-parenting, they will silently do release_task() eventually. Note that we must change -child_reaper, otherwise forget_original_parent() will use reaper == father, and in that case we will hit the (correct) BUG_ON(!list_empty(father-children)). Signed-off-by: Oleg Nesterov o...@tv-sign.ru Acked-by: Serge Hallyn se...@us.ibm.com Acked-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com Acked-by: Pavel Emelyanov xe...@openvz.org Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org [bwh: Adjust context for 2.6.26] --- kernel/pid_namespace.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c index ea567b7..598f1ee 100644 --- a/kernel/pid_namespace.c +++ b/kernel/pid_namespace.c @@ -182,9 +182,12 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns) rc = sys_wait4(-1, NULL, __WALL, NULL); } while (rc != -ECHILD); - - /* Child reaper for the pid namespace is going away */ - pid_ns-child_reaper = NULL; + /* +* We can not clear -child_reaper or leave it alone. +* There may by stealth EXIT_DEAD tasks on -children, +* forget_original_parent() must move them somewhere. +*/ + pid_ns-child_reaper = init_pid_ns.child_reaper; return; } --- From: Oleg Nesterov o...@tv-sign.ru Date: Tue, 2 Sep 2008 14:35:49 -0700 Subject: [PATCH 2/2] pid_ns: (BUG 11391) change -child_reaper when init-group_leader exits commit 950bbabb5a804690a0201190de5c22837f72f83f upstream. We don't change pid_ns-child_reaper when the main thread of the subnamespace init exits. As Robert Rex robert@exasol.com pointed out this is wrong. Yes, the re-parenting itself works correctly, but if the reparented task exits it needs -parent-nsproxy-pid_ns in do_notify_parent(), and if the main thread is zombie its -nsproxy was already cleared by exit_task_namespaces(). Introduce the new function, find_new_reaper(), which finds the new -parent for the re-parenting and changes -child_reaper if needed. Kill the now unneeded exit_child_reaper(). Also move the changing of -child_reaper from zap_pid_ns_processes() to find_new_reaper(), this consolidates the games with -child_reaper and makes it stable under tasklist_lock. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=11391 Reported-by: Robert Rex robert@exasol.com Signed-off-by: Oleg Nesterov o...@tv-sign.ru Acked-by: Serge Hallyn se...@us.ibm.com Acked-by: Pavel Emelyanov xe...@openvz.org Acked-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org [bwh: Adjust context for 2.6.26] --- kernel/exit.c | 78 +--- kernel/pid_namespace.c |6 2 files changed, 34 insertions(+), 50 deletions(-) diff --git a/kernel/exit.c b/kernel/exit.c index 75c6473..25ed2ad 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -758,23 +758,48 @@ static void reparent_thread(struct task_struct *p, struct task_struct *father) * the child reaper process (ie init) in our pid * space. */ +static struct task_struct
Bug#488566: some info
Please reply to all. On Mon, 2010-06-28 at 19:03 +, Fito . wrote: hello ben. sorry, but i fail to build the kernel package base on the guide you sent me. but it was probably just because my incompetence in the subject and the complete lack of experience on linux (and no programming knowledge whatsoever for that matter). i tried under my debian testing system (i used the squeeze patch), the kernel was compile but upon install there was a dependency that failed to comply. What was the error message? i will try to patch and compile using make-kpkg --initrd --added-patches=... [...] That should also work. 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
Bug#586554: initramfs-tools fails to upgrade from 0.96.1 to 0.97
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2010?06?29? 07:55, maximilian attems wrote:
On Tue, Jun 29, 2010 at 08:02:03AM +0900, Olaf Meeuwissen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2010???06???28??? 17:31, maximilian attems wrote:
On Mon, Jun 28, 2010 at 05:16:40PM +0900, Olaf Meeuwissen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Image Scan! for Linux upstream maintainer here.
Care to point out why iscan is the culprit? I went through the logs but
nothing ran a bell.
you are sending the message to the wrong recipient.
we do not maintain that iscan software, nor their initramfs-tools hooks
please nag them.
# I'd have to nag myself then. I maintain iscan.
Let me put the question differently then. What exactly led to the
conclusion that iscan's initramfs hooks are the culprit.
There is nothing in the log that gives me any clues about why iscan is
the culprit. The hook provided by iscan is so trivial (and has worked
fine upto at leat 0.94.4) that I don't see what is wrong.
I haven't looked at the iscan hook script yet. The difference in
initramfs-tools is that now the hooks are run under errexit and
thus may abort. afair it has been determined that your hook script
fails (mkinitramfs needs to be more explicit about what goes on).
Thanks for the info. I've checked the dash and bash manual pages but
running under errexit seems to be the same as using `set -e`. The hook
provided by iscan has done a `set -e` from the beginning so that can't
be the reason (unless I misunderstood the errexit stuff).
FTR, I've attached the hook scripts template. The @...@ stuff is
substituted at package build time.
Hope this helps,
- --
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962 Help support software freedom
http://www.fsf.org/jf?referrer=1962
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwpOOIACgkQt5qrxaZLMnKNRgCghiCZgHJZZ1jKzlL8Zmkg+T36
iiMAoI2eRFWZGjdRTCWETdtQU2audlB6
=VZ4p
-END PGP SIGNATURE-
#! /bin/sh
# Copyright (C) 2009 SEIKO EPSON CORPORATION
#
# License: GPLv2+
state_d...@deb_configure_localstatedir@/lib/@DEB_SOURCE_PACKAGE@
set -e
PREREQS=udev
prereqs()
{
echo $PREREQS
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
test -r $STATE_DIR/clean-files || exit 0
awk '{print $2}' $STATE_DIR/clean-files \
| while read file; do
test -e ${DESTDIR}$file rm -f ${DESTDIR}$file
done
Bug#520468: Incorporate fixes for WUSB54GS support from 2.6.33
On Thu, 2010-06-24 at 02:51 +0100, Luís Picciochi Oliveira wrote: On Thu, Jun 24, 2010 at 2:27 AM, Ben Hutchings b...@decadent.org.uk wrote: Please can you confirm or correct the following summary of your results so far: Debian 2.6.32-15: fails to pass traffic Correct. Debian 2.6.32-15 with patch reverted: good I had no crashes since Monday (June 21st). So, apparently yes. It used to take a while to crash: minutes to hours. But so far it hasn't failed. Debian 2.6.34-1~experimental.2: fails to pass traffic Debian 2.6.34-1~experimental.2 with patch reverted: driver crashes! The driver crashes as soon as I plug the adapter with both versions. Now that I compare them, the crash logs with and without the patch seem to be exactly the same crash. I just rebooted to test with a vanilla 2.6.34 kernel from kernel.org: it also crashes with the same error. I'm attaching the log from that kernel. I think the attached patch will fix this. Please test it. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. From 97b812bf3f4abd5d554f38bc67a8d7fd6ab97d6d Mon Sep 17 00:00:00 2001 From: Ben Hutchings b...@decadent.org.uk Date: Tue, 29 Jun 2010 02:15:48 +0100 Subject: [PATCH] usbnet: Set parent device early for netdev_printk() netdev_printk() follows the net_device's parent device pointer, so we must set that earlier than we previously did. --- drivers/net/usb/usbnet.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index a95c73d..81c76ad 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -1293,6 +1293,9 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod) goto out; } + /* netdev_printk() needs this so do it as early as possible */ + SET_NETDEV_DEV(net, udev-dev); + dev = netdev_priv(net); dev-udev = xdev; dev-intf = udev; @@ -1377,8 +1380,6 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod) dev-rx_urb_size = dev-hard_mtu; dev-maxpacket = usb_maxpacket (dev-udev, dev-out, 1); - SET_NETDEV_DEV(net, udev-dev); - if ((dev-driver_info-flags FLAG_WLAN) != 0) SET_NETDEV_DEVTYPE(net, wlan_type); if ((dev-driver_info-flags FLAG_WWAN) != 0) -- 1.7.1 signature.asc Description: This is a digitally signed message part
Bug#587215: [linux-image-2.6.32-5-686]
Subject: Re: module for usb ethernet ax8817x 0b95:1780 not working Package: linux-2.6 Version: 2.6.32-15 Severity: normal Hello Ben, OK, *** Please type your report below this line *** OK reconfigured to restore the bug: - remove device modprobe -r asix aptitude reinstall linux-image-2.6.32-5-686 - plug in device dmesg (checked and see the debian driver, OK eth2) Try to reconfigure network #!/bin/bash sudo /etc/init.d/networking stop [ -e /etc/network/interfaces ] sudo mv --verbose /etc/network/interfaces /etc/network/interfaces.backup sudo touch /etc/network/interfaces echo auto lo | sudo tee -a /etc/network/interfaces echo iface lo inet loopback | sudo tee -a /etc/network/interfaces echo | sudo tee -a /etc/network/interfaces echo auto eth2 | sudo tee -a /etc/network/interfaces echo iface eth2 inet dhcp | sudo tee -a /etc/network/interfaces echo | sudo tee -a /etc/network/interfaces sudo /etc/init.d/networking restart exit Will wait for a reply- but never comes- see attachment On Sun, Jun 27, 2010 at 7:40 PM, Ben Hutchings b...@decadent.org.uk wrote: OK, and for comparison, can you repeat that while using the original driver? (Temporarily remove the driver you got from the manufacturer.) Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. reportbug-587215-20100629-2919-CBUGkx Description: Binary data
