Re: [SOLVED] Unbootable after kernel upgrade: Lilo can't load kernel
reopen 505609 reassign 505609 linux-2.6 affects 505609 lilo thanks Stephen Powell wrote: The real question is, Why didn't the map installer get run during the kernel upgrade? [...] So is this a bug in the kernel maintainer scripts? Or is it a feature? I don't know. I'll leave that up to the kernel maintainers to decide. Reopening and reassigning to the kernel team. -- 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/201005302059.16911.elen...@planet.nl
Bug#580799: linux-image-2.6.32-5-sparc64: Should include pata_cmd64x driver instead of cmd64x
Package: linux-2.6 Version: 2.6.32-12 Severity: serious Because of the IDE - ATA transition for Squeeze the pata_cmd64x driver should be enabled instead of the (old) cmd64x driver. AFAIK the pata_cmd64x has been tested and is known to work correctly. My system failed to boot after updrading to 2.6.32-12 because I had updated my bootloader config and fstab as per the debconf dialogs, but was still getting the /dev/hdX devices from the old driver. -- Package-specific info: ** Version: Linux version 2.6.32-5-sparc64 (Debian 2.6.32-12) (b...@decadent.org.uk) (gcc version 4.3.4 (Debian 4.3.4-10) ) #1 Mon May 3 12:15:34 UTC 2010 ** Command line: root=/dev/hda2 ro ** Not tainted ** Kernel log: [ 34.412487] Unpacking initramfs... [ 36.425976] Freeing initrd memory: 8542k freed [ 36.428004] power: Control reg at 1fff1724000 [ 36.429219] audit: initializing netlink socket (disabled) [ 36.429481] type=2000 audit(2.160:1): initialized [ 36.430530] HugeTLB registered 4 MB page size, pre-allocated 0 pages [ 36.446641] VFS: Disk quotas dquot_6.5.2 [ 36.447294] Dquot-cache hash table entries: 1024 (order 0, 8192 bytes) [ 36.448042] msgmni has been set to 2016 [ 36.450085] alg: No test for stdrng (krng) [ 36.450673] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [ 36.450782] io scheduler noop registered [ 36.450847] io scheduler anticipatory registered [ 36.450913] io scheduler deadline registered [ 36.451104] io scheduler cfq registered (default) [ 36.451824] atyfb: 3D RAGE II+ (Mach64 GT) [0x4754 rev 0x9a] [ 36.453534] atyfb: 2M SGRAM (1:1), 14.31818 MHz XTAL, 200 MHz PLL, 67 Mhz MCLK, 67 MHz XCLK [ 36.516048] Console: switching to colour frame buffer device 144x56 [ 36.541375] atyfb: fb0: ATY Mach64 frame buffer device on PCI [ 36.542671] /SUNW,f...@1e,0: FFB at 01fc, type 51, DAC pnum[236e] rev[10] manuf_rev[1] [ 36.556761] [drm] Initialized drm 1.1.0 20060810 [ 36.557763] /p...@1f,0/p...@1,1/e...@1/s...@14,3083f8: Keyboard port at 1fff13083f8, irq 6 [ 36.558491] /p...@1f,0/p...@1,1/e...@1/s...@14,3062f8: Mouse port at 1fff13062f8, irq 7 [ 36.559586] f0061c64: ttyS0 at MMIO 0x1fff140 (irq = 5) is a SAB82532 V3.2 [ 36.560168] f0061c64: ttyS1 at MMIO 0x1fff1400040 (irq = 5) is a SAB82532 V3.2 [ 36.893614] Floppy drive(s): fd0 is 1.44M [ 36.910680] FDC 0 is a National Semiconductor PC87306 [ 36.912772] Uniform Multi-Platform E-IDE driver [ 36.913344] ide-gd driver 1.18 [ 36.914572] mice: PS/2 mouse device common for all mice [ 36.916206] rtc-m48t59 rtc-m48t59.0: rtc core: registered m48t59 as rtc0 [ 36.920416] TCP cubic registered [ 36.922175] NET: Registered protocol family 10 [ 36.927110] lo: Disabled Privacy Extensions [ 36.930640] Mobile IPv6 [ 36.930789] NET: Registered protocol family 17 [ 36.931687] registered taskstats version 1 [ 36.932518] rtc-m48t59 rtc-m48t59.0: setting system clock to 2010-05-08 17:43:06 UTC (1273340586) [ 36.932895] Initalizing network drop monitor service [ 37.102842] udev: starting version 153 [ 37.560607] PCI: Enabling device: (:01:01.1), cmd 2 [ 37.560667] sunhme.c:v3.10 August 26, 2008 David S. Miller (da...@davemloft.net) [ 37.567765] input: Sun Type 5 keyboard as /devices/root/f005f9c0/f00601b4/f0061504/f0063594/serio0/input/input0 [ 37.570655] input: Sun Mouse as /devices/root/f005f9c0/f00601b4/f0061504/f0064df4/serio1/input/input1 [ 37.580218] eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:9c:14:f5 [ 37.613386] cmd64x :01:03.0: IDE controller (0x1095:0x0646 rev 0x03) [ 37.627752] cmd64x :01:03.0: 100% native mode on irq 14 [ 37.634742] ide0: BM-DMA at 0x1fe02c00020-0x1fe02c00027 [ 37.641890] ide1: BM-DMA at 0x1fe02c00028-0x1fe02c0002f [ 37.649158] Probing IDE interface ide0... [ 37.937464] hda: ST34342A, ATA DISK drive [ 38.613346] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4 [ 38.613792] hda: MWDMA2 mode selected [ 38.621602] Probing IDE interface ide1... [ 38.909368] hdc: Maxtor 6E040L0, ATA DISK drive [ 39.417005] hdd: CD-ROM 56X/AKH, ATAPI CD/DVD-ROM drive [ 39.425289] hdc: host max PIO5 wanted PIO255(auto-tune) selected PIO4 [ 39.425427] hdc: MWDMA2 mode selected [ 39.433355] hdd: host max PIO5 wanted PIO255(auto-tune) selected PIO4 [ 39.433451] hdd: MWDMA2 mode selected [ 39.441443] ide0 at 0x1fe02c0-0x1fe02c7,0x1fe02ca on irq 14 (serialized) [ 39.450618] ide1 at 0x1fe02c00010-0x1fe02c00017,0x1fe02c0001a on irq 14 (serialized) [ 39.459783] hda: max request size: 128KiB [ 39.468269] hda: 8404830 sectors (4303 MB), CHS=8894/15/63 [ 39.477020] hda: cache flushes not supported [ 39.486101] hda: hda1 hda2 hda3 hda4 [ 39.521765] hdc: max request size: 128KiB [ 39.541162] hdc: 80293248 sectors (41110 MB) w/2048KiB Cache, CHS=65535/16/63 [ 39.550586] hdc: cache flushes supported [ 39.561151] hdc: hdc1 hdc2 hdc3 hdc4 [
Re: Bug#580265: Failed netinst
reassign 580265 linux-2.6 2.6.32-9 thanks On Tuesday 04 May 2010, Gmail Notifier wrote: 00:19.0 Ethernet controller [0200]: Intel Corporation 82578DC Gigabit Network Connection [8086:10f0] (rev 06) Subsystem: Intel Corporation Device [8086:0037] Kernel driver in use: e1000e Comments/Problems: Did not find my e1000e network interface, even after selecting it explicitly from the list. After installing without using a net connection, a simple modprobe e1000e and dhclient made the net connection work. The following were added automaticly to /etc/modules by the installation: e100 e1000 e1000e But booting with these in /etc/modules did not make the network interface work. Had to do modprobe e1000e manually after each boot. This sounds like a kernel issue. Reassigning to the kernel team. Cheers, FJP -- 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/201005051041.20978.elen...@planet.nl
Bug#549681: needs MODULES=dep on some PowerPC systems
reassign 549681 base-installer severity 549681 normal tag 549681 help user debian-b...@lists.debian.org usertag 549681 powerpc thanks On Wednesday 24 March 2010, maximilian attems wrote: some OpenFirmware implementations, such as the one in the PegasosII, have a 12 MB size limit on kernel images, and no initrd loading capability. The latter is worked around by merging the initrd into the image with the mkvmlinuz tool, however the generated images are unbootable if they exceed 12 MB. It would be good if mkinitramfs would fail on systems that have the string platform: CHRP in /proc/cpuinfo if compressed kernel and initramfs together are larger than 12 MB, to stop unpleasant surprises when booting. partman has some checks for partitions, aboves specialised wish sound nice for debian installer although there are not many powerpc guys. Deciding on the MODULES= setting is done by base-installer. If somebody from the Debian PowerPC community can provide a tested patch for this we'll be happy to apply it. If help is needed developing the patch, feel free to ask on the debian-boot list. Cheers, FJP -- 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/201003240306.03527.elen...@planet.nl
Re: PATA transition
On Sunday 21 March 2010, Ben Hutchings wrote: On Fri, 2010-03-19 at 03:29 +, Marco d'Itri wrote: elen...@planet.nl wrote: I don't think the first would be a very good idea as it means that we'll still not be rid of the IDE drivers. It seems better to concentrate the Indeed. Please remember that udev has at least a couple of open bugs about things like persistent links breaking with the IDE drivers, which obviously nobody cares about because other distributions stopped using IDE drivers long ago. We cannot get rid of the IDE drivers as not all of them have replacements yet. However, I have now made the configuration changes and upgrade script apply to all architectures, so for every device that can be handled by either an IDE driver or a (stable) libata driver, the libata driver will be used. The upgrade script will show an additional note if it does not find a boot loader that it can handle automatically. That sounds great Ben. Thanks. -- 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/201003211341.05251.elen...@planet.nl
Re: PATA transition
(Replying to the list only; please CC me on replies as I'm not subscribed) On Thursday 18 March 2010, Ben Hutchings wrote: PATA drivers of either flavour are mostly selected on a per-architecture basis, and no change has been made to non-x86. If people are willing to test on the non-x86 architectures then we may have a chance to change them over as well. Does that mean that for other arches the kernel config remains unchanged, or that they will get the new pata drivers, but without automatic conversion support? I don't think the first would be a very good idea as it means that we'll still not be rid of the IDE drivers. It seems better to concentrate the pain in one release than dragging it out. As for not offering automated conversion support, IMO that's acceptable for non-x86 arches[1]. But I think it would be good to display a huge warning. As to testing. I have in the past tested the pata_cmd64x driver, and can confirm that it works fine for my Ultra10. Cheers, FJP [1] Although it could be painful for e.g. headless NAS systems. -- 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/201003181705.47632.elen...@planet.nl
Re: PATA transition
(Please CC on replies.) On Thursday 18 March 2010, Ben Hutchings wrote: On Thu, Mar 18, 2010 at 05:05:47PM +0100, Frans Pop wrote: On Thursday 18 March 2010, Ben Hutchings wrote: PATA drivers of either flavour are mostly selected on a per-architecture basis, and no change has been made to non-x86. If people are willing to test on the non-x86 architectures then we may have a chance to change them over as well. Does that mean that for other arches the kernel config remains unchanged, or that they will get the new pata drivers, but without automatic conversion support? The kernel config remains unchanged. Ugh. That really seems like a bad idea. And waiting for testers seems like a guarantee the transition will never complete: I doubt you'll ever be able to find testers for _all_ possible IDE drivers. I think it would be good to discuss this on d-devel, or at least communicate this very clearly on d-d-a. It's completely new (and unexpected) to me that the kernel team is not actually planning a complete IDE-PATA transition for all architectures. IMO it would be better to force the issue now in unstable and testing and try to correct as much fallout as possible before the release and anything not caught in stable updates than to stay with IDE and risk bugs due to increasing reduced upstream maintenance of IDe drivers. There is code to display a warning for files that require manual conversion. And that would be needed for architectures/boot loaders that do not support an initramfs or initrd, since we cannot use LABEL/UUID specifications for them. Ack. That's why I said that IMO not supporting automatic conversion for all architectures is not a problem. Better to leave it up to the admins than to promise automated conversion and have it fail because of arch-specific corner cases. As to testing. I have in the past tested the pata_cmd64x driver, and can confirm that it works fine for my Ultra10. I'm more concerned about boot loader config than the drivers themselves. Agreed. silo (sparc bootloader) isn't a problem in that respect. When I tested pata_cmd64x I only changed the root fs in silo.conf from hda to sda and it worked. I've not tested UUID as it is simply not needed on my box. [1] Although it could be painful for e.g. headless NAS systems. Why so? Because they often also don't have a serial port or other form of (boot) console access, so if a kernel/initrd update results in a failed boot (for whatever reason) the only option left in a lot of cases is relatively a complex and at least partly blind rescue procedure. -- 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/201003181807.54465.elen...@planet.nl
Re: Bug#572787: debian-installer: 64bit install hangs after Booting the kernel
reassign 572787 linux-2.6 2.6.32-9 thanks On Saturday 06 March 2010, Marc Haber wrote: a hp ProLiant DL385 G6 does not boot the daily installer image in 64bit mode. The box is a Dual Six-Core Opteron with 80 Gig of RAM. Trying a 64 bit expert install, vga=normal is needed to get output at all. The following results have been obtained with vga=normal console=ttyS0 and all permutations of edd=off and nosmp on the command line. All results have been the same. Vmlinuz and initrd are loaded just fine, the line of dots after initrd load ends with ready. This can be seen both on the system console and on the serial console. Afterwards, the serial console screen is blanked (and stays blank); the system console moves its cursor up left without clearing the screen. I then see Decompressing Linux... Parsing ELF... Done with the dotline written by the initrd load being back after the Done. Then the next line is overwritten with Booting the kernel.y. with the y. being the remainder of the ready. With this display, the system stops dead in its tracks with a blinking red error LED: Installing 32bit Debian works just fine. That's something for the kernel team. -- 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/201003061806.23942.elen...@planet.nl
Bug#529567: linux-image-2.6.26-1-486: kernel BUG at mm/mmap.c:2075
On Wednesday 03 March 2010, Moritz Muehlenhoff wrote: As for Lenny; is this error reproducible on your system with low memory, so that we can test it (e.g. by exhausting system memory)? I've tried to put a virtual machine under memory pressure, but couldn't trigger the error in my limited testing. I really have no idea. I'd forgotten I even filed this report... I've not seen the error since reporting it, but that's not so strange as I've also long since switched to newer custom kernels based on upstream source. I've provided all the info I can on this. Whether or not that patch should be backported for Lenny is completely up to the kernel team. I might have been able to provide additional info if the response had been more timely, but now I don't see any realistic way to do so. Sorry. Cheers, FJP -- 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/201003032310.50296.elen...@planet.nl
Re: failure to remove+purge debian package generated by make deb-pkg
On Monday 01 March 2010, Uwe Kleine-König wrote: It's already fixed in 072ad3179c526b90b57719e127de851182b04c4c[1] == 0.93.4-16-g02cb277. Should I report the problem anyhow? That would seem rather pointless. Cheers, FJP -- 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/201003011252.19161.elen...@planet.nl
Re: failure to remove+purge debian package generated by make deb-pkg
Uwe Kleine-König wrote:
I created and successfully installed a custom kernel package using
$(make deb-pkg).
Then after a failed boot test I removed it and then thought that I
actually want to purge it.
Cannot delete /boot/initrd.img-2.6.33-rc8-rt, doesn't exist.
run-parts: /etc/kernel/postrm.d/initramfs-tools exited with return code 1
It has nothing to do with the kernel package itself. The problem is in the
maintainer scripts that are run as hooks from /etc/kernel/*.d.
The kernel package built by deb-pkg does not have any maintainer scripts of
itself. All it does is run whatever is in the hooks. As custom kernels may
have other requirements than distro ones it's not surprising that the
distro hooks can throw errors [1].
Personally I use a set of custom hook scripts with my deb-pkg kernels.
Simply because I don't want to have to fix issues that are the result of
the distro hook scripts in /etc/kernel.
You can simply use custom hook scripts by doing e.g:
export KDEB_HOOKDIR=/etc/kernel.custom
before calling 'make deb-pkg'. You can then create your own hook scripts
in /etc/kernel.custom/{pre,post}{inst,rm}.d/.
Cheers,
FJP
[1] Although in this case I would say that the initrd could also simply be
removed using 'rm -f' so it does not fail if it does not exist.
You could file a BR against the package that installed that particular hook
script, probably initramfs-tools.
--
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/201002252329.12338.elen...@planet.nl
Bug#512679: initramfs-tools: 'more' pager is broken in initramfs shell
reassign 512679 initramfs-tools 0.92o thanks I can reproduce the problem for Lenny in the initramfs debug shell, but more works fine if I do 'busybox sh' and then 'find | more'. I guess that the most likely cause of the problem is either console or keyboard configuration in the initramfs environment, so reassigning back. -- 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/201002211536.10237.elen...@planet.nl
Bug#569351: linux-2.6: Please support newer Areca controllers
On Friday 12 February 2010, Ben Hutchings wrote: Perhaps it is not included in the appropriate d-i package? arcmsr has been included in scsi-extra-modules since Nov 2006, if available for an architecture. For amd64: $ dpkg -c scsi-extra-modules-2.6.30-2-amd64-di_1.61_amd64.udeb | grep arcmsr drwxr-xr-x root/root 0 2009-10-08 15:58 ./lib/modules/2.6.30-2-amd64/kernel/drivers/scsi/arcmsr/ -rw-r--r-- root/root 34621 2009-09-26 00:21 ./lib/modules/2.6.30-2-amd64/kernel/drivers/scsi/arcmsr/arcmsr.ko Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565639: SunBlade 1000 installation report - boot fails after installation
reassign 565639 linux-2.6 2.6.30-8 severity 565639 serious affects 565639 debian-installer On Sunday 24 January 2010, Jurij Smakov wrote: Adding kernel team for comment: it looks like the value returned by uname -m has changed from 'sparc64' in kernel 2.6.26 to 'sparc' in 2.6.30 (and, probably, later ones). This breaks SILO, which uses this value to determine what first-stage bootloader to install, as a result the sparc machines installed with current daily installer builds turn unbootable by the end of installation. Thanks for tracing the cause to this. Reassigning to the kernel team for further investigation. Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562525: linux-2.6: [s390] Etch proposed-updates kernel boot failure
On Tuesday 19 January 2010, dann frazier wrote: This fixes the issue for me, can you verify? zelenka.debian.org:~dannf/linux-image-2.6.18-6-s390_2.6.18.dfsg.1-27~562 525.testfix.1_s390.deb Works for me too. Thanks. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565511: ext4.ko module missing from initramfs
reassign 565511 initramfs-tools 0.93.4 retitle 565511 ext4.ko module missing from dep initramfs thanks On Saturday 16 January 2010, ael wrote: On further investigation, I find that /lib/modules/2.6.30-2-686/kernel/fs/ext4/ext4.ko is missing from the initramfs. I assume that this explains the failure. I do now seem to remember choosing a slim initrd during installation. That's the problem. The ext4 module *would* have been included if you'd selected the standard initrd. Going into rescue mode, I could not find any way to revert to a full initrd. Just edit the initramfs-tools configuration file in /etc for the installed system to use 'MODULES=most' and then regenerate the initrd (see 'man update-initramfs'). I could not see any bug about this against linux-image-2.6.30-2-686. I assume it generates initrd? No, the package is initramfs-tools. Not sure that it is a bug though. I'm reassigning your report because maybe initramfs-tools should be detecting that ext4 is needed in this case. We'll let its maintainer decide. So it seems that while the installer supports ext4, the installed target system initrd does not. Only because you used an expert option without knowing the consequences or knowing how to fix it. You really should have stuck to the default! So I guess that I will have to compile my own kernel on the target and then change to ext4 via the rescue mode (it's the root partition) later. That's absolutely not necessary. You only need to get ext4 included in the initrd. Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565511: ext4.ko module missing from initramfs
On Sunday 17 January 2010, Frans Pop wrote: On Saturday 16 January 2010, ael wrote: On further investigation, I find that /lib/modules/2.6.30-2-686/kernel/fs/ext4/ext4.ko is missing from the initramfs. I assume that this explains the failure. I do now seem to remember choosing a slim initrd during installation. That's the problem. The ext4 module *would* have been included if you'd selected the standard initrd. I cannot reproduce the problem though. If I install a system with an ext4 root file system and MODULES=dep for initramfs-tools, the ext4 module gets correctly included in the initrd and the installed system boots fine. I wonder if the issue isn't caused by the initial problems you had with your SSD. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562525: linux-2.6: [s390] Etch proposed-updates kernel boot failure
On Sunday 03 January 2010, dann frazier wrote: Thanks. This suggests that the fixes for CVE-2009-0029 are causal. To verify, can you test this kernel which drops only those fixes? zelenka.debian.org:~dannf/linux-headers-2.6.18-6-s390_2.6.18.dfsg.1-26et ch1+nocve20090029_s390.deb s/headers/image/ :-) Linux version 2.6.18-6-s390 (Debian 2.6.18.dfsg.1-26etch1+nocve20090029) [...] mordor login: Works! -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562525: linux-2.6: [s390] Etch proposed-updates kernel boot failure
On Saturday 02 January 2010, you wrote: Can you try: zelenka.debian.org:~dannf/linux-image-2.6.18-6-s390_2.6.18.dfsg.1-26etch 1+div64_s390.deb Linux version 2.6.18-6-s390 (Debian 2.6.18.dfsg.1-26etch1+div64) [...] Failed to execute /init Kernel panic - not syncing: No init found. Try passing init= option to kernel. If that *doesn't* work, can you then try: zelenka.debian.org:~dannf/linux-image-2.6.18-6-s390_2.6.18.dfsg.1-24+cve 20090029_s390.deb Linux version 2.6.18-6-s390 (Debian 2.6.18.dfsg.1-24+cve20090029) Failed to execute /init Kernel panic - not syncing: No init found. Try passing init= option to kernel. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562525: linux-2.6: [s390] Etch proposed-updates kernel boot failure
Package: linux-2.6 Severity: serious Version: 2.6.18.dfsg.1-26etch1 Tags: d-i X-Debbugs-CC: da...@debian-org While testing the update for oldstable of debian-installer on my Hercules s390 emulator, I found that the new kernel fails to boot. It fails to execute init after loading the initramfs. The current oldstable version (2.6.18.dfsg.1-24) boots fine. And the current oldstable D-I (which has 2.6.18.dfsg.1-18) also boots fine. Attached a diff between the boot messages. This diff is for an installed system, but I get the exact same Failed to execute /init error when booting D-I which suggests that the problem is not in the initrd but in the kernel. The diff for the lines bringing up CPUs is mostly due to two messages getting mixed up. Probably not significant. --- s390_etch.cur 2009-12-25 13:37:55.0 +0100 +++ s390_etch.new 2009-12-25 13:53:15.0 +0100 @@ -1,57 +1,55 @@ -Linux version 2.6.18-6-s390 (Debian 2.6.18.dfsg.1-24) (da...@debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Sat Dec 27 08:51:06 UTC 2008 +Linux version 2.6.18-6-s390 (Debian 2.6.18.dfsg.1-26etch1) (da...@debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Thu Nov 5 21:15:26 UTC 2009 We are running native (31 bit mode) This machine has an IEEE fpu Detected 2 CPU's -Boot cpu address 0 +Boot cpu address 1 Built 1 zonelists. Total pages: 65536 Kernel command line: root=/dev/disk/by-path/ccw-0.0.0122-part1 BOOT_IMAGE=0 PID hash table entries: 2048 (order: 11, 8192 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) -Memory: 252928k/262144k available (2195k kernel code, 0k reserved, 789k data, 100k init) +Memory: 252928k/262144k available (2195k kernel code, 0k reserved, 792k data, 100k init) Write protected kernel read-only data: 0x227000 - 0x29afff Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 -cpu 0 phys_idx=0 vers=00 ident=002623 machine=3090 unused= +cpu 0 phys_idx=1 vers=00 ident=102623 machine=3090 unused= +cpu 1 phys_idx=0 vers=00 ident=002623 machine=3090 unused= Brought up 2 CPUs -migration_cost=cpu 1 phys_idx=1 vers=00 ident=102623 machine=3090 unused=1000 +migration_cost=1000 checking if image is initramfs... it is Freeing initrd memory: 3005k freed NET: Registered protocol family 16 debug: Initialization complete cio: Was not able to determine available CHSCs. NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 98304 bytes) TCP bind hash table entries: 4096 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 4096) TCP reno registered hypfs: diag 204 not working.3hypfs: Initialization failed with rc = -61. audit: initializing netlink socket (disabled) -audit(1261744119.616:1): initialized +audit(1261745535.320:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) RAMDISK driver initialized: 16 RAM disks of 24576K size 1024 blocksize Channel measurement facility using basic format (autodetected) qdio: loading QDIO base support version 2 qdio : Not all CHSCs supported. Continuing. TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 10 lo: Disabled Privacy Extensions IPv6 over IPv4 tunneling driver NET: Registered protocol family 17 Freeing unused kernel memory: 100k freed -Loading, please wait... -Begin: Loading essential drivers... ... -Done. -Begin: Running /scripts/init-premount ... -[...] +Failed to execute /init +Kernel panic - not syncing: No init found. Try passing init= option to kernel.
Re: Bits from the kernel team
Kurt Roeckx wrote: Now that we have a 2.6.32 kernel in unstable, can you updates us on the various things mentioned in this mail? I have another question. The naming policy for linux-image packages seems to have changed: instead of an ABI we now have trunk. First I thought this was a bug, but now that meta packages have been updated to use trunk too that seems unlikely. I've not seen any announcement for this, nor any discussion on how this may affect other packages (such as packages building out of tree modules and Debian Installer). I've always considered the fact that a kernel update with a different ABI did not replace the current kernel an important feature (reducing the need for an immediate reboot). Are we no longer interested in the ABI? What will happen during/after upgrades if the ABI does change? Would someone care to explain to the rest of the project? Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Heads-up: nfs-kernel-server package will break with 2.6.32
JFYI. Yesterday I found that the nfs-kernel-server init script will fail with 2.6.32 because a test if the kernel has NFS support fails due to the fact that the symbol it tests for no longer exists in /proc/kallsyms. For details: http://bugs.debian.org/554508 Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553056: initramfs-tools: Duplicate scripts under /etc/kernel/*.d/
Package: initramfs-tools Version: 0.93.4 Severity: important I noticed that I now have what seems to be duplicate hook scripts: /etc/kernel$ ls * postinst.d: 10initramfs initramfs-tools postrm.d: 10initramfs initramfs-tools Reason is probably that these are conffiles, which don't get removed automatically on upgrade. The old versions have to be removed by the package maintainer scripts. -- Package-specific info: -- /proc/cmdline root=/dev/sda5 HOME=/ console=ttyS0 TERM=vt102 palo_kernel=2/vmlinux -- /proc/filesystems ext2 cramfs sysv v7 ext3 -- lsmod Module Size Used by ipv6 443316 26 nfs 493216 1 lockd 117845 1 nfs nfs_acl 3639 1 nfs auth_rpcgss61465 1 nfs sunrpc314191 11 nfs,lockd,nfs_acl,auth_rpcgss ide_gd_mod 23541 0 ext3 209694 2 jbd80029 1 ext3 sd_mod 45534 5 ide_cd_mod 38093 0 cdrom 52223 1 ide_cd_mod ohci_hcd 51820 0 ehci_hcd 76166 0 sym53c8xx 109592 4 ns87415 6441 0 scsi_transport_spi 35697 1 sym53c8xx usbcore 212025 2 ohci_hcd,ehci_hcd scsi_mod 201858 3 sd_mod,sym53c8xx,scsi_transport_spi tulip 82353 0 ide_core 138312 3 ide_gd_mod,ide_cd_mod,ns87415 -- /etc/kernel-img.conf do_symlinks = yes relative_links = yes do_bootloader = no do_bootfloppy = no do_initrd = yes link_in_boot = yes -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=y KEYMAP=n BOOT=local DEVICE=eth0 NFSROOT=auto -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 2.6.32-rc5 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages initramfs-tools depends on: ii cpio 2.10-1 GNU cpio -- a program to manage ar ii findutils 4.4.2-1utilities for finding files--find, ii klibc-utils 1.5.15-1 small utilities built with klibc f ii module-init-tools 3.11-1 tools for managing Linux kernel mo ii udev 146-6 /dev/ and hotplug management daemo Versions of packages initramfs-tools recommends: ii busybox 1:1.14.2-2 Tiny utilities for small and embed initramfs-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upstream plans to add a + suffix to kernel versions
Hi, On lkml there's a discussion about unconditionally adding a + to the kernel version if it is being built from a version control system and there are commits after the last tagged release. So, during the merge window you would no longer get '2.6.31', but '2.6.31+'. This is mostly targeted at users building custom kernels, but main arguments are about how it affects distro kernels. Ingo Molnar would for example not mind seeing '2.6.31+-2-amd64' [1]... My input in the discussion has mainly been to try to get the proposed change include backwards compatibility in the sense that if someone really does not want the + because it messes up his existing kernel version naming scheme, he should be able to disable it without needing to patch the Makefile. I'm not sure if this change will actually affect official kernel builds or not, but even if it does not I think it would be good if the Debian kernel team could offer an opinion on the proposal. Besides the possible impact on packaging there is also a risk I thought of today that adding a + will break userspace, especially in Debian where we've always had a - as separator between the kernel minor and any suffixes. For details see: http://lkml.org/lkml/2009/10/15/210. Avoiding the + will of course be possible for official Debian kernels, even if by patching the Makefile, but there are also users running custom built kernels on Debian. The (long) discussion started here: http://lkml.org/lkml/2009/10/5/407. My main arguments and counter proposal (although I have quite a few other mails in that thread too): http://lkml.org/lkml/2009/10/14/507 Current proposed patch: http://lkml.org/lkml/2009/10/15/62 The full thread is probably easier to read here: http://thread.gmane.org/gmane.linux.kernel/897768/focus=898885 Cheers, FJP [1] http://lkml.org/lkml/2009/10/15/103 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550990: IPv6 is broken
Looks a lot like http://bugs.debian.org/494311 (which is still open...). Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508492: linux-image-2.6.26-1-parisc64: [hppa64] XFS internal error xlog_valid_rec_header(2)
Moritz Muehlenhoff wrote: Adding debian-hppa in the loop: Is this a known issue and specific to hppa? (Since otherwise I would suppose there were earlier reports from the more widely used archs). A quick google for xlog_valid_rec_header suggests [1] that this is neither a recent issue, nor specific to hppa. I'd suggest contacting the upstream XFS devs on this. The trace in the link looks very much alike, even though that's 2.6.27 and on arm. It's also a Debian kernel though. I did not really check any of the other hits and I also did not read the thread on this one. Cheers, FJP [1] http://lkml.org/lkml/2008/10/1/314 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table overflow
tags 539378 fixed-upstream thanks Fix is now in upstream mainline: b4f2e2ad5348063ef94aa623f6f09b52ecaf0990 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
tags 539378 patch
thanks
On Saturday 01 August 2009, Helge Deller wrote:
Kyle, you beat me.
Attached is my patch
Tested and works.
Works for me too. Cool.
Your patch contained a few whitespace errors and, because of that, one
unnecessary change. Attached a version with those cleaned up.
Thanks,
FJP
parisc: module.c - fix GOT table overflow with large kernel modules on 64 bit kernels
Signed-off-by: Helge Deller del...@gmx.de
diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index ef5caf2..d291bf9 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -86,8 +86,12 @@
* the bottom of the table, which has a maximum signed displacement of
* 0x3fff; however, since we're only going forward, this becomes
* 0x1fff, and thus, since each GOT entry is 8 bytes long we can have
- * at most 1023 entries */
-#define MAX_GOTS 1023
+ * at most 1023 entries.
+ * To overcome this 14bit displacement with some kernel modules, we'll
+ * use instead the unusal 16bit displacement method (see reassemble_16a)
+ * which gives us a maximum positive displacement of 0x7fff, and as such
+ * allows us to allocate up to 4095 GOT entries. */
+#define MAX_GOTS 4095
/* three functions to determine where in the module core
* or init pieces the location is */
@@ -151,6 +155,16 @@ static inline int reassemble_14(int as14)
((as14 0x2000) 13));
}
+static inline int reassemble_16a(int as16)
+{
+ int s, t;
+
+ /* Unusual 16-bit encoding, for wide mode only. */
+ t = (as16 1) 0x;
+ s = (as16 0x8000);
+ return (t ^ s ^ (s 1)) | (s 15);
+}
+
static inline int reassemble_17(int as17)
{
return (((as17 0x1) 16) |
@@ -407,6 +421,7 @@ static Elf_Addr get_stub(struct module *me, unsigned long value, long addend,
enum elf_stub_type stub_type, Elf_Addr loc0, unsigned int targetsec)
{
struct stub_entry *stub;
+ int d;
/* initialize stub_offset to point in front of the section */
if (!me-arch.section[targetsec].stub_offset) {
@@ -465,7 +480,12 @@ static Elf_Addr get_stub(struct module *me, unsigned long value, long addend,
stub-insns[2] = 0xe820d000; /* bve (%r1) */
stub-insns[3] = 0x537b0030; /* ldd 18(%dp),%dp */
- stub-insns[0] |= reassemble_14(get_got(me, value, addend) 0x3fff);
+ d = get_got(me, value, addend);
+ if (d = 15)
+ stub-insns[0] |= reassemble_14(d);
+ else
+ stub-insns[0] |= reassemble_16a(d);
+
break;
case ELF_STUB_MILLI:
stub-insns[0] = 0x2020; /* ldil 0,%r1 */
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
On Saturday 01 August 2009, Carlos O'Donell wrote: I suggest you use Dave's patch please, it is IMO the most correct patch. Right. I think the original patch is probably responsible for endless errors on shutdown/reboot: Bad Address (null pointer deref?): Code=15 regs=bea7cf70 (Addr=c7ffbea7c) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 11001110 Not tainted r00-03 00ff0804ff0e 405ead40 6fc0 bea7ca18 r04-07 37de ffe8 bea7ca18 405ea540 r08-11 0fc212c1 6bc23fd9 000f faf59048 r12-15 be784b28 0025 faf5932d r16-19 bea7bfa0 0014 4074b134 bea7cda0 r20-23 e000 4011d2b4 40479004 0010 r24-27 4011d1e0 4011d838 405dcd40 r28-31 bea7cd90 0350 bea7cf70 bea7cda0 sr00-03 0607b000 0607b000 sr04-07 IASQ: IAOQ: 40127a10 40127a14 IIR: 0f8010dcISR: 3800 IOR: c7ffbea7cd90 CPU:1 CR30: bea6 CR31: ORIG_R28: IAOQ[0]: unwind_once+0x370/0x3d0 IAOQ[1]: unwind_once+0x374/0x3d0 RP(r2): 0x6fc0 John's version works too for me and the system now shuts down cleanly. Cheers, FJP P.S. If anybody ever wants access to my box, just ask: - model: 9000/785/J5600 - cpu: 2 x PA8600 (PCX-W+) at 552.00 MHz - memory: 2048 MB - 3 x 9.1 GB SCSI harddisks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539369: linux-2.6: parisc64-smp fails to boot on J5600: Badness at smp.c:369
Package: linux-2.6
Version: 2.6.30-3
Severity: important
The 2.6.30-1-parisc64-smp kernel fails to boot on my J5600 system.
The non-smp kernel does boot correctly and the oops also indicates
an smp problem.
Boot log from serial console attached.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: hppa (parisc64)
Kernel: Linux 2.6.30-1-parisc64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Command line for kernel: 'root=/dev/sda5 HOME=/ console=ttyS0 TERM=vt102
palo_kernel=2/vmlinux'
Selected kernel: /vmlinux from partition 2
Selected ramdisk: /initrd.img from partition 2
ELF64 executable
Entry 0010 first 0010 n 3
Segment 0 load 0010 size 4771840 mediaptr 0x1000
Segment 1 load 00618000 size 460792 mediaptr 0x48e000
Segment 2 load 0068c000 size 300800 mediaptr 0x4ff000
Loading ramdisk 8182144 bytes @ 3f821000...
Branching to kernel entry point 0x0010. If this is the last
message you see, you may need to switch your console. This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.30-1-parisc64-smp (Debian 2.6.30-3)
(wa...@debian.org) (gcc version 4.3.3 (GCC) ) #1 SMP Sun Jul 19 10:34:15 UTC
2009
[0.00] unwind_init: start = 0x404b9144, end = 0x404e5204, entries =
11276
[0.00] WARNING: Out of order unwind entry! 404bb0c4 and
404bb0d4
[0.00] WARNING: Out of order unwind entry! 404bb0d4 and
404bb0e4
[0.00] FP[0] enabled: Rev 1 Model 16
[0.00] The 64-bit Kernel has started...
[0.00] console [ttyB0] enabled
[0.00] Initialized PDC Console for debugging.
[0.00] Determining PDC firmware type: System Map.
[0.00] model 5d10 0491 0002 778fe5fc 10f0
0008 00b2 00b2
[0.00] vers 0300
[0.00] CPUID vers 17 rev 10 (0x022a)
[0.00] capabilities 0x3
[0.00] model 9000/785/J5600
[0.00] Total Memory: 2048 MB
[0.00] initrd: 7f821000-7ffee980
[0.00] initrd: reserving 3f821000-3ffee980 (mem_max 8000)
[0.00] LCD display at fff0f05d0008,fff0f05d registered
[0.00] SMP: bootstrap CPU ID is 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 517120
[0.00] Kernel command line: root=/dev/sda5 HOME=/ console=ttyS0
TERM=vt102 palo_kernel=2/vmlinux
[0.00] NR_IRQS:128
[0.00] PID hash table entries: 4096 (order: 12, 32768 bytes)
[0.00] Console: colour dummy device 160x64
[0.064000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[0.168000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[0.52] Memory: 2046464k/2097152k available (3144k kernel code, 50140k
reserved, 1467k data, 296k init)
[0.648000] virtual kernel memory layout:
[0.648000] vmalloc : 0x8000 - 0x3f00 (1007 MB)
[0.648000] memory : 0x4000 - 0xc000 (2048 MB)
[0.648000] .init : 0x4068c000 - 0x406d6000 ( 296 kB)
[0.648000] .data : 0x40412078 - 0x40581000 (1467 kB)
[0.648000] .text : 0x4010 - 0x40412078 (3144 kB)
[1.172000] Calibrating delay loop... 1101.82 BogoMIPS (lpj=2203648)
[1.352000] Security Framework initialized
[1.404000] SELinux: Disabled at boot.
[1.456000] Mount-cache hash table entries: 256
[1.516000] Initializing cgroup subsys ns
[1.568000] Initializing cgroup subsys cpuacct
[1.628000] Initializing cgroup subsys devices
[1.684000] Initializing cgroup subsys freezer
[1.744000] Initializing cgroup subsys net_cls
[1.804000] Brought up 1 CPUs
[1.844000] net_namespace: 1928 bytes
[1.892000] regulator: core version 0.5
[1.944000] NET: Registered protocol family 16
[2.004000] EISA bus registered
[2.044000] Searching for devices...
[2.336000] Found devices:
[2.372000] 1. Astro BC Runway Port at 0xfed0 [10] { 12, 0x0,
0x582, 0xb }
[2.48] 2. Elroy PCI Bridge at 0xfed3 [10/0] { 13, 0x0,
0x782, 0xa }
[2.588000] 3. Elroy PCI Bridge at 0xfed32000 [10/1] { 13, 0x0,
0x782, 0xa }
[2.692000] 4. Elroy PCI Bridge at 0xfed34000 [10/2] { 13, 0x0,
0x782, 0xa }
[2.80] 5. Elroy PCI Bridge at 0xfed38000 [10/4] { 13, 0x0,
0x782, 0xa }
[2.908000] 6. Elroy PCI Bridge at 0xfed3c000 [10/6] { 13, 0x0,
0x782, 0xa }
[3.012000] 7. Forte W+ 2w at 0xfffa [32] { 0, 0x0, 0x5d1,
0x4 }
[3.112000] 8. Forte W+ 2w at 0xfffa2000 [34] { 0, 0x0, 0x5d1,
0x4 }
[3.208000] 9. Memory at
Bug#539369: linux-2.6: parisc64-smp fails to boot on J5600: Badness at smp.c:369
Hmm. The Badness at smp.c warning isn't new of course. That was also there with .24 and .26 (the last working kernel I have). What is new is that the boot now hangs immediately after that point. I also note the following in the boot messages: unwind_init: start = 0x404b9144, end = 0x404e5204, entries = 11276 WARNING: Out of order unwind entry! 404bb0c4 and 404bb0d4 WARNING: Out of order unwind entry! 404bb0d4 and 404bb0e4 But those were also present in .26 (though later in the boot). What's very strange is that for the .30-smp boot the following block is missing: On node 0 totalpages: 524288 Normal zone: 7168 pages used for memmap Normal zone: 0 pages reserved Normal zone: 517120 pages, LIFO batch:31 Movable zone: 0 pages used for memmap Especially as it is present in both .26-smp, but also in .30-up. Attached, for comparison, boot logs for .24-smp, .26-smp, .30-smp and .30-up. If needed I can build kernels for intermediate versions between .26 and .30. Cheers, FJP boot-logs.tgz Description: application/tgz
Bug#539369: linux-2.6: parisc64-smp fails to boot on J5600: Badness at smp.c:369
On Friday 31 July 2009, Carlos O'Donell wrote: I'm glad this is fixed in 2.6.31-rc4, do you need any more help from the porters? Well, it might be nice if the responsible change(s) could be identified. Possibly they could be applied/backported to .30. Not sure if it's worth the effort. It might be if e.g. .30 is targeted for a Lenny-and-a-half release. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Kernel BoF, 29th July
On Tuesday 28 July 2009, Ben Hutchings wrote: There will be a second kernel BoF/meeting tomorrow (29th July) at 16:00-18:00 local time (14:00-16:00 UTC). I would like to discuss a possible lenny-and-1/2 kernel release. There should be time to discuss several other issues. Are there logs of the two meetings? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Kernel BoF, 29th July
On Wednesday 29 July 2009, you wrote: Just for the record, the following is NOT correct: 10:09 maks otavio: only linux-modules-extra 10:09 maks nothing d-i uses and nothing one should really have to care. D-I uses the loop-aes modules (for encrypted partitioning) and that is exactly why it is so hard to switch D-I to a new kernel version: D-I can only realistically switch to a new kernel for an arch when both the kernel itself *and* loop-aes are available. sorry to say so, but it is idiotic that d-i *depends* on external modules. *shrug* D-I has been using loop-aes since Sarge. This is nothing new. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Kernel BoF, 29th July
On Wednesday 29 July 2009, Frans Pop wrote: On Wednesday 29 July 2009, you wrote: Just for the record, the following is NOT correct: 10:09 maks otavio: only linux-modules-extra 10:09 maks nothing d-i uses and nothing one should really have to care. D-I uses the loop-aes modules (for encrypted partitioning) and that is exactly why it is so hard to switch D-I to a new kernel version: D-I can only realistically switch to a new kernel for an arch when both the kernel itself *and* loop-aes are available. sorry to say so, but it is idiotic that d-i *depends* on external modules. *shrug* D-I has been using loop-aes since Sarge. This is nothing new. To clarify: D-I does not *depend* on loop-aes (as you put it), but it does *use* it. And if it is missing we have a regression in offered functionality, which is especially bad for any D-I release. Besides that, if l-m-e fails to build and is migrated to testing then any users having encrypted partitions using loop-aes will be unable to update their kernel, so treating the absence of l-m-e as a blocker for migration of the kernel seems quite correct to me. Debian has been offering support for encrypted partitions using loop-aes and if that is to be dropped it should be done in a clean way. The kernel team ignoring build failures in one of the packages it maintains is IMO not a reason to lower the normal quality criteria of the testing suite. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538898: Squeeze install hangs at Setting console to Unicode
On Monday 27 July 2009, Felix Zielcke wrote: Am Montag, den 27.07.2009, 22:11 +0200 schrieb Felix Zielcke: Am Montag, den 27.07.2009, 14:29 -0500 schrieb David A. Greene: Boot of any install method freezes after the message Setting console to Unicode appears. Immediately prior to the message the screen flashes and all previous text disappears. Thus only the Setting console message is visible after the hanng. This is with an NVidia GTX 285 if that matters. I have the same problem with current daily amd64 and i386 with VMware Workstation Beta. The graphical installer works fine, just not text mode. Joey just told me to use nopat kernel option and it worked. If you want to get this fixed, the best thing is to file a bug against the kernel upstream in http://bugzilla.kernel.org/. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
Note that an additional issue was found with 2.6.27 after the change to -fno-strict-overflow. See http://lkml.org/lkml/2009/7/20/80 and follow-ups for details. The cause (compiler bug in gcc-4.2.4) was identified in http://lkml.org/lkml/2009/7/21/423 and it looks like it's going to be fixed with a kernel patch: http://lkml.org/lkml/2009/7/21/499. But it shows that there may definitely be unexpected effects from the change for arches using gcc-4.2 or later in Lenny. Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536354: please verify build
On Sunday 19 July 2009, dann frazier wrote: A fix has been committed in r13974 and an s390 build should appear in the lenny suite of the snapshot archive after the next daily build cycle. Can you test a 2.6.26-18~snapshot.13974 (or greater) build when it appears? linux-image-2.6.26-2-s390_2.6.26-18~snapshot.13976_s390.deb boots fine. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537152: update-initramfs fails to create initrd image
On Friday 17 July 2009, maximilian attems wrote: On Fri, 17 Jul 2009, Michalis Georgiou wrote: i did what i describe above. i chose targeted, installation failed and at that time i opened a console and gave : sh -x mkinitramfs -o /tmp/bla the output is : sh: can't open mkinitramfs. it seems that mkinitramfs does not exist in the system. sure it does exist, it is inside the installer chroot. Looks like you need to 'chroot /target' before executing the debug command. Before that you may also need to mount various file systems inside the chroot, such as sysfs, proc and devpts: mount -t proc none /target/proc mount -t sysfs none /target/sys mount -t devpts none /target/dev/pts -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
On Wednesday 15 July 2009, dann frazier wrote: On Mon, Jul 13, 2009 at 11:22:12AM +0200, Frans Pop wrote: Linus has committed a different solution: replacing -fwrapv by -fno-strict-overflow. See upstream commit a137802ee839ace40079bebde24cfb416f73208a. I tried applying that fix, but it causes a build failure because the compiler we use for lenny (gcc-4.1) doesn't support it. It seems strange that upstream would drop '-fwrapv' due to problems w/ gcc-4.1.x, but then require an option that's not supported by gcc-4.1 at all. Maybe that option got added in the 4.1.x stream after Debian released it? Maybe I'm missing a kernel change that would prevent this option from being used in 4.1? That's weird. IIUC the 'call cc-option' function is supposed to check whether an option is supported by the gcc version being used and only actually add it if it is. See Documentation/kbuild/makefiles.txt and scripts/Kbuild.include. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
On Thursday 16 July 2009, Frans Pop wrote: On Wednesday 15 July 2009, dann frazier wrote: On Mon, Jul 13, 2009 at 11:22:12AM +0200, Frans Pop wrote: Linus has committed a different solution: replacing -fwrapv by -fno-strict-overflow. See upstream commit a137802ee839ace40079bebde24cfb416f73208a. I tried applying that fix, but it causes a build failure because the compiler we use for lenny (gcc-4.1) doesn't support it. It seems strange that upstream would drop '-fwrapv' due to problems w/ gcc-4.1.x, but then require an option that's not supported by gcc-4.1 at all. Maybe that option got added in the 4.1.x stream after Debian released it? Maybe I'm missing a kernel change that would prevent this option from being used in 4.1? That's weird. IIUC the 'call cc-option' function is supposed to check whether an option is supported by the gcc version being used and only actually add it if it is. See Documentation/kbuild/makefiles.txt and scripts/Kbuild.include. 2.6.24-17 + Linus' patch builds fine here for s390 with gcc-4.1; the -fno-strict-overflow option is not added. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
Linus has committed a different solution: replacing -fwrapv by -fno-strict-overflow. See upstream commit a137802ee839ace40079bebde24cfb416f73208a. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Coordinating efforts to get a new kernel in testing?
On Saturday 11 July 2009, Luk Claes wrote: what are the remaining issues that you are concerned about? The ones that prevent linux-2.6 from migrating once it would be unblocked. Like FTBFS of linux-modules-extra-2.6 on 3 architectures I guess? That seemed to me like a valid reason not to want to migrate .29 to testing. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
On Friday 10 July 2009, dann frazier wrote: Maybe the -fwrapv change? Bingo. Makes a lot of sense too for an issue related to gcc version. Reverting only that patch on top of -17 results in good boot too. Gah! And it's even a known issue: - http://bugzilla.kernel.org/show_bug.cgi?id=13012 - http://lkml.org/lkml/2009/4/9/458 Does not yet look to be fixed upstream though. I only found 740ebe4a54, but that's mips only. P.S. Having the full series history in the kernel source was great for tracking this bug! It allowed me to use my own (cross-)build system I normally use to build upstream kernels (using 'make deb-pkg') in a very straightforward manner. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
tags 536354 patch thanks On Friday 10 July 2009, Frans Pop wrote: On Friday 10 July 2009, dann frazier wrote: Maybe the -fwrapv change? Bingo. Makes a lot of sense too for an issue related to gcc version. I've proposed the attached patch on lkml: http://lkml.org/lkml/2009/7/10/49. From: Frans Pop elen...@planet.nl Subject: Only add '-fwrapv' gcc CFLAGS for gcc 4.3 and later This flag has been shown to cause init to segfault for kernels compiled with gcc-4.1. gcc version 4.2.4 has been shown to be OK, but as there is some uncertainty the flag is only added for 4.3 and later. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=13012. Signed-off-by: Frans Pop elen...@planet.nl diff --git a/Makefile b/Makefile index 0aeec59..2f8756e 100644 --- a/Makefile +++ b/Makefile @@ -565,7 +565,8 @@ KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,) KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,) # disable invalid can't wrap optimizations for signed / pointers -KBUILD_CFLAGS += $(call cc-option,-fwrapv) +KBUILD_CFLAGS += $(shell if [ $(call cc-version) -ge 0430 ]; then \ + echo $(call cc-option,-fwrapv); fi ;) # revert to pre-gcc-4.4 behaviour of .eh_frame KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
On Friday 10 July 2009, Ben Hutchings wrote: On Fri, 2009-07-10 at 09:51 +0200, Frans Pop wrote: On Friday 10 July 2009, Frans Pop wrote: On Friday 10 July 2009, dann frazier wrote: Maybe the -fwrapv change? Bingo. Makes a lot of sense too for an issue related to gcc version. I've proposed the attached patch on lkml: http://lkml.org/lkml/2009/7/10/49. Perhaps we should be using -fno-strict-overflow instead of simply removing this option? It looks like that option was only introduced with gcc 4.2. At least, I can't find it in the manual for gcc 4.1. So it would not make any difference for this bug. It does make the case a bit stronger to change my check to also allow -fwrapv for gcc 4.2 though. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
On Friday 10 July 2009, Frans Pop wrote: I've proposed the attached patch on lkml: http://lkml.org/lkml/2009/7/10/49. The version check in the patch was incorrect. Here's an improved version that also allows -fwrapv for gcc 4.2. See also the follow ups on lkml. From: Frans Pop elen...@planet.nl Subject: Only add '-fwrapv' to gcc CFLAGS for gcc 4.2 and later This flag has been shown to cause init to segfault for kernels compiled with gcc-4.1. gcc version 4.2.4 has been shown to be OK. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=13012. Reported-by: Barry K. Nathan bar...@pobox.com Signed-off-by: Frans Pop elen...@planet.nl diff --git a/Makefile b/Makefile index 0aeec59..2519fde 100644 --- a/Makefile +++ b/Makefile @@ -565,7 +565,8 @@ KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,) KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,) # disable invalid can't wrap optimizations for signed / pointers -KBUILD_CFLAGS += $(call cc-option,-fwrapv) +KBUILD_CFLAGS += $(shell if [ $(call cc-version) -ge 0402 ]; then \ + echo $(call cc-option,-fwrapv); fi ;) # revert to pre-gcc-4.4 behaviour of .eh_frame KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
Package: linux-2.6 Version: 2.6.26-17 Severity: important A user reported on d-s390 [1] that a Lenny installation on s390 failed with a kernel panic during boot. I could reproduce the panic on my Hercules system using the installer. I then installed the current Lenny kernel on my installed Hercules system (running sid), and when I rebooted that with .26 I got the same panic, so it looks to be a kernel problem and not an installer problem. We included an s390 specific patch in 2.6.26-16 for #511334, but TBH I would be surprised if that was the cause given that it was very well tested. I'll try to look into this myself but can't give an ETA for results. Cheers, FJP [1] http://lists.debian.org/debian-s390/2009/07/msg2.html (contains boot log from submitter) Here's the boot log from my Hercules system: 0.00! Initializing cgroup subsys cpuset 0.00! Initializing cgroup subsys cpu 0.00! Linux version 2.6.26-2-s390 (Debian 2.6.26-17) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Mon Jun 22 09:19:01 UTC 2009 0.00! We are running native (31 bit mode) 0.00! This machine has an IEEE fpu 0.00! Zone PFN ranges: 0.00! Normal 0 -65536 0.00! Movable zone start PFN for each node 0.00! early_node_map 1! active PFN ranges 0.00! 0:0 -65535 0.00! Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65023 0.00! Kernel command line: ro vmpoff=LOGOFF root=/dev/disk/by-path/ccw-0.0.0120-part1 BOOT_IMAGE=3 0.00! PID hash table entries: 1024 (order: 10, 4096 bytes) 17179569.184434! console ttyS0! enabled 17179569.186173! Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) 17179569.196175! Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) 17179569.323701! Memory: 250240k/262144k available (2273k kernel code, 0k reserved, 843k data, 148k init) 17179569.324046! Write protected kernel read-only data: 0x12000 - 0x2eefff 17179569.327670! Security Framework initialized 17179569.327875! SELinux: Disabled at boot. 17179569.328068! Capability LSM initialized 17179569.329135! Mount-cache hash table entries: 512 17179569.336415! Initializing cgroup subsys ns 17179569.336625! Initializing cgroup subsys cpuacct 17179569.337083! Initializing cgroup subsys devices 17179569.372905! CPUs: 2 configured, 0 standby 17179569.712223! cpu 0 phys_idx=0 vers=00 ident=002623 machine=3090 unused= 17179569.720062! cpu 1 phys_idx=1 vers=00 ident=102623 machine=3090 unused= 17179569.720223! Brought up 2 CPUs 17179569.727662! net_namespace: 660 bytes 17179569.733664! NET: Registered protocol family 16 17179569.734205! debug: Initialization complete 17179569.845231! NET: Registered protocol family 2 17179569.904364! IP route cache hash table entries: 2048 (order: 1, 8192 bytes) 17179569.915461! TCP established hash table entries: 8192 (order: 4, 65536 bytes) 17179569.919237! TCP bind hash table entries: 8192 (order: 4, 65536 bytes) 17179569.923241! TCP: Hash tables configured (established 8192 bind 8192) 17179569.923520! TCP reno registered 17179569.945827! NET: Registered protocol family 1 17179569.951199! checking if image is initramfs... it is 17179595.776001! Freeing initrd memory: 4834k freed 17179595.813741! audit: initializing netlink socket (disabled) 17179595.814102! type=2000 audit(1247133977.122:1): initialized 17179595.826079! VFS: Disk quotas dquot_6.5.1 17179595.827719! Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) 17179595.828598! msgmni has been set to 498 17179595.833376! Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) 17179595.833664! io scheduler noop registered 17179595.833861! io scheduler anticipatory registered 17179595.834079! io scheduler deadline registered 17179595.835142! io scheduler cfq registered (default) 17179595.923494! brd: module loaded 17179595.925446! cio: Channel measurement facility using basic format (autodetected) 17179595.925743! qdio: loading QDIO base support version 2 17179595.929133! qdio : Not all CHSCs supported. Continuing. 17179595.929513! sclp_config: no configuration management. 17179595.959702! TCP cubic registered 17179595.962630! NET: Registered protocol family 10 17179595.989321! lo: Disabled Privacy Extensions 17179596.003133! Mobile IPv6 17179596.003321! NET: Registered protocol family 17 17179596.009185! registered taskstats version 1 17179596.030724! Freeing unused kernel memory: 148k freed 17179596.042499! Kernel panic - not syncing: Attempted to kill init Here is what should be happening at that point: Loading, please wait... Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... 17179598.312944! dasd(eckd): 0.0.0120: PSF-SSC on storage subsystem HRC.ZZ0001.0120 returned rc=0
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
A user reported on d-s390 [1] that a Lenny installation on s390 failed with a kernel panic during boot. I could reproduce the panic on my Hercules system using the installer. Hmmm. This is fun. If I cross-compile the kernel myself it boots fine. I used my own cross-build system for this, not the Debian build system. Here's what I did: - apt-get source linux-2.6 (on lenny of course) - apply patches from all series files (1-17; except *-extra) - copy kernel config from 2.6.26-2-s390 - cross-build - install and boot the resulting .deb package Did I miss anything here? Anyway, I wonder if the problem is maybe just a weird error in the build environment used to build the current official package. If that is the case then a simple rebuild could fix that. Dann: could you maybe rebuild the kernel for s390 and send me the resulting image so I could check that? Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
On Thursday 09 July 2009, dann frazier wrote: The buildd log shows that 2.6.26-17 was built w/ gcc-4.1_4.1.2-25. Is there a cross-compiler available w/ that version? Unfortunately not that I know of. Packages currently available on emdebian are incomplete. And I've had very mixed results trying to build a cross toolchain myself. It costs loads of effort with a fairly big chance of failure If someone knows a source I'll be happy to try it. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
On Thursday 09 July 2009, dann frazier wrote: On Thu, Jul 09, 2009 at 10:05:15AM -0600, dann frazier wrote: Here's a simple rebuild from zelenka's lenny chroot: http://people.debian.org/~dannf/bugs/536354/ Thanks Dann. That paniced too. After that I've managed after all to build a 4.1 cross toolchain [1]. And the kernel I just built with that also panics. So, progress: I can now start narrowing it down. Should be easy enough as I was smart enough to commit each patch series in git after applying. Here's what I currently know for certain: * 2.6.26-13 built with gcc-4.1 (4.1.2-24) boots [2] * 2.6.26-17 built with gcc-4.1 (4.1.2-25) panics * 2.6.26-17 built with gcc-4.2 (4.2.4-6) boots So, the failure is gcc related. Now we have to find out if it is a specific kernel patch that gcc 4.1 does not like, or a regression in gcc itself. [1] I now have an s390 cross compiler, built on a Lenny i386 Toshiba laptop, installed in an i386 Sid chroot on an amd64 Lenny HP notebook :-P [2] This just happens to be the last .26 kernel I still had installed in Hercules. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
On Thursday 09 July 2009, Frans Pop wrote: Here's what I currently know for certain: * 2.6.26-13 built with gcc-4.1 (4.1.2-24) boots [2] * 2.6.26-17 built with gcc-4.1 (4.1.2-25) panics * 2.6.26-17 built with gcc-4.2 (4.2.4-6) boots Bisect... - the following all built with gcc-4.1 (4.1.2-25): * 2.6.26-15lenny3 panics * 2.6.26-14 panics * 2.6.26-13 boots * 2.6.26-13lenny1 boots * 2.6.26-13lenny2 boots = the problem is in 2.6.26-14 (I guess this also tells us a lot about how many users run Lenny s390 with a Debian kernel :-/ Unless maybe s390x is not affected.) /me looks at patches in -14 Hmmm, panic is about where modules first get loaded, let's try reverting bugfix/parisc/fix-loading-large-kmods.patch. Nope. Still panics. Do you have any ideas? Bastian maybe? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536354: linux-2.6: [s390,lenny] kernel panic during boot
On Thursday 09 July 2009, dann frazier wrote: I'd suggest the CVE-2009-0029 fixes. Lots of arch-specific stuff in there. Nope. Other suggestions welcome. I'll nail it down tomorrow. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534716: RM: firmware-*-di -- NBS; obsolete
Package: ftp.debian.org Severity: normal The non-free/debian-installer section in unstable contains a number of firmware udebs built from ancient versions of firmware-nonfree. These udebs have never been used and should really have been automatically cleaned from the archive ages ago. Please remove these udebs from the archive. The overview is for i386 (but other arches should have them too as they are arch=all): From firmware-nonfree (0.9): - firmware-ipw3945-di - firmware-iwlwifi-di - firmware-qlogic-di - firmware-ralink-di From firmware-nonfree (0.8): - firmware-rt61-di - firmware-rt73-di From firmware-nonfree (0.5): - firmware-iwl3945-di - firmware-iwl4965-di -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529567: linux-image-2.6.26-1-486: kernel BUG at mm/mmap.c:2075
Package: linux-2.6 Version: 2.6.26-13lenny2 I got the following BUG in my logs. This is on a system with very little memory. kernel: [4205017.800545] sed[4196]: segfault at 13b0f4 ip b7e7c013 sp bfe7eb70 error 4 in libc-2.7.so[b7e21000+138000] kernel: [4205017.801686] [ cut here ] kernel: [4205017.801780] kernel BUG at mm/mmap.c:2075! kernel: [4205017.801852] invalid opcode: [#1] kernel: [4205017.801923] Modules linked in: apm ip6t_REJECT ip6table_filter ip6_tables iptable_nat nf_nat ipt_REJECT xt_tcpudpipt_LOG xt_limit nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables 3c509 ipv6 parport_pc parport snd_pcm snd_timer snd soundcore snd_page_alloc evdev psmouse pcspkr ext3 jbd mbcache ide_cd_mod cdrom ide_disk ata_generic libata scsi_mod dock piix ide_pci_generic ide_core floppy thermal_sys kernel: [4205017.802631] kernel: [4205017.802696] Pid: 4196, comm: sed Not tainted (2.6.26-1-486 #1) kernel: [4205017.802796] EIP: 0060:[c0157dde] EFLAGS: 00010202 CPU: 0 kernel: [4205017.802920] EIP is at exit_mmap+0xae/0xb8 kernel: [4205017.802920] EAX: EBX: c0e0de84 ECX: c1409da0 EDX: c18fc56c kernel: [4205017.802920] ESI: c1e49220 EDI: EBP: c0e0df10 ESP: c0e0de80 kernel: [4205017.802920] DS: 007b ES: 007b FS: GS: SS: 0068 kernel: [4205017.802920] Process sed (pid: 4196, ti=c0e0c000 task=c1fb3640 task.ti=c0e0c000) kernel: [4205017.802920] Stack: 0048 c03c9008 c1e49220 c1fb3640 c1d3ab6c c0119e4b 000b c011e052 kernel: [4205017.802920]0001 c0e0dea4 c0e0dea4 c0122a3f 000b 000b c1d3ab6c c0e0df10 kernel: [4205017.802920]c011e471 00dc c0124b9f c0e0dfb8 c0e0df90 c1d3aaa0 c1cdfc20 b7f5aff4 kernel: [4205017.802920] Call Trace: kernel: [4205017.802920] [c0119e4b] mmput+0x1b/0x67 kernel: [4205017.802920] [c011e052] do_exit+0x1c7/0x594 kernel: [4205017.802920] [c0122a3f] recalc_sigpending+0xa/0x29 kernel: [4205017.802920] [c011e471] do_group_exit+0x52/0x78 kernel: [4205017.802920] [c0124b9f] get_signal_to_deliver+0x2d0/0x2e9 kernel: [4205017.802920] [c011388e] do_page_fault+0x0/0x5ea kernel: [4205017.802920] [c0102f08] do_notify_resume+0x7b/0x61b kernel: [4205017.802920] [c014e89d] free_hot_cold_page+0xfe/0x118 kernel: [4205017.802920] [c0116c02] __dequeue_entity+0x1f/0x71 kernel: [4205017.802920] [c01028ef] __switch_to+0x84/0xf7 kernel: [4205017.802920] [c02a5dce] schedule+0x338/0x351 kernel: [4205017.802920] [c011388e] do_page_fault+0x0/0x5ea kernel: [4205017.802920] [c0103890] work_notifysig+0x13/0x23 kernel: [4205017.802920] === kernel: [4205017.802920] Code: 8b 00 8b 15 00 e0 33 c0 3b 82 f0 00 00 00 75 11 e8 5c af fb ff 90 eb 09 89 f8 e8 1b ff ff ff 89 c7 85 ff 75 f3 83 7e 78 00 74 04 0f 0b eb fe 58 5a 5b 5e 5f c3 55 57 89 c7 56 89 ce 53 83 ec 04 kernel: [4205017.802920] EIP: [c0157dde] exit_mmap+0xae/0xb8 SS:ESP 0068:c0e0de80 kernel: [4205017.807853] ---[ end trace 90ff29e315afb858 ]--- Line 2075 is a BUG_ON in exit_mmap(): BUG_ON(mm-nr_ptes (FIRST_USER_ADDRESS+PMD_SIZE-1)PMD_SHIFT); After looking at the commit log for mmap.c, I suspect that the BUG may have been caused by the following issue fixed in later kernels (but please check if I'm correct or not): commit dcd4a049b9751828c516c59709f3fdf50436df85 Author: Johannes Weiner han...@cmpxchg.org Date: Tue Jan 6 14:40:31 2009 -0800 mm: check for no mmaps in exit_mmap() When dup_mmap() ooms we can end up with mm-mmap == NULL. The error path does mmput() and unmap_vmas() gets a NULL vma which it dereferences. In exit_mmap() there is nothing to do at all for this case, we can cancel the callpath right there. This patch was also included in a 2.6.27 stable update. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513695: fetchmail: race in MSG_PEEK
reassign 513695 linux-2.6 2.6.28-1 forwarded 513695 http://www.spinics.net/lists/netdev/msg96676.html tags 513695 patch thanks The cause of these errors has been traced to the kernel. The errors are bogus and due to a test that's no longer correct after a code change in 2.6.28. The errors have also been seen with other applications than fetchmail: kernel: TCP(kio_imap4:5646): Application bug, race in MSG_PEEK kernel: TCP(wget:4137): Application bug, race in MSG_PEEK A (tested) patch is available in http://www.spinics.net/lists/netdev/msg96700.html which is expected to get included in 2.6.30 and probably the next 2.6.29 stable update. Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: 2.6.29-4 FTBFS on sparc
Bastian Blank wrote: On Mon, May 04, 2009 at 10:50:58AM +0100, Jurij Smakov wrote: 2.6.29-4 failed to build on sparc: Already known. I can investigate, but if you know off the top of your head what can be causing it (missing zImage file after the build), please let me know. This is the difference between the 32 and 64bit build. Hmm. I remember we had an issue late in Lenny with sparc that was caused by a change in make-kpkg. Turned out sparc was still using that. Could this be caused by that or has sparc been switched over since then? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525958: Disable CONFIG_PROM_CONSOLE on sparc - also affects Lenny!
found 525958 2.6.26-15 thanks If I understand David Miller correctly, this also affects stable kernels. Here's a message I received from him for #504721 against D-I's rootskel (which was rejected because that bug's already been archived). I'm not sure if changing this is appropriate for stable, but I guess if anyone is an authority on correct Sparc kernel configuration, then David is. Cheers, FJP Forwarded message === From: David Miller da...@davemloft.net To: 504...@bugs.debian.org Date: 03/05/09 23:32 The reason this bug happens is because CONFIG_PROM_CONSOLE is enabled in the kernel. It unconditionally gets registered as a real console before the Sun Hypervisor console driver has a chance to register. The kernel takes whatever real console registers first, as the highest priority console (unless specified otherwise on the command line). This is why the test program that runs to determine the inittab getty settings doesn't see the console as a serial device. And no, using console=ttyS0 will not fix this problem on Niagara. On Niagara you would need to use console=ttyHV0. The only reasonable fix for this bug is to disable CONFIG_PROM_CONSOLE in the kernel configuration. Nobody should be enabling that kernel config option on sparc. It specifically creates this problem because unlike the framebuffer and serial console drivers, it does not have a way to know whether it should register or not. The serial and framebuffer drivers check the PROM indicated device node of the console device, and it only registers the device as the console if it matches the value of the 'output-device' PROM environment variable setting. Therefore, having CONFIG_PROM_CONSOLE enabled in the tree is going to do nothing other than constantly create problems and conflicts like this. It needs to be turned off, forever. == -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
Could http://bugs.debian.org/511334 be related to your problem? There's a link to patch in one of the last messages. See especially messages #57 and #65. Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
STEPHEN POWELL wrote: My problem, on the other hand, has always been that the kernel hangs right before the permanent root file system gets mounted. I've always been able to get that far but no farther. For me, the key is that the s390x kernel works flawlessly, but the s390 kernel hangs. Please give it a try anyway. If you look at the mail threads on lkml that are referenced from the BR you'll see that this bug resulted in different hangs at different points with both 2.6.27 and 2.6.29 [1] in the Hercules emulator. Bisection pointed to different, completely unrelated changes that somehow triggered the bug even though those changes in themselves were completely correct. The hangs on Hercules were rather unpredictable as 2.6.26, which also has the bug, worked reliably. I don't think it really matters if it's emulator or real hardware. The determining factor is what type of system it is. The bug itself is a rounding error in fairly core s390-specific (31 bit) code, so the fact that s390x does not hang actually increases the chance that this is related. Where exactly the bug manifests itself varies, but when it does it's been completely reproducible and the result in each case was an endless loop: a hang. I'm not saying this definitely is the cause, but it looks similar enough to me that it's worth giving the patch a try. I agree that the remaining Flex-ES issue is completely unrelated. [1] With 2.6.29 I could get as far as the login prompt, but actually logging in would trigger the hang. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Standardizing use of kernel hook scripts
Darren Salt wrote: I demand that Manoj Srivastava may or may not have written... On Wed, Apr 01 2009, Frans Pop wrote: But is anyone still using it? Is there any current reason to support it I think that there are Debian users who use that option of make-kpkg, and I have not seen any indication that there usage of that option has decreased. I make use of it fairly regularly; its next use here will probably be to build kernel 2.6.29.1. I normally use the kernel-image target, but I sometimes have use for the kernel-headers target. Darren, The question was not whether you use make-kpkg, but whether any of the hook scripts you may have in /etc/kernel/*.d/ rely on the second parameter that is passed by the postinst included with the kernel image by make-kpkg. Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Standardizing use of kernel hook scripts
(dropping ltsp as the list is moderated) Manoj Srivastava wrote: My patch series for the upstream kernel contains roughly the following changes: [...] Where are these patches? Only just submitted: http://marc.info/?l=linux-kbuildm=123861445626856w=2 maks has also submitted a set of patches: http://marc.info/?l=linux-kbuildm=123851278623264w=2 Some discussion on those: http://marc.info/?l=linux-kbuildm=123860208704620w=2 ISSUES == Parameters passed to hook scripts - Is anything other than the kernel version really needed? Yes, since in the old days the image location could be changed, by passing a parameter to make-kpkg. I think this feature is used, since it was put into kernel-package by request. But is anyone still using it? Is there any current reason to support it (i.e. is there any reason to _add_ support for it in deb-pkg or in whatever the kernel team is planning)? Maintainer script parameters Currently maintainer script parameters are not passed on to the hook scripts, but IMO they could be very useful, for example: a bootloader update only needs to be run on package removal, but not on purge. Given the previous point I think adding them to the parameters passed to the hook scripts is not a good option. I therefore propose to instead export them in a standard environment parameter. Proposal: export DEB_MAINT_PARAMS=$@ Hmm. That would mean that the first argument is the name of the script, then? No. $@ starts at $1, not at $0. In the hook scripts I currently use I do: version=$1 set -- $DEB_MAINT_PARAMS Execution order of hook scripts --- Both initramfs-tools and ltsp-client currently just dump a script in the hook dirs without any naming convention. If many packages were to do that, chaos would be a guaranteed result. IMO scripts should have standardized names starting with numbers to regulate execution order. Ranges should be reserved, for example: - early scripts 00-19 - initrd generation 30-49 - bootloader update 50-69 - late scripts 80-99 Use of new numbers by packages should probably be coordinated by the kernel team. If this were to become policy, I would say _all_ stakeholders should be involved, not just the official kernel packages, and that means not shutting out end users who compile their own kernel image debs. Agreed. That's why I said coordinated and not mandated. However, IMO it's probably not unreasonable to expect stakeholders to be subscribed to d-kernel. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Standardizing use of kernel hook scripts
On Wednesday 01 April 2009, maximilian attems wrote: On Wed, 01 Apr 2009, maximilian attems wrote: what be cool would be to have it use debhelper instead of the dpkg call. I disagree. deb-pkg only creates a two binary packages. It's not a normal package build process at all and the direct dpkg call is perfectly suited for that. Also: - the lack of orig.tgz would probably break debhelper/dpkg-buildpackage anyway - using debhelper would probably imply running a clean target and that's one of the reasons why I very much prefer deb-pkg over make-kpkg: build times with deb-pkg are significantly lower also a linux header and linux-libc-dev package creation. I've had that thought as well, but please as a _separate_ build target (or somehow optional). Same maybe for a -doc package. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Standardizing use of kernel hook scripts
(dropping ltsp as the list is moderated)
On Wednesday 01 April 2009, maximilian attems wrote:
On Wed, 25 Mar 2009, Frans Pop wrote:
I'm not sure whether this discussion should happen here (d-kernel +
selected interested parties) or would be better held on d-devel.
If ppl think it would be better on d-devel, then please let me know
and I'll restart it there.
think this is right place, we could/should add linux-kbuild too.
Hmmm. IMO the discussion is Debian internal (derivatives might be
interested). It could result in adjustments to deb-pkg, but I don't see
why l-kbuild want to participate in the discussion.
The maintainer scripts for the thus generated kernel image package
don't do anything but call hook scripts in
/etc/kernel/{pre,post}{inst,rm}.d/.
right, we might want to fix that for depmod to have it shipped a
postinst.
I assume:
s/shipped/include/
s/postinst/postscript hook script/
DEB-PKG PATCHES
===
My patch series for the upstream kernel contains roughly the
following changes:
- some minor cleanup
would be nice to see, can you post those linux-kbuild.
maybe as followup on mine, maybe we step on each toes with those ;)
script is not huge.
Posted to linux-kbuild now.
- an option to use a different hook scripts directory from
/etc/kernel (I currently use /etc/kernel.custom to avoid my hook
scripts to be run when I install an official Debian kernel package)
don't think /etc/kernel.custom is a good idea.
Note that I do not proscribe /etc/kernel.custom in any way. I'm just
offering the user the option to specify a different location from
/etc/kernel, so that he has the *option* to use a completely separate set
of scripts for custom kernels than any standard hook scripts. What path
they use is completely up to them.
i'd be more happier to move that to /lib like udev that moved from
/etc/udev/rules.d/ to /lib/udev/rules.d/
Hmm. I thought one of the points for udev was that users can define (at
least add) their own rules. I assume there's still a mechanism to add or
override the standard scripts under /lib in /etc?
IMO the same goes for the kernel hook scripts. Definitely something that
should be considered carefully.
The default for deb-pkg should IMO remain /etc/kernel in order not to
break things for existing users. If you move to /lib and users want to
follow, they can use my mechanism.
ISSUES
==
Parameters passed to hook scripts
-
Official Debian kernels (at least up to 2.6.26) and make-kpkg based
packages pass two parameters:
- kernel version
- $realimageloc$kimage-$version (/boot/vmlinuz-kvers)
deb-pkg based packages only pass the kernel-version.
AFAICT ltsp-client hook scripts use neither of these parameters.
New initramfs-tools hook scripts uses the kernel version and includes
a hack that tests if $2 is defined to avoid running with pre-squeeze
kernels and make-kpkg kernels. Not ideal...
why not ideal?
Because it relies on a very specific, largely accidental difference
between implementations. What if we decide that we _do_ want to use a
second parameter for something.
My suggestion set the origin of a build in an envvar is more flexible.
if you read initramfs-tools changelog you'd see that a first attempt
to have make deb-pkg support was done for lenny but failed
due to double removal of same initramfs irc.
I agree that it's an issue. For me double runs of the boot loader update
was the reason I wanted the alternative hook dir option.
Execution order of hook scripts
---
Both initramfs-tools and ltsp-client currently just dump a script in
the hook dirs without any naming convention. If many packages were to
do that, chaos would be a guaranteed result.
IMO scripts should have standardized names starting with numbers to
regulate execution order. Ranges should be reserved, for example:
- early scripts 00-19
- initrd generation 30-49
- bootloader update 50-69
- late scripts 80-99
Use of new numbers by packages should probably be coordinated by the
kernel team.
nah not very useful,
Eh? Then how are you going to ensure update-initramfs runs before
update-grub? Alphabetically they are in the wrong order.
enforcing correct file name ending with .sh might be more worthwhile.
That's discouraged by policy (except maybe for files that are sourced).
To conffile or not to conffile
--
If I'm correct neither initramfs-tools nor ltsp-client currently
defines the hook scripts as conffiles. This is both good and bad.
- good: the hook script are removed when the package is removed which
avoids the problem that it could get run after removal, but before
purge - bad: user changes in the scripts get lost on package upgrades
no conffile.
users shouldn't care to much about these details.
Most users probably won't care, but I still think you
Re: Standardizing use of kernel hook scripts
Manoj Srivastava wrote: On Wed, Apr 01 2009, Frans Pop wrote: (i.e. is there any reason to _add_ support for it in deb-pkg or in whatever the kernel team is planning)? I think so. If we do standardize on /etc/kernel/*.d directories as the place where kernel packages will look into to run scripts, then the scripts in that location should have a common API. Since we have an installed base, and there is going to be continued support for this feature by the current debian end user kernel packaging tool, we can't just drop the old api and scripts. Eh, different _existing_ tools already diverge. I agree on the need for a common API, or at least ensuring that there is legacy support. (After all, that is why I sent my initial mail). But I see no reason why the the make-kpkg way should be elevated to that standard API without any discussion. Also, this proposal should go through the vetting of the primary place we make technical policy for Debian, which is the debian-policy mailing list. Since this is going to require interaction between all kinds of packages in providing scripts for kernel package handling, the standards we create for determining when these scripts are triggered, how parameters are passed in, is precesily the kind of thing that policy is created for. I have no problems with that. Traditionally, you passed --initrd to make-kpkg to trigger the call to initrd; but now that we are thinking of different drivers than make-kpkg, how is this information stored and sent to the script? Which only worked because initrd generation was/is coded in the postinst itself and not in a postinst hookscript. To be honest, I don't really see why k-p supports hook scripts at all, given that it already does everything that's normally needed in the regular postinst it generates. For that reason I would guess that the number of users that actually use the existing hook script mechanism in make-kpkg is very, very low [1]. And that is a completely different model from what the deb-pkg target does and what's now being considered by the kernel team. Unifying those separate models is always going to be painful. Cheers, FJP [1] Which IMO makes the legacy issue somewhat less important than it would otherwise be. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Standardizing use of kernel hook scripts
As there haven't been any replies to my mail yet, I'm just going to push my patches for the deb-pkg target upstream. The only really important issue is the passing of maintainer script parameters as described below. I hope we can standardize on that. Cheers, FJP Frans Pop wrote: Maintainer script parameters Currently maintainer script parameters are not passed on to the hook scripts, but IMO they could be very useful, for example: a bootloader update only needs to be run on package removal, but not on purge. Other examples are: - a test to prevent removal of the currently running kernel (while allowing upgrades) - a warning to reboot if the currently running kernel is upgraded Given the previous point I think adding them to the parameters passed to the hook scripts is not a good option. I therefore propose to instead export them in a standard environment parameter. Proposal: export DEB_MAINT_PARAMS=$@ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Standardizing use of kernel hook scripts
Hi all,
I'm not sure whether this discussion should happen here (d-kernel +
selected interested parties) or would be better held on d-devel.
If ppl think it would be better on d-devel, then please let me know and
I'll restart it there.
Sorry if any of this has already been discussed or documented. I must
admit I've not looked very hard.
Cheers,
FJP
(I've subscribed to d-kernel for this discussion but don't mind CCs in
this case.)
INTRO
=
For the past year and more I've been building upstream kernels without
using any Debian tools, by just calling the kernel's own 'make deb-pkg'
target.
The maintainer scripts for the thus generated kernel image package don't
do anything but call hook scripts in /etc/kernel/{pre,post}{inst,rm}.d/.
Current official Debian kernels (at least up to 2.6.26) also call any
scripts there and so do kernel packages built using make-kpkg.
I've seen that the new squeeze version of initramfs-tools now installs
hook scripts in those dirs [1]. I think the kernel team is planning to
switch to a general use of the hook scripts for squeeze.
A grep through the lintian lab showed ltsp-client as the only other
package that installs hook scripts there.
For my kernel testing I've been using some patches for the deb-pkg target
which I'd now like to push upstream. While I was finalizing them, I ran
into some issues I'd like to discuss with you.
In general the kernel team should be aware that there _are_ other current
users of /etc/kernel/ hook scripts.
[1] Although I did not see it mentioned in the changelog.
DEB-PKG PATCHES
===
My patch series for the upstream kernel contains roughly the following
changes:
- some minor cleanup
- a fix so that the arm kernel image gets found (use of KBUILD_IMAGE is
not completely standard across arches)
- a way to pass maintainer script parameters to hook scripts (see below)
- an option to specify a custom package version/revision
- an option to use a different hook scripts directory from /etc/kernel
(I currently use /etc/kernel.custom to avoid my hook scripts to be
run when I install an official Debian kernel package)
The last patch provides a general escape, but it would be nice if all
Debian kernel packages could use the same hook scripts. (/me dreams)
Note that none of my patches affect Debian kernel builds as they don't use
the deb-pkg target.
ISSUES
==
Parameters passed to hook scripts
-
Official Debian kernels (at least up to 2.6.26) and make-kpkg based
packages pass two parameters:
- kernel version
- $realimageloc$kimage-$version (/boot/vmlinuz-kvers)
deb-pkg based packages only pass the kernel-version.
AFAICT ltsp-client hook scripts use neither of these parameters.
New initramfs-tools hook scripts uses the kernel version and includes a
hack that tests if $2 is defined to avoid running with pre-squeeze
kernels and make-kpkg kernels. Not ideal...
There is legacy here which makes any transition hard. But given the
limited existing users of hook scripts I think we can essentially ignore,
but it would be good to agree on a standard for the future!
Is anything other than the kernel version really needed?
Maintainer script parameters
Currently maintainer script parameters are not passed on to the hook
scripts, but IMO they could be very useful, for example: a bootloader
update only needs to be run on package removal, but not on purge.
Given the previous point I think adding them to the parameters passed to
the hook scripts is not a good option. I therefore propose to instead
export them in a standard environment parameter. Proposal:
export DEB_MAINT_PARAMS=$@
Execution order of hook scripts
---
Both initramfs-tools and ltsp-client currently just dump a script in the
hook dirs without any naming convention. If many packages were to do
that, chaos would be a guaranteed result.
IMO scripts should have standardized names starting with numbers to
regulate execution order. Ranges should be reserved, for example:
- early scripts 00-19
- initrd generation 30-49
- bootloader update 50-69
- late scripts 80-99
Use of new numbers by packages should probably be coordinated by the
kernel team.
To conffile or not to conffile
--
If I'm correct neither initramfs-tools nor ltsp-client currently defines
the hook scripts as conffiles. This is both good and bad.
- good: the hook script are removed when the package is removed which
avoids the problem that it could get run after removal, but before purge
- bad: user changes in the scripts get lost on package upgrades
IMO all hook scripts should be conffiles so user changes get preserved.
But that means that they need to include a check (existence of main
package binary for example) and exit 0 if the package was removed but not
purged.
Allow user to control execution of hook scripts?
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Friday 20 March 2009, Michal Marek wrote: Frans Pop napsal(a): The use case here, which I suspect is not all that uncommon, is that I built a kernel from upstream source on a (Debian unstable) system with the new version of depmod and then installed that kernel on a (Debian stable) system that has an older version of modprobe [1]. Backward vs. forward compatibility discussion aside, there is a reason why most (all?) distro kernel packages run depmod at *install time* on the target machine. There might be modules installed by other packages, the format might change, newer depmod has a configuration file and finally the files are not exactly small and can be recreated rather easily. It might be a good idea to do the same when compiling kernels manually and copying them around. After some more reflection I've come to agree with this. Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511334: S390 boot fails on Flex-ES machine
tags 511334 patch thanks On Thursday 19 March 2009, Adam Thornton wrote: This appears to fix the problem, in that I get much farther and then get stuck in the init-premount scripts because it can't vary my root disk online. But *that* is probably because, on this host, I've been using by-path disk IDs, and I'd been changing various kernel build parameters to roll the DASD drivers into the kernel (that is, not use them as modules). So that is very likely my fault. I suspect this issue is resolved. Get me an official kernel image build with it (and with the requisite modules) and I'll be happy to test, or I can build another one tomorrow (which will, alas, take all day again). Thanks for testing. There's no way I can get you an official fixed kernel on short notice. You'll have to build your own for now. Dann: Can you please consider the patch I linked to in [1] for stable updates of both .24 and .26? AFAICT the patch should apply cleanly to both as the broken code was introduced in .19. The patch also fixed two very hard to trace hangs in .28 and .29 where bisection lead to unrelated changes which just happened to trigger this bug in such a way that it caused a hang. TIA. [1] http://bugs.debian.org/511334#65 signature.asc Description: This is a digitally signed message part.
Bug#518412: initramfs-tools: must support relative paths in modules.dep
On Thursday 19 March 2009, maximilian attems wrote: Recently kernels I built from upstream kernel source failed to boot after unpacking them because no modules got included in the initramfs initrd (and thus no root file system). This problem was solved after downgrading to m-i-t 3.4.1. how can i reproduce this? upgraded to latest m-i-t 3.7-pre9-1 and run depmod + mkinitramfs. the generated initramfs had all modules i expect it to have. You have to build a kernel from source while having the new m-i-t installed. And then install that kernel *without* running depmod (which is currently also not done by i-t). If you do run an extra depmod manually before calling i-t the problem will have fixed itself because depmod is then called differently than during the kernel build. I saw this issue after installing a kernel built from upstream source using 'fakeroot make deb-pkg' (i.e. without using kernel-package or anything). With the stable version of m-i-t kernels built that way install perfectly (using custom hook scripts to create the initrd and update grub etc.). You can probably also reproduce it by running the following sequence of commands, which should emulate the way the upstream kernel Makefile calls depmod (using any kernel version you have installed for kvers): # kvers=kvers # mkdir -p /tmp/lib/modules # cp -r /lib/modules/$kvers /tmp/lib/modules/ # rm /tmp/lib/modules/$kvers/modules.* # depmod -ae -F /boot/System.map-$kvers -b /tmp/ -r $kvers The file /tmp/lib/modules/kvers/modules.dep should then show the problem. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: initramfs-tools: must support relative paths in modules.dep
On Thursday 19 March 2009, maximilian attems wrote: thanks for quick feedback. On Thu, Mar 19, 2009 at 05:15:06PM +0100, Frans Pop wrote: You have to build a kernel from source while having the new m-i-t installed. And then install that kernel *without* running depmod (which is currently also not done by i-t). well linux-2.6 images postinst and even k-p do this, so this quite arguiably a bug in make deb-pkg. No. deb-pkg CANNOT do this because it is executed on the system building the kernel and the extra depmod would need to be run on the system where the kernel is installed. So *at most* my custom hook scripts that get executed when the kernel is installed would be at fault for not doing the extra depmod (and I could easily change them to do that, but that would be only solving the problem for me and not for everybody else). However, IMO a modules.dep file created by the upstream kernel Makefile using an official version of m-i-t should be assumed to be valid and should thus be supported by i-t. If the file is not valid, then there would be a bug in m-i-t, but Marco has argued that it is not. You can probably also reproduce it by running the following sequence of commands, which should emulate the way the upstream kernel Makefile calls depmod (using any kernel version you have installed for kvers): # kvers=kvers # mkdir -p /tmp/lib/modules # cp -r /lib/modules/$kvers /tmp/lib/modules/ # rm /tmp/lib/modules/$kvers/modules.* # depmod -ae -F /boot/System.map-$kvers -b /tmp/ -r $kvers The file /tmp/lib/modules/kvers/modules.dep should then show the problem. copied over that file and saw still no sign of a trouble: mkinitramfs -v -o /tmp/foo | head -n 12 Are you sure you have the new version of m-i-t installed? Did you check the contents of the generated modules.dep file? Maybe my command was broken though. I did not check it as I've put m-i-t on hold on all my machines. I'll check the actual command executed by the kernel later. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: initramfs-tools: must support relative paths in modules.dep
On Thursday 19 March 2009, maximilian attems wrote: copied over that file and saw still no sign of a trouble: mkinitramfs -v -o /tmp/foo | head -n 12 Here's the actual depmod command executed during a kernel build: /sbin/depmod -ae -F System.map -b /home/fjp/projects/kernel/builds/amd64/debian/tmp 2.6.29-rc8-rjw So, the (undocumented?) -r option is not there. But even with the -r the commands I gave work for me to reproduce the broken modules.dep file: f...@thorin:~$ apt-cache show module-init-tools | grep Version Version: 3.7-pre9-1 f...@thorin:~$ kvers=2.6.26.3 f...@thorin:~$ mkdir -p /tmp/lib/modules f...@thorin:~$ cp -r /lib/modules/$kvers /tmp/lib/modules/ f...@thorin:~$ rm /tmp/lib/modules/$kvers/modules.* f...@thorin:~$ sudo depmod -ae -F /boot/System.map-$kvers -b /tmp/ -r $kvers f...@thorin:~$ less /tmp/lib/modules/2.6.26.3/modules.dep f...@thorin:~$ grep : .\+ /tmp/lib/modules/2.6.26.3/modules.dep | head -n3 kernel/fs/cramfs/cramfs.ko: kernel/lib/zlib_inflate/zlib_inflate.ko kernel/fs/hfs/hfs.ko: kernel/fs/nls/nls_base.ko kernel/fs/nfs_common/nfs_acl.ko: kernel/net/sunrpc/sunrpc.ko While for the original (correct) modules.dep: f...@thorin:~$ grep : .\+ /lib/modules/2.6.26.3/modules.dep | head -n3 /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/rpcsec_gss_spkm3.ko: /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko /lib/modules/2.6.26.3/kernel/net/sunrpc/sunrpc.ko /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/rpcsec_gss_krb5.ko: /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko /lib/modules/2.6.26.3/kernel/net/sunrpc/sunrpc.ko /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko: /lib/modules/2.6.26.3/kernel/net/sunrpc/sunrpc.ko My hookscript does: if [ -f /boot/initrd.img-$version ]; then update-initramfs -u -k $version else update-initramfs -c -k $version fi Does 'update-initramfs -c' behave differently from mkinitramfs? If I run update-initramfs (0.92o) with a broken modules.dep I get: # update-initramfs -v -c -k 2.6.26.3 | head update-initramfs: Generating /boot/initrd.img-2.6.26.3 Copying module directory kernel/drivers/ide Copying module directory kernel/drivers/scsi Copying module directory kernel/drivers/block Copying module directory kernel/drivers/ata Copying module directory kernel/drivers/mmc Adding binary /usr/share/initramfs-tools/init Adding binary /etc/initramfs-tools/initramfs.conf Adding binary /usr/share/initramfs-tools/conf.d/uswsusp Adding binary /etc/initramfs-tools/conf.d/resume Adding binary /bin/busybox # ls -l /boot/initrd.img-2.6.26.3* -rw-r--r-- 1 root root 4139731 2009-03-19 18:42 /boot/initrd.img-2.6.26.3 -rw-r--r-- 1 root root 5537135 2008-08-22 02:58 /boot/initrd.img-2.6.26.3.sv -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
(lkml dropped) On Thursday 19 March 2009, Jon Masters wrote: On Thu, 2009-03-19 at 21:13 +0100, maximilian attems wrote: That would mean that m-i-t has created a backwards incompatibility problem _with itself_ and that the problem actually is installing a kernel, that was built on a system with new m-i-t, on a system with old m-i-t. Looks like the problem is actually that depmod was run under the newer version and then you tried to use the generated files with an older modprobe. I'm not sure that's actually an error - it was noted that the slight format change was unideal for such unlikely cases and in fact we won't do that again in the future. But if you were just moving forwards from one release to the next you would have been fine - you're talking lack of forward compatibility actually. The use case here, which I suspect is not all that uncommon, is that I built a kernel from upstream source on a (Debian unstable) system with the new version of depmod and then installed that kernel on a (Debian stable) system that has an older version of modprobe [1]. The kernel Makefile of course does: /sbin/depmod -ae -F System.map -b $(INSTALL_MOD_PATH) $(KERNELRELEASE) Because the old modprobe does not understand the new relative (or rather rootless) paths, aggravated by the fact that initramfs-tools does not error out or display errors from modprobe (probably for good historic reasons), I suddenly had an initramfs that contained no modules and thus a system that failed to reboot with the new kernel. It took me quite a lot of time to trace it back to the upgrade of module-init-tools. Needless to say that this had always worked without any problems before. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Thursday 19 March 2009, Jon Masters wrote: Yes, it was a bad idea of mine (perhaps) to change the existing file format and I've learned something, but it should only have affected for example that 3.4 release you're using. Do you mean that earlier versions are not affected? Hasn't depmod generated full paths basically any version up to 3.6? But even if it is only 3.4, that still makes it every Debian stable user (and unknown other distros) who runs the risk of ending up with an unbootable system for hard to trace reasons... Potentially painful for example for NAS devices where the kernel and initrd get installed in flash, replacing the previous version. As the kernel Makefile does run depmod during a build, I don't think it's strange to assume users rely on that modules.dep being valid, even for older versions of modprobe. What exactly are the resons behind the change in file format that're so strong that depmod cannot continue to generate the old format for the next 5 years or so as a transition period, until the risk is much lower that users run into problems because their current version of modprobe does not understand the new format? Are they really worth the potential consequences? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Thursday 19 March 2009, Jon Masters wrote: [...] I understand how and why and when it works now. I can also easily avoid the problem now that I know about it. The question here is if the breakage is really necessary. I ran into the problem within days of installing the new m-i-t. I don't think I'm very special, so my guess is it's going to affect others too. I guess it's called progress ;) Sarcasm aside, if you can give me an example of an actual real life set of users who are adversely affected then I'll try to do something to help out. But if you're asking for old versions of software to be compatible with newer releases in every case I think you're not being terribly realistic. The kernel changes to make progress, and so do other utilities. No, sorry. That isn't, at least AIUI, how kernel (related) development is supposed to be done: http://lkml.org/lkml/2005/12/29/173 and similar discussions later. Sure, if there are very strong reasons to break things, fine. But whenever possible the kernel has ensured backwards compatibility, mostly only _after_ someone complained. Think of the i386 and x86_64 symlinks after the x86 integration, think of the COMPAT_SYSFS flags, think of optional support for old /proc files, think feature-removal-schedule.txt. So far you seem to be avoiding to give the reasons for the change. What would be so wrong with ensuring the compatibility for some transition period and avoiding the problem? P.S. Thanks a lot for your prompt replies. I do appreciate the discussion. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Friday 20 March 2009, Jon Masters wrote: Sure, if there are very strong reasons to break things, fine. But whenever possible the kernel has ensured backwards compatibility, mostly only _after_ someone complained. Think of the i386 and x86_64 symlinks after the x86 integration, think of the COMPAT_SYSFS flags, think of optional support for old /proc files, think feature-removal-schedule.txt. All of these examples refer to the future. The *future*. Things that will change, preserving backward compatibility, keeping symlinks around for those who are used to the old location. *Backward* compatibility. Exactly: making sure that tools in older userspace environments (old version of modprobe) continue to work with new kernels (or built in an environment that happens to have the latest and greatest depmod). But the issue you raised was about *Forward* compatibility. This is nice but isn't the same. That would be like guaranteeing that all future kernel features will work with a kernel from 6 months ago, or that modules will, or other similar stuff. I really don't see the huge difference. IMO you are comparing apples with oranges. I'm really don't think I'm trying to use modules from a 2.4 kernel with a 2.6 kernel here. m-i-t is _not_ an integral part of the kernel. It's just another tool, and one that's used in two different environments: a kernel build environment and a kernel user environment. And the format of the files generated by one and read by the other is the glue that keeps things together. Changing that format should IMO be done with due consideration for relevant use cases, and only if there are very strong arguments to do so. So far you seem to be avoiding to give the reasons for the change. What would be so wrong with ensuring the compatibility for some transition period and avoiding the problem? [...] Hopefully you see that this is not a regular compatibility issue. What I mainly see is that you seem to be avoiding answering this question and are apparently unwilling to consider to repair the situation. I think my 2 cents are played out by now, so I'll drop things here. Maybe someone else will be willing to take up the batton. At least the issue is somewhat documented now. I'll inform others in Debian that the issue exists and fix things locally for my own use case. Thanks again for your replies. Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511334: #511334 debian-installer: S390 boot fails on Flex-ES machine
Adam, Can you test if the following patch on top of the Debian 2.6.26 kernel fixes the problem for you? http://lkml.org/lkml/2009/3/18/79 Please CC me when you reply! Thanks, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511334: debian-installer: S390 boot fails on Flex-ES machine
I think this bug is related to an issue I've seen myself with 2.6.28. The symptoms (point where the boot hangs) are somewhat similar at least. There seems to be a bug in the kernel's timekeeping code which can manifest itself differently depending on the (emulated) hardware clock. My issue was reported upstream in http://lkml.org/lkml/2009/3/7/155. See also http://lkml.org/lkml/2009/3/12/23 and my reply to that. However, it's also possible the above is totally unrelated... Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#518407: module-init-tools: Invalid modules.dep file created during upstream kernel build
On Friday 06 March 2009, Marco d'Itri wrote: On Mar 05, Frans Pop elen...@planet.nl wrote: The problem seems to be that depmod, which is run as part of the build, generates a modules.dep file with incomplete paths. These incomplete paths in turn cause initramfs-tools to create a broken initrd. Upstream says this is a feature, and actually it is documented in the changelog. If path[0] != '/' then the path is relative to the kernel directory. That does not really explain *why* the behavior was changed. and IMO it's an extremely unfortunate backwards compatibility issue. I also don't think changing initramfs-tools is sufficient to fix this. It is very much possible that someone builds a new kernel package on a system running unstable/testing and thus having the new m-i-t, but wants to install it on a system running stable that has the old intramfs-tools. As the initramfs is created at package installation time, a reboot will still fail in that case. For the same reason fixing the upstream kernel Makefile is no solution as that would only fix the problem for new kernel versions. IMO m-i-t will need to ensure backwards compatibility for the forseeable future (at least until lenny is archived) to avoid major problems for users. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515695: installation-reports: USB Install fails when too many ISOs are found
reassign 515695 iso-scan thanks On Tuesday 17 February 2009, Rohan Dhruva wrote: Comments/Problems: My /dev/hda5 is a vfat partition having many (upwards of 15) ISOs. They are all present in a single directory in the root, so debian installer did check them. That is an extremely unusual situation, and the base cause of this failure. To remedy the problem, I moved all the ISOs in /dev/hda5 to 3 level deep directories. That way, they are not scanned on the first run. That is exactly why we limit the depth of the scan: because it is much more likely ISOs are saved deeper in a tree than so high up. Possibly there are ways to improve this issues, but I'm not sure it will receive a very high priority. Reassigning to the correct package. Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Udeb migrations (was: Meeting(s) at FOSDEM)
As requested during the meeting here are two links that explain udeb migration. The first also has a proposal how to improve udeb support in britney. Please ignore the introductory comment about the python implementation of britney. Note that the proposal is not a perfect solution. For that we would need to change the dependency handling for udebs which requires changes in various build tools and D-I. http://lists.debian.org/debian-release/2007/05/msg00086.html http://lists.debian.org/debian-boot/2008/04/msg00132.html Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Meeting(s) at FOSDEM
On Thursday 05 February 2009, Steve McIntyre wrote: On Sun, Feb 01, 2009 at 02:53:58PM +, Steve McIntyre wrote: Hi folks, Apologies for the massive cross-posting, but I'm trying to arrange some discussions between the various teams, or at least those members who will be at FOSDEM. Topics I'd like us to talk about include: 1. how the d-i daily builds are done and distributed 2. how the needs of the kernel d-i teams can better be reconciled I'm guessing that quite a number of people may be interested in these, and in other topics. Is there anything else I'm missing that you would like to discuss? Then: when and where would be a good time to meet up? Hello? Anyone? As I've already made my opinion clear by mail on the first issue I don't see much point in a meeting unless others show an interest in it. For the second issue I doubt that FOSDEM is the right venue. I'll be at FOSDEM and if there is a meeting I'm willing to attend. I can explain some of the technical issues involved and explain why IMO triggering daily builds by uploads is a very bad idea. signature.asc Description: This is a digitally signed message part.
Re: Bug#511334: debian-installer: S390 boot fails on Flex-ES machine
reassign 511334 linux-2.6 2.6.26-12 thanks On Friday 09 January 2009, Adam Thornton wrote: S390 boot fails (sometimes just after detecting memory, sometimes after detecting devices) on z/VM 5.2 and a Flex-ES machine. Since there are reports of d-i working on z9 boxes, I suspect the issue is that the kernel is built to exploit later System z functionality. At least for d-i the basic 31-bit-no-frills architecture should be selected as the s390 kernel (and basic 64-bit for s390x, e.g. z900), with options for kernels that exploit later additions to the architecture for installation (ideally based on detected machine type). This sounds like a kernel issue rather than an installer issue. Therefore reassigning to the kernel team. Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#509202: sparc on Sun Fire V880 fails due to unaligned access
reassign 509202 linux-2.6 2.6.26-12 thanks Reassigning to the kernel team and informing Sparc porters. Original report contains full log with kernel oopses. Cheers, FJP On Wednesday 07 January 2009, Adrian Knoth wrote: When trying to boot the debian sparc kernels linux-image-2.6.26-1-sparc64(-smp) from harddisk, the machine freezes very early, probably around [0.00] [00036f10-f8b00a80] page_structs=131072 node=0 entry=1469/0 (cannot be too sure about that, the attached RSC serial console is somewhat limited) I compiled my own sparc64 kernel (2.6.28, initial config taken from the Gentoo 2.6.24 live CD). This new kernel boots without any problems, the machine is up and running. I've attached you my working kernel config, so you can check what might have caused the problems reported in this bug. Perhaps it's worth to reassign this bug to the kernel package. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#416208: Installation report HP-715/64 (HIL)
On Wednesday 24 December 2008, Moritz Muehlenhoff wrote: Is it possible that someone from the debian-installer teams add this modprobe hilkbd somewhere to the bootup process? This modprobe should also be carried over to the installed system afterwards. I'm willing to test any temporary images (preferably netboot images) as soon as possible. [Forwarding to debian-b...@lists.debian.org] Why not (also) reassign the BR to debian-installer? Can that be considered for rc2? Theoretically that would still be possible, but it is extremely late in the day for such a change, especially without any detailed info about how *exactly* this should be implemented. Questions that come to mind are: - why doesn't the kernel/udev autoload this module? - is there any way to recognize whether the module should be loaded or not (most hppa installs are headless)? - if it's decided to load the module unconditionally for the installer, it may still be possible to only do so when needed for the installed system; can this be recognized somehow? - is loading the module for the installed system needed for the initrd too (would be my guess), or just for the final system? We have repeatedly indicated in the debian-hppa list that the D-I team needs porter support and this is *exactly* the kind of issue for which knowledgable porter support is needed. I even had a long discussion with Helge himself about that. As this issue has been known for ages my first reaction is that it is too late for RC2 and for Lenny. However, *if* porters work with the D-I team to get the questions above answered the change could be implemented early for squeeze and, after testing, it could then be considered for backporting for a stable update release. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#506711: kernel-package: [sparc] no longer produces compressed kernels for linux-2.6
Package: kernel-package Version: 11.0011 Severity: serious Tags: d-i Justification: kernels built using this break sparc D-I builds Daily builds of D-I for sparc have been failing with: gzip: ./tmp/netboot/vmlinuz-2.6.26-1-sparc64: not in gzip format This has been traced to the fact that the kernel as taken from the 2.6.26-10 linux-image package for sparc64 (built 08 Nov) is no longer compressed. As sparc still uses kernel-package to build official Debian kernel images (based on info from Bastian Blank), this is most likely a regression in kernel-package. It is unknown whether this issue also affects other architectures or not. The previous D-I kernel udebs were based on linux-image 2.6.26-8 (built for sparc on 9 Okt) did not have this issue, so at that time things were still OK. Please inform both the kernel team and the installer teams when this issue is fixed as we will need binNMU's for linux-2.6 for any (potentially) affected architectures and after that new uploads of the kernel udebs for D-I. Cheers, FJP -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-rc6 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kernel-package depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii debianutils 2.30 Miscellaneous utilities specific t ii dpkg1.14.22 Debian package management system ii dpkg-dev1.14.22 Debian package development tools ii file4.26-1 Determines file type using magic ii gcc [c-compiler]4:4.3.2-2The GNU C compiler ii gcc-4.1 [c-compiler 4.1.2-23 The GNU C compiler ii gcc-4.2 [c-compiler 4.2.4-4 The GNU C compiler ii gcc-4.3 [c-compiler 4.3.2-1 The GNU C compiler ii gettext 0.17-4 GNU Internationalization utilities ii make3.81-5 The GNU version of the make util ii module-init-tools 3.4-1tools for managing Linux kernel mo ii perl5.10.0-17Larry Wall's Practical Extraction ii po-debconf 1.0.15 manage translated Debconf template ii util-linux 2.13.1.1-1 Miscellaneous system utilities Versions of packages kernel-package recommends: ii bzip2 1.0.5-1high-quality block-sorting file co ii libc6-dev [libc-dev] 2.7-16 GNU C Library: Development Librari Versions of packages kernel-package suggests: pn docbook-utils none (no description available) ii e2fsprogs 1.41.3-1 ext2/ext3/ext4 file system utiliti ii initramfs-tools [linux-in 0.92l tools for generating an initramfs pn libdb3-devnone (no description available) ii libncurses5-dev [libncurs 5.6+20080830-1 developer's libraries and docs for pn linux-source | kernel-sou none (no description available) ii xmlto 0.0.20-3 XML-to-any converter -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#506711: kernel-package: [sparc] no longer produces compressed kernels for linux-2.6
On Monday 24 November 2008, Manoj Srivastava wrote: Could you provide more detail, please? This is not enough to indicate where the fault lies. At a minimum, the kernel package invocation line, and the full logs of the build where failure was noticed should be provided to the bug report. Without this information, it is hard to diagnose the problem. The only thing I can see is that sparc processing in k-p defines NEED_DIRECT_GZIP_IMAGE. Now, what kernel-package thinks is the architecture is taken from either a) user specified value, b) dpkg-architecture -qDEB_HOST_ARCH_CPU If the architecture contains the string sparc, then we arrange to gzip the image. If this is not happening, we need to determine if it tried to compress, but compressed the wong file, or it did not try to compress it at all, or if the actual image is in some other place. If the build logs for the kernel image show which of these scenarios it is, it can be easily fixed. So the build log of the kernel image would be useful. This has been traced to the fact that the kernel as taken from the 2.6.26-10 linux-image package for sparc64 (built 08 Nov) is no longer compressed. As sparc still uses kernel-package to build official Debian kernel images (based on info from Bastian Blank), this is most likely a regression in kernel-package. Why do you say this is a regression? Does the previous version work? What was the last known working version of the kernel-package? It is unknown whether this issue also affects other architectures or not. The previous D-I kernel udebs were based on linux-image 2.6.26-8 (built for sparc on 9 Okt) did not have this issue, so at that time things were still OK. Which version of kernel-package was being used then? Sorry, I cannot provide the requested info as I'll be off-line for a few day starting in 30 minutes. CC'ing d-boot and d-kernel. signature.asc Description: This is a digitally signed message part.
Re: Bug#504016: Lenny Beta II + daily build, kernel dies after initrd.gz....ready.
reassign 504016 linux-2.6 thanks On Saturday 01 November 2008, Hans-Joachim Zierke wrote: But I found it by completely disabling almost everything in the BIOS, getting a success, then systematically reenabling stuff. It's the Promise ATA-100 BIOS. If I reset that BIOS from Auto to Disabled, then I get the Ok, booting the kernel message. The A7V Board has an ATA-66 controller in the chipset, plus an additional ATA-100 Promise controller on the motherboard. The strange thing is that your initial report shows that the initrd and kernel do get loaded from the CD; it just fails to take the next step. As this really looks like a kernel issue, I'm reassigning your report to the kernel team. Maybe they can offer additional help. It could also possibly an isolinux problem. have you tried installing the Lenny kernel on your Etch system and booting that? I won't even know how to do that. ;-) I know how to compile a kernel for the running system with make-kpkg, but that's it. Just download the package from packages.debian.org and install it using 'dpkg -i package'. I'm not a Linux freak, but a user. When I looked for Lenny news on the website, I read that we should try the installer, so I did. Thanks a lot for testing it. We do appreciate that and the fact that you filed your installation report. Unfortunately when you do run into such a problem with Linux it's basically up to the user to find the correct person to look into the problem and to provide any needed info to track it down. Depending on the issue, that can require a significant amount of effort on the user's part. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#504655: debian-installer: Kernel panic when velocity driver started
reassign 504655 linux-2.6 2.6.26-8 thanks On Wednesday 05 November 2008, Axel Beckert wrote: Tried to install Debian Lenny on a VIA EPIA SN (VIA C7, i386 arch) board today. This one has a VIA Rhine II (VT6102) and a VIA Velocity (VT6120/VT6121/VT6122) NIC. When detecting the network cards, the kernel panics. In the log I saw that the panic happened while ip was running. The panic hasn't happened with an old, 2.6.24 based Lenny installer I tried first (but didn't seem to have LVM support). http://bugzilla.kernel.org/show_bug.cgi?id=11121 seems to be exactly the problem I have. Looks like the problem has been introduced with 2.6.26, so it's really a regression. Workaround is to add pci=noacpi at the boot prompt as reported in the comments to the above mentioned kernel bug report. As this is a kernel problem, I'm reassigning this to the kernel team. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#501023: kernel 2.6.26-1-amd64 hangs at boot.
reassign 501023 linux-2.6 2.6.26-5 thanks Reassigning to the kernel team. On Friday 03 October 2008, Ade King wrote: Comments/Problems: After a fresh install of Lenny i upgraded the kernel to 2.6.26-1-amd64. During the boot process i get a hang here is the result from dmesg: [ 19.165444] ata3: link is slow to respond, please be patient (ready=0) [ 24.881079] ata3: COMRESET failed (errno=-16) It will hang at this point for approximately 10 seconds,then continue to boot normally. This problem only occured after installing this kernel. The previous version 2.6.24 booted fine??. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497505: virtualbox-ose doesn't work with linux 2.6.26
I've taken a look at the upstream SVN repository and it looks like the fix is in changeset 12305 [1]. There are differences between the code there and the source in Debian. That changeset seems to e.g. depend on changeset 12299 [2]. I have not looked much deeper, but at first glance it looks like it should be possible to backport the fix for someone skilled enough in C++ (which I'm not). HTH, FJP [1] http://www.virtualbox.org/changeset/12305 [2] http://www.virtualbox.org/changeset/12299 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497505: virtualbox-ose doesn't work with linux 2.6.26
# No longer assign to linux-2.6 as the issue has been confirmed for VBox
reassign 497505 virtualbox-ose 1.6.2-dfsg-4
tags 497505 patch fixed-upstream
thanks
On Friday 12 September 2008, Frans Pop wrote:
I've taken a look at the upstream SVN repository and it looks like the
fix is in changeset 12305 [1].
There are differences between the code there and the source in Debian.
That changeset seems to e.g. depend on changeset 12299 [2].
I have not looked much deeper, but at first glance it looks like it
should be possible to backport the fix for someone skilled enough in
C++ (which I'm not).
Well, turns out I was wrong. The two patchsets applied cleanly so I was
able to do that myself. It did not work though. After looking again it
turned out that changesets 12303, 12307 and 12308 were related.
After applying those changesets as well, the problem seems to be fixed.
A virtual machine that was failing for me (a clean Debian Lenny install)
now boots reliably with 2.6.26-1-686 (on an amd64 host running unstable
with 2.6.27-rc6 kernel).
Note that the installer itself has never been affected as D-I uses the 486
kernel flavor. The problem only showed for me when trying to boot into an
installed system with the 686 kernel flavor.
Please consider applying the attached patch and pushing the new version
for Lenny. The patch contains the cumulative diff for the mentioned
changesets.
Cheers,
FJP
diff -u virtualbox-ose-1.6.2-dfsg/debian/changelog virtualbox-ose-1.6.2-dfsg/debian/changelog
--- virtualbox-ose-1.6.2-dfsg/debian/changelog
+++ virtualbox-ose-1.6.2-dfsg/debian/changelog
@@ -1,3 +1,11 @@
+virtualbox-ose (1.6.2-dfsg-5~fjp) UNRELEASED; urgency=low
+
+ * Apply changesets 12299, 12303, 12305, 12307 and 12308 from upstream SVN
+to fix errors running 2.6.26-686 kernels in a Virtual Machine.
+Closes: #497505.
+
+ -- Frans Pop [EMAIL PROTECTED] Sat, 13 Sep 2008 00:04:23 +0200
+
virtualbox-ose (1.6.2-dfsg-4) unstable; urgency=medium
* Adding patch from Gonéri Le Bouder [EMAIL PROTECTED] to fix FTBFS with
diff -u virtualbox-ose-1.6.2-dfsg/debian/patches/00list virtualbox-ose-1.6.2-dfsg/debian/patches/00list
--- virtualbox-ose-1.6.2-dfsg/debian/patches/00list
+++ virtualbox-ose-1.6.2-dfsg/debian/patches/00list
@@ -13,0 +14 @@
+14-recompiler-flush-tb-cache.dpatch
only in patch2:
unchanged:
--- virtualbox-ose-1.6.2-dfsg.orig/debian/patches/14-recompiler-flush-tb-cache.dpatch
+++ virtualbox-ose-1.6.2-dfsg/debian/patches/14-recompiler-flush-tb-cache.dpatch
@@ -0,0 +1,276 @@
+#!/bin/sh /usr/share/dpatch/dpatch-run
+## 14-recompiler-flush-tb-cache.dpatch by Frans Pop [EMAIL PROTECTED]
+##
+## DP: Flush the recompilers translation block cache.
+
[EMAIL PROTECTED]@
+
+only in patch2:
+unchanged:
+--- virtualbox-ose-1.6.2-dfsg.orig/include/VBox/em.h
virtualbox-ose-1.6.2-dfsg/include/VBox/em.h
+@@ -313,6 +313,13 @@
+ */
+ EMDECL(int) EMInterpretPortIO(PVM pVM, PCPUMCTXCORE pCtxCore, PDISCPUSTATE pCpu, uint32_t cbOp);
+
++/**
++ * Flushes the REM translation blocks the next time we execute code there.
++ *
++ * @param pVM The VM handle.
++ */
++EMDECL(void) EMFlushREMTBs(PVM pVM);
++
+ EMDECL(uint32_t) EMEmulateCmp(uint32_t u32Param1, uint32_t u32Param2, size_t cb);
+ EMDECL(uint32_t) EMEmulateAnd(uint32_t *pu32Param1, uint32_t u32Param2, size_t cb);
+ EMDECL(uint32_t) EMEmulateInc(uint32_t *pu32Param1, size_t cb);
+only in patch2:
+unchanged:
+--- virtualbox-ose-1.6.2-dfsg.orig/include/VBox/rem.h
virtualbox-ose-1.6.2-dfsg/include/VBox/rem.h
+@@ -67,7 +67,7 @@
+ REMR3DECL(int) REMR3Step(PVM pVM);
+ REMR3DECL(int) REMR3BreakpointSet(PVM pVM, RTGCUINTPTR Address);
+ REMR3DECL(int) REMR3BreakpointClear(PVM pVM, RTGCUINTPTR Address);
+-REMR3DECL(int) REMR3State(PVM pVM);
++REMR3DECL(int) REMR3State(PVM pVM, bool fFlushTBs);
+ REMR3DECL(int) REMR3StateBack(PVM pVM);
+ REMR3DECL(void) REMR3StateUpdate(PVM pVM);
+ REMR3DECL(void) REMR3A20Set(PVM pVM, bool fEnable);
+only in patch2:
+unchanged:
+--- virtualbox-ose-1.6.2-dfsg.orig/src/VBox/VMM/EM.cpp
virtualbox-ose-1.6.2-dfsg/src/VBox/VMM/EM.cpp
+@@ -720,11 +720,12 @@
+ /*
+ * Switch to REM, step instruction, switch back.
+ */
+-int rc = REMR3State(pVM);
++int rc = REMR3State(pVM, pVM-em.s.fREMFlushTBs);
+ if (VBOX_SUCCESS(rc))
+ {
+ rc = REMR3Step(pVM);
+ REMR3StateBack(pVM);
++pVM-em.s.fREMFlushTBs = false;
+ }
+ LogFlow((emR3RemStep: returns %Vrc cs:eip=%04x:%08x\n, rc, CPUMGetGuestCS(pVM), CPUMGetGuestEIP(pVM)));
+ return rc;
+@@ -778,11 +779,12 @@
+ if (!fInREMState)
+ {
+ STAM_PROFILE_START(pVM-em.s.StatREMSync, b);
+-rc = REMR3State(pVM);
++rc = REMR3State(pVM, pVM-em.s.fREMFlushTBs);
+ STAM_PROFILE_STOP(pVM-em.s.StatREMSync, b);
+ if (VBOX_FAILURE(rc))
+ break;
+ fInREMState = true;
++pVM-em.s.fREMFlushTBs = false
Bug#497843: linux-2.6: [s390] 2.6.26 does not boot in Hercules emulator
Package: linux-2.6 Version: 2.6.26-1 Tags: fixed-upstream, d-i Current 2.6.26 kernels [1] will fail to boot in the Hercules emulator: Begin: Running /scripts/init-premount ... 23.398929! dasd(eckd): 0.0.0120: PSF-SSC on storage subsystem HRC.ZZ 0001.0120 returned rc=0 23.401291! dasd_generic couldn't online device 0.0.0120 with discipline ECKD rc=-5 This should be fixed with upstream stable release 2.6.26.4 which is currently being prepared with commit 49fd38bdaa96f093fcad3176a781a4d0de8f8602. [1] The same issue was also there in 2.6.25; 2.6.24-7 is the last good version. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471892: r8169 does not load properly in 2.6.24 kernel
clone 471892 -1 reassign -1 linux-2.6.24 tags -1 - pending tags -1 patch thanks Cloning to 2.6.24 as it is likely affected and this may be worth fixing in an update of that kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
(adding d-kernel and d-release) On Monday 07 July 2008, Otavio Salvador wrote: Frans Pop [EMAIL PROTECTED] writes: On Thursday 03 July 2008, Otavio Salvador wrote: please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2, linux-modules-extra-2.6 2.6.25-5 Please wait few more days until we get it properly done on sid (d-i migrates to it). Why? We have never blocked migration of a new kernel when that wasn't needed because of a D-I release. Uploading udebs and switching to a kernel is not dependant on the migration. A new kernel can basically migrate (from a D-I PoV) as soon as a release is out. Except that kernel team wants it to upload 2.6.26 to sid when it's released (probably this week) OK, then _that_ should be discussed, not the migration to testing. The two are completely separate issues. In fact, having 2.6.25 in testing would possibly make it easier for the kernel team to do a final (?) 2.6.25 upload with latest stable updates. There are valid arguments to be found for staying with 2.6.25 a bit longer, but D-I has not yet converted to it is NOT one of them. A much more important argument is that .25 has seen and will almost certainly continue to get a lot more stabilization effort upstream than is normal for upstream kernel releases because long term releases for at least two important other distros are based on it. I doubt .26 will get the same upstream attention. Given the lack of capacity in Debian to do any real stabilization (cherry picking/backporting of fixes from later releases) ourselves, that could IMO be an important consideration for staying with .25 for Lenny. .26 also includes at least one change I know of that is somewhat risky: PAT support for x86 (which could be disabled). Se IMO we should take a real good look at .25 and .26 and check what's new, what's important for Lenny and what's risky, and maybe check if some things we do want could be backported. Delaying the upload of .26 to unstable could give us time, as a distribution, to stay up to date with .25, see how things are going with .26 and make a more informed decision. However, if the kernel team (together with maybe the release team) has already decided on .26 for Lenny, then it would be better to get it into unstable ASAP and for D-I to basically skip .25. and we have not yet got all architectures tested with 2.6.25 on d-i. So what? That's largely our own damned fault... Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Monday 07 July 2008, maximilian attems wrote: There are valid arguments to be found for staying with 2.6.25 a bit longer, but D-I has not yet converted to it is NOT one of them. testing users are currently on an unsupported kernel. Eh, how does that follow my last para which I assume you are commenting on, but which has nothing to do with testing? A side-note to your comment though... IMO testing kernel support is the weakest point in the current upload strategy by the kernel team. By uploading the next upstream release to unstable basically as soon as it's available upstream, Debian users (both unstable and testing) are frequently missing out on at least one or two upstream stable updates for the previous stable (stable -1) release. We worked around this for .24 by doing an upstream stable update through t-p-u. Upstream does seem to recognize the fact that a new release will need at least a few updates before it is actually stable and usable, and will therefore do at least a few stable updates (for both new stable and stable -1 in parallel). This basically happens in parallel to the new merge window (say the time to -rc2) and some upstream releases get longer term upstream stable support (.18, .22, .25). My personal opinion is that it would be better to delay the upload of new upstream releases to unstable until the .2 or maybe even .3 upstream stable update has become available. This would mean a bit more work for the kernel team, but I would expect that to be solvable. That would also give more time for initial arch-specific and l-m-e issues for the new upstream to be worked out (e.g. in experimental) without breaking unstable too much. IMO a new kernel version should only be uploaded to unstable if kernel meta packages can be updated at roughly the same time. It would also allow to upload a few more stable updates for stable -1 and to migrate those to testing, giving testing users on average better support and it would give D-I some more breathing space to do releases. When a new stable *is* uploaded, D-I should be able to switch faster too (at least, if there's someone willing to do the initial kernel-wedge work) as the main criterium for D-I to switch to a new kernel version is: does the new version look about to be ready to migrate to testing, which current early uploads of the kernel to unstable effectively never are. A much more important argument is that .25 has seen and will almost certainly continue to get a lot more stabilization effort upstream than is normal for upstream kernel releases because long term releases for at least two important other distros are based on it. I doubt .26 will get the same upstream attention. Given the lack of capacity in Debian to do any real stabilization (cherry picking/backporting of fixes from later releases) ourselves, that could IMO be an important consideration for staying with .25 for Lenny. that doesn't matter a lot, if you look into our 2.6.18 or the RH patch biest you'll notice the RH men force boot behind their backporting machine. I'm having serious trouble parsing what you're trying to say here. Could you rephrase? Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Selection of kernel for Lenny
On Monday 07 July 2008, Frans Pop wrote: .26 also includes at least one change I know of that is somewhat risky: PAT support for x86 (which could be disabled). #d-uk just gave me this tidbit: ... am I missing something or will the move to .26, with libata binding before most of the IDE stuff, cause a lot of pain unless the distro manages the move from hd* to sd*? Which is basically the why don't we have persistent device naming issue (on which I won't comment). There's two things to say about this (assuming status quo otherwise): - this will probably reduce the pain on reboots for new installations as module loading order should become more predictable between different boots - this may increase the pain for people upgrading from Etch to Lenny, or not, or ... Other related issue/question. Early in lenny, when libata first stuck up its head, we made some effort to disable drivers or remove duplicate PCI IDs so that existing users using the old IDE drivers would not suddenly be confronted with a hda-sda switch. I have not really followed Debian kernels regarding this, but currently I think we basically just have both IDE and ATA drivers enabled. Correct? Are any of those early avoid duplicate PCI ID patches still active? Do we have any idea yet how this is going to be handled/documented for upgrades? signature.asc Description: This is a digitally signed message part.
Re: Bug#486168: Lenny Beta2 Kernel Panic - fails to re-boot on HP Netserver E60
reassign 486168 linux-2.6 2.6.24-7 thanks On Friday 13 June 2008, Chris Bell wrote: Comments/Problems: On re-boot the A channel is identified, but kernel panic while checking the B channel. scsi 0 : adaptec AIC 7xxx EISA/VLB/PCI SCSI HBA Driver, Rev 7.0 Adaptec aic 7895 Ultra SCSI adapter aic 7895C: UltraWide Channel A, SCSI Id=7, 32/253 SCBs ACPI : PCI Interrpt :00:05.1 [B] - GSI 18 (level, low) - IRQ 17 Kernel Panic - not syncing: HOST_MSG_LOOP with invalid SCB ff I would expect some more info about the kernel panic after this (register values and such). That info will be needed to follow up on this. As this is a kernel panic after the reboot after the installation is completed, this is not an installation issue, but a kernel issue. For that reason I'm reassigning the report to the kernel team. It is a bit strange though that you don't see the same panic during the installation. This indicates that the problem may be either that a slightly different kernel is used, or that the order in which modules are loaded and things get initialized makes a difference. Here are some things you can try and check. - Run the installer again, but start it in rescue mode. - Check if your conroller gets detected again without problems. - If it is, start a chroot shell on your / partition, either as offered by the installer or manually from VT2 or VT3; if needed mount any other partitions. - Install the -486 flavor of the 2.6.24-1 kernel for the installed system. That is the same kernel as the installer uses. Check if the installed system boots with that. - Save the output of dmesg and lsmod of the installer and compare that with what you see during a normal boot. It may provide clues. For example, do 'dmesg /var/log/dmesg.txt' and then use the Save debug logs option in the main menu of the installer. - Check that the installer and the installed system actually load the same driver module for your disk (I expect they do). - Install the 2.6.25 kernel from unstable and see if that solves the problem. If using the -486 flavor of .24 solved the problem, try both flavors of .25! If the panic also occurs with 2.6.25, you can consider also filing a bug with the upstream kernel developers, but please keep this report updated about any progress if you do. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485786: initramfs-tools: support for ide-generic for Lenny
Package: initramfs-tools Version: 0.92b Severity: wishlist Tags: d-i Hi maks, I've been thinking a bit more about how we could support ide-generic for Lenny without loading it by default on systems that do not need it, but also avoiding /etc/i-t/modules which results in it being loaded first, thus potentially blocking other drivers. My suggestion is to include your old Etch script again, but to only actually run that if a (new) i-t config option is set. In D-I we could then load ide-generic pretty much as was done for Etch, and set that config option (in /etc/i-t/conf.d) _only if_ loading the driver actually resulted in new block devices being created. I'm not completely sure how etch-lenny upgrades for systems that need ide-generic could best be handled. They would also need to be able to set this config option somehow. Some options would be: - display a debconf note on upgrade if ide-generic is currently loaded and ask whether it should remain loaded - or better, if it is possible to see that ide-generic is actually in use, automatically set the config option only in that case - not do anything automatically, but support a boot parameter that will load it so that users can then set the config option manually - others? The issue should probably at least be mentioned in the Release Notes. What do you think? Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Bug#485609: Problem with device renaming and grub after clean install
reassign 485609 linux-2.6 2.6.24-7 retitle 485609 modules.pcimap lists both pata_sis and sis5513 for [1039:5513] thanks On Tuesday 10 June 2008, [EMAIL PROTECTED] wrote: It seems that the kernel is remapping /dev/hda using the scsi emulation, which I did not enable and grub doesn't know about during the installation. Oddly I have the same kernel installed for the unstable partition and I do not run into the same problem. I took a look at the kernel config on both and nothing stands out. Reason for this is that the Debian kernel provides two modules that support your IDE controller: $ grep 1039.*5513 /lib/modules/2.6.24-1-amd64/modules.pcimap pata_sis 0x1039 0x5513 0x 0x 0x 0x 0x0 sis5513 0x1039 0x5513 0x 0x 0x 0x 0x0 Which gets loaded is somewhat random and apparently the installer used the second (setting the system up to use /dev/hda), while after the reboot the first was used (changing the device name to /dev/sda). This is a known issue listed in the errata. Reassigning your report to the kernel team because AFAIK we should not be listing two modules for the same controller. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
