2.6.30 source into testing?
Is there any chance of linux-source 2.6.30 migrating to testing any time soon? John -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535440: [REGRESSION] 2.6.30 fails to boot [amd64]
Package: linux-image-2.6.30-1-amd64 Version: 2.6.30-1 Severity: critical This kernel fails to boot on my computer.. I have a whole screen of backtrace info. It is not saved in the syslog. I wrote down some of the lines. [ 6.230405] [8023411b]? wakeup_preempt_system+0x91/0x9e [ 6.231010] EOI [8031e7] ? cap_inode_alloc_security+0x0/0x3 [ 6.231300] [8020fa42] ? system_call_fastpath+0x16/0x1b 2.6.29 works. -- Package-specific info: -- System Information: Debian Release: squeeze/sid APT prefers unstable-i386 APT policy: (500, 'unstable-i386'), (500, 'transitional-i386'), (500, 'transitional'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-2-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.30-1-amd64 depends on: ii debconf [debconf-2.0] 1.5.26 Debian configuration management sy ii initramfs-tools [linux-initra 0.93.3 tools for generating an initramfs ii module-init-tools 3.9-2 tools for managing Linux kernel mo linux-image-2.6.30-1-amd64 recommends no packages. Versions of packages linux-image-2.6.30-1-amd64 suggests: ii grub 0.97-53GRand Unified Bootloader (Legacy v pn linux-doc-2.6.30 none (no description available) -- debconf information: linux-image-2.6.30-1-amd64/preinst/initrd-2.6.30-1-amd64: linux-image-2.6.30-1-amd64/postinst/create-kimage-link-2.6.30-1-amd64: true linux-image-2.6.30-1-amd64/preinst/abort-overwrite-2.6.30-1-amd64: linux-image-2.6.30-1-amd64/postinst/kimage-is-a-directory: linux-image-2.6.30-1-amd64/preinst/lilo-initrd-2.6.30-1-amd64: true linux-image-2.6.30-1-amd64/prerm/removing-running-kernel-2.6.30-1-amd64: true linux-image-2.6.30-1-amd64/preinst/elilo-initrd-2.6.30-1-amd64: true linux-image-2.6.30-1-amd64/postinst/depmod-error-2.6.30-1-amd64: false linux-image-2.6.30-1-amd64/preinst/failed-to-move-modules-2.6.30-1-amd64: linux-image-2.6.30-1-amd64/postinst/old-system-map-link-2.6.30-1-amd64: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.30-1-amd64/postinst/bootloader-error-2.6.30-1-amd64: linux-image-2.6.30-1-amd64/preinst/lilo-has-ramdisk: linux-image-2.6.30-1-amd64/postinst/old-dir-initrd-link-2.6.30-1-amd64: true linux-image-2.6.30-1-amd64/postinst/old-initrd-link-2.6.30-1-amd64: true linux-image-2.6.30-1-amd64/prerm/would-invalidate-boot-loader-2.6.30-1-amd64: true linux-image-2.6.30-1-amd64/preinst/bootloader-initrd-2.6.30-1-amd64: true linux-image-2.6.30-1-amd64/preinst/overwriting-modules-2.6.30-1-amd64: true linux-image-2.6.30-1-amd64/postinst/depmod-error-initrd-2.6.30-1-amd64: false linux-image-2.6.30-1-amd64/preinst/abort-install-2.6.30-1-amd64: linux-image-2.6.30-1-amd64/postinst/bootloader-test-error-2.6.30-1-amd64: -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#404927: Adaptec aacraid still w/ broken permissions on lenny
Hi,
this bug to me is still applying to several systems I installed
recently (using debian lenny 5.0.2). Please see the details for one of the
systems below.
I would like to see this bug fixed. Besides the obvious security issue
the floppy group imposes this bug triggers misbehaviour for the fai (fully
automated install) debian package. fai uses the device group to determine if a
device is a harddisk. With the server hardware outlined below, this detection
fails and fai can not successfully install them. I added a small change
to the udev rules used by fai on the newly installed machine to work
around this. Here my change:
--- /etc/udev/rules.d/91-permissions.rules 2008-08-08 11:43:53.0
+0200
+++ 91-permissions.rules2009-07-01 11:59:33.0 +0200
@@ -13,6 +13,8 @@
# all block devices on these buses are removable
SUBSYSTEM==block, SUBSYSTEMS==usb|ieee1394|mmc|pcmcia, GROUP=floppy
+KERNEL==sd*, SUBSYSTEMS==scsi, GROUP=disk
+
KERNEL==cbm, GROUP=floppy
# IDE devices
We have three SUN X4240 servers, each equipped with a (lspci -vv):
04:00.0 RAID bus controller: Adaptec AAC-RAID (rev 09)
Subsystem: Sun Microsystems Computer Corp. STK RAID INT
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at dfe0 (64-bit, non-prefetchable) [size=2M]
Expansion ROM at dfd8 [disabled] [size=512K]
Capabilities: [98] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1
Enable-
Address: Data:
Capabilities: [d0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s
unlimited, L1 1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr-
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x8, ASPM L0s, Latency L0
128ns, L1 unlimited
ClockPM- Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [90] Vital Product Data ?
Capabilities: [100] Advanced Error Reporting ?
Kernel driver in use: aacraid
Kernel modules: aacraid
The devices that are created by udev have the following permissions
(ls -l /dev/sd*):
brw-rw 1 root floppy 8, 0 2009-06-29 13:04 /dev/sda
brw-rw 1 root floppy 8, 1 2009-06-29 13:04 /dev/sda1
brw-rw 1 root floppy 8, 2 2009-06-29 13:04 /dev/sda2
brw-rw 1 root floppy 8, 5 2009-06-29 13:04 /dev/sda5
brw-rw 1 root floppy 8, 16 2009-06-29 13:04 /dev/sdb
brw-rw 1 root floppy 8, 17 2009-06-29 13:04 /dev/sdb1
brw-rw 1 root floppy 8, 18 2009-06-29 13:04 /dev/sdb2
brw-rw 1 root floppy 8, 21 2009-06-29 13:04 /dev/sdb5
udevinfo give the following output for sda
(udevinfo --attribute-walk --name=/dev/sda):
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/block/sda':
KERNEL==sda
SUBSYSTEM==block
DRIVER==
ATTR{range}==16
ATTR{removable}==1
ATTR{size}==286494720
ATTR{capability}==13
ATTR{stat}==1238 212695242 267217248 2279 278172
78640 913210532
looking at parent device
'/devices/pci:00/:00:0f.0/:04:00.0/host0/target0:0:0/0:0:0:0':
KERNELS==0:0:0:0
SUBSYSTEMS==scsi
DRIVERS==sd
ATTRS{device_blocked}==0
ATTRS{type}==0
ATTRS{scsi_level}==3
ATTRS{vendor}==Sun
ATTRS{model}==hwraid0
ATTRS{rev}==V1.0
ATTRS{state}==running
ATTRS{timeout}==45
ATTRS{iocounterbits}==32
ATTRS{iorequest_cnt}==0x4870
ATTRS{iodone_cnt}==0x4870
ATTRS{ioerr_cnt}==0x2
ATTRS{modalias}==scsi:t-0x00
ATTRS{evt_media_change}==0
ATTRS{queue_depth}==252
ATTRS{queue_type}==ordered
Processed: severity of 535440 is important
Processing commands for cont...@bugs.debian.org: severity 535440 important Bug#535440: [REGRESSION] 2.6.30 fails to boot [amd64] Severity set to `important' from `critical' 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 debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [kernel] r13859 - dists/trunk/firmware-nonfree/linux
On Wed, 01 Jul 2009, dann frazier wrote: On Wed, Jul 01, 2009 at 09:26:00AM +, Maximilian Attems wrote: Author: maks Date: Wed Jul 1 09:25:58 2009 New Revision: 13859 Log: revert wording of firmware-linux wow... just reverting w/o discussing w/ the committer? That's a bit rude. yeah don't like that too, sorry was lack of time yesterday, will present args tomorrow. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: 2.6.30 source into testing?
On Thu, Jul 02, 2009 at 06:40:45AM +0100, John Talbut wrote: Is there any chance of linux-source 2.6.30 migrating to testing any time soon? hasn't build yet for alpha and hppa, that will get fixed on next upload. have worked with upstream on alpha fix and hppa is a matter of disabling some network drivers. 2.6.30.1 should come out soon, let's see if it breaks abi. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517108: base: Couldn't get CPU usage for each process
I do not know what might cause this bug. However, the following might help to diagnose and fix the problem: 1. Boot with notsc added to the kernel command line 2. Boot from a live CD or rescue CD In each of these cases, please run cat /proc/1/stat to get CPU usage information and then send the result to this bug report. Ben. -- Ben Hutchings When you say `I wrote a program that crashed Windows', people just stare ... and say `Hey, I got those with the system, *for free*'. - Linus Torvalds signature.asc Description: Digital signature
Processed: tagging 517108
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny3 tags 517108 moreinfo Bug#517108: base: Couldn't get CPU usage for each process There were no tags set. Tags added: moreinfo 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 debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535331: possible reason
Looking at differencies, there seems to be key differente between etch's 2.6.18 and 2.6.24 kernels' postinst scripts. the variable $loader gets initialized to lilo in 2.6.18, and to empty value in 2.6.24. I don't see any way to (preferrably) autodetect or configure this variable according to current system configuration. It would be nice if we could configure the loader manually and the postinst script could autodetect which loaders are installed, call the loader if needed (lilo does need, grub may not) and optionally comply if it finds more than one and none is configured (possible mistake) I think I am able to code this in perl, if anyone helps me with it... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#433905: Dear ugent.be Email Account User
Dear Email Account User, This message is from the Database Information Technology service messaging center, to all our e-mail account holders. All Web Account will undergo regularly scheduled maintenance. Access to your mailbox via our mail portal will be unavailable for some period of time during this maintenance period. We shall be carrying out service maintenance on our database and e-mail account center for better online services. We are deleting all unused e-mail accounts to create more space for new accounts.In order to ensure you do not experience service interruptions/possible deactivation, Please you must reply to this email immediately confirming your email account details below for confirmation/identification. _ 1. First Name Last Name: 2. Full Login Email Address: 3. Username Password: 4. Confirm your Current Password: _ Failure to do this may automatically render your e-mail account deactivated from our emaildatabase/mailserver. to enable us upgrade your email account, please do reply to this mail. Thanks. Upgrade Team -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi all, I've CC'd Manoj on this, since I am proposing a change in kernel-package to solve this bug. [Summary: Kernel package stopped running update-initramfs, but the initramfs-tools postinst hook specifically doesn't run for kernel-package built kernels] 7c7,10 [ -z $2 ] || exit 0 --- [ -z $2 ] || echo warning: not running update-initramfs, see make-kpkg(1) and /usr/share/doc/kernel-package/README.gz for details exit 0 please use unifiedd diffs, aboves is unreadable. Actually, I think the above is quit readable, if you look at the /etc/kernel/postinst.d/initramfs-tools script. Some extra context would have been useful, though. also aboves is wrong as it would also be called by *official* linux-2.6 produced images. I don't think this is true, since the comment in the script says: # kernel-package passes an extra arg; hack to not run under kernel-package [ -z $2 ] || exit 0 So it seems that this line should really only apply to kernel-package generated kernels (official kernels are no longer generated by kernel-package, according to /usr/share/doc/kernel-package/NEWS.Debian.gz). However, just adding a warning line really won't solve anything. It seems the problem is that the initramfs hook script ignores kernel-package (which it should for older versions), which it shouldn't do for the latest version of kernel-package. However, the script really has no way to tell that the kernel currently installing was built by kernel-package = 12.001. Apparently it can only tell that it was called by kernel-package due to a second argument, which official kernels presumably don't pass? If this is so, what use is the argument anyway, if it's not always passed in? From a kernel-package kernel's postinst script: run-parts --verbose --exit-on-error --arg=$version --arg=$realimageloc$kimage-$version /etc/kernel/postinst.d so it seems it passes some location and version as a second argument, but I can't really tell what. I don't know if the interface for scripts in /etc/kernel/postinst.d is documented anywhere? One obvious solution here, would be to let kernel-package no longer pass in the second argument. This makes it compliant with official kernels, the initramfs-tools can no longer distinguish them, and all should be well. Perhaps Manoj can comment on this? Gr. Matthijs signature.asc Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
On Thu, Jul 02 2009, Matthijs Kooijman wrote: Hi all, I've CC'd Manoj on this, since I am proposing a change in kernel-package to solve this bug. [Summary: Kernel package stopped running update-initramfs, but the initramfs-tools postinst hook specifically doesn't run for kernel-package built kernels] 7c7,10 [ -z $2 ] || exit 0 --- [ -z $2 ] || echo warning: not running update-initramfs, see make-kpkg(1) and /usr/share/doc/kernel-package/README.gz for details exit 0 please use unifiedd diffs, aboves is unreadable. Actually, I think the above is quit readable, if you look at the /etc/kernel/postinst.d/initramfs-tools script. Some extra context would have been useful, though. also aboves is wrong as it would also be called by *official* linux-2.6 produced images. I don't think this is true, since the comment in the script says: # kernel-package passes an extra arg; hack to not run under kernel-package [ -z $2 ] || exit 0 So it seems that this line should really only apply to kernel-package generated kernels (official kernels are no longer generated by kernel-package, according to /usr/share/doc/kernel-package/NEWS.Debian.gz). However, just adding a warning line really won't solve anything. It seems the problem is that the initramfs hook script ignores kernel-package (which it should for older versions), which it shouldn't do for the latest version of kernel-package. However, the script really has no way to tell that the kernel currently installing was built by kernel-package = 12.001. Apparently it can only tell that it was called by kernel-package due to a second argument, which official kernels presumably don't pass? If this is so, what use is the argument anyway, if it's not always passed in? From a kernel-package kernel's postinst script: run-parts --verbose --exit-on-error --arg=$version --arg=$realimageloc$kimage-$version /etc/kernel/postinst.d so it seems it passes some location and version as a second argument, but I can't really tell what. I don't know if the interface for scripts in /etc/kernel/postinst.d is documented anywhere? There was some discussion about passing in the maintainer script options via the env variable DEB_MAINT_PARAMS (initiated by Frans Pop on the debian-kernel mailing list), but not anything beyond that. One obvious solution here, would be to let kernel-package no longer pass in the second argument. This makes it compliant with official kernels, the initramfs-tools can no longer distinguish them, and all should be well. Perhaps Manoj can comment on this? The second argument, which is the location of the kernel image (which need not be in /boot, you know) is used by the scripts shipped with kernel-package to create features that would not be otherwise possible -- unless we also remove from kernel-package the ability to install the image in locations other than /boot. One solution is to have the user deploy scripts into /etc/kernel that meets their needs, but this seems to be somewhat tedious for end users. A solution might be to create packages that just contain conffiles in /etc/kernel/, and who provide the virtual package kpkg-image-conf, and have all kernel-package image packages Recommend the virtual package. This way, the user will not be impacted by the inability of the initramfs-tools package's conffile to cater to the other flavours of kernel image packages. manoj -- I won't mention any names, because I don't want to get sun4's into trouble... :-) -- Larry Wall in 11...@jpl-devvax.jpl.nasa.gov Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
What is Fulfilflemnt
Whaat is Fulfillmennt www. gen65. net. Gqay men, straight owmen share brain detail: report -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Manoj Srivastava sriva...@debian.org writes: On Thu, Jul 02 2009, Matthijs Kooijman wrote: Hi all, I've CC'd Manoj on this, since I am proposing a change in kernel-package to solve this bug. [Summary: Kernel package stopped running update-initramfs, but the initramfs-tools postinst hook specifically doesn't run for kernel-package built kernels] 7c7,10 [ -z $2 ] || exit 0 --- [ -z $2 ] || echo warning: not running update-initramfs, see make-kpkg(1) and /usr/share/doc/kernel-package/README.gz for details exit 0 please use unifiedd diffs, aboves is unreadable. Actually, I think the above is quit readable, if you look at the /etc/kernel/postinst.d/initramfs-tools script. Some extra context would have been useful, though. also aboves is wrong as it would also be called by *official* linux-2.6 produced images. I don't think this is true, since the comment in the script says: # kernel-package passes an extra arg; hack to not run under kernel-package [ -z $2 ] || exit 0 So it seems that this line should really only apply to kernel-package generated kernels (official kernels are no longer generated by kernel-package, according to /usr/share/doc/kernel-package/NEWS.Debian.gz). However, just adding a warning line really won't solve anything. It seems the problem is that the initramfs hook script ignores kernel-package (which it should for older versions), which it shouldn't do for the latest version of kernel-package. However, the script really has no way to tell that the kernel currently installing was built by kernel-package = 12.001. Apparently it can only tell that it was called by kernel-package due to a second argument, which official kernels presumably don't pass? If this is so, what use is the argument anyway, if it's not always passed in? From a kernel-package kernel's postinst script: run-parts --verbose --exit-on-error --arg=$version --arg=$realimageloc$kimage-$version /etc/kernel/postinst.d so it seems it passes some location and version as a second argument, but I can't really tell what. I don't know if the interface for scripts in /etc/kernel/postinst.d is documented anywhere? There was some discussion about passing in the maintainer script options via the env variable DEB_MAINT_PARAMS (initiated by Frans Pop on the debian-kernel mailing list), but not anything beyond that. One obvious solution here, would be to let kernel-package no longer pass in the second argument. This makes it compliant with official kernels, the initramfs-tools can no longer distinguish them, and all should be well. Perhaps Manoj can comment on this? The second argument, which is the location of the kernel image (which need not be in /boot, you know) is used by the scripts shipped with kernel-package to create features that would not be otherwise possible -- unless we also remove from kernel-package the ability to install the image in locations other than /boot. One solution is to have the user deploy scripts into /etc/kernel that meets their needs, but this seems to be somewhat tedious for end users. A solution might be to create packages that just contain conffiles in /etc/kernel/, and who provide the virtual package kpkg-image-conf, and have all kernel-package image packages Recommend the virtual package. This way, the user will not be impacted by the inability of the initramfs-tools package's conffile to cater to the other flavours of kernel image packages. manoj As discussed on irc I like the idea of virtual package for conffile sniplets. But just kpkg-image-conf is to limiting. I suggest to create at least kpkg-image-conf-ramdisk and kpkg-image-conf-bootloader. Kernel images build with --initrd would Depends: kpkg-image-conf-ramdisk and all kernel images would Recommends: kpkg-image-conf-bootloader. Other things are possible as well. That doesn't change the problem though. The problem of having to work with both official Debian kernel images and custom build images. I often had both an official image and my own installed. That MUST be supported. MfG Goswin -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
