Bug#889002: Simple reboot reminder
Package: linux-base Version: 4.5 Severity: wishlist We use the following line from cron to remind us to reboot a machine, if the initrd for the currently running kernel has been updated: test /proc -nt /boot/initrd.img-$(uname -r) || echo reboot required Would you be open to the idea to provide such functionality from linux-base? I'd be happy to extend it to make it work for systems without initrd, as well as in the case of kernel version upgrades (configurable), but I'd want to gauge first if this is the right place for such a script. If you don't think linux-base is the place for this, please reassign. -- .''`. martin f. krafft <madduck@d.o> @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#843153: [Pkg-samba-maint] Bug#843153: Provide a means to wake-up (reconnect) an existing share
also sprach Mathieu Parent <math.par...@gmail.com> [2016-11-05 20:59 +0100]: > > After a laptop suspend, SMB sessions are usually disconnected on the > > server, and even the client will have a hard time just resuming. > > This is most probably kernel-side. Yes, I agree. Per se it's not a bug. I filed this against cifs-utils because I was imagining a user-space interface to influence the kernel. > > This will either lead to soft-errors or hard-blocks, until on > > the client, eventually, the kernel states > > eventually? Meaning not always? No, always. I should have used another word. In English, eventually means that something will happen, whereas in German and possibly French, it might suggest that something possibly happens, or not. > > I don't really want to shorten the 120 seconds (and I wouldn't know > > how, there seems to be no mount option), > > 120 comes from echo_interval [1] which looks undocumented. > > [1] http://sources.debian.net/src/linux/4.8.5-1/fs/cifs/connect.c/?hl=496#L496 Seems a bit weird that this is hard-coded. > Again, have you tried mount -o remount? Yes, but unfortunately it doesn't have the desired effect. It just blocks until the 120 seconds are over. It'd be a nice interface though! > > which would immediately cause a reconnection, not only after 120 > > seconds. This could then be executed by systemd for the resume > > target… > > Looking at the NFS kernel code, I don't see any resume handling. > I don't know if it's affected too. As far as I know, it's not affected, because NFS is datagram-based, whereas CIFS is session-based. It's a bit like mosh and SSH… -- .''`. martin f. krafft <madduck@d.o> @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems "in any hierarchy, each individual rises to his own level of incompetence, and then remains there." -- murphy (after dr. laurence j. peter) digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#843061: radeon/hawaii_k_smc.bin fails to load with 4.8 kernel
Package: firmware-amd-graphics Version: 20160824-1 Severity: normal Booting a 4.8 kernel results in the following messages (and non-working X.org), while booting a 4.7 kernel works just fine: kernel: [ 38.874663] radeon :06:00.0: firmware: direct-loading firmware radeon/hawaii_ce.bin kernel: [ 38.875522] radeon :06:00.0: firmware: direct-loading firmware radeon/hawaii_mec.bin kernel: [ 38.876165] radeon :06:00.0: firmware: direct-loading firmware radeon/hawaii_rlc.bin kernel: [ 38.877010] radeon :06:00.0: firmware: direct-loading firmware radeon/hawaii_sdma.bin kernel: [ 38.877767] radeon :06:00.0: firmware: direct-loading firmware radeon/hawaii_mc.bin kernel: [ 38.877786] radeon :06:00.0: firmware: failed to load radeon/hawaii_k_smc.bin (-2) kernel: [ 38.877787] radeon :06:00.0: Direct firmware load for radeon/hawaii_k_smc.bin failed with error -2 kernel: [ 38.883896] radeon :06:00.0: firmware: direct-loading firmware radeon/HAWAII_smc.bin kernel: [ 38.883900] ci_fw: mixing new and old firmware! kernel: [ 38.884032] [drm:cik_init [radeon]] *ERROR* Failed to load firmware! I suppose this either means a faulty module, or simply outdated firmware? -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) firmware-amd-graphics depends on no packages. firmware-amd-graphics recommends no packages. Versions of packages firmware-amd-graphics suggests: ii initramfs-tools 0.125 -- no debconf information -- .''`. martin f. krafft <madduck@d.o> @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#776623: dpkg-reconfigure leaves initramfs-tools in broken 't' state (dpkg)
Package: initramfs-tools Version: 0.118 Severity: normal I just set up a new jessie system and ran dpkg-reconfigure -a -u¹. This did some stuff to grub-pc (I think) and then left initramfs-tools broken: […] update-initramfs: deferring update (trigger activated) Installing for i386-pc platform. File descriptor 3 (pipe:[3115275]) leaked on vgs invocation. Parent PID 9176: grub-install File descriptor 3 (pipe:[3115275]) leaked on vgs invocation. Parent PID 9176: grub-install File descriptor 3 (pipe:[3115275]) leaked on vgs invocation. Parent PID 9176: grub-install Installation finished. No error reported. Generating grub configuration file ... Found linux image: /boot/vmlinuz-3.16.0-4-586 Found initrd image: /boot/initrd.img-3.16.0-4-586 Found linux image: /boot/vmlinuz-3.16-2-486 Found initrd image: /boot/initrd.img-3.16-2-486 done /usr/sbin/dpkg-reconfigure: initramfs-tools is broken or not fully installed # dpkg -l initramfs-tools it initramfs-tools 0.116 all generic modular initramfs generator I am failing to reproduce this now, but I'll keep posting news as I find them. ¹) well, since -a was dropped: dpkg --get-selections | sed -rne 's,([^[:space:]]+)[[:space:]]+install$,\1,p' \ | xargs dpkg-reconfigure -u -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#733545: Fails to set profiles
also sprach Mattia Dongili malat...@linux.it [2013-12-30 15:15 +1300]: cpufreqd: cpufreqd_set_profile : Couldn't set profile Performance High set for cpu0 (240-240-performance) cpufreqd: cpufreqd_loop: Cannot set policy, Rule unchanged (none). This log seems a bit poor for the max verbosity level (this may be a different problem I never managed to diagnose). Nah, I did not include verbose output, because I could not find anything interesting therein. Right now I cannot reproduce the problem, but I will provide a full log once I can. Thank you for your analysis. I do not seem to have the same problem, unfortunately, as I can manipulate the scaling via sysfs just fine. I'll be back… -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems (a)bort, (r)etry, (p)retend this never happened digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#656899: mdadm: sending ioctl 1261 to a partition warnings in kernel log with kernel 3.2
also sprach Jonathan Nieder jrnie...@gmail.com [2012.03.05.1056 +0100]: Rik's original report… Oh, sorry, the mail looked like a new report to me. Thanks for watching! -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems president thieu says he'll quit if he doesn't get more than 50% of the vote. in a democracy, that's not called quitting. -- the washington post digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing
also sprach Jort Koopmans jort.koopm...@gmail.com [2011.10.12.2143 +0200]: In the mean while I've checked another solution; moving the call to the local-top scripts till after the ROOTDELAY loop (within the local file). init-top/udev also uses it. This works in my config. But this would delay finding the ROOT dir in normal instances (where devices are quick enough) So? Instead of patching this here and there with band aids, I suggest that everyone with an interest instead invests time in testing mdadm/experimental, which provides event-based assembly, and helps porting the changes to current mdadm (since I don't have the time at the moment). And then, LVM is up next. -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing
also sprach Jort Koopmans jort.koopm...@gmail.com [2011.10.13.1148 +0200]: First of all, thanks for helping me out. (I did not CC the bug report at the time…) - if you are criticising initramfs/mdadm, then it helps to reproduce the output you are seeing, ideally after set -x. True, since this machine does not have a serial port I haven't been able to log the output yet (but i'll look into that). http://wiki.debian.org/InitramfsDebug -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems man kann die menschen nur von ihren eigenen meinungen überzeugen. -- charles tschopp digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#506419: high volumes of traffic kill forcedeth chip
also sprach Jonathan Nieder jrnie...@gmail.com [2011.03.24.0728 +0100]: I'm closing this because I think a year is more than enough time to test a new version. I'll take ownership then. I used to have a forcedeth and while I don't anymore, I'm interested in the driver being reliable. Martin, ping? Of course if you've lost interest (e.g., if you've lost the hardware) then closing the bug again is probably the right thing to do. I still have the hardware, but it's on a production machine. It is onboard and I added a separate NIC, so it's unused, but I cannot really run kernel-level experiments. However, the machine has KVM, and as soon as KVM supports PCI passthrough, that might be useful. There are two cards connected to each other (I expected debugging), and with two KVM instances, this could be interesting. -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems never try to explain computers to a layman. it's easier to explain sex to a virgin. -- robert heinlein (note, however, that virgins tend to know a lot about computers.) digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#612298: repeated columns on VGA/Radeon head
- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 256 bytes Interrupt: pin B routed to IRQ 75 Region 0: Memory at fbcfc000 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: HDA Intel 07:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 02) Subsystem: ASUSTeK Computer Inc. Device [1043:8367] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 256 bytes Interrupt: pin A routed to IRQ 67 Region 0: I/O ports at d800 [size=256] Region 2: Memory at fbdff000 (64-bit, non-prefetchable) [size=4K] Region 4: Memory at fadf (64-bit, prefetchable) [size=64K] Expansion ROM at fbdc [disabled] [size=128K] Capabilities: access denied Kernel driver in use: r8169 08:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 02) Subsystem: ASUSTeK Computer Inc. Device [1043:8367] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 256 bytes Interrupt: pin A routed to IRQ 66 Region 0: I/O ports at e800 [size=256] Region 2: Memory at fbeff000 (64-bit, non-prefetchable) [size=4K] Region 4: Memory at faef (64-bit, prefetchable) [size=64K] Expansion ROM at fbec [disabled] [size=128K] Capabilities: access denied Kernel driver in use: r8169 ** USB devices: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 0dda:2001 Integrated Circuit Solution, Inc. Multi-Card Reader Bus 002 Device 003: ID 1058:1003 Western Digital Technologies, Inc. Bus 002 Device 006: ID 0409:005a NEC Corp. HighSpeed Hub Bus 006 Device 002: ID 03f0:1024 Hewlett-Packard Smart Card Keyboard Bus 007 Device 002: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse Bus 007 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Bus 008 Device 002: ID 20df:0001 Simtec Electronics Entropy Key [UDEKEY01] Bus 002 Device 008: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640 USB-2.0 TetraHub Bus 002 Device 009: ID 0409:005a NEC Corp. HighSpeed Hub -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.37-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-image-2.6.37-trunk-amd64 depends on: ii debconf [debconf 1.5.38 Debian configuration management sy ii initramfs-tools 0.98.8 tools for generating an initramfs ii linux-base 2.6.37-1~experimental.1 Linux image base package ii module-init-tool 3.12-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.37-trunk-amd64 recommends: ii firmware-linux-free 2.6.32-30 Binary firmware for various driver Versions of packages linux-image-2.6.37-trunk-amd64 suggests: pn grub | lilo none (no description available) pn linux-doc-2.6.37 none (no description available) Versions of packages linux-image-2.6.37-trunk-amd64 is related to: pn firmware-bnx2 none (no description available) pn firmware-bnx2xnone (no description available) pn firmware-ipw2x00 none (no description available) pn firmware-ivtv none (no description available) pn firmware-iwlwifi none (no description available) ii firmware-linux0.28 Binary firmware for various driver ii firmware-linux-nonfree0.28 Binary firmware for various driver pn firmware-qlogic none (no description available) pn firmware-ralink none (no description available) pn xen-hypervisornone (no description available) -- debconf information excluded -- .''`. martin f. krafft madduck@d.o
2.6.36-rc6: udev settle timeouts during rcS (audio-related?)
bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Control Registers (rev 05) Subsystem: Intel Corporation Device 8086 ff:06.1 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Address Registers (rev 05) Subsystem: Intel Corporation Device 8086 ff:06.2 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Rank Registers (rev 05) Subsystem: Intel Corporation Device 8086 ff:06.3 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Thermal Control Registers (rev 05) Subsystem: Intel Corporation Device 8086 The kernel BUG: BUG: unable to handle kernel NULL pointer dereference at 01a4 IP: [a02e9e54] edac_create_mci_instance_attributes+0xe0/0x139 [edac_core] PGD 6393ff067 PUD 6393fe067 PMD 0 Oops: [#1] SMP last sysfs file: /sys/devices/pci:ff/:ff:02.1/uevent CPU 1 Modules linked in: i7core_edac(+) tpm cdc_acm wmi soundcore processor serio_raw evdev tpm_bios i2c_i801 asus_atk0110 pcspkr edac_core button shpchp pci_hotplug snd_page_alloc i2c_core sha256_generic aes_x86_64 aes_generic cbc ext4 mbcache jbd2 crc16 dm_crypt dm_mod raid1 md_mod sg sr_mod sd_mod cdrom crc_t10dif usbhid hid usb_storage uhci_hcd ahci libahci libata scsi_mod ehci_hcd usbcore r8169 mii thermal thermal_sys nls_base [last unloaded: scsi_wait_scan] Pid: 705, comm: modprobe Tainted: GW 2.6.36-rc6-amd64 #1 P6T6 WS REVOLUTION/System Product Name RIP: 0010:[a02e9e54] [a02e9e54] edac_create_mci_instance_attributes+0xe0/0x139 [edac_core] RSP: 0018:880638f37b88 EFLAGS: 00010282 RAX: 01a4 RBX: 88063c718a20 RCX: RDX: 88063a56c0f0 RSI: a02ecdc0 RDI: 88063c718a30 RBP: a04bcd28 R08: 880001a31928 R09: 88063a56c130 R10: 88063c718370 R11: 88063a56c130 R12: 88063c718a30 R13: 88063a56c000 R14: 88063a56c130 R15: 0060 FS: 7f57294e1700() GS:880001a2() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 01a4 CR3: 0006393fc000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 705, threadinfo 880638f36000, task 880639209b40) Stack: 88063a56c0f0 88063c718370 8806399802d0 88063c718360 0 a04bcc38 88063c718370 88063a56c000 88063a56c130 0 0060 a02e9e75 88063a56c0f0 88063a56c0f0 Call Trace: [a02e9e75] ? edac_create_mci_instance_attributes+0x101/0x139 [edac_core] [a02e9f1b] ? edac_create_sysfs_mci_device+0x6e/0x1d3 [edac_core] [a02e89a5] ? edac_mc_add_mc+0x8d/0x16d [edac_core] [a04bbdd8] ? i7core_probe+0x842/0x9f9 [i7core_edac] [811a24e7] ? local_pci_probe+0x49/0x93 [811a3226] ? pci_device_probe+0xc2/0xef [81228782] ? driver_sysfs_add+0x66/0x8d [812288c3] ? driver_probe_device+0xa8/0x138 [812289a2] ? __driver_attach+0x4f/0x6f [81228953] ? __driver_attach+0x0/0x6f [81227f4c] ? bus_for_each_dev+0x44/0x78 [812283a4] ? bus_add_driver+0xa8/0x1f0 [81228c49] ? driver_register+0x90/0xf8 [811a3470] ? __pci_register_driver+0x4e/0xbe [a04c007d] ? i7core_init+0x7d/0x9d [i7core_edac] [a04c] ? i7core_init+0x0/0x9d [i7core_edac] [81002079] ? do_one_initcall+0x78/0x131 [81072982] ? sys_init_module+0x97/0x1d5 [81008a02] ? system_call_fastpath+0x16/0x1b Code: 8d 63 10 4c 89 33 48 c7 c6 c0 cd 2e a0 4c 89 e7 48 89 43 08 48 89 18 48 8b 45 10 4c 89 6b 58 48 89 43 50 48 8b 45 10 48 8b 14 24 48 8b 08 31 c0 e8 8e 33 ea e0 85 c0 75 3c 48 8b 43 50 4c 89 e2 RIP [a02e9e54] edac_create_mci_instance_attributes+0xe0/0x139 [edac_core] RSP 880638f37b88 CR2: 01a4 ---[ end trace a7919e7f17c0a727 ]--- -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems when faced with a new problem, the wise algorithmist will first attempt to classify it as np-complete. this will avoid many tears and tantrums as algorithm after algorithm fails. -- g. niruta digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#551101: still exists
also sprach Ben Hutchings b...@decadent.org.uk [2010.06.21.0120 +0200]: I am running 2.6.32 and am faced by exactly this problem on a machine I cannot just reboot: % ps aux | egrep -c '\D\.+vgdisplay' 37821 lsof or strace on existing processes don't show anything, but strace on a new vgdisplay process shows that it blocks on opening /dev/cdrom, which seems to be defective. Was this a version before or after the libata transition? I have not really followed the transition, but this is on a lenny system with a 2.6.32 backports.org kernel. How can I check? -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#551101: still exists
also sprach Ben Hutchings b...@decadent.org.uk [2010.06.21.1211 +0200]: We switched from IDE drivers to libata-based drivers in 2.6.32-10. My suspicion is that this is a bug in ide-cd which will no longer apply. This could very well be. I was running linux-image-2.6.32-bpo.2-amd64 2.6.32-8~bpo50+1 at the time. With linux-image-2.6.32-bpo.5-amd64 2.6.32-15~bpo50+1, the problem seems to have disappeared. Thanks, -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#583917: initramfs-tools: long delay (6–200 minutes) during boot (root device detection) after upgrade on RAID/LVM/LUKS setup
also sprach Paul Menzel pm.deb...@googlemail.com [2010.06.01.1127 +0200]: Dear Debian mdadm maintainers and Debian LVM Team, could you please comment on the first issue if it is related to your packages. I don't see a way in which mdadm could be responsible for this. Have you tried downgrading it to see if the error persists? -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems vulgarity is simply the conduct of other people. -- oscar wilde digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#551101: still exists
I am running 2.6.32 and am faced by exactly this problem on a machine I cannot just reboot: % ps aux | egrep -c '\D\.+vgdisplay' 37821 lsof or strace on existing processes don't show anything, but strace on a new vgdisplay process shows that it blocks on opening /dev/cdrom, which seems to be defective. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#572256: linux-base does not install debconf files
Package: linux-base
Version: 2.6.33-1~experimental.1
Severity: serious
You forgot to install the debconf files, thus yielding:
Setting up linux-base (2.6.33-1~experimental.1) ...
Error setting debconf question linux-base/disk-id-convert-auto:
linux-base/disk-id-convert-auto doesn't exist at
/var/lib/dpkg/info/linux-base.postinst line 1384, STDIN line 2.
dpkg: error processing linux-base (--configure):
subprocess installed post-installation script returned error exit status 9
% sudo grep linux-base /var/cache/debconf/templates.dat || echo not found
not found
% ls /var/lib/dpkg/info/linux-base.{templates,config}
ls: cannot access /var/lib/dpkg/info/linux-base.templates: No such file or
directory
ls: cannot access /var/lib/dpkg/info/linux-base.config: No such file or
directory
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-2-686 (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages linux-base depends on:
ii libapt-pkg-perl 0.1.24 Perl interface to libapt-pkg
linux-base recommends no packages.
linux-base suggests no packages.
-- no debconf information
--
.''`. martin f. krafft madd...@d.o Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#572256: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#572256: linux-base does not install debconf files)
also sprach Debian Bug Tracking System ow...@bugs.debian.org [2010.03.02.1942 +0100]: You're a bit late with this... Sorry, I've been having bugs.debian.org access problems all day, and I didn't see a newer package. Anyway, glad this is fixed. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: md homehost
also sprach Goswin von Brederlow goswin-...@web.de [2010.02.23.0829 +0100]: Or virtualization with raid in the virtual hosts. The host system will see all the raids of the virtual systems but none of them should be started. I'd say there are better ways to set this up, but this is a fair point. -- martin | http://madduck.net/ | http://two.sentenc.es/ one should never allow one's mind and one's foot to wander at the same time. -- edward perkins (yes, the librarian) spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: md homehost
also sprach Goswin von Brederlow goswin-...@web.de [2010.02.23.0831 +0100]: Both filesystems and LVM have UUIDs. Does dm-crypt / LUKS have one too? LVM already identifies PVs using UUIDs, so if you are using anything-on-LVM-on-md, you need not worry about device names anyway. dm-crypt currently needs to be told explicitly to use a base device using /dev/disk/by-uuid if you want it to be flexible. The only issue homehost protects against, I think, is machines that use /dev/md0 directly from grub.conf or fstab. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
also sprach Goswin von Brederlow goswin-...@web.de [2010.02.22.0806 +0100]: Yes, it would be useful to have a system UUID that could be generated by the installer and henceforth written to the newly installed system. This is probably something the LSB should push. But you could also bring it up for discussion on debian-devel. How would that work with network boot where the initrd would have to work for multiple hosts? Right now, that doesn't work either, except with the traditional method of simply assembling all arrays found. Neil has implemented the homehost feature to prevent that. Arguably that's to protect against a circumstance that is rather rare, and one might not want/need it. However, if used, then it is true: Unless the homehost in the superblock matches the local value, you need mdadm.conf to assemble the devices, because the superblock information won't be trusted if the homehost doesn't match. To be able to determine whether the homehost matches, you need to know the value for the system after the initramfs was unpacked. Therefore, the homehost value must either be stored in the initramfs, which makes it non-portable, or we must use a unique identifier of the system that is available from ROM, e.g. the CPU ID. I don't think that's standardised. If auto-assembly of all RAIDs bears dangers and must be regulated, then we must either have host-specific initramfs's, or be able to determine the homehost value early during boot otherwise. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
also sprach Michael Evans mjevans1...@gmail.com [2010.02.22.0837 +0100]: I don't know how whatever was mentioned previously would work for that, but I do have a solution. […] Incremental assembly, or examine with all block devices to generate a new mdadm.conf file. Please see the thread for reasons why incremental assembly works only with an mdadm.conf file, or if you can uniquely identify the system before the root filesystem is mounted. Please see the thread for reasons why unconditional auto-assembly of all available arrays may not be desirable. Presuming you have a consistently labeled rootfs in your deployment (say mandating that the / filesystem be labeled 'root' or some other value and that no other FS may share that same label) then it should work out just fine. I fundamentally agree. However, driving this change from mdadm will be impossible. If that is the way to go, then we must first ensure that device names become deprecated, and that everyone uses /dev/disk/by-uuid/*. Only then can we start relying on it. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
also sprach Piergiorgio Sartor piergiorgio.sar...@nexgo.de [2010.02.21.2113 +0100]: I do not see how the homehost plays a role, here. Neil, Could you please put forth the argument for why the homehost must match, and why unconditional auto-assembly is not desirable? Realistically, what problems are we protecting against? Thanks, -- martin | http://madduck.net/ | http://two.sentenc.es/ fitter, healthier, more productive like a pig, in a cage, on antibiotics -- radiohead spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
also sprach Neil Brown ne...@suse.de [2010.02.23.0330 +0100]: The problem to protect against is any consequence of rearranging devices while the host is off, including attaching devices that previously were attached to a different computer. How often does this happen, and how grave/dangerous are the effects? But if '/' is mounted by a name in /dev/md/, I want to be sure mdadm puts the correct array at that name no matter what other arrays might be visible. Of course it would be nice if this happened, but wouldn't it be acceptable to assume that if someone swaps drives between machines that they ought to know how to deal with the consequences, or at least be ready to tae additional steps to make sure the system still boots as desired? Even if the wrong array appeared as /dev/md0 and was mounted as root device, is there any actual problem, other than inconvenience? Remember that the person who has previously swapped the drives is physically in front of (or behind ;)) the machine. I am unconvinced. I think we should definitely switch to using filesystem-UUIDs over device names, and that is the only real solution to the problem, no? -- martin | http://madduck.net/ | http://two.sentenc.es/ Escape Meta Alt Control Shift spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
also sprach Daniel Reurich dan...@centurion.net.nz [2010.02.19.0351 +0100]: But if a generated 'system uuid' value (I just suggested the root fs UUID because it would be highly unlikely to be unchanged, and nobody would be likely to fiddle with it) was copied into a file called /etc/system_uuid and copied into the initrd, then we could add put into mdadms hook script in initramfs-tools, to verify and update the homehost variable in the boot time required raid volumes when ever a new initrd is installed. (This generally happens on debian whenever a kernel is installed and mdadm is installed or upgraded. Neil's point is that no such value exists. The root filesystem UUID is not available when the array is created. And updating the homehost in the RAID metadata at boot time would defeat the purpose of homehost in the first place. As an added protection we could include checks in mdadm shutdown script a check that warns when mdadm.conf doesn't exist and the /etc/system_uuid doesn't match the homehost value in the boottime assembled raid volumes. If we did use the root filesystem UUID for this, we could compare that as well. Debian has no policy for this. There is no way to warn a user and interrupt the shutdown process. It would be useful to have a tool similar to /bin/hostname that could be used to create|read|verify|update the system uuid, which would update all the relevant locations which store and check against this system uuid. Yes, it would be useful to have a system UUID that could be generated by the installer and henceforth written to the newly installed system. This is probably something the LSB should push. But you could also bring it up for discussion on debian-devel. -- martin | http://madduck.net/ | http://two.sentenc.es/ arguments are extremely vulgar, for everyone in good society holds exactly the same opinion. -- oscar wilde spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
also sprach Piergiorgio Sartor piergiorgio.sar...@nexgo.de [2010.02.19.1016 +0100]: There is the kernel boot paramenter rd_NO_MDADMCONF, which forces dracut to do not use the mdadm.conf in the initramfs image. My impression is that it uses the mdadm -I functionality. Indeed, it does. However, I could not find out how it does device naming? From what I understand, mdadm will only assemble devices using the name stored in the superblocks iff the homehost matches, so dracut either doesn't provide for this and requires the use of UUIDs to mount filesystems (making the array name secondary), or it needs to know what the homehost is. For this, it either needs mdadm.conf, or the hostname must be stored in the initramfs. Could you research this and let us know how dracut invokes mdadm? -- martin | http://madduck.net/ | http://two.sentenc.es/ licht wird alles, was ich fasse - friedrich nietzsche spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
also sprach Daniel Reurich dan...@centurion.net.nz [2010.02.21.2004 +0100]: On Sun, 2010-02-21 at 18:14 +0100, martin f krafft wrote: also sprach Daniel Reurich dan...@centurion.net.nz [2010.02.19.0351 +0100]: But if a generated 'system uuid' value (I just suggested the root fs UUID because it would be highly unlikely to be unchanged, and nobody would be likely to fiddle with it) was copied into a file called /etc/system_uuid and copied into the initrd, then we could add put into mdadms hook script in initramfs-tools, to verify and update the homehost variable in the boot time required raid volumes when ever a new initrd is installed. (This generally happens on debian whenever a kernel is installed and mdadm is installed or upgraded. Neil's point is that no such value exists. The root filesystem UUID is not available when the array is created. And updating the homehost in the RAID metadata at boot time would defeat the purpose of homehost in the first place. I said copy You said update the homehost variable in the boot time required raid volumes initrd is installed. As an added protection we could include checks in mdadm shutdown script a check that warns when mdadm.conf doesn't exist and the /etc/system_uuid doesn't match the homehost value in the boottime assembled raid volumes. If we did use the root filesystem UUID for this, we could compare that as well. Debian has no policy for this. There is no way to warn a user and interrupt the shutdown process. We could use the mdadm to fix it though to ensure the system won't end up in an unbootable state. No, because the whole point of homehost is that it should not be automatically updated. -- martin | http://madduck.net/ | http://two.sentenc.es/ truth is stranger than fiction, but it is because fiction is obliged to stick to possibilities; truth isnt. -- mark twain spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
also sprach Neil Brown ne...@suse.de [2010.02.18.1834 +1300]: But it would be rather awkward to store the uuid of the root filesystem in the metadata for the array that stores the root filesystem (and so is created before the root filesystem)... True. You'd have to update the superblock UUID right after creation of the filesystem. That doesn't sound like a robust strategy to making mdadm.conf optional. Are you suggesting that when mdadm finds some bits that looks like the form an array it should test-assemble it, look inside for a filesystem, extra the uuid of that filesystem and compare against some known uuid before deciding whether to assemble that array or not? I hope not. Hehe, that would be fun, wouldn't it? ;) So I don't think I know what is really being proposed. I really would like to make mdadm.conf optional and still have things work incrementally from initrd. -- martin | http://madduck.net/ | http://two.sentenc.es/ stupidity management for the superuser is a user space issue in unix systems. -- alan cox spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: [dan...@centurion.net.nz: Re: (boot time consequences of) Linux mdadm superblock question.]
I should not have bounced that message to -quiet, so here she goes again, the good idea: - Forwarded message from Daniel Reurich dan...@centurion.net.nz - Debian experimental. But so far, I was unable to get rid of mdadm.conf because it only works without the info in that file if the homehost is correctly encoded in the metadata. So the challenge I am facing is http://bugs.debian.org/567468. Why not use an installation generated uuid like that of the root filesystem for the homehost identifier. It's less likely to change then just about any other system identifier. - End forwarded message - -- martin | http://madduck.net/ | http://two.sentenc.es/ http://lavender.cime.net/~ricky/badgers.txt spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#506419: not alone
also sprach Moritz Muehlenhoff j...@inutil.org [2010.02.15.0111 +1300]: The machine is in a rack and running lenny, so I'll have to wait for a backport or squeeze, but then I ought to be able to test thanks to the third network card I now have installed. Did you test this yet (preferrably with the current Squeeze kernel, installs fine in stable)? No. This machine is a core part of my infrastructure. It will really have to wait until after I did a squeeze upgrade — or can go to the rack. Thanks for following up. I hope you understand. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems there was silence for a moment, and then out of the scrambled mess of arthur's brain crawled some words. -- hitchhiker's guide to the galaxy digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: please set hostname via sysctl early on
Package: initramfs-tools
Version: 0.93.4
Severity: wishlist
mdadm in incremental mode needs the hostname to be able to work
without a configuration file, which would make RAID-boot much more
robust. Instead of mdadm touching
/proc/sys/kernel/{host,domain}name, it feels like initramfs should
do that.
The attached scripts take care of it. hostname is the hook, and
00hostname the script for init-top. It might make more sense to put
this into local-top though, I don't really know how it interacts
with netboot.
--
.''`. martin f. krafft madd...@d.o Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
#!/bin/sh
#
# initramfs script to inform the kernel about the hostname early on
#
# Copyright © 2010 martin f. krafft madd...@debian.org
# Released under the terms of the Artistic Licence 2.0
#
set -eu
case ${1:-} in prereqs) exit 0;; esac
if [ -s /conf/hostname ]; then
. /scripts/functions
HOSTNAME=$(cat /conf/hostname)
log_begin_msg Setting hostname to $HOSTNAME
case $HOSTNAME in
*.*)
echo ${HOSTNAME#*.} /proc/sys/kernel/domainname
HOSTNAME=${HOSTNAME%%.*}
;;
esac
echo $HOSTNAME /proc/sys/kernel/hostname
log_end_msg
fi
exit
#!/bin/sh
#
# initramfs hook to store the hostname in the initrd
#
# Copyright © 2010 martin f. krafft madd...@debian.org
# Released under the terms of the Artistic Licence 2.0
#
set -eu
exec hostname --fqdn $DESTDIR/conf/hostname
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: please set hostname via sysctl early on
also sprach Marco d'Itri m...@linux.it [2010.01.30.0233 +1300]:
mdadm in incremental mode needs the hostname to be able to work
without a configuration file, which would make RAID-boot much
more robust. Instead of mdadm touching
/proc/sys/kernel/{host,domain}name, it feels like initramfs
should do that.
What happens if the hostname is changed but the initramfs is not
rebuilt?
How likely is that to happen? How likely is it to happen that the
hostname is changed, an array built (thus carrying the new
hostname), and the initramfs not rebuilt?
Yes, I see these problems, but I don't think they are so real that
they warrant guarding against them.
--
.''`. martin f. krafft madd...@d.o Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
syntactic sugar causes cancer of the semicolon.
-- epigrams in programming
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: please set hostname via sysctl early on
also sprach Marco d'Itri m...@linux.it [2010.01.30.0839 +1300]: What happens if the hostname is changed but the initramfs is not rebuilt? How likely is that to happen? How likely is it to happen that the hostname is changed, an array built (thus carrying the new hostname), and the initramfs not rebuilt? It looks likely to me when building a new system. Right, but if you muck around with the system at this level, I assume you can recover the system if it fails to bring up the RAID by itself using the initramfs console. Anyway, I don't really see a way to guard against the problems, nor a way to solve it otherwise, short of running update-initramfs from the hostname binary or grub trying to read /etc/hostname and passing it via kernel command line. I guess I could try this, but it sounds fragile and hard. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems i wish i hadn't slept all day, it's really lowered my productivity -- robert mcqueen digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: domainname
also sprach Gabor Gombas gomb...@digikabel.hu [2010.01.30.1131 +1300]: IMHO you are confused: /proc/sys/kernel/domainname is the NIS domain name and has nothing to do with DNS; in fact, the NIS domain can be different from the DNS domain. Thus your script is doubly wrong: on a NIS system hostnames are normally not qualified so you cannot obtain the NIS domain from the host name, and on a non-NIS system the NIS domainname should remain unset even if the hostname is qualified. Okay, so the script is wrong in that it sets the domain name, which can be easily fixed. I don't see how it's doubly wrong Also, mdadm currently works fine with custom-built kernels having no initramfs at all. Why break that? I am not breaking that, but it's been deprecated for years. In fact, kernel-mode md assembly does not support 1.x metadata — now the default — and that won't be changed. It would be much nicer to patch mdadm to try to read /etc/hostname directly if gethostname() returns an empty string. There is no /etc/hostname in the initrd, but this is an idea. Regarding to the issue Marco raised: in fact it is quite common to install a machine on an internal network where it gets some random name from DHCP, and rename it when it is ready to be put at it's intended location. When you do not have physical access to the final location then finding out that the machine no longer boots with the new name may be painful. It won't be a problem is the mdadm.conf file is in place and accurate. Having the hostname set and correct just means that it would all work even without the conf file. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#566192: initramfs-tools: md0 device not recognized at boot after upgrade to kernel 2.6.30
also sprach Louis Richard Pirlet lrpir...@gmail.com [2010.01.22.0952 +1300]: I upgraded my kernel from 2.6.26 to 2.6.30 and could not boot the system over the new kernel. I still can boot it from the old 2.6.26 kernel. My root disk is on a mirror raid based on 2 SCSI disk. The boot process stopsand gives a message to the effect that the file system is unavailable. Have you tried the rootdelay parameter? I think there is a problem with the initramfs-tools because there is no mdadm.conf describing my md devices... In fact there is no mdadm directory under etc in the initrd.img-2.6.30.2.686 created by the upgrade. This is not good but mdadm's initramfs is designed to work anyway. Once your system boots, it would be good to find out what's going on. Is there an /etc/mdadm/mdadm.conf there? -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#563466: rebinding is enough to cause freeze
The module needs not be reloaded; it is enough to rebind the device to the driver via sysfs to cause the freeze. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#563466: reloading ath5k module and bringing link up freezes machine
none (no description available) -- debconf information excluded -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Debian Kernel Group Meeting
also sprach Vincent Sanders vi...@debian.org [2009.10.15.1431 +0200]: Debian Kernel Group Meeting === Report by Vincent Sanders for Debian Project Kernel List Dear kernel team, and Vincent the reporter, I really appreciate this account, for two reasons: first, the past years have somewhat given the impression that we had very little of a kernel team, but seeing the names on the list of attendees at this series of meetings really gives me hope. Thank you for investing your time into these meetings. Second, the apparent professionality and effectiveness with which these meetings were conducted and recorded strongly underlines this hope. It's also great to see Canonical's mandate to sync with Debian. That's additional good news for Debian. Thank you all, -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems most people become bankrupt through having invested too heavily in the prose of life. to have ruined one's self over poetry is an honour. -- oscar wilde digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#506419: not alone
also sprach Moritz Muehlenhoff j...@inutil.org [2009.09.12.1009 +0200]: Please test with 2.6.31 (in unstable soon). If the problem persists it should be reported upstream at http://bugzilla.kernel.org The machine is in a rack and running lenny, so I'll have to wait for a backport or squeeze, but then I ought to be able to test thanks to the third network card I now have installed. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems the liar at any rate recognises that recreation, not instruction, is the aim of conversation, and is a far more civilised being than the blockhead who loudly expresses his disbelief in a story which is told simply for the amusement of the company. -- oscar wilde digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#494363: thecus nic driver multicast issue
also sprach Joey Hess jo...@debian.org [2008.08.08.2035 +0200]:
Apparently the nic driver for my thecus n2100 has a problem with
multicast packets. It ignores them unless put in promisc or allmulti
mode.
I cannot reproduce this at all. My N2100 with lenny and tbm's lenny
kernels works fine with IPv6. Following the instructions by Steve
Langasek, I verified with `ip neigh` that the N2100 ('vizier') and
my laptop ('lapse') did not know each other, and that the N2100 was
not in promisc or allmulti mode, and then ran `tcpdump` on the
laptop and pinged the N2100 from the laptop:
19:08:31.608732 IP6 2001:41e0:ff12:0:214:a4ff:fe04:eadc ff02::1:ff30:386a:
ICMP6, neighbor solicitation, who has 2001:41e0:ff12:0:214:fdff:fe30:386a,
length 32
19:08:31.616274 IP6 2001:41e0:ff12:0:214:fdff:fe30:386a
2001:41e0:ff12:0:214:a4ff:fe04:eadc: ICMP6, neighbor advertisement, tgt is
2001:41e0:ff12:0:214:fdff:fe30:386a, length 32
19:08:31.616302 IP6 2001:41e0:ff12:0:214:a4ff:fe04:eadc
2001:41e0:ff12:0:214:fdff:fe30:386a: ICMP6, echo request, seq 1, length 64
19:08:31.617498 IP6 2001:41e0:ff12:0:214:fdff:fe30:386a
2001:41e0:ff12:0:214:a4ff:fe04:eadc: ICMP6, echo reply, seq 1, length 64
19:08:36.615264 IP6 fe80::214:fdff:fe30:386a
2001:41e0:ff12:0:214:a4ff:fe04:eadc: ICMP6, neighbor solicitation, who has
2001:41e0:ff12:0:214:a4ff:fe04:eadc, length 32
19:08:36.615337 IP6 2001:41e0:ff12:0:214:a4ff:fe04:eadc
fe80::214:fdff:fe30:386a: ICMP6, neighbor advertisement, tgt is
2001:41e0:ff12:0:214:a4ff:fe04:eadc, length 24
or with hostnames, if you prefer:
19:10:01.752628 IP6 lapse.oerlikon.madduck.net ff02::1:ff30:386a: ICMP6,
neighbor solicitation, who has vizier.oerlikon.madduck.net, length 32
19:10:01.754137 IP6 vizier.oerlikon.madduck.net lapse.oerlikon.madduck.net:
ICMP6, neighbor advertisement, tgt is vizier.oerlikon.madduck.net, length 32
19:10:01.754163 IP6 lapse.oerlikon.madduck.net vizier.oerlikon.madduck.net:
ICMP6, echo request, seq 1, length 64
19:10:01.755175 IP6 vizier.oerlikon.madduck.net lapse.oerlikon.madduck.net:
ICMP6, echo reply, seq 1, length 64
19:10:06.746764 IP6 fe80::214:fdff:fe30:386a lapse.oerlikon.madduck.net:
ICMP6, neighbor solicitation, who has lapse.oerlikon.madduck.net, length 32
19:10:06.746839 IP6 lapse.oerlikon.madduck.net fe80::214:fdff:fe30:386a:
ICMP6, neighbor advertisement, tgt is lapse.oerlikon.madduck.net, length 24
I have been using the N2100 with IPv6 for about 2 weeks now and
never had a single problem.
The machine also has a rtl8169 switch, albeit connected to a 100Mbit
switch.
Hth,
--
.''`. martin f. krafft madd...@d.o Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
have you drugged your kids today?
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#540202: include a cron reboot reminder
Package: linux-2.6 Severity: wishlist Maybe the linux-image packages could install a cron.daily script that compared the currently installed version to /proc/version and sent an e-mail to root in case there's a mismatch, which most likely means that a new kernel exists, but the machine has not been rebooted. Extra bonus for making this debconf configurable. ;) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc3-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#540202: include a cron reboot reminder
also sprach dann frazier da...@debian.org [2009.08.06.1853 +0200]: Any reason this couldn't be fully implemented externally to linux-2.6? The parsing code should be static enough to live outside, I would think. No reason why it couldn't happen externally. It just seems that the linux-image packages are the logical place for it. Otoh, if you have multiple images installed, only the one with the highest version should be considered. A better approach would be something like /var/lib/debian/reboot-required.d, where packages can drop files containing reasons why a reboot is needed. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems i dislike arguments of any kind. they are always vulgar, and often convincing. -- oscar wilde digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#540202: include a cron reboot reminder
also sprach dann frazier da...@debian.org [2009.08.06.2118 +0200]: To me, it seems more like an external service. Like you mention, multiple linux-image packages could be installed at one time, so it would seem like the logic is something we'd want to factor out into a single standalone package. It is also very difficult to do any amount of rapid development within the linux-2.6 source package as new uploads require a lot of resources. Good point. It might make sense to do this as a commandline toolset, and let other people build tools on top as they wish. e.g.: $ kernstatus --booted-kernel UNAME=2.6.26-2-686 PKGVER=2.6.26-18 $ kernstatus --default-kernel UNAME=2.6.30-1-686 PKGVER=2.6.30-5 I could see using such a tool inside of s2disk to make sure that we will be booting the same kernel we used to hibernate. Possibly offtopic, I've also personally always wanted a simple, bootloader/arch independent tool that knows how to list the available kernels, and have the option to set a given kernel as the default for the next boot. e.g.: $ kerntool --list-images 2.6.30-1-686 2.6.26-2-686 $ kerntool --set-default 2.6.30-1-686 This all sounds too nice. Otoh, I am sure grub2 people will play along, and it shoud be trivial to do for grub1 too. A better approach would be something like /var/lib/debian/reboot-required.d, where packages can drop files containing reasons why a reboot is needed. Yeah, that might make sense - esp if there are other such packages, but I can't think of any myself (thankfully). But I think for the kernel case we would probably want that dropped-in file to be managed by a more intelligent tool rather than trying to figure things out (only) inside of maintainer scripts. Ha! When I teach sysadmining courses, my students get to reboot their machines *all* *the* *time* (and they have to do exercises and brainstorming in the mean time). The reason is simply that anything could break, and if the next boot will fail, then I'd like to know *now*, not then. I do like the idea of a cronjob that checks periodically to see if the kernel-that-would-be-booted-next is the same kernel that is currently booted. It would be able to detect a mismatch introduced outside of a dpkg operation - for example, if the the user reconfigures which installed kernel is the default. This is a twist on my proposal. All I wanted is a tool that knocks me over the head like hey, you installed a new 2.6.30 last week and were to tired or unable to drive to the colo centre, or you were too much of a chicken to do a remote reboot. But you still have to do it. And till then, I'll mail you every day! -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems my father, a good man, told me: 'never lose your ignorance; you cannot replace it.' -- erich maria remarque digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#540202: include a cron reboot reminder
also sprach dann frazier da...@debian.org [2009.08.06.2150 +0200]: Yeah, rebooting is certainly a good sysadmin practice, esp after a significant upgrade, but I just can't think of many packages that need to request a reboot from the admin during install/upgrade. Every. single. one. ;) I do like the idea of a cronjob that checks periodically to see if the kernel-that-would-be-booted-next is the same kernel that is currently booted. It would be able to detect a mismatch introduced outside of a dpkg operation - for example, if the the user reconfigures which installed kernel is the default. This is a twist on my proposal. All I wanted is a tool that knocks me over the head like hey, you installed a new 2.6.30 last week and were to tired or unable to drive to the colo centre, or you were too much of a chicken to do a remote reboot. But you still have to do it. And till then, I'll mail you every day! It is a twist (well, an extension), but one I suspect users to want. If you are running a 2.6.30 and install an updated 2.6.26 (or vice-versa), do you want to be nagged everyday until you reboot? It would be preferable to only nag if the default-kernel was updated (either by installing 2.6.31 or an updated 2.6.30). For the running kernel version (2.6.30 is 2.6.30, so 2.6.30-1-amd64 == 2.6.30-2-amd for this purpose), check if there is an image package installed that is strictly larger in version than what's currently running according to /proc/version. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems ... and so he killed Miguel in a rit of fealous jage. -- inspector clouseau digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#532613: Still in 2.6.30-1 and 2.6.31-rc3
The bug persists up until 2.6.31-rc3 from buildserver.net. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#532613: Still in 2.6.30-1 and 2.6.31-rc3
also sprach martin f krafft madd...@debian.org [2009.07.17.1733 +0200]: The bug persists up until 2.6.31-rc3 from buildserver.net. Very strangely, after a failed s2ram suspend-resume cycle, it now works. Before that, reboots wouldn't repair it. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#536644: initramfs-tools: Boot failure from software-RAID1 with debian Lenny
also sprach D. North ro...@tditx.com [2009.07.12.0535 +0200]: mdadm: no devices found for /dev/md0 Segmentation fault I suggest you run a hardware and memory check. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Bug#536644: initramfs-tools: Boot failure from software-RAID1 with debian Lenny
also sprach D. North ro...@tditx.com [2009.07.12.2309 +0200]: Also - somewhere along the line today, the UUIDs of the /dev/md0 members have changed. I am not aware of anything I did to change them, and I do not know exactly WHEN they changed. It concerns me quite a bit that the lower half of the uuid's now match /dev/md1. Here are my updated and again-working array defs from /etc/mdadm/mdadm.conf: (the commented array def WAS working prior to today's re-testing) # definitions of existing MD arrays # ARRAY /dev/md0 level=raid1 num-devices=2 UUID=abdd9eb3:faeb7c80:e30e8841:87878c43 ARRAY /dev/md0 level=raid1 num-devices=2 UUID=abdd9eb3:faeb7c80:34b6d411:a56b552d ARRAY /dev/md1 level=raid1 num-devices=2 UUID=8d97d0a5:41763dfc:34b6d411:a56b552d This is due to the HOMEHOST feature. Check the manpage. I have never seen mdadm segfault like you describe. Maybe you can change the initramfs hook so that it runs strace (you'll have to copy strace into the initramfs too) and stores the results in /dev/.initramfs/, which will be available after the boot has finished, I think. Other than that, maybe it would make sense if you included the output of /usr/share/bug/mdadm/script 31 run as root and sent it to the bug report. Btw, no reason to send mail to the debian-kernel mailing list. Just keep sending to the bug report. Thanks, -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems fitter, healthier, more productive like a pig, in a cage, on antibiotics -- radiohead digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#532613: snd_via82xx: volume levels too low
Package: linux-image-2.6.30-rc8-amd64 Version: 2.6.30~rc8-1~experimental.1~snapshot.13724 Severity: normal Since upgrading from rc5 to rc8, the volume levels of my soundcard output are so low that I cannot hear anything anymore, even with all the jogs yanked to 100%. This is possibly related to commit b452e08e73c0e3dbb0be82130217be4b7084299e, which hit rc6. Thanks to Mark Brown for his help. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-rc8-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-image-2.6.30-rc8-amd64 depends on: ii debconf [debconf-2.0] 1.5.26 Debian configuration management sy ii initramfs-tools [linux-initra 0.93.2 tools for generating an initramfs ii module-init-tools 3.7-pre9-1 tools for managing Linux kernel mo linux-image-2.6.30-rc8-amd64 recommends no packages. Versions of packages linux-image-2.6.30-rc8-amd64 suggests: ii grub-pc [grub] 1.96+20090603-2 GRand Unified Bootloader, version pn linux-doc-2.6.30 none (no description available) -- debconf information excluded -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
also sprach Tony Godshall t...@of.net [2009.05.12.2003 +0200]: Yes, I see that it's optional, and actually rather pointless in my case since I'm booting off the RAID partition, unless grub reads mdadm.conf . But grub only reads /boot, not /etc, right? /etc would not be available until /etc/fstab is processed. The point is that mdadm.conf is copied into the initramfs and is thus available at boot time before the root filesystem is available. Now that I have a better idea of what's going on during the boot process, I googled and found this: http://wiki.debian.org/InitramfsDebug Note the change history. ;) Wish I'd found it earlier. I could have submitted a much better initial report. By the way, Martin, sometimes it's good to give people a little more why with the do this, do that. Or point them to a good wiki or faq. Bug reporters don't necessarily choose to be ignorant and a word to the wise-guy may save a bit of flame. ;-) Yes, I am aware. And sometimes it is necessary to first poke around a bit to find out which direction the actual cause lies. It just takes too much time and is potentially confusing to explain the background for each case. Once the solution is found, I always give more information, for the poster, to recap myself and find possible holes, and for posterity. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems a farmer is a man outstanding in his field. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
also sprach Tony Godshall t...@of.net [2009.05.11.2058 +0200]: They are *not*. That would seem to be the nub of the problem. No base partitions, thus no RAID. Good, thanks, that's progress. Might be good for md to report that that a little better (see screenshot). Oh, duh, I moved /etc/mdadm/mdadm.conf out of the way. So it doesn't even know I have a RAID until it autodetects it, right? Oh, wait, in this initramfs environment there is an /etc/mdadm/mdadm.conf, and it shows UUID and the 4-way RAID1. What, so the /etc/mdadm/mdadm.conf inside the initrd is not from the kernel package but was built locally? Didn't realize that. It's copied from the main system when the initramfs is created, unless it's faulty or doesn't represent the system or hasn't been checked since the 2.5.3 upgrade. In the initramfs, if there is a config file, it's used. If there's not a config file, mdadm scans all partitions and assembles them all (like /sbin/mdadm-startall). Thus, if you remove it in the initramfs, you basically tell the system that you want it to scan, rather than search for the specific UUID in the file. Perhaps if I could figure out how to grab the dmesg output from initramfs environment, I could then compare the amd64 kernel output to the 686-bigmem kernel output... :-/ Append 'break=bottom debug' to the kernel line and at the shell do something like mount -o remount,rw /root cp /dev/.initramfs/initramfs.debug /root/root/initramfs-debug.foo mount -o remount,ro /root and then find the file in /root once the system booted. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems review of a chemistry paper: paper should be greatly reduced or completely oxidized. -- frank vastola digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#528393: manpage states wrong path for debug file
Package: initramfs-tools Version: 0.92o Severity: normal The manpage says initramfs-tools write debug info to /tmp/initramfs.debug, but it's actually using /dev/.initramfs/initramfs.debug already, meaning the file will actually be available once the system has booted. It might make sense to push a fix out with the next stable upgrade. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-rc4-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages initramfs-tools depends on: ii cpio 2.9.90-3 GNU cpio -- a program to manage ar ii findutils 4.4.1-1utilities for finding files--find, ii klibc-utils 1.5.15-1 small utilities built with klibc f ii module-init-tools 3.7-pre9-1 tools for managing Linux kernel mo ii udev 0.141-1/dev/ and hotplug management daemo Versions of packages initramfs-tools recommends: ii busybox 1:1.13.3-1 Tiny utilities for small and embed initramfs-tools suggests no packages. -- no debconf information -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
also sprach Tony Godshall t...@of.net [2009.05.11.1819 +0200]: retitle 526525 amd64 kernel cannot find bnx2 PCI device base address Um. BNX2 is the network card? WTF does it have to do with being able to mount and boot off RAID in 64-bit mode only? I don't know, but your attitude does not make me want to help you further. http://www.chiark.greenend.org.uk/~sgtatham/bugs.html -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems sobald man über niveau spricht ist man längst darüber hinweg. -- thomas krafft digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
also sprach Tony Godshall t...@of.net [2009.05.11.1843 +0200]: I filed the report because I want to see Debian work great on all configurations, with all CPUs, with all RAID configurations, off the bat, without tweaking. And I'm trying to do what small part I can. With the limited access to the equipment I have. As I said before, this is not a RAID problem. RAID works no different on amd64 than it does on i386. I'm trying to help, and you tell me to delete config files, you don't bother to read key parts of my report, and you talk about my attitude when I notice a bad rename. I told you to delete a file in an initrd image copied to RAM, because I suspected your UUIDs to have gotten out of sync. Which part of your report didn't I read? What bad rename are you talking about? Please find attached screenshots of boot with /etc/mdadm/mdadm.conf removed out of the way. No screenshot attached. Also, note that I didn't ask you to remove the file from the disk, but I asked you to remove the file from the command line you see when initramfs fails to mount the rootfs. Sorry if that wasn't clear. If you want to get an idea of what relevant information is, please run /usr/share/bug/mdadm/script 31 as root and post the output. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems life moves pretty fast. if you don't stop and look around once in a while, you could miss it. -- ferris bueller digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
retitle 526525 amd64 kernel cannot find bnx2 PCI device base address thanks also sprach Tony Godshall t...@of.net [2009.05.09.0117 +0200]: If you cannot boot, append break=mount to the kernel line, and at the initramfs prompt, type rm /etc/mdadm/mdadm.conf /scripts/local-top/mdadm ctrl-d and then fix the initramfs. I'm not interested in deleting mdadm.conf or taking any other steps that might break the existing functionality. I considered it a necessary step in my analysis, but if you prefer to do things your way, it's your system. Note that I would have never proposed anything that made permanent changes without adequate warning. I'm not reporting this bug because I must have an amd64 kernel- like I said, the 686 and 686bigmem kernels are working. I initiated this bug to help get the amd64 version of the kernel (or mdadm?) fixed. I'm interested in steps that will help fix the packages, not manually work around its flaws. Then please provide all the necessary infos. mdadm works perfectly fine with amd64 kernels. I think your problem is that the kernel doesn't initialise the drives you're using properly, so mdadm doesn't find them when trying to assemble. You will have to make sure the kernel sees your drives. From what you've allowed me to see, I can conclude that this is not a RAID problem. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems fashions have done more harm than revolutions. -- victor hugo digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see root RAID device /dev/md0
also sprach Tony Godshall t...@of.net [2009.05.08.0055 +0200]: bnx2 :01:00.1: Cannot find PCI device base address, aborting. mptbase: ioc0: ERROR - : ERROR - Unable to map adapter memory! mptbase: ioc1: ERROR - : ERROR - Unable to map adapter memory! mdadm: No devices listed in conf file were found. Looks like your mdadm.conf is wrong. I suggest you remake that (check output of /usr/share/mdadm/mkconf) and then update your initramfs. If you cannot boot, append break=mount to the kernel line, and at the initramfs prompt, type rm /etc/mdadm/mdadm.conf /scripts/local-top/mdadm ctrl-d and then fix the initramfs. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
kbuild packages on buildserver
Hey folks, I am tracking http://kernel-archive.buildserver.net/debian-kernel and would be keen to experiment with new kernel releases. However, when a new release comes out, like 2.6.30-rc*, it lacks the corresponding linux-kbuild-2.6 binary package, e.g. linux-kbuild-2.6.30 in this case. I know I am supposed to build this by hand[0], but that's quite an effort, and possibly duplicated by many people at the same time. [0] http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage#Thestoryoflinux-kbuild-2.6 Wouldn't it be possible to also upload the kbuild packages alongside the kernel image pre-releases to buildserver? Browsing the web, I found http://www.linux-archive.org/debian-kernel/209956-linux-kbuild-2-6-27-kernel-archive-buildserver-net.html. Is this still an issue? Would you let me upload for i386/amd64 if I built the packages? I am sure this would lead to many more people trying newer kernels and improve the overall feedback. Cheers, -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems a woman is an occasional pleasure but a cigar is always a smoke. -- groucho marx digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526737: marked as done (md: RAID 1 check makes kernel almost panic)
also sprach Bastian Blank wa...@debian.org [2009.05.03.1133 +0200]: It is a valid bug and fixed with the next upload. Can you please provide details on how I can reproduce this bug? -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems and no one sings me lullabies, and no one makes me close my eyes, and so i throw the windows wide, and call to you across the sky -- pink floyd, 1971 digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#506419: not alone
It seems I am not alone with the problem: http://www.nvnews.net/vbulletin/archive/index.php/t-84319.html yet, Transtec fails to reproduce with SLES, but they also didn't test IPv6 or large frames, I think. Anyway, I've requested the driver they use, as well as the following information: dmesg output from insmod lsmod | grep nvnet # suspect use of proprietary driver in SLES ethtool eth0 ethtool --driver eth0 ethtool --show-offload eth0 ethtool --show-nfc eth0 modinfo forcedeth modinfo nvnet Will keep this bug in the loop, -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#517833: sysctl net.ipv?.conf.all.* interface broken
Package: linux-2.6
Version: 2.6.24-6~etchnhalf.8
Severity: important
Forwarded: http://marc.info/?l=linux-kernelm=123599691025508w=2
[ObFront: I wanted to make this critical and tagged security, but
until I find more information, I'll leave it as is]
seamus# head ipv6/conf/{all,eth0}/accept_ra
== ipv6/conf/all/accept_ra ==
1
== ipv6/conf/eth0/accept_ra ==
1
seamus# echo 0 | ipv6/conf/all/accept_ra
seamus# head ipv6/conf/{all,eth0}/accept_ra
== ipv6/conf/all/accept_ra ==
0
== ipv6/conf/eth0/accept_ra ==
1
ipv6/conf/echo/accept_ra should be 0 as well, but it isn't. This
applies to all ipv[46]/conf/all/* I've tried, between 2.6.24 and
2.6.28. I have not been able to try an earlier kernel.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
.''`. martin f. krafft madd...@d.o Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
tracking the kernel with svn
Hello, d-kernel people, You are tracking the kernel packaging with SVN. Do you just import snapshots/tarballs and maintain your changes across them, or do you have some funky setup that allows you to keep an SVN repo in sync with a Git upstream? This is a serious question, not flame bait or facetiousness, as we are trying to find a strategy for a similar situation and would love to benefit from your experience. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems in a country where the sole employer is the state, opposition means death by slow starvation. the old principle: who does not work shall not eat, has been replaced by a new one: who does not obey shall not eat. -- leon trotsky, 1937 digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#516709: huge /lib/modules directory, almost 3x size of 2.6.26
Package: linux-image-2.6.28-1-amd64 Version: 2.6.28-1 Severity: important While the .deb is only 3M larger than the 2.6.26-1-amd64 .deb, unpacked, this 2.6.28 package tries to install 212M worth of modules into /lib/modules, while 2.6.26 only had 78M. It seems likely that there was a build error here, e.g. maybe noopt or nostrip was set. Also see: http://lists.debian.org/debian-kernel/2009/02/msg00555.html Cheers, -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#504611: me too
I also would like to see this feature (as a module) in the Debian kernel. Thanks, -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#446323: mdadm: recovery in infinite loop
also sprach Lukasz Szybalski szybal...@gmail.com [2009.02.04.0655 +0100]:
3. I then readded my /dev/hda2 to /dev/md2 and a lot of errors
started to appear in syslog...
[...]
Feb 3 23:49:09 hplinux kernel: hdc: dma_intr: status=0x51 {
DriveReady SeekComplete Error }
Looks like your /dev/hdc is dying. I hope you have backups, and
I would replace the disk ASAP.
I am starting to believe this is a hardware problem.
--
.''`. martin f. krafft madd...@d.o Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#506419: also with ipv4
retitle 506419 high volumes of traffic kill forcedeth chip tags 506419 -ipv6 found 506419 2.6.26-13 thanks I just managed to reproduce this with plain IPv4 traffic: sending a huge file to the machine via SSH killed the network chip. The only way to get the network card to work again for any sort of traffic was with a rmmod/modprobe cycle of the driver. Joy! I hope to exchange the motherboard soon so be sure that this isn't a hardware problem. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#508460: ipv6: add/up results in permanent 'tentative' flag, up/add works
Package: linux-image-2.6.26-1-amd64 Version: 2.6.26-11 Severity: normal Tags: ipv6 X-Debbugs-Cc: [EMAIL PROTECTED] Over at #507646, we stumbled over something that seems like a bug in the duplicate address detection mechanism of the kernel: If I add an address to an interface (bridge or physical interface, does not matter), and then up the iface, then the tentative flag on the address never gets cleared (look for SEE HERE markers): khyber:/# ip addr add 2001:41e0:ff38:fffd::5 dev br1 ip addr show dev br1 sleep 10 ip addr show dev br1 ip link set br1 up ip addr show dev br1 sleep 10 ip addr show dev br1 9: br1: BROADCAST,MULTICAST mtu 1500 qdisc noqueue state DOWN link/ether 3e:2b:4a:f3:6a:e1 brd ff:ff:ff:ff:ff:ff inet6 2001:41e0:ff38:fffd::5/128 scope global tentative valid_lft forever preferred_lft forever 9: br1: BROADCAST,MULTICAST mtu 1500 qdisc noqueue state DOWN link/ether 3e:2b:4a:f3:6a:e1 brd ff:ff:ff:ff:ff:ff inet6 2001:41e0:ff38:fffd::5/128 scope global tentative valid_lft forever preferred_lft forever 9: br1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UNKNOWN link/ether 3e:2b:4a:f3:6a:e1 brd ff:ff:ff:ff:ff:ff inet6 2001:41e0:ff38:fffd::5/128 scope global tentative valid_lft forever preferred_lft forever^ SEE HERE inet6 fe80::3c2b:4aff:fef3:6ae1/64 scope link tentative valid_lft forever preferred_lft forever 9: br1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UNKNOWN link/ether 3e:2b:4a:f3:6a:e1 brd ff:ff:ff:ff:ff:ff inet6 2001:41e0:ff38:fffd::5/128 scope global tentative valid_lft forever preferred_lft forever^ SEE HERE inet6 fe80::3c2b:4aff:fef3:6ae1/64 scope link valid_lft forever preferred_lft forever If I first up the interface, then add the address, it works as expected (look for SEE HERE markers) khyber:/# ip addr show dev br1 ip link set br1 up ip addr show dev br1 ip addr add 2001:41e0:ff38:fffd::5 dev br1 ip addr show dev br1 sleep 10 ip addr show dev br1 9: br1: BROADCAST,MULTICAST mtu 1500 qdisc noqueue state DOWN link/ether 3e:2b:4a:f3:6a:e1 brd ff:ff:ff:ff:ff:ff 9: br1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UNKNOWN link/ether 3e:2b:4a:f3:6a:e1 brd ff:ff:ff:ff:ff:ff inet6 fe80::3c2b:4aff:fef3:6ae1/64 scope link tentative valid_lft forever preferred_lft forever 9: br1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UNKNOWN link/ether 3e:2b:4a:f3:6a:e1 brd ff:ff:ff:ff:ff:ff inet6 2001:41e0:ff38:fffd::5/128 scope global tentative valid_lft forever preferred_lft forever^ SEE HERE inet6 fe80::3c2b:4aff:fef3:6ae1/64 scope link tentative valid_lft forever preferred_lft forever 9: br1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UNKNOWN link/ether 3e:2b:4a:f3:6a:e1 brd ff:ff:ff:ff:ff:ff inet6 2001:41e0:ff38:fffd::5/128 scope global valid_lft forever preferred_lft forever^ SEE HERE inet6 fe80::3c2b:4aff:fef3:6ae1/64 scope link valid_lft forever preferred_lft forever I cannot reproduce this with a sit tunnel device, which seems logical as DAD/tentative states are not used in a point-to-point context, I think. -- .''`. martin f. krafft [EMAIL PROTECTED] Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems ah, but a man's reach should exceed his grasp, or what's a heaven for? -- robert browning -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-image-2.6.26-1-amd64 depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92l tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo linux-image-2.6.26-1-amd64 recommends no packages. Versions of packages linux-image-2.6.26-1-amd64 suggests: ii grub 0.97-47lenny1 GRand Unified Bootloader (Legacy v pn linux-doc-2.6.26 none(no description available) -- debconf information: linux-image-2.6.26-1-amd64/postinst/create-kimage-link-2.6.26-1-amd64: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.26-1-amd64/postinst/kimage-is-a-directory: linux-image-2.6.26-1-amd64/postinst/old-initrd-link-2.6.26-1-amd64: true linux-image-2.6.26-1-amd64/preinst/bootloader-initrd-2.6.26-1-amd64: true linux-image-2.6.26-1-amd64
Bug#508460: ipv6: add/up results in permanent 'tentative' flag, up/add works
also sprach Bjørn Mork [EMAIL PROTECTED] [2008.12.11.1525 +0100]: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e3ec6cfc260e2322834e200c2fa349cdf104fd13 Yeah, that seems like the problem. Seems like this should go into lenny... IPv6 is a release goal, and this bug causes a number of problems, at least because it's unexpected... -- .''`. martin f. krafft [EMAIL PROTECTED] Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems review of a chemistry paper: paper should be greatly reduced or completely oxidized. -- frank vastola digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#506419: Driver from Supermicro fixes issue
also sprach martin f krafft [EMAIL PROTECTED] [2008.12.09.1154 +0100]: The attached patch against linux-2.6 2.6.26-11 seems to fix the original problem for me, [...] I just saw another gso-related kernel trace, even with the new driver. :/ -- .''`. martin f. krafft [EMAIL PROTECTED] Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#506419: Driver from Supermicro fixes issue
also sprach Bastian Blank [EMAIL PROTECTED] [2008.12.10.1541 +0100]: You managed to get the _unpatched_ source. The patches are applied during the build: Okay, that makes sense. How do I get the patched source? The accepted standard methods (see policy 4.9 and 4.14) don't reveal anything and don't work: piper:..orcedeth|master|linux-2.6-2.6.26% less debian/README.source debian/README.source: No such file or directory piper:..orcedeth|master|linux-2.6-2.6.26% fakeroot debian/rules patch make: *** No rule to make target `patch'. Stop. -- .''`. martin f. krafft [EMAIL PROTECTED] Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems the wonderful thing about standards is that there are so many to choose from. -- grace hopper digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#506419: Driver from Supermicro fixes issue
also sprach Bastian Blank [EMAIL PROTECTED] [2008.12.09.1211 +0100]: This is no patch which suffice our guidelines. Please show submittions to the Linux maintainers and/or commit ids. As stated in my message, I don't have the time to do this right now, but I will try to get Transtec/Supermicro to push this stuff into the kernel. It's still a patch. I don't mind if you remove the patch tag, but it might still be useful to some people. I, for one, don't expect this to be fixed for lenny, or even any time soon, unfortunately. Cheers, -- .''`. martin f. krafft [EMAIL PROTECTED] Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#506419: Driver from Supermicro fixes issue
also sprach Bjørn Mork [EMAIL PROTECTED] [2008.12.09.1413 +0100]: This should not apply against linux-2.6 2.6.26-11 since it is already a part of debian/patches/bugfix/all/stable/2.6.26.4.patch. Are you sure your patch really does apply? If it does, then I'd suggest trying *just* edcfe5f7e307846e578fb88d69fa27051fded0ab instead. My patch does no apply, it was made against 2.6.26-11 -- Supermicro just sent me their forcedeth.c and I made the patch. BTW, I also noticed that linux-2.6 2.6.26-11 includes the patch linux-2.6-2.6.26/debian/patches/features/all/net-use-gso.patch which very well may trigger the problem. You might also want to try building without that patch. I have not tried -11 on the server, only -8 and -10, which both had the problems. How do I find out when net-use-gso.patch was added? The changelog does not mention it, and I cannot find a repository for the source (there are also no Vcs-* links in the package). But then again, there's your performance requirements. I guess you'd better get a proper NIC :-) As soon as I get a second switch port, I will. While I only have one switch port, I have no choice... -- .''`. martin f. krafft [EMAIL PROTECTED] Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#506419: kernel trace during IPv6 ssh output
also sprach Ben Hutchings [EMAIL PROTECTED] [2008.11.29.2153 +0100]: This could be a bug in the interaction of bridging or netfilter with GSO. Could you try to rule out either of those? I cannot reproduce the same bug anymore, which may be due to the fact that I am using a proto-41 IPv6 tunnel at the new location (and thus lower transmission rates). But I found a but that seems awfully related. This time, it's on incoming traffic though, not outgoing. So the bug is kinda horrid: the NIC that provides eth0 also connects to the IPMI card, and when I cause a whole lot of IPv6 traffic (incoming, e.g. downloading ISOs from switch.ch via IPv6), the NIC locks up to the point where the IPMI card also becomes unreachable. A soft-reboot fixes the problem. There is nothing in the logs. I can produce this problem with bridging and iptables, or either of the two, but not if I disable bridging and iptables. But since it is rather intermittent, sometimes requiring several gigabytes to be shoved across the line before it hangs up, it could be that plain, no-iptables-no-bridge also has the problem. The machine is coming back home with me. :( -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
reassign 426465 to initramfs-tools
reassign 426465 initramfs-tools -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
reassign 489608 to linux-2.6
reassign 489608 linux-2.6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
reassign 489608 to linux-2.6
reassign 489608 linux-2.6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502058: maybe_break fails if $break is undefined
12804 1 ext3 dm_mirror 20608 0 dm_log 13956 1 dm_mirror dm_snapshot19400 0 dm_mod 58864 4 dm_crypt,dm_mirror,dm_log,dm_snapshot raid10 23680 6 raid1 24192 2 md_mod 80164 10 raid10,raid1 ide_cd_mod 36360 0 cdrom 37928 1 ide_cd_mod floppy 61672 0 ehci_hcd 36108 0 uhci_hcd 25760 0 via82cxxx 12164 0 [permanent] ide_pci_generic 9220 0 [permanent] ide_core 128284 3 ide_cd_mod,via82cxxx,ide_pci_generic ata_generic10116 0 skge 41744 0 via_rhine 25864 0 mii 9856 1 via_rhine ohci1394 32564 0 ieee1394 93816 1 ohci1394 sd_mod 29376 35 thermal22688 0 processor 42304 1 thermal fan 9352 0 thermal_sys17728 4 video,thermal,processor,fan sata_promise 16516 15 sata_via 13060 16 libata165472 3 ata_generic,sata_promise,sata_via scsi_mod 160760 3 usb_storage,sd_mod,libata dock 14112 1 libata -- /etc/kernel-img.conf do_symlinks = no do_bootloader = no do_bootfloppy = no do_initrd = yes postinst_hook = update-grub postrm_hook = update-grub -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=y KEYMAP=n BOOT=local DEVICE=eth0 NFSROOT=auto -- /etc/crypttab # target name source device key file options -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages initramfs-tools depends on: ii cpio 2.9-14 GNU cpio -- a program to manage ar ii findutils 4.4.0-2utilities for finding files--find, ii klibc-utils 1.5.12-2 small utilities built with klibc f ii module-init-tools 3.4-1 tools for managing Linux kernel mo ii udev 0.125-7/dev/ and hotplug management daemo Versions of packages initramfs-tools recommends: ii busybox 1:1.10.2-2 Tiny utilities for small and embed initramfs-tools suggests no packages. -- no debconf information -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#497812: please enable CONFIG_USB_SUSPEND
Package: linux-2.6 Version: 2.6.26-1 Severity: wishlist According to powertop: Suggestion: Enable the CONFIG_USB_SUSPEND kernel configuration option. This option will automatically disable UHCI USB when not in use, and may save approximately 1 Watt of power. Please enable this option for the Debian kernel images. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#493448: closed by Bastian Blank [EMAIL PROTECTED] (fixed)
also sprach Debian Bug Tracking System [EMAIL PROTECTED] [2008.08.04.1651 -0300]: Stop bitching around. This was broken for less then three days. What was broken? If it was broken and is now fixed, then close this bug with a version number. And as you've correctly seen, the kbuild package also have the version in it and linux-2.6 is _not_ the source package. Aha. I didn't know that. Thanks for letting me know, albeit you could have done so a little less cocky. linux-kbuild-2.6 fails to build from source anyway. Expect another bug report. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#490396: initramfs-tools: fails to start md devices
reassign 490396 busybox retitle 490396 busybox drops mkdir long option support since etch severity 490396 important tags 490396 - patch thanks also sprach John Newnham [EMAIL PROTECTED] [2008.07.12.0553 +0200]: The cause was that mdadm failed to make the root filesystem available, due to a script which will run fine with the mkdir from coreutils, but which will fail when used with busybox. I use it on a daily basis and this is new to me. But $ busybox mkdir --parents a mkdir: unrecognized option `--parents' you are right. This seems to have been dropped from busybox since etch. There is no entry in the changelog though. mdadm in lenny already uses -p rather than the long options, so if you had upgraded mdadm as well, the problem wouldn't have happened. I agree that this is a problem we should fix in time for lenny, but I can't fix it in mdadm. Thus I am reassigning to busybox, which should support long options for mkdir in lenny, possibly mark them deprecated, and only remove them for lenny+1. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#488969: please warn if a non-executable file in scripts/*/* is found
also sprach maximilian attems [EMAIL PROTECTED] [2008.07.05.2251 +0200]: the maintainer should test such stuff before uploading. if s/he does, then there won't be a warning and the user won't even notice a difference. also, this is about the user putting stuff into /etc, which is precisely how I rendered my system unbootable. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems Most Intelligent Customers Realise Our Software Only Fools Them. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#488963: please provide break at the top of mountroot
also sprach maximilian attems [EMAIL PROTECTED] [2008.07.05.0044 +0200]: I would suggest to rename the hooks as follows and call the new hook mount. top - init mount - top new - mount not sure if i'd like to play a renaming game, Why not? It's for debugging purposes and thus not critical. adding a maybe_break mountroot seems easier and makes sense. ok with you? Better than nothing. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems aus der kriegsschule des lebens - was mich nicht umbringt, macht mich härter. - friedrich nietzsche digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#488969: please warn if a non-executable file in scripts/*/* is found
also sprach maximilian attems [EMAIL PROTECTED] [2008.07.05.0054 +0200]: initramfs runs executable scripts in scripts/*/* at various stages. Albeit an error by the user or the package, scripts without executable permissions get copied to the initrd by the hooks, but then they don't get executed. Maybe initramfs could warn about files in scripts/*/* it would install, which aren't executable? chmod 666 /usr/share/initramfs-tools/hooks/legacylvm I was talking about scripts. update-initramfs -u -v | grep legacy /usr/share/initramfs-tools/hooks/legacylvm ignored: not executable Without -v, it seems that files in /etc/initramfs-tools are copied but remain non-executable. As a result, they won't be run. I think initramfs-tools should be reporting this, and the above hooks message as a warning, not requiring -v for it. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems linux: because a pc is a terrible thing to waste digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#488969: please warn if a non-executable file in scripts/*/* is found
also sprach maximilian attems [EMAIL PROTECTED] [2008.07.05.2228 +0200]: hmmm? that is an script. yes, but unlike e.g. scripts/local-top scripts, it's a hook script. why should a user be bothered if a maintainer fucks up the installation? because the system may be left unbootable? -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#488963: please provide break at the top of mountroot
Package: initramfs-tools
Version: 0.92b
Severity: wishlist
Please provide a maybe_break hook right at the top of mountroot,
after running the ${BOOT}-top scripts and before mounting root.
I would suggest to rename the hooks as follows and call the new hook
mount.
top - init
mount - top
new - mount
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.25-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages initramfs-tools depends on:
ii cpio 2.9-13 GNU cpio -- a program to manage ar
ii findutils 4.4.0-2utilities for finding files--find,
ii klibc-utils 1.5.11-2 small utilities built with klibc f
ii module-init-tools 3.4-1 tools for managing Linux kernel mo
ii udev 0.114-2/dev/ and hotplug management daemo
Versions of packages initramfs-tools recommends:
ii busybox 1:1.10.2-1 Tiny utilities for small and embed
-- no debconf information
--
.''`. martin f. krafft [EMAIL PROTECTED]
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#488969: please warn if a non-executable file in scripts/*/* is found
Package: initramfs-tools Version: 0.92b Severity: wishlist initramfs runs executable scripts in scripts/*/* at various stages. Albeit an error by the user or the package, scripts without executable permissions get copied to the initrd by the hooks, but then they don't get executed. Maybe initramfs could warn about files in scripts/*/* it would install, which aren't executable? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages initramfs-tools depends on: ii cpio 2.9-13 GNU cpio -- a program to manage ar ii findutils 4.4.0-2utilities for finding files--find, ii klibc-utils 1.5.11-2 small utilities built with klibc f ii module-init-tools 3.4-1 tools for managing Linux kernel mo ii udev 0.114-2/dev/ and hotplug management daemo Versions of packages initramfs-tools recommends: ii busybox 1:1.10.2-1 Tiny utilities for small and embed -- no debconf information -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
[PATCH] Wait for udevsettle after $BOOT-top scripts ran
udev may be busy creating links for the root device by the time
mountroot is called. udevsettle makes sure these are processed. I thus
call udevsettle with a timeout of 10 seconds after the $BOOT-top
scripts have run and before the ROOTDELAY hack kicks in.
I thought about doing this with a local-top script instead, but there is
no way to ensure that it'll run last; cryptsetup uses a hack to make
sure it runs last, if we also use the same hack, there'll be
a dependency loop.
Signed-off-by: martin f. krafft [EMAIL PROTECTED]
---
scripts/functions |9 +
scripts/local |2 ++
scripts/nfs |2 ++
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/scripts/functions b/scripts/functions
index d36884c..558f521 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -313,3 +313,12 @@ configure_networking()
. /tmp/net-*.conf
fi
}
+
+wait_for_udev()
+{
+ if [ -x $(command -v udevsettle) ]; then
+ [ $quiet != y ] log_begin_msg Waiting for udev to
process events
+ udevsettle ${1:+--timeout=$1}
+ [ $quiet != y ] log_end_msg
+ fi
+}
diff --git a/scripts/local b/scripts/local
index d28917b..dc0745d 100644
--- a/scripts/local
+++ b/scripts/local
@@ -31,6 +31,8 @@ mountroot ()
run_scripts /scripts/local-top
[ $quiet != y ] log_end_msg
+ wait_for_udev 10
+
# If the root device hasn't shown up yet, give it a little while
# to deal with removable devices
if [ ! -e ${ROOT} ] || ! $(get_fstype ${ROOT} /dev/null); then
diff --git a/scripts/nfs b/scripts/nfs
index b9c2522..435d2d0 100644
--- a/scripts/nfs
+++ b/scripts/nfs
@@ -59,6 +59,8 @@ mountroot()
# For DHCP
modprobe af_packet
+ wait_for_udev 10
+
# Default delay is around 180s
# FIXME: add usplash_write info
if [ -z ${ROOTDELAY} ]; then
--
1.5.6
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[PATCH] Remove extra ellipses
log_begin_msg already puts ... at the end of the stuff it prints, so no
need to have it in there explicitly.
Signed-off-by: martin f. krafft [EMAIL PROTECTED]
---
init |4 ++--
scripts/local |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/init b/init
index 885f240..4c72eab 100755
--- a/init
+++ b/init
@@ -157,7 +157,7 @@ maybe_break top
run_scripts /scripts/init-top
maybe_break modules
-log_begin_msg Loading essential drivers...
+log_begin_msg Loading essential drivers
load_modules
log_end_msg
@@ -167,7 +167,7 @@ run_scripts /scripts/init-premount
[ $quiet != y ] log_end_msg
maybe_break mount
-log_begin_msg Mounting root file system...
+log_begin_msg Mounting root file system
. /scripts/${BOOT}
parse_numeric ${ROOT}
mountroot
diff --git a/scripts/local b/scripts/local
index b55212e..d28917b 100644
--- a/scripts/local
+++ b/scripts/local
@@ -34,7 +34,7 @@ mountroot ()
# If the root device hasn't shown up yet, give it a little while
# to deal with removable devices
if [ ! -e ${ROOT} ] || ! $(get_fstype ${ROOT} /dev/null); then
- log_begin_msg Waiting for root file system...
+ log_begin_msg Waiting for root file system
# Default delay is 180s
if [ -z ${ROOTDELAY} ]; then
--
1.5.6
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477441: cannot be used as dom0
Package: linux-image-2.6.24-1-xen-686 Version: 2.6.24-6 Severity: important Tags: upstream The kernel image does not have CONFIG_XEN_PRIVILEGED_GUEST=y set and /var/lib/linux-image-2.6.24-1-xen-686/xen-versions is empty. This is a regression from previous versions and causes update-grub not to add a stanza for the hypervisor. As a result, 2.6.24 cannot be used on a xen host. I am told this is an upstream problem. I am filing it with debbugs for posterity. Apparently 2.6.25, which is about to hit sid, will support x86_32 again, and *_64 has to wait for 2.6.24. This also means that lenny will likely not support xen dom0 on amd64. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.24-1-xen-686 depends on: ii initramfs-tools 0.92 tools for generating an initramfs ii linux-modules-2.6.24-1-xen-68 2.6.24-6 Linux 2.6.24 modules on i686 Versions of packages linux-image-2.6.24-1-xen-686 recommends: ii libc6-xen 2.7-10 GNU C Library: Shared libraries [X -- no debconf information -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#475674: source package rules.gen build does not generate -common headers
Package: linux-2.6 Version: 2.6.24-5 Severity: wishlist I wanted to apply a patch to the kernel yesterday, and after running into problems with make-kpkg, I found http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage and adopted the method. I even rewrote most of the wiki page to make sure it applies. Comments welcome, of course. My problem now is that the single kernel variant instructions only yield 8 packages: linux-image-2.6.24-1+foo.1-686_2.6.24-5+foo.1_i386.deb linux-headers-2.6.24-1+foo.1-686_2.6.24-5+foo.1_i386.deb linux-support-2.6.24-1+foo.1-686_2.6.24-5+foo.1_i386.deb linux-tree-2.6.24_2.6.24-5+foo.1_i386.deb linux-patch-debian-2.6.24_2.6.24-5+foo.1_i386.deb linux-source-2.6.24_2.6.24-5+foo.1_i386.deb linux-manual-2.6.24_2.6.24-5+foo.1_i386.deb linux-doc-2.6.24_2.6.24-5+foo.1_i386.deb Unfortunately, linux-headers-2.6.24-1+foo.1-686 depends on linux-headers-2.6.24-1+foo.1-common, but that is not being created until I build binary-arch_i386, which takes infinitely longer. Shouldn't the binary-arch_i386_none_686 target build the common headers too, since its result depends on them? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1+scoflowctrl.1-686 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
linux-headers...common in single variant build
Hello kernel team, I wanted to apply a patch to the kernel yesterday, and after running into problems with make-kpkg, I found http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage and adopted the method. I even rewrote most of the wiki page to make sure it applies. Comments welcome, of course. My problem now is that the single kernel variant instructions only yield 8 packages: linux-image-2.6.24-1+foo.1-686_2.6.24-5+foo.1_i386.deb linux-headers-2.6.24-1+foo.1-686_2.6.24-5+foo.1_i386.deb linux-support-2.6.24-1+foo.1-686_2.6.24-5+foo.1_i386.deb linux-tree-2.6.24_2.6.24-5+foo.1_i386.deb linux-patch-debian-2.6.24_2.6.24-5+foo.1_i386.deb linux-source-2.6.24_2.6.24-5+foo.1_i386.deb linux-manual-2.6.24_2.6.24-5+foo.1_i386.deb linux-doc-2.6.24_2.6.24-5+foo.1_i386.deb Unfortunately, linux-headers-2.6.24-1+foo.1-686 depends on linux-headers-2.6.24-1+foo.1-common, but that is not being created until I build binary-arch_i386, which takes infinitely longer. Shouldn't the binary-arch_i386_none_686 target build the common headers too, since its result depends on them? -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems the mind of the thoroughly well-informed man is a dreadful thing. it is like a bric-à-brac shop, all monsters and dust, with everything priced above its proper value. -- oscar wilde digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: libata PATA transition
also sprach maximilian attems [EMAIL PROTECTED] [2008.03.12.1249 +0100]: on mdadm side: #435983 Marco has not responded. I wonder if there's someone else who can implement this? I don't have the time to read up on it and I would have to learn udev first. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems logik ist analsadismus: gedanken werden gewaltsam durch einen engen gang gepreßt. -- frei nach lacan digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#446323: mdadm: recovery in infinite loop
also sprach Neil Brown [EMAIL PROTECTED] [2007.10.16.0043 +0100]: I was hoping for cat /proc/partitions and maybe even fdisk -l /dev/hda /dev/hdb In the future, consider asking for /usr/share/bug/mdadm/script 31 which should have *all* the output you could ever want. :) In future versions of Debian/Ubuntu's mdadm, you can just run /usr/share/bug/mdadm/script without the redirection. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: /scripts/local: Waiting for root file system...
also sprach Petr Kohts [EMAIL PROTECTED] [2007.10.04.2056 +0100]: Begin: Waiting for root file system... ... Just yesterday: http://lists.debian.org/msgid-search/[EMAIL PROTECTED] -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems normaliser unix c'est comme pasteuriser le camembert. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#441211: system unbootable: MODULES=dep creates initrd without ext3.ko (RAID-only system here)
-grub -- /etc/initramfs-tools/initramfs.conf MODULES=dep BUSYBOX=y KEYMAP=n BOOT=local DEVICE=eth0 NFSROOT=auto -- /etc/crypttab # target name source device key file options -- /sys/block fd0 hda hdb md0 md1 md2 md3 md4 md5 md6 md7 ram0 ram1 ram10 ram11 ram12 ram13 ram14 ram15 ram2 ram3 ram4 ram5 ram6 ram7 ram8 ram9 sda sdb sdc sdd sde sdf sdg sdh sdi -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages initramfs-tools depends on: ii busybox 1:1.1.3-5 Tiny utilities for small and embed ii cpio 2.9-3 GNU cpio -- a program to manage ar ii klibc-utils 1.5.7-1 small statically-linked utilities ii module-init-tools3.3-pre11-4 tools for managing Linux kernel mo ii udev 0.114-2 /dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#441211: system unbootable: MODULES=dep creates initrd without ext3.ko (RAID-only system here)
also sprach maximilian attems [EMAIL PROTECTED] [2007.09.07.1704 +0200]:
please post the ouput of:
mount
mount | awk '/ \/ / {print root= $1 \nrootfs= $5; exit}'
/dev/md1 on / type auto (rw,noatime,errors=remount-ro,acl,user_xattr)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/md0 on /boot type ext3 (rw,noexec,nosuid,nodev,noatime,acl,user_xattr)
/dev/md3 on /srv type ext3 (rw,nosuid,nodev,acl,user_xattr)
/dev/md6 on /tmp type ext3 (rw,nosuid,nodev,acl,user_xattr)
/dev/md2 on /usr type ext3 (rw,nodev,noatime,acl,user_xattr)
/dev/md4 on /usr/local type ext3 (rw,nosuid,nodev,noatime,acl,user_xattr)
/dev/md5 on /var type ext3 (rw,acl,user_xattr)
/srv/home on /home type none (rw,bind)
/srv/home on /srv/chroots/sid-i386/home type none (rw,bind)
/tmp on /srv/chroots/sid-i386/tmp type none (rw,bind)
/dev on /srv/chroots/sid-i386/dev type none (rw,bind)
/media on /srv/chroots/sid-i386/media type none (rw,bind)
/usr/src on /srv/chroots/sid-i386/usr/src type none (rw,bind)
proc on /srv/chroots/sid-i386/proc type proc (rw)
sysfs on /srv/chroots/sid-i386/sys type sysfs (rw)
tunes:/srv/music on /srv/music type nfs
(rw,rsize=8192,wsize=8192,hard,mountport=730,addr=192.168.14.1)
automount(pid4379) on /wg type autofs (rw,fd=4,pgrp=4379,minproto=2,maxproto=4)
root=/dev/md1
rootfs=auto
--
.''`. martin f. krafft [EMAIL PROTECTED]
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
aus der kriegsschule des lebens -
was mich nicht umbringt, macht mich härter.
- friedrich nietzsche
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#440694: initramfs-tools: hook-functions:dep_add_modules() breaks with /dev/md/x device names
also sprach Mario 'BitKoenig' Holbe [EMAIL PROTECTED] [2007.09.03.2147 +0200]: [ please use reportbug in furture it adds important info ] ...and add python to my system... grrr :) Write yourself a shell replacement then. See #440712: v1-style naming is currently not supported by Debian's mdadm because I lack the time to implement it, especially since it would take considerably longer given how inconsistent upstream does stuff. If you want to take a stab, please do. I'll try to help you with anything I can. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] wickedness is a myth invented by good people to account for the curious attraction of others. -- oscar wilde spamtraps: [EMAIL PROTECTED] digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#440694: initramfs-tools: hook-functions:dep_add_modules() breaks with /dev/md/x device names
also sprach maximilian attems [EMAIL PROTECTED] [2007.09.04.1850 +0200]: However... no offense meant, just as strategic hint: please don't do the mistake and consider /dev/md/ style names as old way or old fashioned, since exactly the opposite is the case: Neil (md, mdadm developer) considers them the new way and fashion :) any pointer to a statement on that topic? i don't have one, but this squares with what I remember Neil saying. He wants to get rid of /dev/mdX and promote /dev/md/* and I agree with him. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#433905: closed by martin f krafft [EMAIL PROTECTED] (Re: Bug#433905: initramfs-tools: Boot failure from software-RAID1 with debian on nslu2)
also sprach Frans Pop [EMAIL PROTECTED] [2007.07.21.1131 +0200]: I'm tempted to reopen this bug report. Manually adding the rootdelay parameter is all very nice as a workaround for this issue, but is it really an adequate solution? How can we expect users to know that such an option is required? How can we make sure in the installer that a first boot does not fail if a user does a RAID install? Adding rootdelay=x by default for all mdadm (and crypto, and lvm?) installs does not seem like an attractive option. There must surely be better ways to deal with this issue? Probably, I'd love the hear one or even a patch! Since I have no setup in which to confirm the bug, I'll have a hard time creating a fix. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems licht wird alles, was ich fasse - friedrich nietzsche signature.asc Description: Digital signature (GPG/PGP)
Bug#433905: closed by martin f krafft [EMAIL PROTECTED] (Re: Bug#433905: initramfs-tools: Boot failure from software-RAID1 with debian on nslu2)
also sprach Toon Verstraelen [EMAIL PROTECTED] [2007.07.21.0754 +0200]: I do know what the rootdelay is meant to do. The initramfs scripts assume a default value of 180 seconds, so one does not have to pass it explicitly at the kernel command line. That is clearly not the problem. Have you even bothered to try it? The default value for rootdelay is *not* 180. It waits for 180 seconds for the root filesystem if rootdelay has not been specified. But udev also sleeps for $rootdelay seconds *before* mdadm is called, so there will be plenty time for the driver to create the usb-storage-SCSI devices. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems Most Intelligent Customers Realise Our Software Only Fools Them. signature.asc Description: Digital signature (GPG/PGP)
Bug#426941: cannot set default locale
tags 426941 unpreproducible thanks The problem has since fixed itself. Sorry, I failed to capture more information when I encountered it. Feel free to close. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems whoever fights monsters should see to it that in the process he does not become a monster. and when you look into an abyss, the abyss also looks into you. - friedrich nietzsche signature.asc Description: Digital signature (GPG/PGP)
Bug#426548: bug in i810 X driver, fixed upstream
reassign 426548 xserver-xorg-video-intel
retitle 426548 BIOS timing issues cause hard freeze with i855 chips
tags 426548 fixed-upstream patch
thanks
I believe this issue had to do with a timing issue, which Keith
Packard fixed as follows:
diff --git a/src/i830_display.c b/src/i830_display.c
index 6965337..ce20864 100644
--- a/src/i830_display.c
+++ b/src/i830_display.c
@@ -361,8 +361,10 @@ i830FindBestPLL(xf86CrtcPtr crtc, int target, int refclk,
intel_clock_t *best_cl
void
i830WaitForVblank(ScrnInfoPtr pScreen)
{
-/* Wait for 20ms, i.e. one cycle at 50hz. */
-usleep(2);
+/* Wait for 30ms, i.e. one cycle at slightly less than 50hz.
+ * THIS PATCHED BY KEITH
+ */
+usleep(3);
}
void
Also, commit fbbb41bc5e03478cb46ee8f64ef68b23ff3fc14b may be related:
Author: Keith Packard [EMAIL PROTECTED]
Date: Sun Jun 17 14:59:24 2007 +0100
Let DPMS functions enable plane/pipe/output on 8xx hardware.
On 855, letting crtc_mode_set enable the plane and pipe will occasionally
hang the chip. Instead, wait for crtc_enable to light things up. For 9xx,
leave things alone.
diff --git a/src/i830_display.c b/src/i830_display.c
index adc7479..6965337 100644
--- a/src/i830_display.c
+++ b/src/i830_display.c
@@ -958,11 +958,17 @@ i830_crtc_mode_set(xf86CrtcPtr crtc, DisplayModePtr mode,
else
pipeconf = ~PIPEACONF_DOUBLE_WIDE;
}
-#if 1
-dspcntr |= DISPLAY_PLANE_ENABLE;
-pipeconf |= PIPEACONF_ENABLE;
-dpll |= DPLL_VCO_ENABLE;
-#endif
+/*
+ * This shouldn't be needed as the dpms on code
+ * will be run after the mode is set. On 9xx, it helps.
+ * On 855, it can lock up the chip (and the entire machine)
+ */
+if (IS_I9XX (pI830))
+{
+ dspcntr |= DISPLAY_PLANE_ENABLE;
+ pipeconf |= PIPEACONF_ENABLE;
+ dpll |= DPLL_VCO_ENABLE;
+}
/* Disable the panel fitter if it was on our pipe */
if (i830_panel_fitter_pipe (pI830) == pipe)
--
.''`. martin f. krafft [EMAIL PROTECTED]
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
signature.asc
Description: Digital signature (GPG/PGP)
