Bug#344711: linux-image-2.6.14-2-powerpc: Can't install
reassign 344711 linux-2.6 retitle 344711 [powerpc] linux-image-2.6.14-2-powerpc: Can't install merge 344711 344416 thanks On Sun, Dec 25, 2005 at 02:50:19AM +0100, Benoît Dejean wrote: Package: linux-image-2.6.14-2-powerpc Version: 2.6.14-6 Severity: grave Justification: renders package unusable Configuring hangs on GET mkvmlinuz/bootloaders. Known problem for which we don't really have a solution yet, in the meantime, you can edit /etc/kernel/*/mkvmlinuz, and remove the 3 debconf lines and set bootloaders to mkvmlinuz or yaboot depending on your choice. Merging with the other bug report about this (make sure to check bug reports before fillinf next time :) Oh, and happy christmas :) Friendly, Sven Luther
Processed: #341452
Processing commands for [EMAIL PROTECTED]: clone 341452 -1 Bug#341452: lvm2: v2.02.00-1: breaks VGs: device-mapper ioctl cmd 9 failed: Invalid argument Bug 341452 cloned as bug 344741. retitle -1 kernel-source-2.6.8 - device-mapper patch lacks support for major/minor device resolution Bug#344741: lvm2: v2.02.00-1: breaks VGs: device-mapper ioctl cmd 9 failed: Invalid argument Changed Bug title. block 341452 with -1 Bug number -1 not found. Unknown blocking bug/s: -1. Bug#341452: lvm2: v2.02.00-1: breaks VGs: device-mapper ioctl cmd 9 failed: Invalid argument Was not blocked by any bugs. Blocking bugs added: reassign -1 kernel-source-2.6.8 Bug#344741: kernel-source-2.6.8 - device-mapper patch lacks support for major/minor device resolution Bug reassigned from package `lvm2' to `kernel-source-2.6.8'. -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 344741 to kernel-source-2.4.27 ...
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.10 reassign 344741 kernel-source-2.4.27 Bug#344741: kernel-source-2.6.8 - device-mapper patch lacks support for major/minor device resolution Bug reassigned from package `kernel-source-2.6.8' to `kernel-source-2.4.27'. retitle 344741 kernel-source-2.4.27 - device-mapper patch lacks support for major/minor device resolution Bug#344741: kernel-source-2.6.8 - device-mapper patch lacks support for major/minor device resolution Changed Bug title. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343227: linux-image-2.6.12-1-amd64-k8-smp: clock running much too fast
Hello, can you please give latest 2.6.14 package from unstable a try, is the problem still present? Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: [kernel] r5087 - in dists/trunk/linux-2.6/debian/arch: alpha amd64 hppa i386 ia64 s390
On Sun, Dec 25, 2005 at 01:31:34PM +, Frederik Sch??ler wrote: Author: fschueler-guest Date: Sun Dec 25 13:31:33 2005 New Revision: 5087 Modified: dists/trunk/linux-2.6/debian/arch/alpha/config dists/trunk/linux-2.6/debian/arch/amd64/config dists/trunk/linux-2.6/debian/arch/hppa/config dists/trunk/linux-2.6/debian/arch/i386/config dists/trunk/linux-2.6/debian/arch/ia64/config dists/trunk/linux-2.6/debian/arch/s390/config Log: Activate CONFIG_CC_OPTIMIZE_FOR_SIZE on all architectures but sparc, which is known to be broken. sparc is fixed in -rc7. the kernel build has been passing a bogus parameter to gcc which caused the problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [kernel] r5087 - in dists/trunk/linux-2.6/debian/arch: alpha amd64 hppa i386 ia64 s390
Hello, On Sun, Dec 25, 2005 at 06:37:32PM +0100, Christoph Hellwig wrote: Activate CONFIG_CC_OPTIMIZE_FOR_SIZE on all architectures but sparc, which is known to be broken. sparc is fixed in -rc7. the kernel build has been passing a bogus parameter to gcc which caused the problems. thanks for pointing this out, changes where just committed to svn. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Processed: reassign 344754 to initramfs-tools
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.8.14 reassign 344754 initramfs-tools Bug#344754: fails to load ide-disk, doesn't find hdd Warning: Unknown package 'initramfs' Bug reassigned from package `initramfs' to `initramfs-tools'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: automatic custom kernels?
Andreas Barth schrieb am Friday, den 16. December 2005: 1. Automatically obtain the latest list of kernel-patch packages (patch packages can be hinted out that are known to be problematic, or only apply to upstream vanilla) 2. Automatically obtain the latest list of linux-source packages 3. If either #1 or #2 has new items, proceed 4. Individually attempt to apply each patch (verbose) to source making patch logs available, if failure is detected do not proceed 5. If indicated somewhere attempt to apply a second patch (allowing for kernels with grsecurity+vserver patches for example) we could for a first round make a list of apply patches foo, bar, baz, so that these patches are applied in this order. I think the first step would be to get a process together to handle single kernel patches first. Once this is sorted out, then we can look at the larger idea of multiple different patches. I was thinking it might be an interesting idea to try and do this in a similar way as is taken with buildds. A patch is somehow queued to be applied to the kernels. The queue runs and pulls the kernel source and the kernel patch, unpacks the kernel source, runs /usr/src/kernel-patches/all/apply/$patchname and then mails the patch maintainer the results. If they sign the log and return it this means that they have verified that the patch has applied cleanly, and the kernel-patch+kernel_version would then proceed to be compiled. I'm not sure if this extra confirmation would be necessary as it might be trivial to just test the result-code of the attempted patch and not proceed if it is non-zero. This needs some scripting to see how it would work. The solution to this could be having a separate repository for these patched kernel images, so you would have to make a conscious decision to use this repository and thus would know what you are getting into. Well, perhaps we even should make the patches to be part of the filename, so you can get something like deb $url vserver/ oder deb $url vserver-grsecurity/ With this szenario, you get only the kernels to see that you really want. This would be good, although it would be better if users did not have to add a new entry to their sources.list to be able to find these patched kernels. However, I'm wary of uploading patched kernels to the main archive for all the different flavors as this would quickly result in a looong list of available kernels, which can cause confusion. Micah signature.asc Description: Digital signature
Re: Bug#344613: udev: external disk requires manual modprobe now
On Dec 26, GSR [EMAIL PROTECTED] wrote: Well, but after the last dist-upgrade (which included udev 0.079-1, but also debconf debconf-i18n debconf-utils ethereal ethereal-common kernel-package libruby1.8 nano ruby1.8 udev yaird zsh) it seems to have solved and plugin it makes the devices appear as before. So maybe it was a kernel 2.6.14 vs udev 0.076 mismatch? There is no known mismatch (and I doubt that one exists), and the changes between 076 and 079 are very minor. -- ciao, Marco signature.asc Description: Digital signature
Bug#344613: udev: external disk requires manual modprobe now
Hi, [EMAIL PROTECTED] (2005-12-24 at 1039.26 +0100): reassign 344613 linux-2.6 thanks On Dec 24, GSR [EMAIL PROTECTED] wrote: Previously an external disk got its device nodes created correctly, but that does not seem to happen anymore. The only way to get it working seems to be is loading by hand sbp2 module when used via ieee1384 or usb-storage when pluged via usb2 connector. Once I do that, logs show proper identification of device (vendor, type, partitions...) and devices become avaliable (sdc*). Without those modules all I can see is info about devices being added or removed, reported by each bus when I plug and unplug it. This looks like a kernel bug. Well, but after the last dist-upgrade (which included udev 0.079-1, but also debconf debconf-i18n debconf-utils ethereal ethereal-common kernel-package libruby1.8 nano ruby1.8 udev yaird zsh) it seems to have solved and plugin it makes the devices appear as before. So maybe it was a kernel 2.6.14 vs udev 0.076 mismatch? GSR -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344613: marked as done (udev: external disk requires manual modprobe now)
Your message dated Mon, 26 Dec 2005 01:26:45 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#344613: udev: external disk requires manual modprobe now has caused the attached Bug report 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 I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 24 Dec 2005 03:06:25 + From [EMAIL PROTECTED] Fri Dec 23 19:06:25 2005 Return-path: [EMAIL PROTECTED] Received: from 16.red-80-32-164.staticip.rima-tde.net ([80.32.164.16] helo=fake.com ident=0) by spohr.debian.org with esmtp (Exim 4.50) id 1Epzjl-0008M9-8H for [EMAIL PROTECTED]; Fri, 23 Dec 2005 19:06:25 -0800 Received: (from [EMAIL PROTECTED]) by fake.com (8.11.6/8.11.6) id jBO36Lc06243 for [EMAIL PROTECTED]; Sat, 24 Dec 2005 04:06:21 +0100 Date: Sat, 24 Dec 2005 04:06:21 +0100 From: GSR [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: udev: external disk requires manual modprobe now Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 Package: udev Version: 0.076-6 Severity: normal Previously an external disk got its device nodes created correctly, but that does not seem to happen anymore. The only way to get it working seems to be is loading by hand sbp2 module when used via ieee1384 or usb-storage when pluged via usb2 connector. Once I do that, logs show proper identification of device (vendor, type, partitions...) and devices become avaliable (sdc*). Without those modules all I can see is info about devices being added or removed, reported by each bus when I plug and unplug it. -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 4 lrwxrwxrwx 1 root root 20 2005-08-14 20:53 020_permissions.rules - ../permissions.rules -rw-r--r-- 1 root root 120 2005-02-12 11:42 10-wacom.rules lrwxrwxrwx 1 root root 19 2005-08-14 20:53 cd-aliases.rules - ../cd-aliases.rules lrwxrwxrwx 1 root root 13 2005-08-14 20:53 udev.rules - ../udev.rules lrwxrwxrwx 1 root root 19 2005-11-10 03:30 z20_persistent.rules - ../persistent.rules lrwxrwxrwx 1 root root 12 2005-11-10 03:30 z50_run.rules - ../run.rules lrwxrwxrwx 1 root root 16 2005-11-10 03:30 z55_hotplug.rules - ../hotplug.rules lrwxrwxrwx 1 root root 19 2005-11-10 03:43 z60_alsa-utils.rules - ../alsa-utils.rules lrwxrwxrwx 1 root root 15 2005-10-31 20:19 z60_hdparm.rules - ../hdparm.rules lrwxrwxrwx 1 root root 17 2005-11-10 03:30 z70_hotplugd.rules - ../hotplugd.rules -- /sys/: /sys/block/hda/dev /sys/block/hda/hda1/dev /sys/block/hda/hda2/dev /sys/block/hda/hda3/dev /sys/block/hdb/dev /sys/block/hdb/hdb1/dev /sys/block/hdb/hdb2/dev /sys/block/hdb/hdb3/dev /sys/block/hdc/dev /sys/block/hdd/dev /sys/block/md0/dev /sys/block/md1/dev /sys/block/md2/dev /sys/block/md3/dev /sys/block/md4/dev /sys/block/md5/dev /sys/block/md6/dev /sys/block/ram0/dev /sys/block/ram1/dev /sys/block/ram10/dev /sys/block/ram11/dev /sys/block/ram12/dev /sys/block/ram13/dev /sys/block/ram14/dev /sys/block/ram15/dev /sys/block/ram2/dev /sys/block/ram3/dev /sys/block/ram4/dev /sys/block/ram5/dev /sys/block/ram6/dev /sys/block/ram7/dev /sys/block/ram8/dev /sys/block/ram9/dev /sys/block/sda/dev /sys/block/sda/sda1/dev /sys/block/sda/sda10/dev /sys/block/sda/sda2/dev /sys/block/sda/sda3/dev /sys/block/sda/sda4/dev /sys/block/sda/sda5/dev /sys/block/sda/sda6/dev /sys/block/sda/sda7/dev /sys/block/sda/sda8/dev /sys/block/sda/sda9/dev /sys/block/sdb/dev /sys/block/sdb/sdb1/dev /sys/block/sdb/sdb10/dev /sys/block/sdb/sdb2/dev /sys/block/sdb/sdb3/dev /sys/block/sdb/sdb4/dev /sys/block/sdb/sdb5/dev /sys/block/sdb/sdb6/dev /sys/block/sdb/sdb7/dev /sys/block/sdb/sdb8/dev /sys/block/sdb/sdb9/dev /sys/block/sdc/dev /sys/block/sdc/sdc1/dev /sys/block/sdc/sdc2/dev /sys/class/input/event0/dev /sys/class/input/event1/dev /sys/class/input/mice/dev /sys/class/input/mouse0/dev /sys/class/misc/device-mapper/dev /sys/class/misc/hpet/dev /sys/class/misc/psaux/dev /sys/class/misc/rtc/dev /sys/class/usb_device/usbdev1.1/dev /sys/class/usb_device/usbdev1.4/dev /sys/class/usb_device/usbdev2.1/dev /sys/class/usb_device/usbdev3.1/dev /sys/class/usb_device/usbdev4.1/dev -- Kernel configuration: -- System
