Bug#535331: ditto
On Fri, Oct 23, 2009 at 11:54:21AM +0200, Josip Rodin wrote: I've experienced the same problem. I've got two lenny machines which have [...] FWIW Here's the last upgrade output pasted exactly as it just happened: % sudo apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: linux-image-2.6.26-2-686 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 20,2MB of archives. After this operation, 0B of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://security.debian.org lenny/updates/main linux-image-2.6.26-2-686 2.6.26-19lenny2 [20,2MB] Fetched 20,2MB in 21s (929kB/s) Preconfiguring packages ... (Reading database ... 24703 files and directories currently installed.) Preparing to replace linux-image-2.6.26-2-686 2.6.26-19lenny1 (using .../linux-image-2.6.26-2-686_2.6.26-19lenny2_i386.deb) ... The directory /lib/modules/2.6.26-2-686 still exists. Continuing as directed. Done. Unpacking replacement linux-image-2.6.26-2-686 ... Setting up linux-image-2.6.26-2-686 (2.6.26-19lenny2) ... Running depmod. Running mkinitramfs-kpkg. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.26-19lenny1 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.26-19lenny1 was configured last, according to dpkg) % % sudo perl -pi -e 's,^(my \$loader\s+=\s+),$1lilo,' /var/lib/dpkg/info/linux-image-2.6.26-2-686.postinst % sudo dpkg-reconfigure linux-image-2.6.26-2-686 Running depmod. Running mkinitramfs-kpkg. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.26-19lenny2 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.26-19lenny2 was configured last, according to dpkg) You already have a LILO configuration in /etc/lilo.conf Running boot loader as requested Testing lilo.conf ... Testing successful. Installing the partition boot sector... Running /sbin/lilo ... Installation successful. % [...] after upgrading linux-image-2.6.26-2-686, I just get [...] FWIW it also happens on the amd64 version, exactly the same: % sudo apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: linux-image-2.6.26-2-amd64 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 20,9MB of archives. After this operation, 4096B of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://security.debian.org lenny/updates/main linux-image-2.6.26-2-amd64 2.6.26-19lenny2 [20,9MB] Fetched 20,9MB in 20s (1013kB/s) Preconfiguring packages ... (Reading database ... 20849 files and directories currently installed.) Preparing to replace linux-image-2.6.26-2-amd64 2.6.26-19lenny1 (using .../linux-image-2.6.26-2-amd64_2.6.26-19lenny2_amd64.deb) ... The directory /lib/modules/2.6.26-2-amd64 still exists. Continuing as directed. Done. Unpacking replacement linux-image-2.6.26-2-amd64 ... Setting up linux-image-2.6.26-2-amd64 (2.6.26-19lenny2) ... Running depmod. Running mkinitramfs-kpkg. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.26-19lenny1 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.26-19lenny1 was configured last, according to dpkg) % % sudo perl -pi -e 's,^(my \$loader\s+=\s+),$1lilo,' /var/lib/dpkg/info/linux-image-2.6.26-2-amd64.postinst % sudo dpkg-reconfigure linux-image-2.6.26-2-amd64 Running depmod. Running mkinitramfs-kpkg. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.26-19lenny2 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.26-19lenny2 was configured last, according to dpkg) You already have a LILO configuration in /etc/lilo.conf Running boot loader as requested Testing lilo.conf ... Testing successful. Installing the partition boot sector... Running /sbin/lilo ... Installation successful. % -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504805: and another....
Can I provide more information, or is there anything else I can do to help fix this? (XEN) domain_crash_sync called from entry.S (ff188600) (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) [ Xen-3.2-1 x86_32p debug=n Not tainted ] (XEN) CPU:0 (XEN) EIP:0061:[c01013a7] (XEN) EFLAGS: 0246 CONTEXT: guest (XEN) eax: ebx: 0001 ecx: edx: c0389fc8 (XEN) esi: edi: ebp: esp: c0389fbc (XEN) cr0: 8005003b cr4: 06f0 cr3: 001dec80 cr2: bfba0a10 (XEN) ds: 007b es: 007b fs: 00d8 gs: ss: 0069 cs: 0061 (XEN) Guest stack trace from esp=c0389fbc: (XEN)c0105f52 c05669bb 9b7f 0020 (XEN)c01028ab c0102810 0020 c20ee000 c038f88b c03ac580 0002080b (XEN) c038f5c3 c038f5cb c038f5d3 c0102374 c010263c c01027c8 c0102981 (XEN)c0102fd7 c0102ff8 c0103480 c0103520 c0103609 c0103a81 c0103b3d c0103bfa (XEN)c0103c59 c0103d03 c01042f9 c010430c c0104332 c010433f c01043db c0104999 (XEN)c0104a5c c010506c c01050ec c01051bc c0105ebf c0105eff c0105f58 c0106238 (XEN)c0106323 c010664a c0106a80 c0106be4 c039453d c0394546 c0108085 c0108093 (XEN)c0108108 c0108116 c0395faf c0395fc2 c01085ef c0108679 c010934c c0109547 (XEN)c0109572 c010957b c010985d c0109865 c010a3ae c010a425 c010a434 c010a468 (XEN)c010a4a2 c010a4ab c010a4b4 c02c5f1d c02c60c1 c02c6118 c02c6138 c02c62fe (XEN)c02c63c2 c02c67ea c03962cb c03962d3 c02c6d11 c0396429 c0396432 c039643b (XEN)c0396444 c0396453 c039645c c039646b c0396474 c02c6df1 c02c6e5a c02c6fbd (XEN)c02c7033 c02c708d c02c7093 c02c72d1 c02c7317 c02c738f c02c739f c02c741b (XEN)c02c742f c02c753c c02c754d c02c7554 c02c76d3 c02c7962 c02c7b49 c02c7b9a (XEN)c02c7c3a c02c7c3f c02c7c4d c02c7d80 c02c7d95 c02c7fea c02c8037 c02c80bf (XEN)c02c80e0 c02c81c7 c02c81d6 c02c81e5 c02c8206 c02c8215 c010b59e c010b5c7 (XEN)c010b5ef c010bbad c010bbe0 c010bc47 c010bc9d c010bccf c010bd07 c010bd91 (XEN)c010be10 c010be59 c010c0e7 c039753b c039755e c039798f c010ce93 c010de56 (XEN)c039867c c03986a3 c0398797 c0398a78 c010e3f9 c010f656 c010fec4 c0110fb9 (XEN)c0110fc3 c0ba c0c4 c01116a8 c0111a69 c0111ab0 c0111b39 c0111cba (XEN) Domain 0 crashed: 'noreboot' set - not rebooting. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: reassign 554793 to watchdog
Processing commands for cont...@bugs.debian.org: reassign 554793 watchdog Bug #554793 [linux-image-2.6.26-2-amd64] linux-image-2.6.26-2-amd64: ipmi_watchdog module frequently returns errno=16 - Device or resource busy on Dell Poweredge 860s Bug reassigned from package 'linux-image-2.6.26-2-amd64' to 'watchdog'. Bug No longer marked as found in versions 2.6.26-17lenny1. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554793: linux-image-2.6.26-2-amd64: ipmi_watchdog module frequently returns errno=16 - Device or resource busy on Dell Poweredge 860s
On Fri, 2009-11-06 at 16:00 +, Tim Small wrote: Package: linux-image-2.6.26-2-amd64 Version: 2.6.26-17lenny1 Severity: normal Opening /dev/watchdog as provided by ipmi_watchdog on a Dell PowerEdge 860 running Lenny 5.0 (64 bit), frequently fails with EBUSY. Nov 5 11:50:09 kernel: [ 29.583805] IPMI Watchdog: driver initialized Nov 5 11:50:12 watchdog[3239]: starting daemon (5.4): Nov 5 11:50:12 watchdog[3239]: int=10s realtime=yes sync=no soft=no mla=0 mem=140733193388032 [...] Nov 5 11:50:12 watchdog[3239]: test=none(0) repair=none alive=/dev/watchdog heartbeat=none temp=none to=root no_act=no Nov 5 11:50:12 watchdog[3239]: cannot open /dev/watchdog (errno = 16 = 'Device or resource busy') Nov 5 11:50:12 kernel: [ 57.375695] IPMI Watchdog: Unexpected close, not stopping watchdog worse, if the module is loaded with the nowayout=1 - the machine then gets hard-reset timeout seconds later! The watchdog device cannot be closed if it was not successfully opened. This is a problem with the watchdog daemon. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou signature.asc Description: This is a digitally signed message part
Processed: closing 552472
Processing commands for cont...@bugs.debian.org: # updating all initramfs costs too much time and is useless risk close 552472 Bug#552472: cryptsetup: dpkg-trigger only rebuilds initramfs for the running kernel 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to Thiemo Nagel thiemo.na...@ph.tum.de End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: bug 553067 is forwarded to http://bugzilla.kernel.org/show_bug.cgi?id=14496
Processing commands for cont...@bugs.debian.org: forwarded 553067 http://bugzilla.kernel.org/show_bug.cgi?id=14496 Bug #553067 [linux-2.6] linux-image-2.6.31-trunk-686: uvcvide camera does not work anymore Set Bug forwarded-to-address to 'http://bugzilla.kernel.org/show_bug.cgi?id=14496'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509441: marked as done (computer locks up during down-load)
Your message dated Sun, 8 Nov 2009 00:18:57 +0100 with message-id 20091107231857.ga3...@galadriel.inutil.org and subject line Re: Bug#509441: computer locks up during down-load has caused the Debian Bug report #509441, regarding computer locks up during down-load to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 509441: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509441 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: ppp Version: 2.4.4rel-8 Computer fails to respond to mouse, keyboard, and even to CtrlAltDel when attempting to download a web page e.g. http://www.uk.debian.org/ . I am trying to get Etch to run in an old computer, which has about 361 Mega-bytes of SDRAM. It uses an external modem to dial into an ISP. It uses a simple shel script which calls pon, I attach a copy of the shell script, and a copy of the called file. The bugs appears when that ISP is Entanet using dial in number 0845 6040104. It seem to dial in successfully, I attach a copy of the ppp dialogue. However, then I tried to use Epiphany to download a web page e.g. http://www.uk.debian.org/ . The system downloaded some of the page, and displayed as much as would fit in the window. The computer then did not respond to any of the controls -- keyboard, mouse. It just froze, or locked-up. Eventually the OH light on the modem went out, I took this as my cue to push the power switch, and hold it in, till it switched off the power. I tried several times with variations. first using Iceweasel; then Iceweasel and squid; then wget. Iceweasel, with or without squid, caused the computer to lock up. Wget sometimes caused it to lock up. Downloading a smaller webpage instead usually worked, except that the pictures did not get displayed. Workaround; I tried using various different ISPs, system worked with all of these others. Knoppix version 5.1.1 live CD, running in the same hardware works, even on the Entanet dial up line, but slowly. versions; I attach a list of versions of some of the packages in my system. It is Etch as installed plus a few Etch packages which were not installed as default. These were all updated by aptitude update, and then aptitude upgrade on 20 December 2008. I attach output from reportbug, which seems to contain at least one error (from address). Thank you very much for providing ppp. Best regards Richard Betham ii ppp2.4.4rel-8 Point-to-Point Protocol (PPP) daemon ii pppconfig 2.3.15.etch1 A text menu based utility for configuring pp ii base-files 4 Debian base system miscellaneous files ii libpam-modules 0.79-5 Pluggable Authentication Modules for PAM ii libpam-runtime 0.79-5 Runtime support for the PAM library ii libpam0g 0.79-5 Pluggable Authentication Modules library ii libcap11.10-14support for getting/setting POSIX.1e capabilities ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libc6-i686 2.3.6.ds1-13etch5 GNU C Library: Shared libraries [i686 optimi ii linux-image-2.6-k7 2.6.18+6etch3 Linux kernel 2.6 image on AMD K7 ii linux-image-2.6.18-6-k7 2.6.18.dfsg.1-23etch1 Linux 2.6.18 image on AMD K7 ii kdm3.5.5a.dfsg.1-6etch2 X display manager for KDE Entanet6.sh Description: application/shellscript # This optionfile was generated by pppconfig 2.3.15. # # hide-password noauth connect /usr/sbin/chat -v -f /etc/chatscripts/Entanet6 debug /dev/ttyS0 115200 defaultroute noipdefault user jubileeweb ipparam Entanet6 usepeerdns idle 600Sat Dec 20 20:32:17 GMT 2008 Serial connection established. using channel 1 Using interface ppp0 Connect: ppp0 -- /dev/ttyS0 sent [LCP ConfReq id=0x1 asyncmap 0x0 magic 0x4c7ddae5 pcomp accomp] rcvd [LCP ConfReq id=0x1 asyncmap 0xa auth chap MD5 magic 0x844dfb9b pcomp accomp mrru 1524 endpoint [local:42.54.4d.44.49.50]] sent [LCP ConfRej id=0x1 mrru 1524] rcvd [LCP ConfReq id=0x2 asyncmap 0xa auth chap MD5 magic 0x844dfb9b pcomp accomp endpoint [local:42.54.4d.44.49.50]] sent [LCP ConfAck id=0x2 asyncmap 0xa auth chap MD5 magic 0x844dfb9b pcomp accomp endpoint [local:42.54.4d.44.49.50]] sent [LCP ConfReq id=0x1 asyncmap 0x0 magic 0x4c7ddae5 pcomp accomp] rcvd [LCP ConfAck id=0x1 asyncmap 0x0 magic 0x4c7ddae5 pcomp accomp] sent [LCP EchoReq id=0x0 magic=0x4c7ddae5] rcvd [CHAP Challenge id=0x1 4b4c283cd7222792e0c032b21eeb7e4a, name = BTMDIP] sent [CHAP Response id=0x1 483ef642a3082bcacd81cd1c5a68039b, name = jubileeweb] rcvd [LCP EchoRep id=0x0 magic=0x844dfb9b] rcvd [CHAP
Bug handling policy [2nd draft]
This incorporates all the comments, I think. I'll take further comments on this draft until 14th November, then consider this final if no-one objects. Ben. --- 1. Required information Submitters are expected to run reportbug or other tool that runs our 'bug' script under the kernel version in question. The response to reports without this information should be a request to follow-up using reportbug. If we do not receive this information within a month of the request, the bug may be closed. Exceptions: * If the kernel does not boot or is very unstable, instead of the usual system information we need the console messages via netconsole, serial console, or a photograph. * If the report is relaying information about a bug acknowledged upstream, we do not need system information but we do need specific references (bugzilla.kernel.org or git commit id). * If the bug is clearly not hardware-specific (e.g. packaging error), we do not need system information. * If the bug is reported against a well-defined model, we may not need device listings. 2. Severities Many submitters report bugs with the wrong severity. We interpret the criteria as follows and will adjust severity as appropriate: 'critical: makes unrelated software on the system (or the whole system) break...' The bug must make the kernel unbootable or unstable on common hardware or all systems that a specific flavour is supposed to support. There is no 'unrelated software' since everything depends on the kernel. 'grave: makes the package in question unusable or mostly so...' If the kernel is unusable, this already qualifies as critical. 'grave: ...or causes data loss...' We exclude loss of data in memory due to a crash. Only corruption of data in storage or communication, or silent failure to write data, qualifies. important We include lack of support for new hardware that is generally available. 3. Tagging We do not use user-tags. In order to aid bug triage we should make use of the standard tags and 'forwarded' field defined by the BTS. In particular: * Add 'moreinfo' whenever we are waiting for a response from the submitter and remove it when we are not * Do not add 'unreproducible' to bugs that may be hardware-dependent 4. Analysis by maintainers Generally we should not expect to be able to reproduce bugs without having similar hardware. We should consider: * Searching bugzilla.kernel.org (including closed bugs) or other relevant bug tracker * Searching kernel mailing lists - Of the many archives, http://news.gmane.org seems to suck least - Patches submitted to some lists are archived at http://patchwork.kernel.org/ * Viewing git commit logs for relevant source files - In case of a regression, from the known good to the bad version - In other cases, from the bad version forwards, in case the bug has been fixed since * Searching kerneloops.org for similar oopses * Matching the machine code and registers in an 'oops' against the source and deducing how the impossible happened (this doesn't work that often but when it does you look like a genius ;-) 5. Testing by submitter Depending on the technical sophistication of the submitter and the service requirements of the system in question (e.g. whether it's a production server) we can request one or more of the following: * Gathering more information passively (e.g. further logging, reporting contents of files in procfs or sysfs) * Upgrading to the current stable/stable-proposed-updates/ stable-security version, if it includes a fix for a similar bug * Adding debug or fallback options to the kernel command line or module parameters * Installing the unstable or backports version temporarily * Rebuilding and installing the kernel with a specific patch added (the script debian/bin/test-patches should make this easy) * Using 'git bisect' to find a specific upstream change that introduced the bug When a bug occurs in what upstream considers the current or previous stable release, and we cannot fix it, we ask the submitter to report it upstream at bugzilla.kernel.org under a specific Product and Component, and to tell us the upstream bug number. We do not report bugs directly because follow-up questions from upstream need to go to the submitter, not to us. Given the upstream bug number, we mark the bug as forwarded. bts-link then updates its status. 6. Keeping bugs separate Many submitters search for a characteristic error message and treat this as indicating a specific bug. This can lead to many 'me too' follow-ups where, for example, the message indicates a driver bug and the second submitter is using a different driver from the original submitter. In order to avoid the report turning into a mess of conflicting information about two or more different bugs: * We should try to respond to such a follow-up quickly, requesting a separate bug report * We can use the BTS 'summary' command to improve the
Re: Re: Building vanilla kernel .debs
On Sun, Oct 18, 2009 at 22:21:00 +0200, maximilian attems wrote: On Sun, Oct 18, 2009 at 09:53:58PM +0200, Marc Haber wrote: snippage Is there any documentation about which features are available? not yet, as currently it is dead simple, but in the work indeed. On build it respects DEBEMAIL and DEBFULLNAME for changelog and control file generation. If firmware is also build you get a seperated firmware package. On install eventual hook scripts in /etc/kernel will be executed. For this to be a make-kpkg replacement, I'd need the possibility to run the actual build process as non-root user while using fakeroot to build the .deb, done in linux-next kbuild tree heading for 2.6.33. append a string to the version number and a debian revision. if you set KDEB_PKGVERSION you can set both, the debian revision is controled by .version. Just found this thread and tried it. What I see I like, makes things nice and simple. BUT - is there any way to generate a header-package? Doc package would be nice as well, although not as critical. I can easily live without that. I really need a header package though. I often remove the source tree, or modify it, after compiling a kernel. TIA -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
