Re: 2.6.14 status summary, and upcoming 2.6.15 ...
On Sun, Nov 27, 2005 at 07:15:22PM -0500, Kyle McMartin wrote: On Mon, Nov 28, 2005 at 12:13:50AM +0100, Sven Luther wrote: Anyway, i will start with the powerpc situation : parisc: - klibc will work after this patch is applied: http://www.zytor.com/pipermail/klibc/2005-November/001174.html - I haven't (and won't for the next month) have time to do anything, as exams are underway. - parisc patchset is mostly merged in 2.6.15-rc2 Cheers, Kyle thanks i got this patch and i plan to upload parisc fixed klibc early this week. currently waiting for a patch from svenl to build against linux-kernel-headers, status? a++ -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.4.27-12 for Sid
On Sun, Nov 27, 2005 at 11:13:33PM -0500, Joey Hess wrote: Horms wrote: Holger kindly reminded me on IRC yesterday that its been a long time since a new 2.4.27 was uploaded into Sarge. He pointed out that there are a number of valuable fixes in SVN. Is there any reason why you're sticking with 2.4.27+patches rather than following the 2.4 series upstream? Seems to this uninformed observer Because 2.4.27+patches is the less work path for a kernel which is aimed at going away before the etch release anyway, and this is as much effort as Horms is ready to invest in this, given that it is work already done for the sarge security upgrades anyway. In a way, our 2.4 kernels are nothing more than forward ports of the sarge kernels. like it might be less work to follow upstream since it's limited to security fixes, serious bug fixes, and driver backports, assuming merging with it isn't too much work. Since the work is already done for sarge ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#341014: broken with udev 0.76
Processing commands for [EMAIL PROTECTED]: tags 341014 pending Bug#341014: broken with udev 0.76 There were no tags set. Tags added: pending stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341014: broken with udev 0.76
tags 341014 pending stop On Sun, Nov 27, 2005 at 08:05:35PM +0100, Heikki Henriksen wrote: udev 0.76 failed to queue events correctly and didn't populate /dev at all using initramfs-tools. I only got a /dev/.udev/failed. urggs indeed, will need another high urgency upload, will do this afternoon. No devices in /dev lead to failure to find root and no boot. initramfs-tools 0.40 works with udev 0.74, for 0.76 we need to invoke it differently. fix was discussed with udev Maintainer and is on its way. To get up and running again I had to build a new initrd on a remote system and copy it over using a live-cd. yaird seems to have no problems with the same kernel (2.6.14-2-k7) and udev (0.76-2) baah sorry for that mess. in the middle term udev initramfs-tools hooks will be maintained by the udev maintainer so we shouldn't run that badly out of sync. regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
On Mon, Nov 28, 2005 at 04:12:34AM +0100, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please, Sven, do not cc me: I am subscribed to the kernel list! On Mon, 28 Nov 2005 02:48:01 +0100 Sven Luther [EMAIL PROTECTED] wrote: On Mon, Nov 28, 2005 at 02:23:32AM +0100, Jonas Smedegaard wrote: On Mon, 28 Nov 2005 00:13:50 +0100 Sven Luther [EMAIL PROTECTED] wrote: Jonas, maybe you would feel like adding a wiki page with the arch status or something ? Sorry - I don't understand - what do you want different from the arch status notes on http://wiki.debian.org/InitrdReplacementOptions ? What i really like is a summary of any remaining showstoppers for not moving 2.6.14-4 kernels to testing, from a yaird perspective. Well, from a yaird+initramfs-tools perspective probably. Ah, so it is same thing as your earlier request for filing bugreports against linux-2.6 for each unknown hardware combinations and have the ramdisk tools close those as the hardware gets tested. I cannot do that task: It is a too big job for me! Nope, i am asking you for a few lines of situation report of yaird, is that so difficult ? The point is to ensure that no users are left out in the cold with no upgrade path and a broken kernel if we do so. What about 328534 for example, altough i suppose this one is mergeable with the other dpt_io bug. I was tempted to reassign a clone thereof to yaird + initramfs-tools. Yaird only by default supports drivers using sysfs. I suspect that the issue of bug#328534 is a driver module not properly using sysfs. And I guess the workaround is simply to add it manually to /etc/yaird/Default.cfg. But it is pure speculation - I'd really want Erik's opinion. What is strange is that the module apparently gets added when manually added to Default.cfg, but still no devices are created. So if workarounds like the driver for your hardware is currently too limited for automated recognition using yaird, so you need to manually edit the config file for your hardware to work, or try initramfs-tools is considered left out in the cold then bug#328534 is a showstopper. And it would require a big chart of all kernel modules for harddisk controller (for each arch?) to make sure that no user would be left in such situation. Well, do we have a workaround ? I mean, people will apt-get upgrade and automatically get yaird and the 2.6.14 kernel pulled in, and not only will the next reboot not work, but possibly there will be no way to bring the box alive again. This is the kind of situation which i believe showstoppers. If there is a workaround, we could put out a errata list of the problems and possible workarounds and stuff. BTW, also, about ia64 situation, is it possible to use yaird in initrd case still ? I know Eric was disabling this for 0.12, but we are still using 0.11 ? Yaird 0.0.11 is newest release - so it _will_ be removed but _was_ not yet. Ok, so, what would be the best way to generate an initrd on ia64, and someone with ia64 hardware, can you test that ? We can put this bug report on yaird 0.0.12 once it is out, or something. It is deprecated due to lack of testing. So if someone starts testing it then Erik might get convinced to keep it: Replace /etc/yaird/Templates.cfg with /usr/share/doc/yaird/examples/Debian-initrd.cfg.gz gunzipped should do the trick. Ok, but we really need a way to automatically set yaird to initrd on ia64, maybe by a postinst editing Templates.cfg or something ? Dannf, or someone with ia64 hardware, can you please test that ? Friendly, Sven Luther - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDinWin7DbMsAkQLgRAhNiAJ0T70pa4UOBZN3WXQtJG59dGJ5Z/gCgosFr YpOPS+TmLMzTGlKsEClcl8o= =386X -END PGP SIGNATURE- --- Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
On Mon, Nov 28, 2005 at 09:53:11AM +0100, Marco d'Itri wrote: [EMAIL PROTECTED] wrote: Marco what about udev ? Nothing to report, except a few packaging bugs it has been working well. When 2.6.15 will be in testing I will raise the required kernel version to 2.6.15 to have proper support for the input subsystem and in-kernel uevents synthesis. Well, i saw passing a couple of reports about the ramdisk not creating needed devices, which sound RCish for this case, what about those ? Also, more importantly, what are the bugs closed in the unstable udev, but open in the testing one, which will be the one used once 2.6.14 goes to testing. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 341076 to linux-2.6
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.8.14 reassign 341076 linux-2.6 Bug#341076: linux-image-2.6.14-2-smp: Kernel crashes on boot with hyperthreading cpus Warning: Unknown package 'linux-image-2.6.14-2-smp' Bug reassigned from package `linux-image-2.6.14-2-smp' to `linux-2.6'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
On Mon, Nov 28, 2005 at 09:04:59AM +0100, Maximilian Attems wrote: On Sun, Nov 27, 2005 at 07:15:22PM -0500, Kyle McMartin wrote: On Mon, Nov 28, 2005 at 12:13:50AM +0100, Sven Luther wrote: Anyway, i will start with the powerpc situation : parisc: - klibc will work after this patch is applied: http://www.zytor.com/pipermail/klibc/2005-November/001174.html - I haven't (and won't for the next month) have time to do anything, as exams are underway. - parisc patchset is mostly merged in 2.6.15-rc2 Cheers, Kyle thanks i got this patch and i plan to upload parisc fixed klibc early this week. currently waiting for a patch from svenl to build against linux-kernel-headers, status? Nope, sorry, i had no real time to investigate this more than i did, and my tests didn't work out because of the asm-powerpc symlink farm breakage. I believe that l-k-h needs to be setup to use another newer kernel headers, or better yet use the same kernel libc project headers as ubuntu uses, altough jbailey reported having build klibs with and older kernels (2.6.12 or something such). not sure what influence the pure64 patch from Andreas Jochens has on this, but i guess it confuses the issue more. My own testing where hurt by the ARCH=powerpc header migration, which is now fixed in 2.6.14-4, and i only need to find time for it again. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: your mail
Processing commands for [EMAIL PROTECTED]: reassign 341049 initramfs-tools 0.40 Bug#341049: linux-image-2.6.14-2-686: Doesn't boot (/dev/hda1 does not exist) Bug reassigned from package `linux-image-2.6.14-2-686' to `initramfs-tools'. merge 341014 341049 Bug#341014: broken with udev 0.76 Bug#341049: linux-image-2.6.14-2-686: Doesn't boot (/dev/hda1 does not exist) Mismatch - only Bugs in same state can be merged: Values for `severity' don't match: #341014 has `grave'; #341049 has `normal' thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 28 Nov 2005 11:21:45 +0100 Sven Luther [EMAIL PROTECTED] wrote: On Mon, Nov 28, 2005 at 04:12:34AM +0100, Jonas Smedegaard wrote: Ah, so it is same thing as your earlier request for filing bugreports against linux-2.6 for each unknown hardware combinations and have the ramdisk tools close those as the hardware gets tested. I cannot do that task: It is a too big job for me! Nope, i am asking you for a few lines of situation report of yaird, is that so difficult ? No, that's tedious - difficult part was to understand your request :-) The following problems are known for yaird currently in sid: * Does not work on alpha and ia64. * Needs test on arm, hppa, m68k, mips, mipsel and sh. * Possibly works after manual editing config files on s390. * Does not work with EVMS, loopaes, IEEE1394, dmraid and swsusp. * Works after manual editing config files with rootfs on NFS and (badly!) with swsusp2. * fstab labels works only on ext2 and reiser. * crypsetup-luks not tested recently. * Needs test with usb-stick. * Works only with drivers supporting sysfs. This is all from the wiki page[1], which has more details for some of of the items. So if workarounds like the driver for your hardware is currently too limited for automated recognition using yaird, so you need to manually edit the config file for your hardware to work, or try initramfs-tools is considered left out in the cold then bug#328534 is a showstopper. And it would require a big chart of bug#all kernel modules for harddisk controller (for each arch?) to make sure that no user would be left in such situation. Well, do we have a workaround ? I mean, people will apt-get upgrade and automatically get yaird and the 2.6.14 kernel pulled in, We do not have _automated_ workarounds, which it seems you imply and I clearly didn't above. not only will the next reboot not work, but possibly there will be no way to bring the box alive again. Well, for yaird I believe most errors causes the kernel installation to fail. Only yaird problem I know of leading to problems booting (and brick'ing if using bootloaders with no alternative) is with drivers that does not support sysfs. We do not have an overview of the size of that problem. Can someone dig out such info from the kernel source itself? Or perhaps on the net somewhere is a status page of driver sysfs support? If there is a workaround, we could put out a errata list of the problems and possible workarounds and stuff. ...that's what Erik wants to do as well for the non-sysfs supported hardware. I am not ahead of him, and I don't think such list exist yet. we really need a way to automatically set yaird to initrd on ia64, maybe by a postinst editing Templates.cfg or something ? I believe we really need ia64 to support initramfs, no? - Jonas [1] http://wiki.debian.org/InitrdReplacementOptions - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDiu3mn7DbMsAkQLgRAkfmAJ4q0rqqpMLwK7xO4UOx8qncOzMhywCeNgyA 8KphewWHk8IiUIJ5V45qWm0= =+CXQ -END PGP SIGNATURE-
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
On Monday 28 November 2005 12:45, Jonas Smedegaard wrote: The following problems are known for yaird currently in sid: Add: * Does not work for drivers that don't have sysfs support, like BusLogic We do not have _automated_ workarounds, which it seems you imply and I clearly didn't above. Manual workarounds are not always possible. In a lot of cases manual workarounds are fine for upgrades, but they are impractical to say the least for new installations. Every case where a manual workaround is needed is one that makes yaird less attractive for use in Debian Installer. Only yaird problem I know of leading to problems booting (and brick'ing if using bootloaders with no alternative) is with drivers that does not support sysfs. We do not have an overview of the size of that problem. Correct. It would be very nice if that could be investigated. IMHO it should not be too hard to write a yaird module that checks if modules that don't support sysfs are loaded on the running system and, if that is the case, adds them to the initrd. If there is a workaround, we could put out a errata list of the problems and possible workarounds and stuff. ...that's what Erik wants to do as well for the non-sysfs supported hardware. I am not ahead of him, and I don't think such list exist yet. Again, this is not really a solution for new installations. pgpXVOf7twCph.pgp Description: PGP signature
Processed: your mail
Processing commands for [EMAIL PROTECTED]: severity 341049 grave Bug#341049: linux-image-2.6.14-2-686: Doesn't boot (/dev/hda1 does not exist) Severity set to `grave'. merge 341014 341049 Bug#341014: broken with udev 0.76 Bug#341049: linux-image-2.6.14-2-686: Doesn't boot (/dev/hda1 does not exist) Merged 341014 341049. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
Thanks Jonas for your detailed report. On Mon, Nov 28, 2005 at 01:24:34PM +0100, Frans Pop wrote: On Monday 28 November 2005 12:45, Jonas Smedegaard wrote: The following problems are known for yaird currently in sid: Add: * Does not work for drivers that don't have sysfs support, like BusLogic We do not have _automated_ workarounds, which it seems you imply and I clearly didn't above. Manual workarounds are not always possible. In a lot of cases manual workarounds are fine for upgrades, but they are impractical to say the least for new installations. Every case where a manual workaround is needed is one that makes yaird less attractive for use in Debian Installer. Yeah, but those are issues that will be fixed before the etch release, and also we have to take into account the case where initramfs-tools is not possible (like the ia64 case and its lake of initramfs support). If there is a workaround, we could put out a errata list of the problems and possible workarounds and stuff. ...that's what Erik wants to do as well for the non-sysfs supported hardware. I am not ahead of him, and I don't think such list exist yet. Again, this is not really a solution for new installations. No, but is important to diagnose the problems and see where there is work needed yet or not. And more importantly, to help us decide whether we can push 2.6.14 into testing, or preferably keep it out of it and kill 2.6.14 in favour of 2.6.15. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.4.27-12 for Sid
Hi, On Monday 28 November 2005 10:05, Sven Luther wrote: ... for a kernel which is aimed at going away before the etch release anyway... I don't think this is true (for debian as a whole). Sorry. Removing 2.4 is not a etch release goal as defined by the release managers. And it's also neither necessary nor particular useful as 2.6 still lacks some features 2.4 has: some hardware is only supported in 2.4, some firewall related features are only in 2.4 (atm). Maybe there is even more... Joeyh wrote: like it might be less work to follow upstream since it's limited to security fixes, serious bug fixes, and driver backports, assuming merging with it isn't too much work. Ack. I've made up my mind and decided that I'l do (or try to do :-P) the work needed for bringing 2.4.32 in debian. Help is certainly welcome. I'll publish my results as soon as I have some. regards, Holger P.S.: I'm subscribed to -kernel now. cc'ed Joey as I dont know if he is.. pgpQvEuthrzDP.pgp Description: PGP signature
Bug#341104: linux-patch-debian-2.6.14: dropping EXTRAVERSION from official kernel patches
Package: linux-patch-debian-2.6.14 Version: 2.6.14-4 Severity: minor Hello, I've just compiled a new kernel from linux-patch-debian-2.6.14_2.6.14-4_all.deb, and I noticed this includes the official patches 2.6.14.1 up to 2.6.14.3, except from the extraversion. So, by default the new kernel will be called vmlinuz-2.6.14, possibly overriding a previous 2.6.14. Furthermore, it is difficult to tell which version you run exactly. The fix is to run make-kpkg as: make-kpkg --added-patches debian --append-to-version .3 kernel-image modules-image Is there some good reason to drop the EXTRAVERSION from official patches ? Why not keep it, or even modify it as something like .3-debian so that a 'uname -a' will make clear that the actual kernel is a 2.6.14, patched up to interim revision .3, and with specific debian patches ? Pascal Dupuis -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.3 Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Versions of packages linux-patch-debian-2.6.14 depends on: ii bash 3.0-17 The GNU Bourne Again SHell ii bzip2 1.0.2-10 high-quality block-sorting file co ii grep-dctrl2.6.7 Grep Debian package information ii patch 2.5.9-2Apply a diff file to an original linux-patch-debian-2.6.14 recommends no packages. -- no debconf information Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 28 Nov 2005 13:24:34 +0100 Frans Pop [EMAIL PROTECTED] wrote: On Monday 28 November 2005 12:45, Jonas Smedegaard wrote: The following problems are known for yaird currently in sid: Add: * Does not work for drivers that don't have sysfs support, like BusLogic Ahem - yes: On Mon, 28 Nov 2005 12:45:42 +0100 Jonas Smedegaard [EMAIL PROTECTED] wrote: * Works only with drivers supporting sysfs. We do not have _automated_ workarounds, which it seems you imply and I clearly didn't above. Manual workarounds are not always possible. In a lot of cases manual workarounds are fine for upgrades, but they are impractical to say the least for new installations. Every case where a manual workaround is needed is one that makes yaird less attractive for use in Debian Installer. I am aware of that: It is not a bug in yaird to rely on the kernel providing sysfs info - it's a design decision. And it's not a bug in the kernel to not provide sysfs info for all drivers - it's a transition phase. But the end result for Debian is that yaird may not be interesting to use by default. We may want a ramdisk tool which keeps its own lists of How the World Really Works, independent from the kernel. Initramfs-tools stores some such info on its own and relies on udev for other parts. Correct me if I am wrong in above summary... Only yaird problem I know of leading to problems booting (and brick'ing if using bootloaders with no alternative) is with drivers that does not support sysfs. We do not have an overview of the size of that problem. Correct. It would be very nice if that could be investigated. IMHO it should not be too hard to write a yaird module that checks if modules that don't support sysfs are loaded on the running system and, if that is the case, adds them to the initrd. I think it's more tricky than that: How to recognize if such module is relevant for mounting the rootfs or not (without a static list)? But I am not the expert - Erik is, so please file a bugreport and let him and other clever people judge sanity of such improvement :-) - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDiwBFn7DbMsAkQLgRAmt4AJ4xeaPlkgxHTXMkg3m8SsRThjxJUQCcCPrD G5Mct5MPWRrJVzJnftgOCu4= =AT/A -END PGP SIGNATURE-
Re: 2.4.27-12 for Sid
On Mon, Nov 28, 2005 at 02:08:24PM +0100, Holger Levsen wrote: Hi, On Monday 28 November 2005 10:05, Sven Luther wrote: ... for a kernel which is aimed at going away before the etch release anyway... I don't think this is true (for debian as a whole). Sorry. Removing 2.4 is not a etch release goal as defined by the release managers. Well, this is indeed the aim of the kernel team, and is indeed the thinking of Simon Horman, told repeteadly on irc and maybe onlist, but i guess you will prefer that he confirms this. Now, if additional external folk has time to invest in newer 2.4.x kernels, the more power for them, but the aim is indeed to preferably get those drivers and subarch-ports ported before the etch release. And it's also neither necessary nor particular useful as 2.6 still lacks some features 2.4 has: some hardware is only supported in 2.4, some firewall related features are only in 2.4 (atm). Maybe there is even more... If they can't find the effort to get the support done in 2.6 by now (2.6 has been out since 2/3 years), i doubt the support is very serious in the first place. Joeyh wrote: like it might be less work to follow upstream since it's limited to security fixes, serious bug fixes, and driver backports, assuming merging with it isn't too much work. Ack. I've made up my mind and decided that I'l do (or try to do :-P) the work needed for bringing 2.4.32 in debian. Help is certainly welcome. Cool. But as said, it needs to be done in the common kernel infrastructure, as for linux-2.4, but you know that already. I will contribute powerpc/nubus support there, as they are in the not-yet-supported-in-2.6 category, but then i doubt the patches will apply cleanly without work to anything beyond 2.4.27 anyway, so ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341104: linux-patch-debian-2.6.14: dropping EXTRAVERSION from official kernel patches
On Mon, Nov 28, 2005 at 02:04:12PM +0100, Pascal A. Dupuis wrote: Package: linux-patch-debian-2.6.14 Version: 2.6.14-4 Severity: minor Hello, I've just compiled a new kernel from linux-patch-debian-2.6.14_2.6.14-4_all.deb, and I noticed this includes the official patches 2.6.14.1 up to 2.6.14.3, except from the extraversion. So, by default the new kernel will be called vmlinuz-2.6.14, possibly overriding a previous 2.6.14. Furthermore, it is difficult to tell which version you run exactly. The fix is to run make-kpkg as: make-kpkg --added-patches debian --append-to-version .3 kernel-image modules-image Is there some good reason to drop the EXTRAVERSION from official patches ? Why not keep it, or even modify it as something like .3-debian so that a 'uname -a' will make clear that the actual kernel is a 2.6.14, patched up to interim revision .3, and with specific debian patches ? Please have a look at /proc/version, which should have all the info you need : Linux version 2.6.14-2-powerpc (Debian 2.6.14-3) ([EMAIL PROTECTED]) (gcc version 4.0.3 20051023 (prerelease) (Debian 4.0.2-3.sven.1)) #2 Thu Nov 10 11:55:12 UTC 2005 This is mine, for example, and you see that it is 2.6.14-2-powerpc official kernel built from debian source 2.6.14-3. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341104: linux-patch-debian-2.6.14: dropping EXTRAVERSION from official kernel patches
On Mon, Nov 28, 2005 at 02:55:13PM +0100, Sven Luther wrote: Linux version 2.6.14-2-powerpc (Debian 2.6.14-3) ([EMAIL PROTECTED]) (gcc version 4.0.3 20051023 (prerelease) (Debian 4.0.2-3.sven.1)) #2 Thu Nov 10 11:55:12 UTC 2005 This is mine, for example, and you see that it is 2.6.14-2-powerpc official kernel built from debian source 2.6.14-3. Sven, thank you for your reply. Mine reads: Linux version 2.6.14.3 () ([EMAIL PROTECTED]) (gcc version 4.0.2 (Debian 4.0.2-2)) #1 Mon Nov 28 12:39:26 CET 2005 So ... 1) the 2.6.14.3 is VERSION + the EXTRAVERSION I forced with make-kpkg 2) the debian source is empty The suggestion was also to avoid name clashes, i.e. linux-patch-debian-2.6.14_2.6.14-2_all.deb - applied on 2.6.14 linux-patch-debian-2.6.14_2.6.14-3_all.deb - applied on 2.6.14.2 linux-patch-debian-2.6.14_2.6.14-4_all.deb - applied on 2.6.14.3 thus, compiling with one of the three versions should not result each time in vmlinuz-2.6.14 but vmlinuz-2.6.14[.extraversion] Best regards Pascal Dupuis -- Dr. ir. Pascal Dupuis K. U. Leuven, ESAT/ELECTA (formerly ELEN): http://www.esat.kuleuven.ac.be/ Kasteelpark Arenberg, 10; B-3001 Leuven-Heverlee, Belgium Tel. +32-16-32 10 21 -- Fax +32-16-32 19 85 Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341104: linux-patch-debian-2.6.14: dropping EXTRAVERSION from official kernel patches
On Mon, Nov 28, 2005 at 04:49:10PM +0100, Pascal A. Dupuis wrote: On Mon, Nov 28, 2005 at 02:55:13PM +0100, Sven Luther wrote: Linux version 2.6.14-2-powerpc (Debian 2.6.14-3) ([EMAIL PROTECTED]) (gcc version 4.0.3 20051023 (prerelease) (Debian 4.0.2-3.sven.1)) #2 Thu Nov 10 11:55:12 UTC 2005 This is mine, for example, and you see that it is 2.6.14-2-powerpc official kernel built from debian source 2.6.14-3. Sven, thank you for your reply. Mine reads: Linux version 2.6.14.3 () ([EMAIL PROTECTED]) (gcc version 4.0.2 (Debian 4.0.2-2)) #1 Mon Nov 28 12:39:26 CET 2005 So ... 1) the 2.6.14.3 is VERSION + the EXTRAVERSION I forced with make-kpkg 2) the debian source is empty The suggestion was also to avoid name clashes, i.e. linux-patch-debian-2.6.14_2.6.14-2_all.deb - applied on 2.6.14 linux-patch-debian-2.6.14_2.6.14-3_all.deb - applied on 2.6.14.2 linux-patch-debian-2.6.14_2.6.14-4_all.deb - applied on 2.6.14.3 thus, compiling with one of the three versions should not result each time in vmlinuz-2.6.14 but vmlinuz-2.6.14[.extraversion] This is some magic Bastian Blank played with, Bastian, could you comment on this ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338185: reassign to elilo
reassign 338185 elilo stop This is actually a bug in elilo, see: http://marc.theaimsgroup.com/?l=linux-ia64m=113315906701976w=2 -- dann frazier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign to elilo
Processing commands for [EMAIL PROTECTED]: reassign 338185 elilo Bug#338185: ia64 has problems footprinting initramfs Bug reassigned from package `linux-2.6' to `elilo'. stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] Backport of CVE-2005-2709 fix
On Fri, Nov 18, 2005 at 03:42:19PM -0700, dann frazier wrote: I've backported the fix for CVE-2005-2709 to 2.4 for Debian's 2.4 sarge kernel. Below is a patch against 2.4.32, in case one hasn't been submitted to you yet. Please apply. CVE-2005-2709 sysctl.c in Linux kernel before 2.6.14.1 allows local users to cause a denial of service (kernel oops) and possibly execute code by opening an interface file in /proc/sys/net/ipv4/conf/, waiting until the interface is unregistered, then obtaining and modifying function pointers in memory that was used for the ctl_table. Applied, thanks Dann. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341152: initrd-tools: unable to boot after replacing devfs with udev: kernel panic, unable to create null, no console
Package: initrd-tools Version: 0.1.84 Severity: important I cannot get 2.6.12 or 2.6.12 to boot because of the transition from devfs to udev, and the problem seems to lie with initrd. The symptom: * when I boot using devfs=mount, the boot succeeds. I get a cannot umount /proc/mount message but the boot continues. * when devfs is not running, at about the same point I get a cannot create null, followed by a cannot open dev/console, followed by a Kernel panic and Attempting to kill init message. Notes: When I look at the initrd-img, I notice that there's a devfs directory as well as a dev directory. The contents pf the /dev directory are: lrwxrwxrwx 1 root root 14 Dec 31 1969 cciss - ../devfs/cciss crw--- 1 root root 5, 1 Dec 31 1969 console lrwxrwxrwx 1 root root 12 Dec 31 1969 ida - ../devfs/ida drwx-- 1 root root 20 Dec 31 1969 ide lrwxrwxrwx 1 root root 15 Dec 31 1969 mapper - ../devfs/mapper drwx-- 1 root root 32 Dec 31 1969 md crw-rw-rw- 1 root root 1, 3 Dec 31 1969 null drwx-- 1 root root 20 Dec 31 1969 scsi so the console should be available on init, if I understand what's going on (and perhaps I do not). There's nothing in the /devfs directory in the initrd-img. Now, it's entirely possible that this is all a stupid user trick: I got udev running by adding it into my system, but I didn't do anything else, such as a rm -r on my /dev directory. I have the compatibility rules package for udev running, so I see vc/* and the tty packages when I boot using devfs=mount. If anyone has any hints or tricks that might fix this problem, or needs further data, please let me know. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages initrd-tools depends on: ii coreutils [fileutils] 5.93-5 The GNU core utilities ii cpio 2.6-9 GNU cpio -- a program to manage ar ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii dash 0.5.2-8The Debian Almquist Shell ii fileutils 5.93-5 The GNU file management utilities ii util-linux2.12p-8Miscellaneous system utilities initrd-tools recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336519: bad initrd_size?
hey Vagrant,
I just root caused an issue w/ the same symptom on ia64. Turns out
the bootloader was passing a bloated initrd_size option to the kernel.
Since initramfs is known to work on x86 w/ other bootloaders, I'm
thinking qemu maybe doing the same thing.
Can you try a test for me?
1) Rebuild your kernel w/ the following patch, and post a copy of the
boot log
2) Post the output of zcat /boot/initrd-img-2.6.14-1-386 | wc -c
diff --git a/init/initramfs.c b/init/initramfs.c
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -416,6 +416,10 @@ static void __init flush_window(void)
static char * __init unpack_to_rootfs(char *buf, unsigned len, int check_only)
{
int written;
+ int firstok = 0;
+
+ printk(KERN_INFO DANNF: initramfs.c:unpack_to_rootfs(%p, %d, %d)\n,
+ buf, len, check_only);
dry_run = check_only;
header_buf = malloc(110);
symlink_buf = malloc(PATH_MAX + N_ALIGN(PATH_MAX) + 1);
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337033: request full boot log
hey Paul, Would it be possible for you to include your full bootlog? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of initramfs-tools_0.41_ia64.changes
initramfs-tools_0.41_ia64.changes uploaded successfully to localhost along with the files: initramfs-tools_0.41.dsc initramfs-tools_0.41.tar.gz initramfs-tools_0.41_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341152: initrd-tools: unable to boot after replacing devfs with udev: kernel panic, unable to create null, no console
On Mon, Nov 28, 2005 at 12:59:34PM -0600, Moshe Yudkowsky wrote: I cannot get 2.6.12 or 2.6.12 to boot because of the transition from devfs to udev, and the problem seems to lie with initrd. initrd-tools is phasing out, if you use testing and udev 0.74 pick initramfs-tools 0.40 from unstable. if you use newer udev you need initramfs-tools 0.41 from debian mentors - http://mentors.debian.net/debian/pool/main/i/initramfs-tools/ if that doesn't work out for you check the alternative yaird. regards maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341162: initramfs-tools: add mptspi module
Package: initramfs-tools Severity: important The mptspi module is required for at least some machines that use the mptscsih driver for the root device. Please bzr merge http://dannf.org/bzr/initramfs-tools (I'm new to bzr - is this the appropriate way to send you a patch?) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: ia64 Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-mckinley Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
On Sun, 2005-11-20 at 21:21 -0500, Graham Knap wrote:
Sure enough, the kernel now boots. I'll attach the dmesg output here.
Do you guys have a final patch in mind?
Let me know if there are other tests you'd like me to run. Now that I
know how to do this, I should be able to turn around test results
fairly quickly.
OK, try the attached. If it works out, I'll soak it in -mm for a while
and then try to put it in as a bug fix for 2.6.15.
James
diff --git a/drivers/scsi/scsi_transport_spi.c
b/drivers/scsi/scsi_transport_spi.c
--- a/drivers/scsi/scsi_transport_spi.c
+++ b/drivers/scsi/scsi_transport_spi.c
@@ -812,12 +812,10 @@ spi_dv_device_internal(struct scsi_devic
if (!scsi_device_sync(sdev) !scsi_device_dt(sdev))
return;
- /* see if the device has an echo buffer. If it does we can
-* do the SPI pattern write tests */
-
- len = 0;
- if (scsi_device_dt(sdev))
- len = spi_dv_device_get_echo_buffer(sdev, buffer);
+ /* len == -1 is the signal that we need to ascertain the
+* presence of an echo buffer before trying to use it. len ==
+* 0 means we don't have an echo buffer */
+ len = -1;
retry:
@@ -840,11 +838,23 @@ spi_dv_device_internal(struct scsi_devic
if (spi_min_period(starget) == 8)
DV_SET(pcomp_en, 1);
}
+ /* Do the read only INQUIRY tests */
+ spi_dv_retrain(sdev, buffer, buffer + sdev-inquiry_len,
+ spi_dv_device_compare_inquiry);
+ /* See if we actually managed to negotiate and sustain DT */
+ if (i-f-get_dt)
+ i-f-get_dt(starget);
+
+ /* see if the device has an echo buffer. If it does we can do
+* the SPI pattern write tests. Because of some broken
+* devices, we *only* try this on a device that has actually
+* negotiated DT */
+
+ if (len == -1 spi_dt(starget))
+ len = spi_dv_device_get_echo_buffer(sdev, buffer);
- if (len == 0) {
+ if (len = 0) {
starget_printk(KERN_INFO, starget, Domain Validation skipping
write tests\n);
- spi_dv_retrain(sdev, buffer, buffer + len,
- spi_dv_device_compare_inquiry);
return;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339093: marked as done (initramfs-tools: kill udevd as late as possible)
Your message dated Mon, 28 Nov 2005 14:03:06 -0800
with message-id [EMAIL PROTECTED]
and subject line Bug#339093: fixed in initramfs-tools 0.41
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 14 Nov 2005 22:00:00 +
From [EMAIL PROTECTED] Mon Nov 14 14:00:00 2005
Return-path: [EMAIL PROTECTED]
Received: from 1-1-12-13a.han.sth.bostream.se ([82.182.30.168]
helo=palpatine.hardeman.nu)
by spohr.debian.org with esmtp (Exim 4.50)
id 1EbmMq-0004D1-3g
for [EMAIL PROTECTED]; Mon, 14 Nov 2005 14:00:00 -0800
Received: from david by palpatine.hardeman.nu with local (Exim 4.50)
id 1EbmMK-A0-R9
for [EMAIL PROTECTED]; Mon, 14 Nov 2005 22:59:28 +0100
Date: Mon, 14 Nov 2005 22:59:28 +0100
From: David =?iso-8859-1?Q?H=E4rdeman?= [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: initramfs-tools: kill udevd as late as possible
Message-ID: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary=XsQoSWH+UP9D9v3l
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2005_01_02
--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Package: initramfs-tools
Severity: minor
Tags: patch
Currently /usr/share/initramfs-tools/init kills udev after init-premount
scripts have executed. However, more devices might become available as a
result of running the local scripts.
I therefore suggest to kill udev as late as possible (right before
chaining to the real root filesystem). If any script has a problem with
udev running it can easilly call killall udevd itself.
Re,
David
--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=initramfs-tools-kill-udev-later.patch
Index: initramfs-tools-0.38/init
===
--- initramfs-tools-0.38.orig/init 2005-10-21 18:37:46.0 +0200
+++ initramfs-tools-0.38/init 2005-11-14 22:53:56.0 +0100
@@ -91,8 +91,6 @@
run_scripts /scripts/init-premount
log_end_msg
-killall udevd
-
log_begin_msg Mounting root file system
mountroot
log_end_msg
@@ -103,6 +101,7 @@
# Move our /dev to the real filesystem. Do the setup that udev otherwise
# would.
+killall udevd
mkdir -p /dev/.static/dev
chmod 700 /dev/.static/
mount -n -o bind ${rootmnt}/dev /dev/.static/dev
--XsQoSWH+UP9D9v3l--
---
Received: (at 339093-close) by bugs.debian.org; 28 Nov 2005 22:11:28 +
From [EMAIL PROTECTED] Mon Nov 28 14:11:28 2005
Return-path: [EMAIL PROTECTED]
Received: from katie by spohr.debian.org with local (Exim 4.50)
id 1Egr5W-0001be-PN; Mon, 28 Nov 2005 14:03:06 -0800
From: maximilian attems [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
X-Katie: $Revision: 1.60 $
Subject: Bug#339093: fixed in initramfs-tools 0.41
Message-Id: [EMAIL PROTECTED]
Sender: Archive Administrator [EMAIL PROTECTED]
Date: Mon, 28 Nov 2005 14:03:06 -0800
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
Source: initramfs-tools
Source-Version: 0.41
We believe that the bug you reported is fixed in the latest version of
initramfs-tools, which is due to be installed in the Debian FTP archive:
initramfs-tools_0.41.dsc
to pool/main/i/initramfs-tools/initramfs-tools_0.41.dsc
initramfs-tools_0.41.tar.gz
to pool/main/i/initramfs-tools/initramfs-tools_0.41.tar.gz
initramfs-tools_0.41_all.deb
to pool/main/i/initramfs-tools/initramfs-tools_0.41_all.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
maximilian attems [EMAIL PROTECTED] (supplier of updated initramfs-tools
package)
(This message was generated automatically at their request; if you
believe that
Bug#341014: marked as done (broken with udev 0.76)
Your message dated Mon, 28 Nov 2005 14:03:06 -0800 with message-id [EMAIL PROTECTED] and subject line Bug#341014: fixed in initramfs-tools 0.41 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 27 Nov 2005 19:06:07 + From [EMAIL PROTECTED] Sun Nov 27 11:06:07 2005 Return-path: [EMAIL PROTECTED] Received: from osl1smout1.broadpark.no ([80.202.4.58]) by spohr.debian.org with esmtp (Exim 4.50) id 1EgRqh-0003dU-7d for [EMAIL PROTECTED]; Sun, 27 Nov 2005 11:06:07 -0800 Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Sun, 27 Nov 2005 20:09:39 +0100 (CET) Received: from renaissance.heitech.no ([80.202.208.45]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Sun, 27 Nov 2005 20:08:24 +0100 (CET) Received: by renaissance.heitech.no (Postfix, from userid 1000) id BF06384A7C; Sun, 27 Nov 2005 20:05:35 +0100 (CET) Date: Sun, 27 Nov 2005 20:05:35 +0100 From: Heikki Henriksen [EMAIL PROTECTED] Subject: broken with udev 0.76 To: Debian Bug Tracking System [EMAIL PROTECTED] Message-id: [EMAIL PROTECTED] MIME-version: 1.0 X-Mailer: reportbug 3.17 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-7.5 required=4.0 tests=BAYES_00,HAS_PACKAGE, RCVD_IN_SORBS autolearn=no version=2.60-bugs.debian.org_2005_01_02 Package: initramfs-tools Version: 0.40 Severity: grave udev 0.76 failed to queue events correctly and didn't populate /dev at all using initramfs-tools. I only got a /dev/.udev/failed. No devices in /dev lead to failure to find root and no boot. To get up and running again I had to build a new initrd on a remote system and copy it over using a live-cd. yaird seems to have no problems with the same kernel (2.6.14-2-k7) and udev (0.76-2) cheers -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (401, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-k7 Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) Versions of packages initramfs-tools depends on: ii busybox 1:1.01-3 Tiny utilities for small and embed ii cpio 2.6-9 GNU cpio -- a program to manage ar ii klibc-utils 1.1.1-4small statically-linked utilities ii udev 0.076-2/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information --- Received: (at 341014-close) by bugs.debian.org; 28 Nov 2005 22:11:29 + From [EMAIL PROTECTED] Mon Nov 28 14:11:29 2005 Return-path: [EMAIL PROTECTED] Received: from katie by spohr.debian.org with local (Exim 4.50) id 1Egr5W-0001bg-Qd; Mon, 28 Nov 2005 14:03:06 -0800 From: maximilian attems [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Katie: $Revision: 1.60 $ Subject: Bug#341014: fixed in initramfs-tools 0.41 Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Mon, 28 Nov 2005 14:03:06 -0800 X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-CrossAssassin-Score: 2 Source: initramfs-tools Source-Version: 0.41 We believe that the bug you reported is fixed in the latest version of initramfs-tools, which is due to be installed in the Debian FTP archive: initramfs-tools_0.41.dsc to pool/main/i/initramfs-tools/initramfs-tools_0.41.dsc initramfs-tools_0.41.tar.gz to pool/main/i/initramfs-tools/initramfs-tools_0.41.tar.gz initramfs-tools_0.41_all.deb to pool/main/i/initramfs-tools/initramfs-tools_0.41_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL
Bug#341049: marked as done (linux-image-2.6.14-2-686: Doesn't boot (/dev/hda1 does not exist))
Your message dated Mon, 28 Nov 2005 14:03:06 -0800 with message-id [EMAIL PROTECTED] and subject line Bug#341014: fixed in initramfs-tools 0.41 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 27 Nov 2005 23:33:12 + From [EMAIL PROTECTED] Sun Nov 27 15:33:12 2005 Return-path: [EMAIL PROTECTED] Received: from qix.demiurgestudios.com ([12.151.131.245]) by spohr.debian.org with esmtp (Exim 4.50) id 1EgW1A-0004Tx-OT for [EMAIL PROTECTED]; Sun, 27 Nov 2005 15:33:12 -0800 Received: from localhost ([127.0.0.1] helo=mole.internal.demiurgestudios.com) by qix.demiurgestudios.com with esmtp (Exim 3.36 #1 (Debian)) id 1EgW18-0007zU-00; Sun, 27 Nov 2005 18:33:10 -0500 Received: by mole.internal.demiurgestudios.com (Postfix, from userid 501) id D79DAC3A2B; Sun, 27 Nov 2005 18:33:07 -0500 (EST) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Andrew Moise [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: linux-image-2.6.14-2-686: Doesn't boot (/dev/hda1 does not exist) X-Mailer: reportbug 3.17 Date: Sun, 27 Nov 2005 18:33:05 -0500 Message-Id: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 Package: linux-image-2.6.14-2-686 Version: 2.6.14-3 Severity: normal The linux kernel now does not boot for me. This is with udev 0.076-1 installed, and with hotplug purged. The IDE subsystem seems to be initialized correctly, but /dev/hda1 does not exist. I get (copied by hand): hda: FUJITSU MHT2040AT, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: max request size: 128KiB hda: 78140160 sectors (40007 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100) hda: cache flushes supported hda: hda1 Done. ... and then soon after: Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Done. ALERT! /dev/hda1 does not exist. Dropping to a shell! Investigation within the shell reveals that /dev contains only /dev/console and /dev/null. The static /dev directory on my /dev/hda1 partition _does_ apparently contain a /dev/hda1 entry. All of the testing above was with root=/dev/hda1 appended to the kernel command line. Without that argument, I get a failure to boot at a different point in the process (immediately after starting udevd, and it asks for the root password for maintenance). Both failures to boot seem to be because of a lack of a /dev/hda1 device node. I can write and copy the transcript for that failure case as well if you like. The debian image linux-image-2.6.12-1-686 version 2.6.12-6 boots correctly for me. Let me know if you need any more information. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.14-2-686 depends on: ii initramfs-tools [linux-initra 0.40 tools for generating an initramfs ii module-init-tools 3.2-pre9-4 tools for managing Linux kernel mo linux-image-2.6.14-2-686 recommends no packages. -- no debconf information --- Received: (at 341014-close) by bugs.debian.org; 28 Nov 2005 22:11:29 + From [EMAIL PROTECTED] Mon Nov 28 14:11:29 2005 Return-path: [EMAIL PROTECTED] Received: from katie by spohr.debian.org with local (Exim 4.50) id 1Egr5W-0001bg-Qd; Mon, 28 Nov 2005 14:03:06 -0800 From: maximilian attems [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Katie: $Revision: 1.60 $ Subject: Bug#341014: fixed in initramfs-tools 0.41 Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Mon, 28 Nov 2005 14:03:06 -0800 X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-CrossAssassin-Score: 2 Source: initramfs-tools Source-Version: 0.41 We believe that the bug you reported is fixed in the latest
initramfs-tools 0.40 MIGRATED to testing
FYI: The status of the initramfs-tools source package in Debian's testing distribution has changed. Previous version: (not in testing) Current version: 0.40 -- This email is automatically generated. See http://people.debian.org/~henning/trille/ for more information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
initramfs-tools_0.41_ia64.changes ACCEPTED
Accepted: initramfs-tools_0.41.dsc to pool/main/i/initramfs-tools/initramfs-tools_0.41.dsc initramfs-tools_0.41.tar.gz to pool/main/i/initramfs-tools/initramfs-tools_0.41.tar.gz initramfs-tools_0.41_all.deb to pool/main/i/initramfs-tools/initramfs-tools_0.41_all.deb Announcing to debian-devel-changes@lists.debian.org Closing bugs: 339093 341014 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
James Bottomley wrote: On Sun, 2005-11-20 at 21:21 -0500, Graham Knap wrote: Sure enough, the kernel now boots. I'll attach the dmesg output here. Do you guys have a final patch in mind? Let me know if there are other tests you'd like me to run. Now that I know how to do this, I should be able to turn around test results fairly quickly. OK, try the attached. If it works out, I'll soak it in -mm for a while and then try to put it in as a bug fix for 2.6.15. [ snip ] Nice patch, looks like the correct thing to do to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341162: initramfs-tools: add mptspi module
tags 341162 patch thanks On Mon, Nov 28, 2005 at 01:20:18PM -0700, dann frazier wrote: The mptspi module is required for at least some machines that use the mptscsih driver for the root device. Please bzr merge http://dannf.org/bzr/initramfs-tools (I'm new to bzr - is this the appropriate way to send you a patch?) cool thanks out of curiosity i fetched your branch. seems to work fine. latest version just reached incoming with needed udev fixes, will throw in your fix as soon 0.41 reaches testing. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#341162: initramfs-tools: add mptspi module
Processing commands for [EMAIL PROTECTED]: tags 341162 patch Bug#341162: initramfs-tools: add mptspi module There were no tags set. Tags added: patch thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
On Mon, 28 Nov 2005, Sven Luther wrote: On Mon, Nov 28, 2005 at 11:26:42AM +0100, Marco d'Itri wrote: On Nov 28, Sven Luther [EMAIL PROTECTED] wrote: Well, i saw passing a couple of reports about the ramdisk not creating needed devices, which sound RCish for this case, what about those ? Also, more I discussed these today with Maximilian Attems, initramfs-tools needed to be updated and now that we have /dev/.udev/queue/ will be more reliable. indeed that's very cool, was looking for such a condition since udev 0.072.. importantly, what are the bugs closed in the unstable udev, but open in the testing one, which will be the one used once 2.6.14 goes to testing. Today I will make a new upload with priority=high. Which will be able to enter testing then, cool. you are one day before initramfs-tools, missed dinstall run shortly, latest initramfs-tools is in incoming. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
On Mon, 28 Nov 2005, Sven Luther wrote: On Mon, Nov 28, 2005 at 09:04:59AM +0100, Maximilian Attems wrote: currently waiting for a patch from svenl to build against linux-kernel-headers, status? Nope, sorry, i had no real time to investigate this more than i did, and my tests didn't work out because of the asm-powerpc symlink farm breakage. ok fine so it was good to fix that :) I believe that l-k-h needs to be setup to use another newer kernel headers, or better yet use the same kernel libc project headers as ubuntu uses, altough jbailey reported having build klibs with and older kernels (2.6.12 or something such). not sure what influence the pure64 patch from Andreas Jochens has on this, but i guess it confuses the issue more. My own testing where hurt by the ARCH=powerpc header migration, which is now fixed in 2.6.14-4, and i only need to find time for it again. jbaley mentioned needing to fix linux-kernel-headers. so in the meantime i would be happy if we could reintroduce that asm symlink. need to talk with waldi, didn't reach him today. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
/* Sorry for not replying to original message, looks like I've lost it */ The quirks I'm aware of: * The perpetual l-h problem: #340486. The build of modules breaks in scripts/basic directory. Since I've contributed the latest fix for scripts, I'm looking into it. At the moment I'm not even sure whether this problem is upstream, packaging screw-up, or kernel-package doing something new. I should post a follow-up to this bug within the next few days. * Some early Sun machines (Ultra1, for example) have an sbus bus. Drivers for sbus devices are not sysfs-trained, so yaird does not include the esp scsi driver (most common in such machines) into initrd. Machine fails to boot as a result. I have not tested initramfs-tools, that's also on my todo list. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] hfs, hfsplus: don't leak s_fs_info and fix an oops
On Fri, Oct 07, 2005 at 09:10:05AM +0200, Colin Leroy wrote: On 07 Oct 2005 at 13h10, Horms wrote: Hi, I took a look at making a backport, and it seems that some of the problems are there, but without a deeper inspection of the code its difficult to tell if the problems manifest or not. That was easy to get the oops: $ dd if=/dev/zero of=im_not_hfsplus count=10 #for example $ mkdir test_dir $ sudo mount -o loop -t hfsplus ./im_not_hfsplus ./testdir $ dmesg After an extended delay I have been able to confirm that the above commands do not cause 2.4 (Debian's 2.4.27) to do anything unusal. Mount just reports: mount: wrong fs type, bad option, bad superblock on /dev/loop0, or too many mounted file systems And there is nothing exciting in dmsg: loop: loaded (max 8 devices) HFS+-fs: unable to find HFS+ superblock HFS+-fs: unable to find HFS+ superblock HFS+-fs: unable to find HFS+ superblock Thus it seems that 2.4 does not suffer from this bug. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341152: initrd-tools: unable to boot after replacing devfs with udev: kernel panic, unable to create null, no console
At 14:01 2005-11-28, Maximilian Attems wrote: On Mon, Nov 28, 2005 at 12:59:34PM -0600, Moshe Yudkowsky wrote: I cannot get 2.6.12 or 2.6.12 to boot because of the transition from devfs to udev, and the problem seems to lie with initrd. initrd-tools is phasing out, if you use testing and udev 0.74 pick initramfs-tools 0.40 from unstable. if you use newer udev you need initramfs-tools 0.41 from debian mentors - http://mentors.debian.net/debian/pool/main/i/initramfs-tools/ Ok, the answer turns out to be quite simple: I didn't have the correct console and null files in my /dev directory. IMO, this is a documentation problem, so let me document the fix. Here's how to transition from devfs to udev -- at least as far as booting. Introduction: There's a difference between devfs and udev. Devfs makes the console and null files available by the time the files are needed during the boot. udev starts later, so you must supply your own copy of /dev/console and /dev/null. Action: Therefore, before trying to boot using udev only, make certain you have a console and null file in /dev. Of course, if your system is running, you have these files now -- but the question is, were they part of the /dev directory, or did devfs put it there? Here's how to check. * First, mount the root directory someplace other than /, so that the /dev directory can be examined as a standalone -- so it can be seen as it looks without stuff that devfs puts there. As root, issue the command: # mount -o bind / /mnt (where /mnt is some random mouting point). * Next, look at /mnt/dev. You need to have two special files there, console and null: crw--- root root 5, 1 Nov 28 16:50 console crw-rw-rw- root root 1, 3 Nov 28 16:51 null If you have them already, you're all set. On my system, I had null and it was *not* a c (special character) file; it was an ordinary file. I got rid of that file and issued the following commands to create console and null: # mknod -m 660 console c 5 1 # mknod -m 660 null c 1 3 * Unmount the / file system: # umount /mnt. * Make certain you have udev! 2.6.14-2 requires udev to boot, but you are responsible for actually installing udev. * Once /dev/console and /dev/null exist, you can boot using udev only. (For example, on my system, a boot using udev only is done by removing the devfs=mount command from lilo.) There's other stuff to do to convert completely to udev, but this gets you started. -- Moshe Yudkowsky Disaggregate 2952 W Fargo Chicago, IL 60645 USA www.Disaggregate.com www.PebbleAndAvalanche.com [EMAIL PROTECTED] +1 773 764 8727 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
On Mon, Nov 28, 2005 at 07:42:34PM -0800, Jurij Smakov wrote: /* Sorry for not replying to original message, looks like I've lost it */ The quirks I'm aware of: * The perpetual l-h problem: #340486. The build of modules breaks in scripts/basic directory. Since I've contributed the latest fix for scripts, I'm looking into it. At the moment I'm not even sure whether this problem is upstream, packaging screw-up, or kernel-package doing something new. I should post a follow-up to this bug within the next few days. kernel-package is still 9.008.4 last i checked, i am not sure Manoj did upload the 10.00x version finally to unstable or not. I have not heard from Manoj since some time. * Some early Sun machines (Ultra1, for example) have an sbus bus. Drivers for sbus devices are not sysfs-trained, so yaird does not include the esp scsi driver (most common in such machines) into initrd. Machine fails to boot as a result. I have not tested initramfs-tools, that's also on my todo list. Ok, you can add the needed modules by hand to Default.cfg for yaird, but i guess there are at least two solutions : 1) enhance yaird to know about how to detect some non-sysfs modules, like the sbus ones, or ... 2) make the sbus stuff sysfs aware. The second solution would be preferable i think. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
