Re: GCC version change / C++ ABI change
On Mon, Jul 04, 2005 at 11:12:21AM +0200, Thiemo Seufer wrote: > Most kernel hackers don't care that much about 2.4 any more. This is of course one of the reasons why users feel left alone by the kernel developers. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to build .deb from Debian's linux-tree-2.6.12
I am currently trying to make myself familiar with building the Debian packages for kernel 2.6 to see whether it's worth to move my local kernel building processes nearer to Debian's own processes. So I have created a fresh sid chroot with build-essential installed, downlaoded linux-tree-2.6.12, unpacked it, installed the build dependencies and invoked debuild. First round, it failed for not finding libncurses, so I installed libncurses-dev. Now, debuild fails with a short "interrupted(11)", in an xterm which thinks of having 23 lines only. Looks like something goes wrong with make menuconfig, but make menuconfig invoked from the command line works fine. Is that an issue with current sid, or am I doing something wrong? Currently, I am inclined to say that linux-tree-2.6.12 is missing a Build Dependency on ncurses, and that it suffers from other kinds of breakage as well. But I might be mistaken. Can somebody help? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to build .deb from Debian's linux-tree-2.6.12
On Fri, Oct 14, 2005 at 05:26:37PM +0200, Sven Luther wrote: > On Fri, Oct 14, 2005 at 02:58:28PM +0200, Marc Haber wrote: > > Is that an issue with current sid, or am I doing something wrong? > > Currently, I am inclined to say that linux-tree-2.6.12 is missing a > > Build Dependency on ncurses, and that it suffers from other kinds of > > breakage as well. But I might be mistaken. Can somebody help? > > linux-tree-2.6.12 is a binary package, and thus its build-dependencies are on > linux-2.6 source, which should do the right thing, not sure though. > > Not sure what you really want to do, but in any case, linux-tree-2.6.12 is > probably a thing of the paste, you want either the linux-2.6 source package > or the linux-source-2.6.12 binary package. I tried the same after apt-get source linux-2.6 and installing all build dependencies (dpkg-checkbuilddeps doesn't complain), and the same thing happens. The package tries to make menuconfig, and that fails with "interrupted(11)". Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to build .deb from Debian's linux-tree-2.6.12
On Fri, Oct 14, 2005 at 07:44:35PM +0200, Sven Luther wrote: > On Fri, Oct 14, 2005 at 07:10:50PM +0200, Marc Haber wrote: > > On Fri, Oct 14, 2005 at 05:26:37PM +0200, Sven Luther wrote: > > > On Fri, Oct 14, 2005 at 02:58:28PM +0200, Marc Haber wrote: > > > > Is that an issue with current sid, or am I doing something wrong? > > > > Currently, I am inclined to say that linux-tree-2.6.12 is missing a > > > > Build Dependency on ncurses, and that it suffers from other kinds of > > > > breakage as well. But I might be mistaken. Can somebody help? > > > > > > linux-tree-2.6.12 is a binary package, and thus its build-dependencies > > > are on > > > linux-2.6 source, which should do the right thing, not sure though. > > > > > > Not sure what you really want to do, but in any case, linux-tree-2.6.12 is > > > probably a thing of the paste, you want either the linux-2.6 source > > > package > > > or the linux-source-2.6.12 binary package. > > > > I tried the same after apt-get source linux-2.6 and installing all > > build dependencies (dpkg-checkbuilddeps doesn't complain), and the > > same thing happens. The package tries to make menuconfig, and that > > fails with "interrupted(11)". > > Well, after thinking about this, it is only normal, since the build process > obviously uses oldconfig, since it is non-interactive. I now know what was going on. Despite debian/rules not directly using make-kpkg, the build process somehow uses code delivered by kernel-package, which in turn honors ~/.kernel-pkg.conf, which on my system has config_target := menuconfig. That's a gotcha. > In any case, there is no way that what you try to do is something where > build-dependencies are involved, Can you please explain that? I am trying to convert a Debian source package (consisting of .orig.tar.gz, diff.gz and .dsc) into a set of Debian binary packages (.deb). The usual way to do so is to use the debuild command (or another of the dpkg-buildpackage frontends available in numerous different flavours) after installing build-essential and all packages listed in the Build-Depends line in debian/control. I must be missing something here, please enlighten me. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to build .deb from Debian's linux-tree-2.6.12
On Sat, Oct 15, 2005 at 07:06:05AM +0200, Sven Luther wrote: > On Fri, Oct 14, 2005 at 10:43:34PM +0200, Marc Haber wrote: > > I now know what was going on. Despite debian/rules not directly using > > make-kpkg, the build process somehow uses code delivered by > > kernel-package, which in turn honors ~/.kernel-pkg.conf, which on my > > system has config_target := menuconfig. > > > > That's a gotcha. > > Ah, ... and moving that file away solved the issue. the kernel now builds nicely. > > Can you please explain that? I am trying to convert a Debian source > > package (consisting of .orig.tar.gz, diff.gz and .dsc) into a set of > > Debian binary packages (.deb). The usual way to do so is to use the > > debuild command (or another of the dpkg-buildpackage frontends > > available in numerous different flavours) after installing > > build-essential and all packages listed in the Build-Depends line in > > debian/control. > > Well, if you take the already packaged version out of the archive, you just > need to : > > dpkg-buildpackage -rfakeroot -us -uc > > And it flies, after installing build-essential, fakeroot and the linux-2.6 > build-deps. That works fine with debuild as well, which is no wonder considering that first thing debuild does it to call dpkg-buildpackage. > i do use dpkg-buildpackage in a clean sid chroot specially created for this > purpose, but don't use any kind of debuild/pbuilder/whatever frontends, so > maybe there is some problem with the frontend you are using ? Since I always use debuild, and package not building with debuild would probably be a bug in the package. But with your help, I have found the issue. It is quite interesting that linux-2.6 uses kernel-package in a way which turns off kernel-package error handling. Maybe linux-2.6 should check whether a ~/.kernel-pkg.conf exists with incompatible settings, as this might be a challenge for other people as well. > > I must be missing something here, please enlighten me. > > What is your problem again, now that we sorted the menuconfig out ? None, at the moment. I just got the impression that the kernel packages need some special handling as you suggested an error in my build process. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Building local kernels from Debian sources
Hi guys, this is basically a re-hash of http://blog.zugschlus.de/archives/231-Thoughts-about-the-Debian-kernel.html, which I published on my blog on sunday. Since the article received less response than I originally expected, I would like to solicit your opinions and answers in a more direct way. I am one of the guys who builds Linux kernels locally, from vanilla sources. What I don't like in this approach is that I do not get the distribution patches and might miss one of the kernel security patches, since I am way too busy to keep track of LKML any more. otoh, I am kind of a version number junkie when it comes to the kernel, so the Debian kernel sources even in sid frequently are not current enough. So, what I want to have is a compromise between a vanilla kernel and the Debian distribution kernels, built in a way that the images integrate well with Debian. This message contains a few questions and wishes directed towards the Debian kernel team which I failed to get addressed on #debian-kernel and on the blog. * The build process is not very transparent * Documentation in the README files seems quite incomplete * In my opinion, answers to these questions are missing: * Which steps happen in which order (prose)? * Are there any hooks to interfere with the build process? * How to keep patches from being applied? * How to add local patches? * Is there anything like dpatch-edit-patch for the (home-grown?) patch system in the Debian kernel source package? * How do I control generation of the kernel-image-2.x-_2.x.y-z_.deb helper packages? They do not seem to be controlled by debian/arch//defines as the real kernel debs do. * Can I have patches from a kernel-patch-foo Package automatically applied for certain flavours? * Are there hooks for building external modules? * Are there debian/rules parameters or environment variables to select only a certain kernel to be built (like for debugging problems)? * Can build of helper packages (-headers, -doc, -patch, -source, -tree) be disabled? * For local kernel builds, should one use the Debian kernel build system, or continue to use make-kpkg as it was usual previously? * there is nothing like a kernel HOWTO * The Kernel Handbook needs to be fleshed out in these regards. I might want to contribute once I have accumulated the knowledge needed to write the passages. * Patches like, for example, amd64-int3-fix need to be better commented * I think it is necessary that a patch file contains information * what does the patch do? * why is it applied? * is it necessary only on certain archs? * is it necessary only if certain drivers are in use? * what does happen when it is omitted? * is it security relevant? * CAN/CVE number, if applicable. * Which role does module-assistant play here? * If one builds kernels with make-kpkg, should one make use of make-kpkg also build the modules, or should one use module-assistant instead? I would really appreciate any hints. Best regards Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building local kernels from Debian sources
On Thu, Oct 27, 2005 at 02:38:34PM +0200, Maximilian Attems wrote: > On Thu, Oct 27, 2005 at 01:54:24PM +0200, Marc Haber wrote: > > the Debian kernel sources even in sid frequently are not current > > enough. > > that should evolve, now that the common build is ironed out the > initrd-tools replacements initramfs-tools and yaird are on the way. > current experimental kernel is pretty latest upstream. It still has to pass ftpmaster approval, and the Debian packages take much longer to build due to the fact that they build multiple flavours. And, of course, the time-to-mirror-pulse. I would expect that locally rolled kernels are faster by at least a day. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
svn commit messages
Hi, would it be possible to apply the following patchlet to /srv/svn.debian.org/svn/kernel/hooks/post-commit? --- /srv/svn.debian.org/svn/kernel/hooks/post-commit2005-10-19 07:45:35.0 + +++ post-commit 2005-11-04 10:31:10.0 + @@ -38,7 +38,7 @@ ## added 2004.08.10 by [EMAIL PROTECTED] $REPOS/bin/ciabot_svn.py "$REPOS" "$REV" & -/usr/lib/subversion/hook-scripts/commit-email.pl "$REPOS" "$REV" [EMAIL PROTECTED] & +/usr/lib/subversion/hook-scripts/commit-email.pl -s "[kernel]" "$REPOS" "$REV" [EMAIL PROTECTED] & ## This should automatically mark bugs pending when it sees it ## closed in a changelog commit. Right now it just e-mails me, With theat patch, the kernel commit messages would get a subject tag which allows easier scanning of commit messages in a mailbox which gets commit messages from multiple repositories. Thanks! Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: svn commit messages
On Fri, Nov 04, 2005 at 07:56:23PM +0900, Horms wrote: > On Fri, Nov 04, 2005 at 11:32:05AM +0100, Marc Haber wrote: > > Hi, > > > > would it be possible to apply the following patchlet to > > /srv/svn.debian.org/svn/kernel/hooks/post-commit? > > > > --- /srv/svn.debian.org/svn/kernel/hooks/post-commit2005-10-19 > > 07:45:35.0 + > > +++ post-commit 2005-11-04 10:31:10.0 + > > @@ -38,7 +38,7 @@ > > ## added 2004.08.10 by [EMAIL PROTECTED] > > $REPOS/bin/ciabot_svn.py "$REPOS" "$REV" & > > > > -/usr/lib/subversion/hook-scripts/commit-email.pl "$REPOS" "$REV" [EMAIL > > PROTECTED] & > > +/usr/lib/subversion/hook-scripts/commit-email.pl -s "[kernel]" "$REPOS" > > "$REV" [EMAIL PROTECTED] & > > > > ## This should automatically mark bugs pending when it sees it > > ## closed in a changelog commit. Right now it just e-mails me, > > > > With theat patch, the kernel commit messages would get a subject tag > > which allows easier scanning of commit messages in a mailbox which > > gets commit messages from multiple repositories. > > Sure, though I don't seem to be able to check hooks/post-commit out :( Juste edit the file directly on costa. This is one of the differences between svn and cvs. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: svn commit messages
On Fri, Nov 04, 2005 at 12:01:38PM +0100, Norbert Tretkowski wrote: > I already did that. Thanks a lot! Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Changes for 2.6.25
On Wed, Mar 19, 2008 at 03:47:21PM +0100, Bastian Blank wrote: > Sure. The documentation is the source, Am I the only one finding this unacceptable? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#473971: debian-installer: lenny installer kernel hangs after boot on Asus M2N notebook
On Wed, Apr 02, 2008 at 06:41:06PM +0200, Bastian Blank wrote: > On Wed, Apr 02, 2008 at 02:48:17PM +0200, Frans Pop wrote: > > On Wednesday 02 April 2008, Marc Haber wrote: > > > the Debian installer lenny kernel (pulled today from > > > http://http.us.debian.org/debian/dists/lenny/main/installer-i386/current/ > > >images/hd-media/) freezes after booting, last line seen is "Setting up > > > standard PCI resources" on an Asus M2N notebook. Setting "noacpi noapic" > > > doesn't help. The etch installer kernel boots just fine. > > Please try a newer kernel. The given message is shown before all other > PCI setup is done. Today's daily image works fine. I had the impression of using a daily image, but in fact I had beta 1. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340746: lists cdbs twice in debian/control (Build-Depends)
On Fri, Nov 25, 2005 at 05:04:48PM +0100, Jonas Smedegaard wrote: > On Fri, 25 Nov 2005 15:26:58 + > Martin Michlmayr <[EMAIL PROTECTED]> wrote: > > > You list cdbs twice in debian/control (Build-Depends): > > > > | Build-Depends: cdbs (>= 0.4.23-1.1), debhelper (>= 4.1.0), quilt, > > | patchutils (>= 0.2.25), cdbs (>= 0.4 .27-1), dh-buildinfo, xmlto > > I know. It is due to the way that file is semi-automatically generated. > > What is buggy about it? It is ugly, redundant, confuses parsers, and with that attitude it would be ok to list a dependency a hundred fold. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: add mailing list debain-kernel-maint
On Wed, Jan 11, 2006 at 10:12:35PM +0100, maximilian attems wrote: > Package: lists.debian.org > > Name: debian-kernel-maint How about using an alioth mailing list? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building local kernels from Debian sources
On Thu, Oct 27, 2005 at 02:31:52PM +0200, Maximilian Attems wrote: > On Thu, Oct 27, 2005 at 01:54:24PM +0200, Marc Haber wrote: > > this is basically a re-hash of > > http://blog.zugschlus.de/archives/231-Thoughts-about-the-Debian-kernel.html, > > which I published on my blog on sunday. Since the article received > > less response than I originally expected, I would like to solicit your > > opinions and answers in a more direct way. > > the comments show a funny public you reached. Yes, they have obviously not understood what upstream does provide and what upstream does not provide. > > I am one of the guys who builds Linux kernels locally, from vanilla > > sources. What I don't like in this approach is that I do not get the > > distribution patches and might miss one of the kernel security > > patches, since I am way too busy to keep track of LKML any more. > > otoh, I am kind of a version number junkie when it comes to the > > kernel, so the Debian kernel sources even in sid frequently are not > > current enough. So, what I want to have is a compromise between a > > vanilla kernel and the Debian distribution kernels, built in a way > > that the images integrate well with Debian. > > then use latest stable. Which package are you referring to? > the addition of this tree helped a lot in the maintenance of the debian > kernel. chris wright and greg kroah-hartman do a fantastic job. They might, but they do seem to hide their documentation pretty well. At least I didn't find documentation about the applied patches in the verbosity I was hoping for. > > This message contains a few questions and wishes directed towards the > > Debian kernel team which I failed to get addressed on #debian-kernel > > and on the blog. > > > > * The build process is not very transparent > > * Documentation in the README files seems quite incomplete > > * In my opinion, answers to these questions are missing: > > * Which steps happen in which order (prose)? > README.build in svn?? Do you have a more exact path to README.build? The repository is huge and I'd like to avoid checking out the entire repos to be able to search for that file. > > * Are there any hooks to interfere with the build process? > > * How to keep patches from being applied? > naah, you were already told: > take it as whole or forget about it. I do not find that very helpful, and this attitude does not positively influence my opinion about the debian kernel team. > > * Is there anything like dpatch-edit-patch for the > > (home-grown?) patch system in the Debian kernel source package? > no. > dpatch was never used afair. I didn't suggest that dpatch was used. I was asking for a tool to easily create patches. > > * The Kernel Handbook needs to be fleshed out in these regards. I > > might want to contribute once I have accumulated the knowledge needed > > to write the passages. > cool. Actually, my motivation to do so has greatly decreased after learning about your attitude towards user requests. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building local kernels from Debian sources
On Thu, Oct 27, 2005 at 04:11:41PM +0200, Sven Luther wrote: > So, all in all, most of your complaints are probably unfunded with regard to > this plan, and you would be better off helping the above plan happen. Helping here is only an option if the documentation is better, which is still lacking. And, basically, my motivation is not very good when somebody tells me to buzz off. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building local kernels from Debian sources
On Fri, Oct 28, 2005 at 10:43:55AM +0900, Horms wrote: > On Thu, Oct 27, 2005 at 01:54:24PM +0200, Marc Haber wrote: > > I am one of the guys who builds Linux kernels locally, from vanilla > > sources. What I don't like in this approach is that I do not get the > > distribution patches and might miss one of the kernel security > > patches, since I am way too busy to keep track of LKML any more. > > otoh, I am kind of a version number junkie when it comes to the > > kernel, so the Debian kernel sources even in sid frequently are not > > current enough. So, what I want to have is a compromise between a > > vanilla kernel and the Debian distribution kernels, built in a way > > that the images integrate well with Debian. > > > > This message contains a few questions and wishes directed towards the > > Debian kernel team which I failed to get addressed on #debian-kernel > > and on the blog. > > > > * The build process is not very transparent > > * Documentation in the README files seems quite incomplete > > The build process is something that is being worked on very heavily. > So yes there is ample room for improvement. And one area that is > particularly lacking is documenation. Contributions in that area > would be greatly welcomed. The build is a lot of make magic, something I am not very familiar with. And it is hard for me to fine a starting point for investigation. > > * In my opinion, answers to these questions are missing: > > * Which steps happen in which order (prose)? > > I'm not entirely sure what you mean. > > apt-get source linux-2.6 > cd linux-2.6 > dpkg-buildpackage -rfakeroot -us -uc -B ... That is too easy ;) > One caveat, is that if you play with stuff before running > dpkg-buildpackage, which I guess you would else you won't be > here, That guess seems to be correct. In particular, I'd like only three flavors of the kernel to be built, all of them for i386, but with my own .config file. > then debian/control probably needs to be regenerated. > > If you just run dpkg-buildpackage as above, it will fail, > telling you that it re-generated debian/control. Confusingly, > this is ok. Just re-run dpkg-buildpackage. If it fails again, > then you are in trouble. I see. > If, like me, this troubles you, run > > rm -f debian/control > ./debian/rules debian/control Thanks. > N.B: This requires python *urgs* > > * Are there any hooks to interfere with the build process? > > No Too bad. > > * How to keep patches from being applied? > > The best thing would be to create a series file > as discussed immediately below (sorry, I'm answering this > email backwards for no apparent reason). And remove the patches > > e.g: > > say you don't like amd64-int3-fix.patch > cat << __EOF__ >> debian/series/2.6.13-12hls.1 > - amd64-int3-fix.patch > __EOF__ > > This will make sure that amd64-int3-fix.patch is unapplied when you > build version 2.6.13-12hls.1 or greater of the package. It will > still be there in earlier versions as dictated by other series files. That sounds pretty neat. Looks like all I need is to learn what a patch does and how it is classified by the one who applied it. > > * How to add local patches? > > There are several ways. Add a patch package, which you asked > about below. If you just want to dd a few patches, put them in > debian/patches-debian. Create a file in debian/patches-debian/series, > that's name is the debian version you are going to build, > and add the patches to that file, one per line, prefixed by "+ ". > > For example: > > cp /tmp/a.patch debian/patches-debian > cp /tmp/b.patch debian/patches-debian > > cat << __EOF__ >> debian/series/2.6.13-12hls.1 > + a.patch > + b.patch > __EOF__ > > When version 2.6.13-12hls.1 or greater of the package gets built > these patches will be applied. They will also be included > in the linux-patch package. Great. I think I understand how things work. Thanks! > Just note that the patch filenames must end in .patch > > > * Is there anything like dpatch-edit-patch for the > > (home-grown?) patch system in the Debian kernel source package? > > I'm not sure what that is, but probably not. > Could you elaborate? dpatch-edit-patch is a tool from the dpatch package which will make a snapshot of the current sources (which might be inappropriate for a package as large as the kernel), drop you into a shell where you can make your modifications. After that shell has exited, your local working copy will be diffed against the snapshot made beforehand, resulting in
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 06:06:22PM +0100, Bastian Blank wrote: > I won't reject the help of volunteers but I strongly think that the > kernel team needs to have its hands on them. How many members of the kernel team are planning to do active work on Xen, kernel and userspace? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362442: Re: Bug#362441: aide: QUIETREPORTS=yes has no effect
tags #362442 - confirmed pending thanks On Sat, Apr 15, 2006 at 12:52:23PM +0200, Marc Haber wrote: > tags #362442 confirmed pending > thanks Errm. That was a typo. I apologize. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
On Mon, Dec 18, 2006 at 09:31:22AM +0100, Goswin von Brederlow wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > Well, the real problem is that Manoj could be part of the kernel team, and > > to > > a point even is, since he has svn access to the repo. > > > > But there is a problem, in that Manoj's principal preocupacion is those user > > who build their own kernel, and the official kernel is only an after thought > > (not mentioning memories of when he was the debian kernel maintainer all > > those > > years ago and whatnot), while Bastian handles most of the official kernel > > infrastructure, and obviously doesn't care much about self-built ones. > > And Bastian is decidetly anti make-kpkg and wants to remove all > make-kpkg use from linux-2.6 as stated several times now. You can see > beginings of that in the xen kernels. > > Further one result of this dislike of kernel-package seems to be that > you can't build proper custom kernels on mips, mipsel, s390 and ppc > and no xen or vserver flavours anywhere. The debian patch is not > make-kpkg compatible and again Bastian spoke against fixing the patch > to work with kernel-package. I consider kernel-package one of the best things in Debian and it is a real pity that it is not being used to build the Debian kernel. Not being able to use Debian's kernel build tool to build a Debian kernel is depressing. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Solving the linux-2.6 firmware issue
On Fri, Jan 05, 2007 at 10:54:42PM +0100, Frederik Schueler wrote: > The following drivers will be completely removed from the next upload, > because they contain legally not distributable components: > > keyspan So keyspan USB devices will be useless with Debian kernels in the very near future, since there is no alternative to the kernel driver? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Towards consensus of our usage of the Uploaders field
On Fri, Mar 16, 2007 at 09:09:48AM +0100, Sven Luther wrote: > So, Frans has the right to speak here, while i have not ? Frans' message was on topic and useful, while you were basically telling him to shut up, which is neither on topic nor useful. Do you see the difference? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Towards consensus of our usage of the Uploaders field
On Fri, Mar 16, 2007 at 09:15:55AM +0100, Sven Luther wrote: > So, will you try to expulse him too, like Frederik and Andres did to me ? Can you please take your personal vendettas from this technical mailing list? Both Bastian and you are difficult to work with, but in different dimensions. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Towards consensus of our usage of the Uploaders field
On Fri, Mar 16, 2007 at 10:00:48AM +0100, Sven Luther wrote: > So, i played nice, to no avail, so i will try to be an asshole for a week or > two now, and see how people like it. Welcome to my killfile. Congratulations, this is a real achivement. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418383: /usr/sbin/update-initramfs: please add an option to leave the built tree around for analysis
Package: initramfs-tools Version: 0.85f Severity: wishlist File: /usr/sbin/update-initramfs update-initramfs builds a new initramfs file system, packs it up, and deletes the directory built before packing. For analysis, it would be great to be able to take a look into the file system, so it would be nice to have update-initramfs leave the tree around instead of unconditionally removing it. Greetings Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426440: /usr/sbin/pppd: sometimes connection with Option GlobeTrotter card hangs, ping: sendmsg: No buffer space available
On Mon, May 28, 2007 at 10:09:04PM +0200, Miernik wrote: > I have a PCMCIA UMTS/HSDPA card Option GlobeTrotter GT Max: > 02:00.0 Network controller: Option N.V. Qualcomm MSM6275 UMTS chip > > After some time, usually something around 12 to 36 hours of the > connection beeing connected, the ppp connection hangs, and attempt to > ping through it results in: > > ping: sendmsg: No buffer space available > ping: sendmsg: No buffer space available > ping: sendmsg: No buffer space available > ping: sendmsg: No buffer space available > ping: sendmsg: No buffer space available > ping: sendmsg: No buffer space available I have this as well, with both my Option 3G Datacard, and a borrowed Novatel 740. After killing the PPP connection, the virtual USB serial port simulated by the card is not responsive any more, AT commands are ignored. Sometimes, it is sufficient to unload and reload the usbserial module, but usually, it is necessary to pull the card and to dial in again afterwards. This is becoming a major nuisance. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Classification scheme for 2.6 kernel patches
e too many patches in that category. The categorization may be wrong since I don't have too much clue with kernel hacking and did this categorization mainly from the comments of the patch. In my opinion, it would be desireable that a patch be categorized by the kernel team on inclusion into Debian svn. I would like to solicit your comments about this concept. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 07:40:06PM +0100, Thiemo Seufer wrote: > I think the effort to do so is better invested elsewhere. As a > general rule, the kernel team strives to keep the debian-specific > patches to a minimum. For people without in-depth kernel knowledge > it's probably best to take the full set of patches and add their > own (feature- ?) patches on top. Actually, the kernel of my dreams is more near to the vanilla kernel.org kernel, so I'd like to be able to throw out patches that you need to apply because of your _much_ broader user base. otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the distribution kernel because it is still stuck in NEW. It is adviseable to take a snapshot from the Debian kernel svn? And, without trolling, I'd like to build my local kernels from sources that haven't had drivers removed because of non-free licenses. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: > Agreed. The package is not a repository for cherrypicking patches > but intended to used as a whole thing. I am pretty disappointed about that attitude towards your users. What exactly is the problem with a little more docs to _allow_ cherrypicking? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 07:36:47PM +, Matthew Wilcox wrote: > On Sun, Jan 09, 2005 at 08:33:51PM +0100, Marc Haber wrote: > > Actually, the kernel of my dreams is more near to the vanilla > > kernel.org kernel, so I'd like to be able to throw out patches that > > you need to apply because of your _much_ broader user base. > > > > otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the > > distribution kernel because it is still stuck in NEW. It is adviseable > > to take a snapshot from the Debian kernel svn? > > > > And, without trolling, I'd like to build my local kernels from sources > > that haven't had drivers removed because of non-free licenses. > > I think only one of my machines is running a Debian-built kernel. Debian > is much more forgiving of using a stock kernel than some other distributions. It definetely is, and it is exceptionally good in allowing usage of infrastructure for local builds and installation as well. kernel-package is one of the big advantages that has driven me to Debian years ago. Using infrastructure that makes individual patch files is a big step forward as well as this enables people to individually choose their patch sets. The progress is impressive. What we need now are better docs, and a few minor tweaks in the tools. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 08:52:59PM +0100, Thiemo Seufer wrote: > Cherrypicking makes little sense, because there are only cherries. :-) For my systems, I care about security holes being fixed, but I do not care about some obscure video hardware, or additional features. So "Cherry" is relative. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 03:56:48PM -0500, Andres Salomon wrote: > On Sun, 09 Jan 2005 20:41:41 +0100, Marc Haber wrote: > > On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: > >> Agreed. The package is not a repository for cherrypicking patches > >> but intended to used as a whole thing. > > > > I am pretty disappointed about that attitude towards your users. What > > exactly is the problem with a little more docs to _allow_ cherrypicking? > > > > Greetings > > Marc > > A large problem with this is that patches in our -source packages assume a > certain order. A patch may depend upon another patch; removing one breaks > the other. We have this problem when cherry-picking changes from > bitkeeper; I'd imagine it gets even worse when you attempt to pick changes > from -source packages. Choosing a working patchset would be the responsibility of the picking user, no work on your side involved. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Kernel compiling....
Hi, On Wed, May 04, 2005 at 02:01:02PM +0200, Marco Calviani wrote: > sorry for the maybe stupid and repetitive question, is it possible to > use the nice features of make-kpkg also with a vanilla kernel coming > from kernel.org or is it required to use the kernel-source from debian > repositories? make-kpkg works with vanilla kernels as well. Currently, it looks like the Debian kernel development has kind of lost communication to the kernel-package maintainer since the kernel sources keep popping up with features that would look more canonical inside kernel-package's code to allow them to be used with vanilla kernels as well. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: speakup flavour\
On Mon, Aug 21, 2006 at 12:58:39AM +0200, Sven Luther wrote: > Try hurt and angry instead. How about "annoying, childish and socially inept"? We all know your beef with Frans and Jonas, and bringing it up again over and over is only hurting _YOUR_ reputation. You certainly don't want people to roll their eyes just when they see your name in a Mailbox, right? You're making a lot of Debian lists harder to bear. Yes, I know that you think that Frans and Jonas are forcing you to do all this, but that point of view is fatally flawed. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-aide-maintainers] Bug#391353: aide: Doesn't work suitably on Xen enabled kernel because of statically linked libc
clone #391353 -1 retitle -1 Should not DoS system if statically linked binary is run reassign -1 linux-image-2.6.18-1-xen-686 submitter -1 Marc Haber <[EMAIL PROTECTED]> block #391353 with -1 thanks On Fri, Oct 06, 2006 at 08:58:16AM +0200, Raphael Hertzog wrote: > I upgraded my personal server to etch and choosed to use a Xen enabled > kernel since we're going to have Xen support in etch (and also because > we're using this for the new alioth.debian.org so I wanted to have a > testbed for me). > > This morning my server was almost unreachable and while looking through > the logs I discovered those messages: > Oct 6 05:17:34 arrakeen kernel: printk: 246 messages suppressed. > Oct 6 05:17:34 arrakeen kernel: 4gb seg fixup, process aide (pid 1627), > cs:ip 73:080ae335 > Oct 6 05:17:40 arrakeen kernel: printk: 291 messages suppressed. > Oct 6 05:17:40 arrakeen kernel: 4gb seg fixup, process aide (pid 1627), > cs:ip 73:080ae335 > > Those messages appear when you use the standard libc6 instead of libc6-xen > on a Xen enabled kernel. However I have libc6-xen installed but aide > is using its own statically linked libc6 which thus generates this > message. > > Those messages means that the kernel worked around the bad libc6 but it's > extremely ineffective in doing so, so much that it effectively DOSsed my > server during the 3 hours when aide was running. I consider this a kernel bug. The kernel should not DoS the system in case a binary statically linked against a normal glibc is run. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Classification scheme for 2.6 kernel patches
On Tue, Jan 11, 2005 at 10:25:37AM +0100, Florian Weimer wrote: > * Marc Haber: > > On Sun, Jan 09, 2005 at 08:52:59PM +0100, Thiemo Seufer wrote: > >> Cherrypicking makes little sense, because there are only cherries. :-) > > > > For my systems, I care about security holes being fixed, but I do not > > care about some obscure video hardware, or additional features. So > > "Cherry" is relative. > > Fix upstream's security process, Broken beyond repair, IMO. > or use vendor kernels. Which is what I am trying to do. Debian is a vendor. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dealing with 2.4 bugreports that are fixed in 2.6 only
On Sun, Jun 27, 2004 at 05:29:38PM +0200, Christoph Hellwig wrote: > There's a few reports against 2.4 kernel that are fixed in 2.6 and are > unlikely to get in 2.4 every (Examples: #146956 or #130217). How should > we deal with them in the BTS? I'd leave them open, tagged wontfix, as a reference for other people who encounter the problem. If "Update to 2.6" is a workaround, this should be documented in the bug. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Karlsruhe, Germany | lose things."Winona Ryder | Fon: *49 721 966 32 15 Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29
Debian or vanilla kernel - best of both worlds possible?
Hi, in the last months, a lot of things have happened with regard to kernel development and packaging. I have been trying in the last weeks to assess these changes' implications on me as a somewhat advanced end-user who is accustomed to building custom kernel .debs from the upstream sources. Let's summarize what has happened. Please correct me if I have gotten anything wrong: - Herbert has resigned. The Debian kernel is now maintained by a group. - 2.6 Debian kernel sources use dpatch for local patches. This makes it easy to enable/disable single patches. - However, Debian's new policy is to remove non-free parts of the kernel. This can't be done by a patch, but must be done by re-packing the upstream tarball, destroying the "pristine source" approach for the kernels. - Kernel Upstream has basically abandoned the end user by declaring that the 2.6 kernels being released on kernel.org are not the most stable kernels, and that building kernels for use on production systems should be the distribution's job. My basic question is "How do I get a stable kernel by retaining best of all three worlds - Upstream, Debian, and my local requirements". A possible starting point for me would be the upstream kernel sources without the non-free firmware removed. This is necessary since hardware vendors will say "use the lastest driver from the Linux kernel", and I cannot argue against that my distribution had the drivers removed. The good news is that the Debian patch only creates files in debian/, which will make it apply cleanly even to vanilla kernel sources. Is it planned (documented as a committment of the kernel team) that this will stay that way? If yes, one could check out the Debian subdirectory without checking out the "real" kernel, which would greatly help in reducing download volume. Additional good news is that you guys use dpatch to actually change the kernel source. Do I see correctly that for example drivers-net-tg3-readd.dpatch was created because the .orig.tar.gz already had tg3 removed? The patch files themselves don't contain too much information about the character of the patch. Short comments inside the patch files themselves saying "fix local root exploit (CANxxx-yyy)" or "re-add tg3 support which was removed in orig.tar.gz", or "fix 'does not build' type error on $OBSCURE_ARCH" would be very appreciated. There seems to be documentation in README.Debian, but I am not too sure whether that list is current, and I am missing the reference to the patch file. Did I overlook something here? During preparation of this message, a few additional questions have popped up. Are the .svn directories inside kernel-source-2.6.7_2.6.7-4.diff.gz left there intentionally? The Description of kernel-patch-debian-2.6.7 says that it should be applied to a pristine 2.6.7 kernel. Does that still apply now that some drivers have been removed from the pristine kernel sources? IMO, kernel-patch-debian's description should also include some reference that the source package uses dpatch which makes it somewhat easier to choose patch sets. Let me sum up: Debian kernel development has recently made a huge leap forward. There are some questions which I would appreciate having answered, and some docs are missing (I can deliver them if I get my questions answered). The really bad things happening can easily be reverted locally. Please, keep up your excellent work. I would, however, appreciate answers to my questions. Thanks in advance. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Karlsruhe, Germany | lose things."Winona Ryder | Fon: *49 721 966 32 15 Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29
Re: Debian or vanilla kernel - best of both worlds possible?
On Thu, Aug 12, 2004 at 05:29:30PM +0200, Christoph Hellwig wrote: > On Thu, Aug 12, 2004 at 03:06:07PM +0200, Marc Haber wrote: > > - However, Debian's new policy is to remove non-free parts of the > > kernel. > > s/of the kernel//. But AFAICS there's been an exception granted for > sarge, so maybe we can add the firmware back except for those two cases > where the firmware license conflicts with the general kernel license. Yes, but I am talking about the general future. > > - Kernel Upstream has basically abandoned the end user by declaring > > that the 2.6 kernels being released on kernel.org are not the most > > stable kernels, and that building kernels for use on production > > systems should be the distribution's job. > > That's bullshit. Upstream kernels are fine for the end user, they are > not fine and never were for the 1% or less of ultra-extrem enterprise > user that want a tested in all possible variants, certified and changed > as little as possible kernel. You are aware that the upstream maintainers announced a change in their release management on kernel summit? > > The good news is that the Debian patch only creates files in debian/, > > which will make it apply cleanly even to vanilla kernel sources. Is it > > planned (documented as a committment of the kernel team) that this > > will stay that way? If yes, one could check out the Debian > > subdirectory without checking out the "real" kernel, which would > > greatly help in reducing download volume. > > Yes, it's our plan to keep it that way. Very good. > > Additional good news is that you guys use dpatch to actually change > > the kernel source. Do I see correctly that for example > > drivers-net-tg3-readd.dpatch was created because the .orig.tar.gz > > already had tg3 removed? > > Yes, but that's probably going to change a little for the 2.6.8-based > kernel (Jens wrote a sed snipplet to just remove the firmware images > from tg3.c) Yes, I am aware of that. > All patches have some comments like: > > ## DP: Description: Add 3ware 9xxx SATA-RAID driver > ## DP: Patch author: Adam Radford <[EMAIL PROTECTED]> > ## DP: Upstream status: merged after 2.6.7 > > or > > ## DP: Description: chown permission check fix for ATTR_GID > ## DP: Patch author: Chris Wright > ## DP: Upstream status: backport Yeah, but some people (including me) might not be able to judge the impact of a patch from these rather terse comments. For example, is Chris Wright's patch close a local root privilege escalation possibility, or does it only fix a "does not build" on mipsel? The comments are way too terse for somebody not following lkml, bugtraq and other discussion media be able to judge whether the patch is locally useful or not. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Karlsruhe, Germany | lose things."Winona Ryder | Fon: *49 721 966 32 15 Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29
Re: Debian or vanilla kernel - best of both worlds possible?
On Thu, Aug 12, 2004 at 05:35:07PM +0200, Sven Luther wrote: > On Thu, Aug 12, 2004 at 03:06:07PM +0200, Marc Haber wrote: > > The good news is that the Debian patch only creates files in debian/, > > which will make it apply cleanly even to vanilla kernel sources. Is it > > planned (documented as a committment of the kernel team) that this > > will stay that way? If yes, one could check out the Debian > > subdirectory without checking out the "real" kernel, which would > > greatly help in reducing download volume. > > Only the debian directory is found in the svn repo. So it is best checked out directly into an unpacked kernel tree? > > Are the .svn directories inside kernel-source-2.6.7_2.6.7-4.diff.gz > > left there intentionally? > No, it is an error. before building, one should always do a svn > export, to remove any cruft and local inconsistency. I had this > problem, and do that now, apparently Jens didn't for the 2.6.7-4 > upload. Would dpkg-buildpackage's -i option solve this issue? Or is an export really needed. > Hope these small answers will help some, They do, thanks. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Karlsruhe, Germany | lose things."Winona Ryder | Fon: *49 721 966 32 15 Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29
Re: Debian or vanilla kernel - best of both worlds possible?
On Thu, Aug 12, 2004 at 05:42:12PM +0200, Christoph Hellwig wrote: > On Thu, Aug 12, 2004 at 05:40:05PM +0200, Marc Haber wrote: > > You are aware that the upstream maintainers announced a change in > > their release management on kernel summit? > > I am part of the upstream maintainers, did attend kernel summit and > didn't see a big annoucement, just an discussion of existing and > on-going practice. I see. I didn't attend, and maybe the news was altered during its "stille post" style transport. > > Yeah, but some people (including me) might not be able to judge the > > impact of a patch from these rather terse comments. For example, is > > Chris Wright's patch close a local root privilege escalation > > possibility, or does it only fix a "does not build" on mipsel? The > > comments are way too terse for somebody not following lkml, bugtraq > > and other discussion media be able to judge whether the patch is > > locally useful or not. > > We can add a [sec] tag to security fixes for future patches. I'd still like the comments to be a little more verbose. I mean, that a patch adds a check of $VARIABLE, I can read from the patch myself, but I usually can't see why that check is necessary and which bad behavior is fixed by the additional check. Especially for security relevant checks, I'd like to see pointers to the security mailing lists or vulnerability codes. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Karlsruhe, Germany | lose things."Winona Ryder | Fon: *49 721 966 32 15 Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29
Bug#426440: /usr/sbin/pppd: sometimes connection with Option GlobeTrotter card hangs, ping: sendmsg: No buffer space available
On Sat, Jun 09, 2007 at 06:20:34AM +0200, Miernik wrote: > On Tue, May 29, 2007 at 03:20:51PM +0200, Marc Haber wrote: > > On Mon, May 28, 2007 at 10:09:04PM +0200, Miernik wrote: > > > ping: sendmsg: No buffer space available > > > > I have this as well, with both my Option 3G Datacard, and a borrowed > > Novatel 740. After killing the PPP connection, the virtual USB serial > > port simulated by the card is not responsive any more, AT commands are > > ignored. > > Marc, can you tell us several things: > > 1) Is at port responsive to AT commands before you kill the ppp > connection, but after it hangs? I don't know, since I need to kill the ppp connection to get access to the serial port, needn't I? > Mine is. After I kill the connection, I can just start a new > connection, and it works, I don't have to unload usbserial, nor > unplug the card. So things seem to be a bit different then in your > case. What kernel and pppd version are you running? I am usually running a fresh vanilla kernel and a rather current sid. I moved into a new apartment without broadband and had to use UMTS quite often since May 12 through June 5, when broadband was finally installed. The issue was present during the entire period. > 2) How often, after how much time of the connection running it usually > happens? Irregular intervals. Sometimes the connection is stable for hours, sometimes it dies after a few minutes. I also doubt that it is depending on traffic volume transported. > I have now two Option cards running: one is like this: > > ATI > Manufacturer: Option N.V. > Model: GlobeTrotter Fusion > Revision: 2.9.4 (Date: May 12 2005, Time: 10:55:21) > > (run "ATI" in minicom or picocom to see yours). ATI Manufacturer: Option Wireless Technology Model: 129 Revision: 3.1.2 (Date: Mar 08 2004, Time: 11:54:30) I used ser2net ;) > and has the first two letters of the serial number "RC". > See http://www.pharscape.org/content/view/40/53/ CL here. That link is a rather nice resource. I have returned the novatel card to my company who was nice enough to provide me with a SIM and PCMCIA card to use during my broadband-less time. > And this card uses usbserial. On this card it hangs very rarely, I have > been able to run it 7 days without a hang. And recently I had it hang, > but after I waited some hours it did unhang. I never waited that long, when the connection hang, I only waited a couple of minutes and then proceeded to reset. > and currently I upgraded the firmware to: > > Revision: 3.19.0Hd (Date: May 31 2006, Time: 15:49:25) Can I upgrade card firmware without Windows? > The longest noted time I was able to run this card on Debian without a > hang so far is: > > Connect time 1676.6 minutes. (that's 27h 56min 36s) > Sent 2459600 bytes, received 17972064 bytes. My personal record is 2219 minutes. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426440: /usr/sbin/pppd: sometimes connection with Option GlobeTrotter card hangs, ping: sendmsg: No buffer space available
On Sat, Jun 09, 2007 at 08:54:53AM +0200, Miernik wrote: > I searched a bit, and I now suspect that tha hangs might be because of > this bug: http://bugzilla.kernel.org/show_bug.cgi?id=6402 > They write that in vanilla kernel 2.6.15.7 it is fine, and the bug was > introduced in some later version, so now I am compiling 2.6.15.7 to see > if it'll fix it. You may try the same, your card is different hardware. > If you do try, tell me if it fixed it or not. I am reluctant to try a kernel that old on my personal notebook. I have broadband again now, and do not use the UMTS card that often any more. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428725: initramfs-tools: please provide hook to initialize LVM before mounting crypto-root
Package: initramfs-tools Version: 0.88 Severity: normal Hi, I have my root filesystem on an encrypted LV: $ grep root /etc/crypttab root /dev/vg0/c_root none luks,keyscript=/etc/keyscript_scyw00225 $ grep root /etc/fstab /dev/mapper/root / ext3defaults,errors=remount-ro 0 1 $ In this setup, the initrd does not start the LVM before trying to unlock the crypto filesystem. From my diagnosis, it looks like scripts/local-top/lvm2 looks whether the file system given to the kernel on its command line is directly on an LV and only starts the appropriate VG in this case. It does not seem to detect the possibility of the root FS being on an encrypted LV. A possible solution to this would be to provide a hook to override the ROOT variable for the lvm2 script. I have worked around this by copying the lvm2 script to /etc/initramfs-tools/scripts/local-top and to hardcode an "activate_vg /dev/mapper/vg0-c_root" there. Greetings Marc -- Package-specific info: -- /proc/cmdline root=/dev/mapper/root ro video=radeon:force_sleep,[EMAIL PROTECTED] initrd=initrd BOOT_IMAGE=vmlinuz -- /proc/filesystems cramfs ext3 -- lsmod Module Size Used by tun10304 1 ieee80211_crypt_ccmp 7008 2 appletalk 33632 2 ax25 49744 2 ipx26052 2 p8023 2080 1 ipx radeon110528 1 drm73908 2 radeon rfcomm 35480 7 hidp 18272 2 hid23680 1 hidp l2cap 22208 10 rfcomm,hidp ppdev 8580 0 lp 10884 0 tcp_diag1760 0 inet_diag 11336 2 tcp_diag ipv6 236320 18 button 7952 0 ac 5220 0 battery10020 0 binfmt_misc10984 1 cpufreq_powersave 1792 0 cpufreq_stats 5120 0 cpufreq_conservative 6888 0 cpufreq_ondemand7884 0 cpufreq_userspace 4128 1 speedstep_centrino 9220 1 freq_table 4512 3 cpufreq_stats,cpufreq_ondemand,speedstep_centrino sr_mod 16100 0 sbp2 21188 0 tsdev 7520 0 joydev 9152 0 irtty_sir 8064 0 pcmcia 35276 0 sir_dev15300 1 irtty_sir irda 172668 2 irtty_sir,sir_dev crc_ccitt 2144 1 irda parport_pc 32740 1 parport33672 3 ppdev,lp,parport_pc rtc12760 0 serio_raw 6564 0 psmouse34952 0 ipw2200 130628 0 pcspkr 3136 0 ieee80211 30984 1 ipw2200 ieee80211_crypt 5792 2 ieee80211_crypt_ccmp,ieee80211 snd_intel8x0 32060 5 i2c_i8018560 0 firmware_class 9408 2 pcmcia,ipw2200 snd_intel8x0m 16716 6 snd_ac97_codec 92356 2 snd_intel8x0,snd_intel8x0m ac97_bus2272 1 snd_ac97_codec snd_pcm_oss39168 0 snd_mixer_oss 15328 1 snd_pcm_oss snd_pcm71940 8 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss snd_timer 20868 3 snd_pcm snd48132 23 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer soundcore 7424 1 snd snd_page_alloc 9512 3 snd_intel8x0,snd_intel8x0m,snd_pcm i2c_core 20480 1 i2c_i801 yenta_socket 24876 3 rsrc_nonstatic 11968 1 yenta_socket pcmcia_core36884 3 pcmcia,yenta_socket,rsrc_nonstatic iTCO_wdt9956 0 hci_usb16220 6 bluetooth 48484 16 rfcomm,hidp,l2cap,hci_usb shpchp 30996 0 pci_hotplug29088 1 shpchp intel_agp 23004 1 agpgart32168 2 drm,intel_agp evdev 9216 5 eth139418276 0 ext3 120904 5 jbd55208 1 ext3 mbcache 8164 1 ext3 sha256 11008 0 aes27680 14 cbc 4256 6 blkcipher 5956 1 cbc dm_crypt 12808 1 raid10 22560 0 raid456 120336 0 xor14376 1 raid456 raid1 22080 0 raid0 7968 0 multipath 8416 0 linear 5856 0 md_mod 72628 6 raid10,raid456,raid1,raid0,multipath,linear ide_generic 1344 0 [permanent] dm_mirror 20116 0 dm_snapshot16420 0 dm_mod 52556 28 dm_crypt,dm_mirror,dm_snapshot ide_cd 36512 0 cdrom 32768 2 sr_mod,ide_cd ide_disk 15648 2 usb_
Bug#428730: initramfs-tools: underdocumented
Package: initramfs-tools Version: 0.88 Severity: minor Documentation of initramfs-tools is somewhat hard to find outside the sources. For example, I didn't find docs explaning the different meanings of the subdirectories in the scripts directory and the interaction between /usr/share/initramfs-tools and /etc/initramfs-tools. Please consider improving the docs. Greetings Marc -- Package-specific info: -- /proc/cmdline root=/dev/mapper/root ro video=radeon:force_sleep,[EMAIL PROTECTED] initrd=initrd BOOT_IMAGE=vmlinuz -- /proc/filesystems cramfs ext3 -- lsmod Module Size Used by tun10304 1 ieee80211_crypt_ccmp 7008 2 appletalk 33632 2 ax25 49744 2 ipx26052 2 p8023 2080 1 ipx radeon110528 1 drm73908 2 radeon rfcomm 35480 7 hidp 18272 2 hid23680 1 hidp l2cap 22208 10 rfcomm,hidp ppdev 8580 0 lp 10884 0 tcp_diag1760 0 inet_diag 11336 2 tcp_diag ipv6 236320 18 button 7952 0 ac 5220 0 battery10020 0 binfmt_misc10984 1 cpufreq_powersave 1792 0 cpufreq_stats 5120 0 cpufreq_conservative 6888 0 cpufreq_ondemand7884 0 cpufreq_userspace 4128 1 speedstep_centrino 9220 1 freq_table 4512 3 cpufreq_stats,cpufreq_ondemand,speedstep_centrino sr_mod 16100 0 sbp2 21188 0 tsdev 7520 0 joydev 9152 0 irtty_sir 8064 0 pcmcia 35276 0 sir_dev15300 1 irtty_sir irda 172668 2 irtty_sir,sir_dev crc_ccitt 2144 1 irda parport_pc 32740 1 parport33672 3 ppdev,lp,parport_pc rtc12760 0 serio_raw 6564 0 psmouse34952 0 ipw2200 130628 0 pcspkr 3136 0 ieee80211 30984 1 ipw2200 ieee80211_crypt 5792 2 ieee80211_crypt_ccmp,ieee80211 snd_intel8x0 32060 1 i2c_i8018560 0 firmware_class 9408 2 pcmcia,ipw2200 snd_intel8x0m 16716 6 snd_ac97_codec 92356 2 snd_intel8x0,snd_intel8x0m ac97_bus2272 1 snd_ac97_codec snd_pcm_oss39168 0 snd_mixer_oss 15328 1 snd_pcm_oss snd_pcm71940 6 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss snd_timer 20868 1 snd_pcm snd48132 19 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer soundcore 7424 1 snd snd_page_alloc 9512 3 snd_intel8x0,snd_intel8x0m,snd_pcm i2c_core 20480 1 i2c_i801 yenta_socket 24876 3 rsrc_nonstatic 11968 1 yenta_socket pcmcia_core36884 3 pcmcia,yenta_socket,rsrc_nonstatic iTCO_wdt9956 0 hci_usb16220 6 bluetooth 48484 16 rfcomm,hidp,l2cap,hci_usb shpchp 30996 0 pci_hotplug29088 1 shpchp intel_agp 23004 1 agpgart32168 2 drm,intel_agp evdev 9216 5 eth139418276 0 ext3 120904 5 jbd55208 1 ext3 mbcache 8164 1 ext3 sha256 11008 0 aes27680 14 cbc 4256 6 blkcipher 5956 1 cbc dm_crypt 12808 1 raid10 22560 0 raid456 120336 0 xor14376 1 raid456 raid1 22080 0 raid0 7968 0 multipath 8416 0 linear 5856 0 md_mod 72628 6 raid10,raid456,raid1,raid0,multipath,linear ide_generic 1344 0 [permanent] dm_mirror 20116 0 dm_snapshot16420 0 dm_mod 52556 28 dm_crypt,dm_mirror,dm_snapshot ide_cd 36512 0 cdrom 32768 2 sr_mod,ide_cd ide_disk 15648 2 usb_storage76384 0 piix9508 0 [permanent] generic 4804 0 [permanent] ide_core 115016 6 ide_generic,ide_cd,ide_disk,usb_storage,piix,generic tg399812 0 ohci1394 32432 0 ieee1394 89560 3 sbp2,eth1394,ohci1394 ata_generic 8100 0 libata109172 1 ata_generic scsi_mod 133740 4 sr_mod,sbp2,usb_storage,libata ehci_hcd 30796 0 uhci_hcd 22608 0 usbcore 123304 5 hci_usb,usb_storage,ehci_hcd,uhci_h
Bug#428729: does not execute all scripts in /etc/initramfs-tools/scripts/local-top
Package: initramfs-tools Version: 0.88 Severity: minor Hi, The regexp used to decide whether a script in /etc/initramfs-tools/scripts/local-top/prelvm2 gets executed or not is considerably more restrictive than the code found in other packages, such as in run-parts. For example, they allow hyphens in the file name, while initramfs-tools does not. This is kind of a surprise. On a second thought, it might be a good idea to print debug output like "not using pre-lvm2 for initrd because of illegal character - in file name". Greetings Marc -- Package-specific info: -- /proc/cmdline root=/dev/mapper/root ro video=radeon:force_sleep,[EMAIL PROTECTED] initrd=initrd BOOT_IMAGE=vmlinuz -- /proc/filesystems cramfs ext3 -- lsmod Module Size Used by tun10304 1 ieee80211_crypt_ccmp 7008 2 appletalk 33632 2 ax25 49744 2 ipx26052 2 p8023 2080 1 ipx radeon110528 1 drm73908 2 radeon rfcomm 35480 7 hidp 18272 2 hid23680 1 hidp l2cap 22208 10 rfcomm,hidp ppdev 8580 0 lp 10884 0 tcp_diag1760 0 inet_diag 11336 2 tcp_diag ipv6 236320 18 button 7952 0 ac 5220 0 battery10020 3 binfmt_misc10984 1 cpufreq_powersave 1792 0 cpufreq_stats 5120 0 cpufreq_conservative 6888 0 cpufreq_ondemand7884 0 cpufreq_userspace 4128 1 speedstep_centrino 9220 1 freq_table 4512 3 cpufreq_stats,cpufreq_ondemand,speedstep_centrino sr_mod 16100 0 sbp2 21188 0 tsdev 7520 0 joydev 9152 0 irtty_sir 8064 0 pcmcia 35276 0 sir_dev15300 1 irtty_sir irda 172668 2 irtty_sir,sir_dev crc_ccitt 2144 1 irda parport_pc 32740 1 parport33672 3 ppdev,lp,parport_pc rtc12760 0 serio_raw 6564 0 psmouse34952 0 ipw2200 130628 0 pcspkr 3136 0 ieee80211 30984 1 ipw2200 ieee80211_crypt 5792 2 ieee80211_crypt_ccmp,ieee80211 snd_intel8x0 32060 1 i2c_i8018560 0 firmware_class 9408 2 pcmcia,ipw2200 snd_intel8x0m 16716 6 snd_ac97_codec 92356 2 snd_intel8x0,snd_intel8x0m ac97_bus2272 1 snd_ac97_codec snd_pcm_oss39168 0 snd_mixer_oss 15328 1 snd_pcm_oss snd_pcm71940 6 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss snd_timer 20868 1 snd_pcm snd48132 19 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer soundcore 7424 1 snd snd_page_alloc 9512 3 snd_intel8x0,snd_intel8x0m,snd_pcm i2c_core 20480 1 i2c_i801 yenta_socket 24876 3 rsrc_nonstatic 11968 1 yenta_socket pcmcia_core36884 3 pcmcia,yenta_socket,rsrc_nonstatic iTCO_wdt9956 0 hci_usb16220 6 bluetooth 48484 16 rfcomm,hidp,l2cap,hci_usb shpchp 30996 0 pci_hotplug29088 1 shpchp intel_agp 23004 1 agpgart32168 2 drm,intel_agp evdev 9216 5 eth139418276 0 ext3 120904 5 jbd55208 1 ext3 mbcache 8164 1 ext3 sha256 11008 0 aes27680 14 cbc 4256 6 blkcipher 5956 1 cbc dm_crypt 12808 1 raid10 22560 0 raid456 120336 0 xor14376 1 raid456 raid1 22080 0 raid0 7968 0 multipath 8416 0 linear 5856 0 md_mod 72628 6 raid10,raid456,raid1,raid0,multipath,linear ide_generic 1344 0 [permanent] dm_mirror 20116 0 dm_snapshot16420 0 dm_mod 52556 28 dm_crypt,dm_mirror,dm_snapshot ide_cd 36512 0 cdrom 32768 2 sr_mod,ide_cd ide_disk 15648 2 usb_storage76384 0 piix9508 0 [permanent] generic 4804 0 [permanent] ide_core 115016 6 ide_generic,ide_cd,ide_disk,usb_storage,piix,generic tg399812 0 ohci1394 32432 0 ieee1394 89560 3 sbp2,eth1394,ohci1394 ata_generic 8100 0 libata109172 1 ata_generic scsi_mod 133740 4
Bug#428730: initramfs-tools: underdocumented
On Fri, Jun 15, 2007 at 05:56:15PM +0200, maximilian attems wrote: > On Wed, 13 Jun 2007, Marc Haber wrote: > > Documentation of initramfs-tools is somewhat hard to find outside the > > sources. > > hmmm, > man initramfs-tools ;) Very well. This answers a lot of the questions I had. I was not looking for a man page for the package name. Please consider adding a hint to that (excellent) man page to README.Debian. > > For example, I didn't find docs explaning the different meanings of the > > subdirectories in the scripts directory and the interaction between > > /usr/share/initramfs-tools and /etc/initramfs-tools. > > the second takes advantage, > did you read aboves manpage? I did now. > > Please consider improving the docs. > > it does not explain the diff between the locations, > but the thought is that the first location is for packages > and the second is for local admins thus overruling the first place. That's clear to the experienced user, yes. The issues left over by your answer are relatively minor, please close this bug at your convenience. Thanks for answering. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WiFi in Debian 'etch'
On Sat, Aug 18, 2007 at 04:06:30PM +0400, [EYE-T] wrote: > Hello. How can I fix the ploblem? > > ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.1.2kmq > ipw2200: Copyright(c) 2003-2006 Intel Corporation > ACPI: PCI Interrupt :04:02.0[A] -> GSI 21 (level, low) -> IRQ 58 > ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection > ipw2200: ipw2200-bss.fw request_firmware failed: Reason -2 > ipw2200: Unable to load firmware: -2 > ipw2200: failed to register network device By reading the docs and installing the appropriate firmware. Sheesh. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#573761: /usr/sbin/update-initramfs: misleading error message if crypto-root fs has snapshot
Package: initramfs-tools Version: 0.93.4 Severity: normal File: /usr/sbin/update-initramfs Hi, my system has its root FS on a crypted LV. Recently, before doing a rather invasive update, I decided to take a snapshot of the root FS. This confuses update-initramfs: [29/526...@swivel:~/bigstuff/agent/running$ sudo lvcreate --snapshot --size 1G --name c_rootsnap /dev/swivel/c_root Logical volume "c_rootsnap" created [30/527...@swivel:~/bigstuff/agent/running$ sudo update-initramfs -k 2.6.33-zgws1 -u update-initramfs: Generating /boot/initrd.img-2.6.33-zgws1 mkinitramfs: for root /dev/mapper/root missing dm- /sys/block/ entry mkinitramfs: workaround is MODULES=most mkinitramfs: Error please report the bug update-initramfs: failed for /boot/initrd.img-2.6.33-zgws1 [31/528...@swivel:~/bigstuff/agent/running$ sudo lvremove /dev/mapper/swivel-c_rootsnap Do you really want to remove active logical volume c_rootsnap? [y/n]: y Logical volume "c_rootsnap" successfully removed [32/529...@swivel:~/bigstuff/agent/running$ sudo update-initramfs -k 2.6.33-zgws1 -u update-initramfs: Generating /boot/initrd.img-2.6.33-zgws1 W: mdadm: /etc/mdadm/mdadm.conf defines no arrays. W: mdadm: no arrays defined in configuration file. [33/530...@swivel:~/bigstuff/agent/running$ Greetings Marc -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-2.6.33-zgws1 root=/dev/mapper/root ro resume=/dev/mapper/swap1 quiet splash hpet=force video=radeon:force_sleep,1400x1050...@60 -- /proc/filesystems ext3 udf iso9660 vfat -- lsmod Module Size Used by iwl394562453 0 iwlcore75506 1 iwl3945 mac80211 106524 2 iwl3945,iwlcore cfg80211 73546 3 iwl3945,iwlcore,mac80211 iptable_filter 1030 0 ipt_MASQUERADE 1130 8 iptable_nat 2798 1 nf_nat 10767 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 7663 3 iptable_nat,nf_nat nf_defrag_ipv4 799 1 nf_conntrack_ipv4 ip_tables 7397 2 iptable_filter,iptable_nat vfat6820 0 fat36008 1 vfat isofs 25174 0 nls_utf8 928 0 udf62456 0 usb_storage29897 0 tun 8884 2 binfmt_misc 4883 1 rfcomm 25525 6 sco 6231 2 bnep7203 2 l2cap 25549 16 rfcomm,bnep crc16 1011 1 l2cap vboxnetflt 10598 0 vboxnetadp 5186 0 vboxdrv 116590 2 vboxnetflt,vboxnetadp nf_conntrack_netlink12636 0 nf_conntrack 39683 5 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4,nf_conntrack_netlink nfnetlink 1838 6 nf_conntrack_netlink ipt_ULOG4461 1 x_tables9112 4 ipt_MASQUERADE,iptable_nat,ip_tables,ipt_ULOG ppdev 4294 0 lp 5768 0 parport12962 2 ppdev,lp acpi_cpufreq5055 1 cpufreq_powersave606 0 cpufreq_userspace 1372 2 cpufreq_conservative 7036 0 cpufreq_ondemand6169 0 freq_table 1743 2 acpi_cpufreq,cpufreq_ondemand 8021q 14027 0 bridge 35340 0 stp 1032 1 bridge llc 2613 2 bridge,stp ipv6 195862 38 sr_mod 11469 0 cdrom 25675 1 sr_mod firewire_sbp2 9669 0 snd_hda_codec_analog46653 1 snd_hda_intel 16009 4 btusb 8416 2 snd_hda_codec 42520 2 snd_hda_codec_analog,snd_hda_intel snd_pcm_oss28573 0 bluetooth 38935 9 rfcomm,sco,bnep,l2cap,btusb snd_mixer_oss 11983 1 snd_pcm_oss arc4 994 2 ecb 1489 2 snd_pcm48251 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss snd_seq_dummy959 0 snd_seq_oss21024 0 radeon543860 1 snd_seq_midi3496 0 snd_rawmidi13140 1 snd_seq_midi snd_seq_midi_event 3968 2 snd_seq_oss,snd_seq_midi pcmcia 23354 0 snd_seq35503 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event ttm34114 1 radeon sdhci_pci 5047 0 sdhci 11863 1 sdhci_pci drm_kms_helper 18609 1 radeon snd_timer 13290 2 snd_pcm,snd_seq snd_seq_device 3965 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq firewire_ohci 17736 0 yenta_socket8878 1 mmc_core 39316 1 sdhci ata_generic 2063 0 drm 116981 3 radeon,ttm,drm_kms_helper rtc_cmos6858 0 i2c_i8015880 0 snd36436 19 snd_hd
Bug#575501: initramfs-tools: radeon.ko not included into initrd
Package: initramfs-tools Version: 0.93.4 Severity: wishlist This may not be a genuine bug, but maybe an understanding problem that I have not been able to solve in other media. I have two systems that are supposed to use KMS. One is working fine, having an i915 graphics chip. On this system, i915.ko is copied into the initramfs, and autoloaded if video=i915:modeset=1 is given on the kernel command line. The second one has an 01:00.0 VGA compatible controller: ATI Technologies Inc M56GL [Mobility FireGL V5200] and is not working properly. I understand that radeon.ko needs to be in the initrd for early loading to work, and this doesn't happen, and I am at a loss to explain why this doesn happen. For what it's worth, I didn't find any configuration that explicitly causes the i915.ko to be included in the initramfs on the Intel system, so I couldn't reproduce this configuration for radeon on the other box. Who is responsible to include the intel module into the initramfs on the Intel box, and who should change what to do the same for radeon? Greetings Marc -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-2.6.33.1-zgws1 root=/dev/mapper/root ro resume=/dev/mapper/swap0 quiet splash video=radeon:modeset=1 -- /proc/filesystems ext3 udf iso9660 vfat -- lsmod Module Size Used by vfat6820 0 fat36008 1 vfat isofs 25174 0 nls_utf8 928 0 udf62456 0 tun 8884 2 snd_intel8x0m 8400 0 snd_ac97_codec 80225 1 snd_intel8x0m ac97_bus 742 1 snd_ac97_codec ppdev 4294 0 lp 5768 0 parport12962 2 ppdev,lp sco 6231 2 bnep7203 2 l2cap 25549 3 bnep crc16 1011 1 l2cap bluetooth 38935 5 sco,bnep,l2cap ipt_ULOG4461 1 vboxnetadp 5186 0 vboxnetflt 10598 0 vboxdrv 116590 2 vboxnetadp,vboxnetflt acpi_cpufreq5059 1 cpufreq_powersave606 0 cpufreq_userspace 1372 0 cpufreq_conservative 7036 0 cpufreq_ondemand6169 2 freq_table 1743 2 acpi_cpufreq,cpufreq_ondemand iptable_filter 1030 0 ipt_MASQUERADE 1130 10 iptable_nat 2798 1 nf_nat 10767 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 7663 3 iptable_nat,nf_nat nf_conntrack 39683 4 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4 nf_defrag_ipv4 799 1 nf_conntrack_ipv4 ip_tables 7397 2 iptable_filter,iptable_nat x_tables9112 4 ipt_ULOG,ipt_MASQUERADE,iptable_nat,ip_tables binfmt_misc 4883 1 8021q 14027 0 bridge 35340 0 stp 1032 1 bridge llc 2613 2 bridge,stp ipv6 195878 40 mmc_block 6589 0 snd_hda_codec_analog46653 1 snd_hda_intel 16049 4 snd_hda_codec 42520 2 snd_hda_codec_analog,snd_hda_intel snd_pcm_oss28573 0 arc4 994 2 snd_mixer_oss 11983 1 snd_pcm_oss ecb 1489 2 snd_pcm48151 5 snd_intel8x0m,snd_ac97_codec,snd_hda_intel,snd_hda_codec,snd_pcm_oss snd_seq_dummy959 0 snd_seq_oss21024 0 snd_seq_midi3496 0 snd_rawmidi13140 1 snd_seq_midi iwl394562461 0 pcmcia 23354 0 snd_seq_midi_event 3968 2 snd_seq_oss,snd_seq_midi iwlcore75518 1 iwl3945 snd_seq35503 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event sdhci_pci 5047 0 firewire_ohci 17740 0 mac80211 106608 2 iwl3945,iwlcore tifm_sd 6410 0 snd_timer 13290 2 snd_pcm,snd_seq ata_generic 2063 0 tg396671 0 tifm_7xx1 3114 0 yenta_socket8878 1 sdhci 11863 1 sdhci_pci snd_seq_device 3965 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq cfg80211 92531 3 iwl3945,iwlcore,mac80211 firewire_core 33273 1 firewire_ohci ata_piix 17129 0 rsrc_nonstatic 7483 1 yenta_socket mmc_core 39316 3 mmc_block,tifm_sd,sdhci uhci_hcd 16204 0 rfkill 11140 3 bluetooth,cfg80211 libphy 12387 1 tg3 led_class 1873 1 sdhci tifm_core 3448 2 tifm_sd,tifm_7xx1 crc_itu_t 1015 2 udf,firewire_core ehci_hcd 26606 0 snd36436 21 snd_intel8x0m,snd_ac97_codec,snd_hda_codec_analog,snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_mixe
Bug#575501: initramfs-tools: radeon.ko not included into initrd
On Fri, Mar 26, 2010 at 01:04:40PM +0100, Bastian Blank wrote: > On Fri, Mar 26, 2010 at 12:31:32PM +0100, Marc Haber wrote: > > The second one has an > > 01:00.0 VGA compatible controller: ATI Technologies Inc M56GL [Mobility > > FireGL V5200] > > and is not working properly. I understand that radeon.ko needs to be > > in the initrd for early loading to work, and this doesn't happen, and > > I am at a loss to explain why this doesn happen. > > Loading drivers which needs firmware this early is currently broken. I see. So there is no KMS for radeon at this time? Is there a bug report about that for reference? > > For what it's worth, I didn't find any configuration that explicitly > > causes the i915.ko to be included in the initramfs on the Intel > > system, > > It is not included. < /boot/inird.img-2.6.33-zgws1 gunzip | cpio -i leads to a directory tree which includes a file lib/modules/*/i915.ko. This I clearly remember. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100326122538.ge6...@torres.zugschlus.de
Bug#575501: initramfs-tools: radeon.ko not included into initrd
Hi, On Fri, Mar 26, 2010 at 02:20:06PM +0100, Bastian Blank wrote: > On Fri, Mar 26, 2010 at 01:25:38PM +0100, Marc Haber wrote: > > On Fri, Mar 26, 2010 at 01:04:40PM +0100, Bastian Blank wrote: > > > On Fri, Mar 26, 2010 at 12:31:32PM +0100, Marc Haber wrote: > > > > The second one has an > > > > 01:00.0 VGA compatible controller: ATI Technologies Inc M56GL [Mobility > > > > FireGL V5200] > > > > and is not working properly. I understand that radeon.ko needs to be > > > > in the initrd for early loading to work, and this doesn't happen, and > > > > I am at a loss to explain why this doesn happen. > > > Loading drivers which needs firmware this early is currently broken. > > I see. So there is no KMS for radeon at this time? > > There is. The radeon module is loaded by udev later from the real > system. This doesn't seem to work here, as the modeset-parameter never gets its way to the module, despite /etc/modprobe.d/radeon-kms.conf saying "options radeon modeset=1". Also, in my understanding, if I want a splashscreen to be shown, the graphics driver moduled needs to be loaded early, right? Are the directfb-based splash screens such as splahy compatible with KMS in the first place? Greetings Marc > > < /boot/inird.img-2.6.33-zgws1 gunzip | cpio -i leads to a directory > > tree which includes a file lib/modules/*/i915.ko. This I clearly > > remember. > > | $ gunzip -c initrd.img-2.6.32-4-686-bigmem | cpio -tv | grep -a i915 > | -rw-r--r-- 1 root root 23 Jan 7 23:51 > etc/modprobe.d/i915-kms.conf > | 12920 blocks What are you trying to say? You need to be a little bit more verbose to be actually helpful. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100326133947.gg6...@torres.zugschlus.de
Bug#578007: initramfs-tools: no lvm in initramfs with 0.94.4
Package: initramfs-tools Version: 0.94.4 Severity: important Hi, when building my initramfs with initramfs-tools 0.94.4, I end up without scripts/local-top/lvm, hence an unbootable system. Downgrading initramfs-tools to 0.92o from stable fixes the issue. The following data was collected after the downgrade and might thus not exactly represent the state of the system at the time of the bug. Greetings Marc -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-2.6.33.2-zgws1 root=/dev/mapper/root ro resume=/dev/mapper/swap0 quiet splash video=radeon:modeset=0 -- /proc/filesystems ext3 -- lsmod Module Size Used by tun 2 lib80211_crypt_ccmp 3719 2 ppdev 4294 0 lp 5768 0 rfcomm 25565 4 sco 6247 2 bnep7211 2 l2cap 25577 16 rfcomm,bnep crc16 1011 1 l2cap ipt_ULOG4461 1 vboxnetadp 5186 0 vboxnetflt 10586 0 vboxdrv 117006 2 vboxnetadp,vboxnetflt acpi_cpufreq5059 0 cpufreq_powersave606 0 cpufreq_userspace 1372 0 cpufreq_conservative 7036 0 cpufreq_ondemand6169 1 freq_table 1743 2 acpi_cpufreq,cpufreq_ondemand iptable_filter 1030 0 ipt_MASQUERADE 1130 10 iptable_nat 2798 1 nf_nat 10767 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 7663 3 iptable_nat,nf_nat nf_conntrack 39743 4 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4 nf_defrag_ipv4 799 1 nf_conntrack_ipv4 ip_tables 7397 2 iptable_filter,iptable_nat x_tables9112 4 ipt_ULOG,ipt_MASQUERADE,iptable_nat,ip_tables binfmt_misc 4883 1 8021q 14027 0 bridge 35340 0 stp 1032 1 bridge llc 2613 2 bridge,stp ipv6 196115 38 snd_intel8x0 20043 3 snd_intel8x0m 8400 5 snd_ac97_codec 80233 2 snd_intel8x0,snd_intel8x0m ac97_bus 742 1 snd_ac97_codec snd_pcm_oss28573 0 snd_mixer_oss 11983 1 snd_pcm_oss snd_pcm48151 7 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss snd_seq_dummy959 0 snd_seq_oss21024 0 pcmcia 23354 0 snd_seq_midi3496 0 ipw2200 101601 0 snd_rawmidi13140 1 snd_seq_midi libipw 19140 1 ipw2200 snd_seq_midi_event 3968 2 snd_seq_oss,snd_seq_midi snd_seq35503 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event btusb 8416 2 yenta_socket8878 3 snd_timer 13290 3 snd_pcm,snd_seq cfg80211 92511 2 ipw2200,libipw rsrc_nonstatic 7483 1 yenta_socket snd_seq_device 3965 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq bluetooth 38935 9 rfcomm,sco,bnep,l2cap,btusb rfkill 11140 3 cfg80211,bluetooth pcmcia_core22364 3 pcmcia,yenta_socket,rsrc_nonstatic snd36436 23 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device lib802112938 3 lib80211_crypt_ccmp,ipw2200,libipw parport_pc 16931 1 i2c_i8015888 0 soundcore 4143 1 snd rtc_cmos6858 0 parport12962 3 ppdev,lp,parport_pc intel_agp 19857 1 rng_core2398 0 snd_page_alloc 5185 3 snd_intel8x0,snd_intel8x0m,snd_pcm video 15566 0 psmouse28445 0 rtc_core9649 1 rtc_cmos rtc_lib 1349 1 rtc_core output 1292 1 video pcspkr 1259 0 evdev 5985 15 ext3 87833 8 jbd33535 1 ext3 mbcache 3990 1 ext3 sha256_generic 11161 18 aes_i5866860 20 aes_generic25762 1 aes_i586 cbc 1995 9 dm_crypt8935 9 dm_mirror 10125 0 dm_region_hash 5776 1 dm_mirror dm_log 7044 2 dm_mirror,dm_region_hash dm_snapshot24779 0 dm_mod 46730 53 dm_crypt,dm_mirror,dm_log,dm_snapshot raid45640328 0 async_raid6_recov 2806 1 raid456 async_pq1392 2 raid456,async_raid6_recov raid6_pq 77980 2 async_raid6_recov,async_pq async_xor865 3 raid456,async_raid6_recov,async_pq xor13829 1 async_xor async_memcpy 586 2 raid456,async_raid6_recov async_tx1169 5 raid456,async_raid6_r
Bug#531158: initramfs-tools: please consider having the initrd create /forcefsck at a kernel command line option
Package: initramfs-tools Version: 0.93.2 Severity: wishlist Hi, I'd like to be able to force an fsck from the kernel command line. For example, the initrd could touch /forcefsck if the kernel command line contains the string forcefsck. Please consider implementing this function. Greetings Marc -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548148: initramfs-tools: add verbose debug output to run_scripts function
Package: initramfs-tools
Version: 0.93.4
Severity: wishlist
Tags: patch
Hi,
please consider adding the following obvious patch to
initramfs-tools/scripts/functions:
--- functions.orig 2009-09-24 10:42:11.0 +0200
+++ functions 2009-09-24 10:42:13.0 +0200
@@ -207,6 +207,9 @@
[ ! -d ${initdir} ] && return
get_prereqs
reduce_prereqs
+ if [ "${verbose}" = "y" ]; then
+ echo "Hook $initdir run list: $runlist"
+ fi
call_scripts
}
Unfortunately, this is untested since I couldn't figure out to
actually have the verbose variable set. Giving "verbose" on the kernel
command line doesn't seem to do it.
Greetings
Marc
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531158: closed by maximilian attems (Re: initramfs-tools: please consider having the initrd create /forcefsck at a kernel command line option)
On Thu, Sep 24, 2009 at 11:36:04PM +, Debian Bug Tracking System wrote: > nice idea, but sorry we want faster boot and not add more complications > in the initramfs. fsck has to happen after init(8) call. In this case, the bug should be marked wontfix instead of being closed. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian Kernel Group Meeting
On Thu, Oct 15, 2009 at 01:31:06PM +0100, Vincent Sanders wrote: > This became a discussion about the general kernel packaging and how we > might use the upstream provided facilities better. There was some > discussion we have way too many ways to build a kernel. > > A general agreement was reached that "make-kpkg" should go away as > it is no longer adequately maintained. Action item for Vince to tell > Manoj it is deprecated and thank him for his contribution. What will be the recommended way to package locally built kernels in a .deb? At the moment, it looks like kernel-package will be a real loss for Debian users. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian Kernel Group Meeting
On Sun, Oct 18, 2009 at 06:49:53PM +0100, Ben Hutchings wrote: > On Sun, 2009-10-18 at 18:34 +0200, Marc Haber wrote: > > On Thu, Oct 15, 2009 at 01:31:06PM +0100, Vincent Sanders wrote: > > > This became a discussion about the general kernel packaging and how we > > > might use the upstream provided facilities better. There was some > > > discussion we have way too many ways to build a kernel. > > > > > > A general agreement was reached that "make-kpkg" should go away as > > > it is no longer adequately maintained. Action item for Vince to tell > > > Manoj it is deprecated and thank him for his contribution. > > > > What will be the recommended way to package locally built kernels in a > > .deb? At the moment, it looks like kernel-package will be a real loss > > for Debian users. > > make deb-pkg >From the official Debian kernel-tree? How is one working if one uses the vanilla kernel? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Building vanilla kernel .debs
Hi, On Sun, Oct 18, 2009 at 07:47:25PM +0100, Ben Hutchings wrote: > On Sun, 2009-10-18 at 20:37 +0200, Marc Haber wrote: > > On Sun, Oct 18, 2009 at 06:49:53PM +0100, Ben Hutchings wrote: > > > On Sun, 2009-10-18 at 18:34 +0200, Marc Haber wrote: > > > > What will be the recommended way to package locally built kernels in a > > > > .deb? At the moment, it looks like kernel-package will be a real loss > > > > for Debian users. > > > > > > make deb-pkg > > > > >From the official Debian kernel-tree? How is one working if one uses > > the vanilla kernel? > > You didn't try it, did you? ;-) Not in a vanilla kernel tree, I didn't dream of .deb support being included upstream. Is there any documentation about which features are available? 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, append a string to the version number and a debian revision. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Building vanilla kernel .debs
Hi, On Sun, Oct 18, 2009 at 10:21:00PM +0200, maximilian attems wrote: > On Sun, Oct 18, 2009 at 09:53:58PM +0200, Marc Haber wrote: > > Not in a vanilla kernel tree, I didn't dream of .deb support being > > included upstream. > > it was lingering for quite some time, massaged it for 2.6.31. > actually submitted by Wichert Akkerman in 2003 upstream! I don't know whether I like the idea of relying on upstream to provide a current version of a debian-related script. Does the kernel-team maintain the respective script in their vcs, and can I simply dump your version into a vanilla tree? > > 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. I'll take a look, cheers. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Building vanilla kernel .debs
On Tue, Oct 20, 2009 at 09:52:21AM +0200, maximilian attems wrote: > On Tue, Oct 20, 2009 at 08:51:45AM +0200, Marc Haber wrote: > > I don't know whether I like the idea of relying on upstream to provide > > a current version of a debian-related script. Does the kernel-team > > maintain the respective script in their vcs, and can I simply dump > > your version into a vanilla tree? > > we maintain the upstream script and yes upstream is very responsive > to our patches. There is currently no seperated git tree for it, > as patches gets mailed to linux-kbuild and applied to that tree. So the most current version is in the upstream kernel git? > great, thanks for feeding us with critics and requirements. You're welcome. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Building vanilla kernel .debs
On Tue, Oct 20, 2009 at 01:42:02PM +0200, maximilian attems wrote: > On Tue, Oct 20, 2009 at 11:35:01AM +0200, Marc Haber wrote: > > So the most current version is in the upstream kernel git? > > kernel guys are currently in the summit so latest 2 patches > related to fakeroot didn't yet land in kbuild git and linux-next. > http://marc.info/?l=linux-kbuild&m=125561337922614&w=2 > http://marc.info/?l=linux-kbuild&m=125561358622933&w=2 After applying these two patches to scripts/package/builddeb from current upstream kernel git (they don't apply to 2.6.31.4), make deb-pkg KBUILD_PKG_ROOTCMD="fakeroot -u" produces packages (which I haven't tested yet). Thanks. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Building vanilla kernel .debs
Hi, On Sun, Oct 18, 2009 at 10:21:00PM +0200, maximilian attems wrote: > On Sun, Oct 18, 2009 at 09:53:58PM +0200, Marc Haber wrote: > > 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. I actually mean the upstream version, not the actual version of the resulting Debian package. When one uses make-kpkg --append=-foo --revision=2.6.31.4.20091013.0, one gets, for example, a linux-image-2.6.31.4-foo_2.6.31.4.20091013.0_i386.deb of a kernel which actually returns 2.6.31.4-foo as answer to uname -r. This is important if one wants to have different kernel flavours including their own module directory. The equivalent to --revision is KDEB_PKGVERSION, but I haven't yet found a way to emulate --append, since this probably needs modification to the upstream version number ending up in include/linux/utsrelease.h. Is there a variable for this as well, or is the official way to do so parsing EXTRAVERSION from the top-level Makefile and make all EXTRAVERSION=$EXTRAVERSION-foo? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Building vanilla kernel .debs
Hi, On Mon, Oct 26, 2009 at 02:58:08PM +0100, Marc Haber wrote: > On Tue, Oct 20, 2009 at 01:42:02PM +0200, maximilian attems wrote: > > On Tue, Oct 20, 2009 at 11:35:01AM +0200, Marc Haber wrote: > > > So the most current version is in the upstream kernel git? > > > > kernel guys are currently in the summit so latest 2 patches > > related to fakeroot didn't yet land in kbuild git and linux-next. > > http://marc.info/?l=linux-kbuild&m=125561337922614&w=2 > > http://marc.info/?l=linux-kbuild&m=125561358622933&w=2 > > After applying these two patches to scripts/package/builddeb from > current upstream kernel git (they don't apply to 2.6.31.4), make > deb-pkg KBUILD_PKG_ROOTCMD="fakeroot -u" produces packages (which I > haven't tested yet). Thanks. Is it a feature that the linux-firmware package doesn't have the upstream kernel version in its name? $ make deb-pkg (...) dpkg-deb: building package linux-firmware-image' in ../linux-firmware-image_2.6.31.4.20091026.4_all.deb'. dpkg-deb: building package linux-image-2.6.31.4-zgws1' in ../linux-image-2.6.31.4-zgws1_2.6.31.4.20091026.4_i386.deb'. I could imagine that, a driver in kernel 2.6.x would need different firmware than the same driver in kernel 2.6.y, where it would be very helpful to have multiple firmware packages installed. Does the firmware infrastructure cater for this need? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Building vanilla kernel .debs
Hi, On Mon, Oct 26, 2009 at 10:19:31PM +, Ben Hutchings wrote: > On Mon, 2009-10-26 at 21:27 +0100, Marc Haber wrote: > > Is it a feature that the linux-firmware package doesn't have the > > upstream kernel version in its name? > > Possibly not. Shall I file a wishlist bug or has this already been noted? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Building vanilla kernel .debs
On Wed, Oct 28, 2009 at 07:30:47AM +, David Woodhouse wrote: > That's intentional. There is no need for it -- the firmware should live > in /lib/firmware. > > If there are incompatible versions of firmware, then they'll have a > different filename and can co-exist. This is, however, a challenge for the packaging system. With the current scheme, I cannot have the firmware package for kernel 2.6.x installed while the firmware package for kernel 2.6.y is installed. If we had this scheme in the past, having a fallback kernel would have been hard or impossible during firmware transitions, which for example the ipw2x00 drivers have gone through multiple times. Please rethink this intention. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Building vanilla kernel .debs
On Wed, Oct 28, 2009 at 10:17:52AM +, David Woodhouse wrote: > On Wed, 2009-10-28 at 10:48 +0100, Marc Haber wrote: > > On Wed, Oct 28, 2009 at 07:30:47AM +, David Woodhouse wrote: > > > That's intentional. There is no need for it -- the firmware should live > > > in /lib/firmware. > > > > > > If there are incompatible versions of firmware, then they'll have a > > > different filename and can co-exist. > > > > This is, however, a challenge for the packaging system. With the > > current scheme, I cannot have the firmware package for kernel 2.6.x > > installed while the firmware package for kernel 2.6.y is installed. > > Right. The newer firmware package ought to be perfectly sufficient for > use with the older kernel. It frequently is not. See ipw2x00. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Custom Kernel Building in Debian
On Mon, Nov 16, 2009 at 02:24:52PM -0500, Stephen Powell wrote: > Maybe I'm re-inventing the wheel here, but I have recently collected and > organized > my notes on custom kernel building in Debian and have put them on the web at > the > following URL: http://www.wowway.com/~zlinuxman/Kernel.htm I would like to suggest addressing the building of out-of-tree modules as well. This is kind of a moving target, as Debian does not currently offer a way to build deb packages from out-of-tree modules which have been (prematurely, IMO) converted to DKMS. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559619: /etc/kernel/postrm.d/initramfs-tools should ignore errors from update-initramfs -d
Package: initramfs-tools Version: 0.93.4 Severity: normal Hi, /etc/kernel/postrm.d/initramfs-tools exists with an error if update-initramfs -d returns with an error. This could happen if one tries to purge a kernel image wihch has its initramfs already removed. Please consider adding a || true to the update-initramfs call in the script or to only invoke update-initramfs if the initrd.img is still there. Greetings Marc -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Xen support on Squeeze
On Sun, 3 Jan 2010 16:55:27 +1100, Brian May wrote: >Like I said previously, I think dropping Xen support is a mistake because KVM >requires QEMU and QEMU seems to have a reputation of being insecure. Xen is unsupportable due to clueless upstream, who has been in a constant FAIL state regarding support of current kernels for years. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537862: linux-image-2.6.30-1-686: does not boot, probably due to #537389
Package: linux-image-2.6.30-1-686 Version: 2.6.30-3 Severity: grave Justification: renders package unusable Most probably due to #537389 (which is a bug in binutils which makes kernels built with this version of binutils unbootable), the kernel doesn't boot. Waldi says that only x86/32 is affected. Greetings Marc -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#426440: /usr/sbin/pppd: sometimes connection with Option GlobeTrotter card hangs, ping: sendmsg: No buffer space available
On Thu, Dec 25, 2008 at 05:11:08PM +0100, Moritz Muehlenhoff wrote: > On Mon, Jun 11, 2007 at 04:55:40PM +0200, Miernik wrote: > > On Sat, Jun 09, 2007 at 04:36:55PM +0200, Marc Haber wrote: > > > I am reluctant to try a kernel that old on my personal notebook. I > > > have broadband again now, and do not use the UMTS card that often any > > > more. > > > > r...@debian106:~# ifconfig ppp0 > > ppp0 Link encap:Point-to-Point Protocol > > inet addr:10.243.69.180 P-t-P:10.64.64.64 Mask:255.255.255.255 > > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 > > RX packets:923 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:1040 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:3 > > RX bytes:1136175 (1.0 MiB) TX bytes:73000 (71.2 KiB) > > > > r...@debian106:~# ping 212.2.96.31 > > PING 212.2.96.31 (212.2.96.31) 56(84) bytes of data. > > ping: sendmsg: No buffer space available > > ping: sendmsg: No buffer space available > > ping: sendmsg: No buffer space available > > > > --- 212.2.96.31 ping statistics --- > > 3 packets transmitted, 0 received, 100% packet loss, time 21078ms > > > > r...@debian106:~# uname -a > > Linux debian106 2.6.15.7 #4 Sat Jun 9 11:40:51 CEST 2007 i686 GNU/Linux > > r...@debian106:~# > > > > Damn :-( > > Does this error still occur with more recent kernel versions? I haven't used the Option 3G in a while (I have a new UMTS device nw), but the issue seems to be present with all UMTS devices. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#426440: /usr/sbin/pppd: sometimes connection with Option GlobeTrotter card hangs, ping: sendmsg: No buffer space available
On Thu, Dec 25, 2008 at 05:11:08PM +0100, Moritz Muehlenhoff wrote: > Does this error still occur with more recent kernel versions? 2.6.27.10 here, with an Option Icon 225 UMTS USB Stick. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#601319: initramfs-tools: existing foo~ causes foo to be ignored
Package: initramfs-tools Version: 0.98.5 Severity: normal Hi, at least in /etc/initramfs-tools/hooks, existence of a foo~ file causes foo (the version without the tilde) to be ignored. If that's a feature, it needs to be documented, and update-initramfs -v output should more prominently reflect this. Greetings Marc -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101025074855.15372.22563.report...@nechayev.zugschlus.de
Bug#601324: initramfs-tools: PREREQ only honored inside single directory
Package: initramfs-tools Version: 0.98.5 Severity: normal Hi, at least for hook scripts, PREREQ is only honored in /etc/initramfs-tools resp /usr/share/initramfs-tools. First all scripts in /usr/share/initramfs-tools are ordered according to their PREREQ values and executed, then all scripts in /etc/initramfs-tools are ordered according to _their_ PREREQ values and executed. There is no possibility to have a local script executed before one from the package. This is at least surprising. Greetings Marc -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101025081718.15755.73475.report...@nechayev.zugschlus.de
Re: CONFIG_PREEMPT_DYNAMIC=y?
On Tue, Oct 10, 2023 at 12:32:22PM +0200, Emanuele Rocca wrote: > On 2023-10-10 12:14, Johannes Schauer Marin Rodrigues wrote: > > Quoting Emanuele Rocca (2023-10-10 12:10:07) > > > Setting CONFIG_HAVE_PREEMPT_DYNAMIC=y on arm64 is likely safe for us too, > > > but > > > we may want to run some benchmark first to see if there are any noticeable > > > slowdowns. > > > > I have a couple of arm64 boards here that I can run benchmarks on. What > > would > > you recommend to run to test the effect of CONFIG_HAVE_PREEMPT_DYNAMIC=y? > > I'm not sure what the best benchmark would be, but maybe you could start > with something generic like timing a kernel build with and without > PREEMPT_DYNAMIC and throwing 'hey' at your favorite web server? > https://github.com/rakyll/hey Whatever you do, check whether having a serial console still works with that setting. I had trouble with that in kernel 6.5, had some fruitless discussions on the LKML and developer interest abruptly died when I found out that the bug I encountered could be worked around by having those settings: [1/4998]mh@fan:~ $ grep PREEMPT /boot/config-6.5.6-zgws1 CONFIG_PREEMPT_BUILD=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_COUNT=y CONFIG_PREEMPTION=y CONFIG_PREEMPT_DYNAMIC=y CONFIG_PREEMPT_RCU=y CONFIG_HAVE_PREEMPT_DYNAMIC=y CONFIG_HAVE_PREEMPT_DYNAMIC_CALL=y CONFIG_PREEMPT_NOTIFIERS=y CONFIG_DRM_I915_PREEMPT_TIMEOUT=640 CONFIG_DRM_I915_PREEMPT_TIMEOUT_COMPUTE=7500 # CONFIG_DEBUG_PREEMPT is not set # CONFIG_PREEMPT_TRACER is not set # CONFIG_PREEMPTIRQ_DELAY_TEST is not set Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1058937: /usr-move: Do we support upgrades without apt?
On Thu, Dec 21, 2023 at 11:19:48AM -0300, Antonio Terceiro wrote: > On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote: > > Is it ok to call upgrade scenarios failures that cannot be reproduced > > using apt unsupported until we no longer deal with aliasing? > > I think so, yes. I don't think it's likely that there are people doing > upgrades on running systems not using apt. Do those GUI frontends that work via packagekit or other frameworks count as "using apt"? I now that WE recommend using apt in a text console outside of X, but even many of our own users do what their Desktop Environment does, and our downstreams like *b*nt* recommend other ways to upgrade as well. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#885166: instability with 4.14 regarding KVM virtualization
Hi, after in total nine weeks of bisecting, broken filesystems, service outages (thankfully on unportant systems), 4.15 seems to have fixed the issue. After going to 4.15, the crashes never happened again. They have, however, happened with each and every 4.14 release I tried, which I stopped doing with 4.14.15 on Jan 28. This means, for me, that the issue is fixed and that I have just wasted nine weeks of time. For Debian, this means that there is a crippling, data-eating issue in the current long-term releae kernel. I do sincerely hope that I never have to lay my eye on any 4.14 kernel again and hope that no major distribution will release with this version. Greetings Marc On Mon, Jan 08, 2018 at 09:53:14AM +0100, Marc Haber wrote: > On Mon, Dec 25, 2017 at 10:02:48PM +, Ben Hutchings wrote: > > Given that commit fb1522e099f0 was merged after -rc7 I assume it's an > > important fix, though the commit message doesn't spell that out. So I > > think that whenever bisect asks you to test a version that doesn't > > contain it, you should cherry-pick it first to avoid the other bug. > > After two more weeks, I can now confirm that cherry-picking fb1522e099f0 > onto earlier 4.13-rc kernels makes things _WORSE_. > > I believe that > - plain 4.13-rc4 works fine and allows stable usage of KVM > virtualization > - 4.13-rc4 with cherry-picked fb1522e099f0 is bad, causing random > segfaults and file-system corruption in VMs under disk and CPU load > - 4.13-rc5 is bad either way > > I will start bisecting between 4.13-rc4 and 4.13-rc5, hoping that this > will yield better results. Since I have to wait between three to five > days to flag a kernel as "good" without too much doubt, and bisect > 4.13-rc4..4.13-rc5 will take "roughly 7 steps". > > I am open to additional suggestions. > > Greetings > Marc > > > -- > - > Marc Haber | "I don't trust Computers. They | Mailadresse im Header > Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 > Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 > -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#885166: instability with 4.14 regarding KVM virtualization
On Sun, Feb 18, 2018 at 10:15:43AM +0100, Salvatore Bonaccorso wrote: > Looking today through the kernel archive, I noticed an answer from > Paolo Bonzini, <62aa6b81-5456-07dc-cf64-e46747d3a...@redhat.com>, > claiming this is fixed by > > https://git.kernel.org/linus/2a266f23550be997d783f27e704b9b40c4010292 > which is in 4.15-rc8, and thus confirming that you did not had the > issue anymore in 4.15. ... unfortunately with a totally unexplaining commit message though. > Closing this bug with that version, but do you have a chance to > confirm that? What exactly do you want me to test: - that the bug doesn't happen any more in Debian 4.15 kernels? - that ths bug still happens in Debian's 4.14 kernel and vanishes with the patch applied? - Something else? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#885166: instability with 4.14 regarding KVM virtualization
On Mon, Feb 19, 2018 at 06:31:16AM +0100, Salvatore Bonaccorso wrote: > On Sun, Feb 18, 2018 at 11:34:21AM +0100, Marc Haber wrote: > > On Sun, Feb 18, 2018 at 10:15:43AM +0100, Salvatore Bonaccorso wrote: > > > Looking today through the kernel archive, I noticed an answer from > > > Paolo Bonzini, <62aa6b81-5456-07dc-cf64-e46747d3a...@redhat.com>, > > > claiming this is fixed by > > > > > > https://git.kernel.org/linus/2a266f23550be997d783f27e704b9b40c4010292 > > > which is in 4.15-rc8, and thus confirming that you did not had the > > > issue anymore in 4.15. > > > > ... unfortunately with a totally unexplaining commit message though. > > > > > Closing this bug with that version, but do you have a chance to > > > confirm that? > > > > What exactly do you want me to test: > > > > - that the bug doesn't happen any more in Debian 4.15 kernels? > > - that ths bug still happens in Debian's 4.14 kernel and vanishes with > > the patch applied? > > - Something else? > > In an optimal case we get a confirmation that > 2a266f23550be997d783f27e704b9b40c4010292 is the fixing commit for your > issues. But given we have uploaded 4.15.4-1 to unstable, if you can > confirm that this one defintively fix your issue that would be great > (bonus if you can confirm your last non-working 4.14+commit fixes the > issue as well). If I used git correctly, then 4.14.20 already has 2a266f23550be997d783f27e704b9b40c4010292, so I tried 4.14.19. 4.14.19 on the one virt host that had the most violent failures failed in the first hour of operation, but with a slightly different error behavior that I was used to. I am therefore not sure whether we are not talking about multiple issues, one of them having been fixed somewhere in between 4.14.13 and 4.14.19. I then applied 2a266f23550be997d783f27e704b9b40c4010292 to 4.14.19, resulting in 4.4.19+, and this one has been running flawlessly for two days (and 0 minutes, incidentally) now. I will stay on 4.14.19+ until 4.15.5 comes out (and will update then). If you don't hear from me again in this bug report, then you can safely assume that 4.14.19+ lived on the test machine until its planned decommissioning during the 4.15.5 rollout. Hope this helps. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#885166: instability with 4.14 regarding KVM virtualization
On Wed, Feb 21, 2018 at 03:57:31PM +0100, Marc Haber wrote: > I then applied 2a266f23550be997d783f27e704b9b40c4010292 to 4.14.19, > resulting in 4.4.19+, and this one has been running flawlessly for two > days (and 0 minutes, incidentally) now. I will stay on 4.14.19+ until > 4.15.5 comes out (and will update then). If you don't hear from me again > in this bug report, then you can safely assume that 4.14.19+ lived on > the test machine until its planned decommissioning during the 4.15.5 > rollout. I regret to say that one of the VMs running on the host running 4.14.19+ has just suffered a "BUG: soft lockup - CPU#1 stuck for 58s!" which is an atypical behavior for the issue I had previously, but might have a common cause. 4.15.5 is currently building on my build host, and I'll move to that kernel asap. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#900346: does not reliably wake up from suspend-to-ram on AMD desktop
Package: src:linux Version: 4.16.5-1 Severity: normal Tags: upstream Hi, on my (only) desktop with an AMD cpu, the 4.16 kernels do not wake up reliably from suspend-to-RAM. If that happens, not even the (hardware) reset button on the machine works (which really confuses me), I need to push long on the power button to turn the machine off. It can then be turned on just fine. I send the box into suspend either via sudo systemcl suspend or with the "Suspend" button in KDE's launcher menu. I try to wake it up either by moving the mouse, by pressing a key or via Wake-on-LAN. The box then actually turns on, the optical drive goes through its power-on motions, the hard disk spins up, the power LED stops blinking and changes to a solid "on". But, the box never comes back, black screen, no reaction with the Num Lock LED, no reaction to pressing keys, no ping on the network (and no DHCP requests or other network traffic being seen). This happens with the Debian kernel and my home-brew 4.16 series kernel. 4.15 and earlier was just fine. I have never had those issues on this box. All other desktop/laptop machines I have run the identical kernel and wake up just fine (they all do have Intel CPUs though, and the desktop is by far the oldest machine). Have there been changes regarding suspend between 4.15 and 4.16? Greetings Marc -- Package-specific info: ** Version: Linux version 4.16.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29) ** Command line: BOOT_IMAGE=/vmlinuz-4.16.0-1-amd64 root=/dev/mapper/root ro splash console=ttyS0,57600n8 quiet ** Not tainted ** Kernel log: [ 90.157712] EDAC amd64: Node 0: DRAM ECC enabled. [ 90.157716] EDAC amd64: F10h detected (node 0). [ 90.157740] EDAC MC: DCT0 chip selects: [ 90.157741] EDAC amd64: MC: 0: 0MB 1: 0MB [ 90.157743] EDAC amd64: MC: 2: 4096MB 3: 4096MB [ 90.157744] EDAC amd64: MC: 4: 0MB 5: 0MB [ 90.157745] EDAC amd64: MC: 6: 0MB 7: 0MB [ 90.157746] EDAC MC: DCT1 chip selects: [ 90.157747] EDAC amd64: MC: 0: 0MB 1: 0MB [ 90.157748] EDAC amd64: MC: 2: 4096MB 3: 4096MB [ 90.157749] EDAC amd64: MC: 4: 0MB 5: 0MB [ 90.157751] EDAC amd64: MC: 6: 0MB 7: 0MB [ 90.157751] EDAC amd64: using x4 syndromes. [ 90.157752] EDAC amd64: MCT channel count: 2 [ 90.158028] EDAC MC0: Giving out device to module amd64_edac controller F10h: DEV :00:18.3 (INTERRUPT) [ 90.158053] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV :00:18.2 (POLLED) [ 90.158053] AMD64 EDAC driver v3.5.0 [ 90.185832] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC892: line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line [ 90.185835] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 90.185836] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [ 90.185837] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 [ 90.185839] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x11/0x1e [ 90.185839] snd_hda_codec_realtek hdaudioC0D0:inputs: [ 90.185841] snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19 [ 90.185842] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 [ 90.185843] snd_hda_codec_realtek hdaudioC0D0: Line=0x1a [ 90.189270] usb 6-5: current rate 30464 is different from the runtime rate 96000 [ 90.197508] adapter failed MAC signature check [ 90.197510] encoded MAC from EEPROM was [ 90.197511] ff: [ 90.197511] ff: [ 90.197511] ff: [ 90.197512] ff: [ 90.197512] ff: [ 90.197512] ff: [ 90.197513] ff: [ 90.197513] ff: [ 90.197513] ff: [ 90.197513] ff: [ 90.197514] ff: [ 90.197514] ff: [ 90.197514] ff: [ 90.197515] ff: [ 90.197515] ff: [ 90.197515] ff: [ 90.197515] ff: [ 90.197516] ff: [ 90.197516] ff: [ 90.197516] ff [ 90.214030] input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input7 [ 90.214089] input: HDA ATI HDMI HDMI/DP,pcm=7 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input8 [ 90.214135] input: HDA ATI HDMI HDMI/DP,pcm=8 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input9 [ 90.214178] input: HDA ATI HDMI HDMI/DP,pcm=9 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input10 [ 90.214222] input: HDA ATI HDMI HDMI/DP,pcm=10 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input11 [ 90.214264] input: HDA ATI HDMI HDMI/DP,pcm=11 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input12 [ 90.218267] usb 6-5: Warning! Unlikely big volume range (=8065), cval->res is probably wrong. [ 90.218270] usb 6-5: [9] FU [Mic Playback Volume] ch = 2, val = -6144/1921/1 [ 90.234265] usb 6-5: Warning! Unlikely big volume range (=8065), cval->res is probably wrong. [ 90.234269] usb 6-5: [11] FU [Line Playback Volume] ch = 2, val = -6144/1921/1 [ 90.2621
Bug#1014352: dpkg: error processing package initramfs-tools (--configure)
On Mon, Jul 04, 2022 at 08:45:05PM +0200, g.l. gragnani wrote: > I don't know if this is a bug in initramfs-tools or in lvm2 or something else. That's #1014314 in lvm2. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Asahi Linux Support - any plans?
On Fri, Aug 05, 2022 at 11:36:40AM +1000, Andrew Worsley wrote: > Thanks Diederik, so I'm guessing 173 is way too much but a lot of it might > not > be critical to something running on the M1 (versus M2). > > If I was to find a smaller set of say 10 patches to 5.19 that booted a > usable > system would I be able to submit those patches some where for building > (arm64 of course)? Is there any reason why you don't take those patches upstream where they belong? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1020718: should at least suggest the expected compressors
Package: initramfs-tools Version: 0.142 Severity: minor Hi, a few weeks ago, update-initramfs has started to complain that zstd is not present on the systems. As I have lost the overview over the compressor-of-the-year evolution slope, I don't have zstd installed, and I also can only guess from the message which compressor is preferred by update-initramfs nowadays. It would be helpful to have a Suggests: zstd | lz4 | xz ... in the package that would indicate the preference of compressors, giving a hint about which compressor to install to get rid of those pesky warnings. Greetings Marc
Bug#1006689: does not purge cleanly
Package: nfs-kernel-server Version: 1:2.6.1-1 Severity: normal Hi, I noticed that nfs-blkmap.service keeps failing on my notebook. Since I'm not using NFS anyway, I found out that this service belongs to nfs-kernel-server and tried to purge the package. This should be possible since I dont have dependencies installed, but it fails: [4/4996]mh@drop:~ $ sudo apt purge nfs-kernel-server Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be REMOVED: nfs-kernel-server* 0 upgraded, 0 newly installed, 1 to remove and 4 not upgraded. After this operation, 650 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 492241 files and directories currently installed.) Removing nfs-kernel-server (1:2.6.1-1) ... Failed to stop nfs-kernel-server.service: Unit nfs-kernel-server.service not loaded. invoke-rc.d: initscript nfs-kernel-server, action "stop" failed. dpkg: error processing package nfs-kernel-server (--remove): installed nfs-kernel-server package pre-removal script subprocess returned error exit status 5 dpkg: too many errors, stopping nfs-mountd.service is a disabled or a static unit not running, not starting it. nfs-server.service is a disabled or a static unit not running, not starting it. nfsdcld.service is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142. Failed to restart nfs-kernel-server.service: Unit nfs-kernel-server.service failed to load properly, please adjust/correct and reload service manager: File exists See system logs and 'systemctl status nfs-kernel-server.service' for details. invoke-rc.d: initscript nfs-kernel-server, action "restart" failed. ○ nfs-kernel-server.service Loaded: error (Reason: Unit nfs-kernel-server.service failed to load properly, please adjust/correct and reload service manager: File exists) Active: inactive (dead) Warning: The unit file, source configuration file or drop-ins of nfs-kernel-server.service changed on disk. Run 'systemctl daemon-reload' to reload units. Failed to restart nfs-kernel-server, ignoring. Errors were encountered while processing: nfs-kernel-server Processing was halted because there were too many errors. needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) 100 [5/4997]mh@drop:~ $ sudo apt purge nfs-kernel-server Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be REMOVED: nfs-kernel-server* 0 upgraded, 0 newly installed, 1 to remove and 4 not upgraded. After this operation, 650 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 492241 files and directories currently installed.) Removing nfs-kernel-server (1:2.6.1-1) ... Failed to stop nfs-kernel-server.service: Unit nfs-kernel-server.service not loaded. invoke-rc.d: initscript nfs-kernel-server, action "stop" failed. dpkg: error processing package nfs-kernel-server (--remove): installed nfs-kernel-server package pre-removal script subprocess returned error exit status 5 dpkg: too many errors, stopping nfs-mountd.service is a disabled or a static unit not running, not starting it. nfs-server.service is a disabled or a static unit not running, not starting it. nfsdcld.service is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142. Failed to restart nfs-kernel-server.service: Unit nfs-kernel-server.service failed to load properly, please adjust/correct and reload service manager: File exists See system logs and 'systemctl status nfs-kernel-server.service' for details. invoke-rc.d: initscript nfs-kernel-server, action "restart" failed. ○ nfs-kernel-server.service Loaded: error (Reason: Unit nfs-kernel-server.service failed to load properly, please adjust/correct and reload service manager: File exists) Active: inactive (dead) Warning: The unit file, source configuration file or drop-ins of nfs-kernel-server.service changed on disk. Run 'systemctl daemon-reload' to reload units. Failed to restart nfs-kernel-server, ignoring. Errors were encountered while processing: nfs-kernel-server Processing was halted because there were too many errors. needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) 100 [6/4997]mh@drop:~ $ I was able to get rid of the package by emptying out the prerm script, but that should be easier. Greetings Marc -- Package-specific info: -- rpcinfo -- -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.11-zgws1 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en She
Bug#1006689: does not purge cleanly
On Thu, Mar 03, 2022 at 06:57:15AM +0100, Salvatore Bonaccorso wrote: > I was not able to reproduce this behaviour and from the trace you > posted, where there some inconsistencies already before in a unclean > state? I had portmapper masked. Might that be a possibility? > If you re-install the package or in syntetic environment can you > reproduce the problem? Will try. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1006689: does not purge cleanly
On Thu, Mar 03, 2022 at 06:57:15AM +0100, Salvatore Bonaccorso wrote: > If you re-install the package or in syntetic environment can you > reproduce the problem? even re-installation fails: [1/5050]mh@drop:~ $ sudo apt install nfs-kernel-server [sudo] password for mh: Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: nfs-kernel-server 0 upgraded, 1 newly installed, 0 to remove and 4 not upgraded. Need to get 180 kB of archives. After this operation, 650 kB of additional disk space will be used. Get:1 http://debian.debian.zugschlus.de/debian sid/main amd64 nfs-kernel-server amd64 1:2.6.1-1 [180 kB] Fetched 180 kB in 1s (193 kB/s) Retrieving bug reports... Done Parsing Found/Fixed information... Done Selecting previously unselected package nfs-kernel-server. (Reading database ... 492203 files and directories currently installed.) Preparing to unpack .../nfs-kernel-server_1%3a2.6.1-1_amd64.deb ... Unpacking nfs-kernel-server (1:2.6.1-1) ... Setting up nfs-kernel-server (1:2.6.1-1) ... nfs-mountd.service is a disabled or a static unit not running, not starting it. nfs-server.service is a disabled or a static unit not running, not starting it. nfsdcld.service is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142. Creating config file /etc/exports with new version Creating config file /etc/default/nfs-kernel-server with new version Failed to start nfs-kernel-server.service: Unit nfs-kernel-server.service failed to load properly, please adjust/correct and reload service manager: File exists See system logs and 'systemctl status nfs-kernel-server.service' for details. invoke-rc.d: initscript nfs-kernel-server, action "start" failed. ○ nfs-kernel-server.service Loaded: error (Reason: Unit nfs-kernel-server.service failed to load properly, please adjust/correct and reload service manager: File exists) Active: inactive (dead) Warning: The unit file, source configuration file or drop-ins of nfs-kernel-server.service changed on disk. Run 'systemctl daemon-reload' to reload units. Failed to start nfs-kernel-server, ignoring. Processing triggers for man-db (2.10.1-1) ... Scanning processes... Scanning candidates... Scanning processor microcode... Scanning linux images... Running kernel seems to be up-to-date. The processor microcode seems to be up-to-date. No services need to be restarted. No containers need to be restarted. No user sessions are running outdated binaries. [2/5051]mh@drop:~ $ -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#863266: bug 863266 is forwarded to https://bugzilla.redhat.com/show_bug.cgi?id=1432684
On Fri, Sep 15, 2017 at 12:18:12PM +0200, Guido Günther wrote: > Let's reassign to the kernel then. > > Dear kernel maintainers. The symptom is that libvirt fails to detect > ports already in use for spice. See > > https://bugzilla.redhat.com/show_bug.cgi?id=1432684#c17 > > for a simple testcase not involving libvirt at all. I'll post the > summary (by Cole Robinson) here: Patches on http://www.spinics.net/lists/netdev/msg454644.html and onwards, four pieces, all needed. I verified that they fix the issue on Debian stable with a vanilla 4.13.2 kernel. Greetigns Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#910090: SD card reader does not work any more
Package: src:linux Version: 4.18.8-1 Severity: minor Hi, since a few kernel versions (sorry, I don't know which one), SD cards put into the built-in reader of the ThinkPad T520 don't work any more. There is nothing happening in the kernel log when the card is inserted. Any information that I can give? Please say so. Greetings Marc -- Package-specific info: ** Version: Linux version 4.18.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-29)) #1 SMP Debian 4.18.8-1 (2018-09-18) ** Command line: BOOT_IMAGE=/vmlinuz-4.18.0-1-amd64 root=/dev/mapper/swivelbtr ro rootflags=subvol=swivel-root i915.i915_enable_rc6=1 pciehp_force=1 pciehp_poll_mode=1 quiet splash ** Not tainted ** Kernel log: [ 13.380671] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default... [ 13.385987] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [ 13.386771] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [ 13.392403] thinkpad_acpi: battery 1 registered (start 0, stop 80) [ 13.392410] battery: new extension: ThinkPad Battery Extension [ 13.392466] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input8 [ 13.408141] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 13.408248] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 13.408290] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 13.408890] iTCO_vendor_support: vendor-support=0 [ 13.410357] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [ 13.410400] iTCO_wdt: Found a Cougar Point TCO device (Version=2, TCOBASE=0x0460) [ 13.411028] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 13.418382] snd_hda_codec_conexant hdaudioC0D0: CX20590: BIOS auto-probing. [ 13.418867] snd_hda_codec_conexant hdaudioC0D0: autoconfig for CX20590: line_outs=1 (0x1f/0x0/0x0/0x0/0x0) type:speaker [ 13.418869] snd_hda_codec_conexant hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 13.418871] snd_hda_codec_conexant hdaudioC0D0:hp_outs=2 (0x1c/0x19/0x0/0x0/0x0) [ 13.418872] snd_hda_codec_conexant hdaudioC0D0:mono: mono_out=0x0 [ 13.418874] snd_hda_codec_conexant hdaudioC0D0:inputs: [ 13.418875] snd_hda_codec_conexant hdaudioC0D0: Internal Mic=0x23 [ 13.418877] snd_hda_codec_conexant hdaudioC0D0: Mic=0x1b [ 13.418879] snd_hda_codec_conexant hdaudioC0D0: Dock Mic=0x1a [ 13.420253] snd_hda_codec_conexant hdaudioC0D0: Enable sync_write for stable communication [ 13.434778] Intel(R) Wireless WiFi driver for Linux [ 13.434779] Copyright(c) 2003- 2015 Intel Corporation [ 13.434993] iwlwifi :03:00.0: can't disable ASPM; OS doesn't have ASPM control [ 13.443067] iwlwifi :03:00.0: firmware: direct-loading firmware iwlwifi-6000-4.ucode [ 13.443231] iwlwifi :03:00.0: loaded firmware version 9.221.4.1 build 25532 op_mode iwldvm [ 13.447419] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 163840 ms ovfl timer [ 13.447420] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules [ 13.447421] RAPL PMU: hw unit of domain package 2^-16 Joules [ 13.447421] RAPL PMU: hw unit of domain pp1-gpu 2^-16 Joules [ 13.473009] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/sound/card0/input9 [ 13.473350] input: HDA Intel PCH Mic as /devices/pci:00/:00:1b.0/sound/card0/input10 [ 13.473405] input: HDA Intel PCH Dock Mic as /devices/pci:00/:00:1b.0/sound/card0/input11 [ 13.473460] input: HDA Intel PCH Dock Headphone as /devices/pci:00/:00:1b.0/sound/card0/input12 [ 13.473512] input: HDA Intel PCH Headphone as /devices/pci:00/:00:1b.0/sound/card0/input13 [ 13.473565] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci:00/:00:1b.0/sound/card0/input14 [ 13.473618] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci:00/:00:1b.0/sound/card0/input15 [ 13.473669] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci:00/:00:1b.0/sound/card0/input16 [ 13.519452] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUG disabled [ 13.519454] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled [ 13.519455] iwlwifi :03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled [ 13.519457] iwlwifi :03:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74 [ 13.532778] intel_rapl: Found RAPL domain package [ 13.532779] intel_rapl: Found RAPL domain core [ 13.532780] intel_rapl: Found RAPL domain uncore [ 13.532784] intel_rapl: RAPL package 0 domain package locked by BIOS [ 13.604779] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' [ 13.784474] iwlwifi :03:00.0 lanw0: renamed from wlan0 [ 13.837340] Adding 8386556k swap on /dev/mapper/swap0. Priority:-2 extents:1 across:8386556k SSFS [ 13.878847] EXT4-fs (dm-12): mounted filesystem with ordered data mode. Opts: (null) [ 14.992226] BTRFS: device label swivelbtr_r devid 1 transid 16366 /dev/dm-13 [ 15.047062] BTRFS info (device dm-13): disk
Bug#910090: SD card reader does not work any more
On Tue, Oct 02, 2018 at 10:23:41PM +0200, Martin Steigerwald wrote: > Marc Haber - 02.10.18, 18:34: > > Package: src:linux > > Version: 4.18.8-1 > > Severity: minor > […] > > since a few kernel versions (sorry, I don't know which one), SD cards > > put into the built-in reader of the ThinkPad T520 don't work any more. > > There is nothing happening in the kernel log when the card is > > inserted. > > Strange. > > The one in this ThinkPad T520 still works. With self-compiled 4.18.7. > > Configuration attached. Can you paste the output of lsmod with an SD card inserted and mounted? > I did not test with Debian kernel. For the means of this bug report, it would be helpful if you tried with the Debian kernel as well. Btw, the SD reader of the X260 doesn't work either, but I cannot confirm that this did work in the past. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#918042: WoL does not work on r8169 (regression since 4.18)
Package: src:linux Version: 4.20-1~exp1 Severity: normal Hi, I frequently send my desktop PC to sleep (suspend-to-ram) and wake it up from remote when I need to access it. To do so, I use a script on a banana pi which ends up calling etherwake 54:04:a6:82:21:00. This has worked reliably up to the last 4.18 release, including the Debian kernel linux-image-4.18.0-3-amd64 version 4.18.20-2. In 4.19, this ceased to work and has remained that way up to the kernel I am reporting this issue on, linux-image-4.20.0-trunk-amd64 version 4.20-1~exp1. I have observed this behavior also on my "own", locally built kernels of various 4.19 releases and also 4.20. Sorry, I didn't try any Debian 4.19 kernels, I decided to pursue this issue further after the regression was also present in 4.20. I am prepared to try kernel patches or follow other hints in debugging this. I acknowledge that this is most probably an upstream issue, but I don't have enough kernel foo to investigate this on an upstream level (and frankly, I am afraid of doing a bisect between 4.18 and 4.19). Any hints will be appreciated. -- Package-specific info: ** Version: Linux version 4.20.0-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.20-1~exp1 (2018-12-24) ** Command line: BOOT_IMAGE=/vmlinuz-4.20.0-trunk-amd64 root=/dev/mapper/root ro splash console=ttyS0,57600n8 quiet ** Not tainted ** Kernel log: [ 225.803103] sd 4:0:0:0: [sdb] Synchronizing SCSI cache [ 225.803252] sd 1:0:0:0: [sda] Stopping disk [ 225.805950] sd 4:0:0:0: [sdb] Stopping disk [ 225.810535] sd 5:0:0:0: [sdc] Synchronizing SCSI cache [ 225.810750] sd 5:0:0:0: [sdc] Stopping disk [ 229.997427] ACPI: EC: interrupt blocked [ 230.015575] ACPI: Preparing to enter system sleep state S3 [ 230.017796] ACPI: EC: event blocked [ 230.017797] ACPI: EC: EC stopped [ 230.017798] PM: Saving platform NVS memory [ 230.017802] Disabling non-boot CPUs ... [ 230.031585] IRQ 17: no longer affine to CPU1 [ 230.031600] IRQ 19: no longer affine to CPU1 [ 230.032656] smpboot: CPU 1 is now offline [ 230.052563] smpboot: CPU 2 is now offline [ 230.083457] IRQ 24: no longer affine to CPU3 [ 230.083479] IRQ 37: no longer affine to CPU3 [ 230.084506] smpboot: CPU 3 is now offline [ 230.107073] IRQ 33: no longer affine to CPU4 [ 230.108097] smpboot: CPU 4 is now offline [ 230.131161] IRQ 29: no longer affine to CPU5 [ 230.131171] IRQ 34: no longer affine to CPU5 [ 230.132203] smpboot: CPU 5 is now offline [ 230.137594] ACPI: Low-level resume complete [ 230.137631] ACPI: EC: EC started [ 230.137632] PM: Restoring platform NVS memory [ 230.137646] PCI-DMA: Resuming GART IOMMU [ 230.137647] PCI-DMA: Restoring GART aperture settings [ 230.137652] LVT offset 1 assigned for vector 0x400 [ 230.137662] LVT offset 1 assigned [ 230.137908] microcode: CPU0: new patch_level=0x01dc [ 230.137935] Enabling non-boot CPUs ... [ 230.137974] x86: Booting SMP configuration: [ 230.137975] smpboot: Booting Node 0 Processor 1 APIC 0x1 [ 230.140530] TSC synchronization [CPU#0 -> CPU#1]: [ 230.140531] Measured 4350120160 cycles TSC warp between CPUs, turning off TSC clock. [ 230.140533] tsc: Marking TSC unstable due to check_tsc_sync_source failed [ 230.140536] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. [ 230.140537] sched_clock: Marking unstable (230135957339, 2389616)<-(230439424037, -29477) [ 231.493902] process: Switch to broadcast mode on CPU1 [ 231.494117] cache: parent cpu1 should not be sleeping [ 231.494207] microcode: CPU1: patch_level=0x01dc [ 231.494380] clocksource: Switched to clocksource hpet [ 230.138878] CPU1 is up [ 230.138902] smpboot: Booting Node 0 Processor 2 APIC 0x2 [ 230.142346] process: Switch to broadcast mode on CPU2 [ 230.142346] cache: parent cpu2 should not be sleeping [ 230.142346] microcode: CPU2: patch_level=0x01dc [ 230.142346] CPU2 is up [ 230.142346] smpboot: Booting Node 0 Processor 3 APIC 0x3 [ 230.142346] process: Switch to broadcast mode on CPU3 [ 230.142346] cache: parent cpu3 should not be sleeping [ 230.142346] microcode: CPU3: patch_level=0x01dc [ 230.142346] CPU3 is up [ 230.142346] smpboot: Booting Node 0 Processor 4 APIC 0x4 [ 230.142346] process: Switch to broadcast mode on CPU4 [ 230.142346] cache: parent cpu4 should not be sleeping [ 230.142346] microcode: CPU4: patch_level=0x01dc [ 230.142346] CPU4 is up [ 230.142346] smpboot: Booting Node 0 Processor 5 APIC 0x5 [ 230.142346] process: Switch to broadcast mode on CPU5 [ 230.142869] cache: parent cpu5 should not be sleeping [ 230.142970] microcode: CPU5: patch_level=0x01dc [ 230.143185] CPU5 is up [ 230.149748] ACPI: Waking up from system sleep state S3 [ 230.258927] ACPI: EC: interrupt unblocked [ 231.495557] ACPI: EC: event unblocked [ 231.496009] usb usb2: root hub lost power or was reset [ 231.496011] usb usb4: root hub lost power or w
Bug#885166: instability with 4.14 regarding KVM virtualization
ing- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: sdhci-pci Kernel modules: sdhci_pci USB devices: not available -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.14.0-1-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.130 ii kmod23-2 ii linux-base 4.5 Versions of packages linux-image-4.14.0-1-amd64 recommends: pn apparmor pn firmware-linux-free pn irqbalance Versions of packages linux-image-4.14.0-1-amd64 suggests: pn debian-kernel-handbook ii grub-efi-amd64 2.02~beta3-5 pn linux-doc-4.14 Versions of packages linux-image-4.14.0-1-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#885166: instability with 4.14 regarding KVM virtualization
On Mon, Dec 25, 2017 at 10:02:48PM +, Ben Hutchings wrote: > It's on a branch that started at 4.13-rc7 but wasn't merged into > mainline until after 4.13. Comparing the two of them, 569dbb88e80d has > the addition of commit fb1522e099f0 "KVM: update to new mmu_notifier > semantic v2". So I would guess that what you landed on is a different > bug than the one you were looking for. Ouch. Two bugs with such similiar behavior in a single kernel release? > Given that commit fb1522e099f0 was merged after -rc7 I assume it's an > important fix, though the commit message doesn't spell that out. So I > think that whenever bisect asks you to test a version that doesn't > contain it, you should cherry-pick it first to avoid the other bug. (I > think you will then need to use 'git bisect good|bad HEAD^' after > testing, rather than implicitly flagging the current head commit.) Would git show fb1522e099f0 | patch -p1 build/test git reset --hard git bisect good|bad be the same thing? I would feel much more comfortable with that. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#885166: instability with 4.14 regarding KVM virtualization
On Mon, Dec 25, 2017 at 10:02:48PM +, Ben Hutchings wrote: > Given that commit fb1522e099f0 was merged after -rc7 I assume it's an > important fix, though the commit message doesn't spell that out. So I > think that whenever bisect asks you to test a version that doesn't > contain it, you should cherry-pick it first to avoid the other bug. After two more weeks, I can now confirm that cherry-picking fb1522e099f0 onto earlier 4.13-rc kernels makes things _WORSE_. I believe that - plain 4.13-rc4 works fine and allows stable usage of KVM virtualization - 4.13-rc4 with cherry-picked fb1522e099f0 is bad, causing random segfaults and file-system corruption in VMs under disk and CPU load - 4.13-rc5 is bad either way I will start bisecting between 4.13-rc4 and 4.13-rc5, hoping that this will yield better results. Since I have to wait between three to five days to flag a kernel as "good" without too much doubt, and bisect 4.13-rc4..4.13-rc5 will take "roughly 7 steps". I am open to additional suggestions. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#838887: please dont bomb out on nofail option
On Mon, Sep 26, 2016 at 02:58:58PM +0100, Ben Hutchings wrote: > On Mon, 2016-09-26 at 07:02 +0200, Marc Haber wrote: > > Package: initramfs-tools > > Severity: wishlist > > > > Hi, > > > > when I looked for the last time (a few months ago), fstab entries > > parsed by initramfs-tools or in initramfs MUST NOT contain the > > "nofail" option. > > All entries are parsed. But I suppose you mean the entries which are > actually processed, which are: /usr And root, right? > And 'nofail' would make no sense for /usr, so I don't understand > why you would want to use it there. I want to use it anywhere so that the system boots as far as it will go, in the hope that it will come up so far that actual help is possible. Unconditionally dropping to a rescue shell on the local console is the least probable variant of "helpful". > [...] > > Please consider tweaking initramfs-tools so that "nofail" can be in > > all lines, with it being ignored in initramfs. > > There's nothing we do that would reject 'nofail', and both busybox and > klibc implementations of mount seem to ignore it. (However I don't > currently have a test VM with separate /usr so I didn't test this > completely.) You're right. "nofail" is ignored, at least in sid. I'm leaving this bug report open since I'd really love initramfs-tools to continue to try booting even if mounting /usr fails. Currently, this is what happens even if nofail is set on /usr: |Begin: Running /scripts/local-block ... done. |done. |Gave up waiting for /usr device. Common problems: | - Boot args (cat /proc/cmdline) | - Check rootdelay= (did the system wait long enough?) | - Missing modules (cat /proc/modules; ls /dev) |ALERT! /dev/vdb does not exist. Dropping to a shell! |BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash) |Enter 'help' for a list of built-in commands. |(initramfs) I guess this would also defeat mechanisms placed in the initramfs such as an emergency ssh daemon (something which I planned to implement for a decade now and never have gotten around to actually doing it). Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#839890: please give a tool (or document how to) unpacking an initramfs with microcode prepended
Package: initramfs-tools Version: 0.125 Severity: wishlist Hi, the new method of prepending a CPU microcode fix to the initramfs is a nuisance when debugging an initramfs. Having to peddle with dd and guessing (?) the correct offset in a situation where only a tiny part of the system might be available or one is working from a rescue system is not nice. Please consider providing a tool which can unpack an initrmamfs with a single call of the tool even if CPU microcode is prepended. Thanks! Greetings Marc
Bug#849276: cp: cannot stat '/etc/modprobe.d/*': No such file or directory
On Sat, Dec 24, 2016 at 10:15:22PM +0800, 積丹尼 Dan Jacobson wrote: > Please check to see if /etc/modprobe.d really exists (it might not!) first. > > Log started: 2016-12-23 22:37:09 > Selecting previously unselected package linux-image-4.8.0-1-amd64. > (Reading database ... 9940 files and directories currently installed.) > Preparing to unpack .../0-linux-image-4.8.0-1-amd64_4.8.7-1_amd64.deb ... > Unpacking linux-image-4.8.0-1-amd64 (4.8.7-1) ... > Selecting previously unselected package linux-image-amd64. > Preparing to unpack .../1-linux-image-amd64_4.8+76_amd64.deb ... > Unpacking linux-image-amd64 (4.8+76) ... > Setting up linux-image-4.8.0-1-amd64 (4.8.7-1) ... > I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.8.0-1-amd64 > I: /initrd.img.old is now a symlink to boot/initrd.img-4.8.0-1-amd64 > I: /vmlinuz is now a symlink to boot/vmlinuz-4.8.0-1-amd64 > I: /initrd.img is now a symlink to boot/initrd.img-4.8.0-1-amd64 > /etc/kernel/postinst.d/initramfs-tools: > update-initramfs: Generating /boot/initrd.img-4.8.0-1-amd64 > cp: cannot stat '/etc/modprobe.d/*': No such file or directory > Setting up linux-image-amd64 (4.8+76) ... > Log ended: 2016-12-23 22:37:25 Are you sure this is the kernel package, and not, for example, initramfs-tools, that gives this error message? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#849280: say 'incompatible binary version', not "not found"
On Sat, Dec 24, 2016 at 09:39:30PM +0800, 積丹尼 Dan Jacobson wrote: > Please give a more correct message, like 'incompatible binary version'. > Returning a not found error to shells is just plain misleading. > > $ set who who2 > $ for i in 'ls -l ' 'file ' './'; do $i$1; $i$2; done > -rwxr-xr-x 1 jidanni jidanni 51092 12-09 22:08 who > -rwxr-xr-x 1 jidanni jidanni 52168 12-09 22:08 who2 > who: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically > linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, > BuildID[sha1]=91f94a82b58bc7a63525c4ff35e43f9dbbe29caa, stripped > who2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically > linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, > BuildID[sha1]=2d07a0c30c834741b64bda8289fa557fa1e1a876, stripped > bash: ./who: No such file or directory > jidanni pts/02016-12-24 18:02 (:0) > $ uname -r > 4.8.0-2-amd64 > $ ./ #same messages as when something that really isn't there: > bash: ./: No such file or directory > $ ./who > dash: 2: ./who: not found Does /lib/ld-linux.so.2 exist on your system? If not, the error message is correct. The kernel just knows that the interpreter given in the executable does not exist, it cannot give a more meaningful error message because lack of knowledge. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#981087: getting rid of false positive firmware warnings?
Package: initramfs-tools-core Version: 0.139 Severity: wishlist Hi, when my initramfs is built, the radeon module complains about a truckload of "Possible missing firmware". Since my system is running finr without them, I guess those are false positives for my graphics card, so the warnings should not be there (their sheer volume hides real issues). Would you be willing to accept a patch to /usr/share/initramfs-tools/hook-functions reading a list of possibly-missing-but-not-necessary firmware files and not emitting the "Possible missing firmware" warning for firmware files that are listed in the file? If so, can you please help me with a language issue and suggest a better name and a probable location for the file? Thank you very much. Greetings Marc -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.9-zgws1 (SMP w/12 CPU threads) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages initramfs-tools-core depends on: ii coreutils8.32-4+b1 ii cpio 2.13+dfsg-4 ii e2fsprogs1.45.6-1 ii klibc-utils 2.0.8-1 ii kmod 28-1 ii logsave 1.45.6-1 ii udev 247.2-5 Versions of packages initramfs-tools-core recommends: ii busybox 1:1.30.1-6+b1 ii pigz 2.5-1 Versions of packages initramfs-tools-core suggests: ii bash-completion 1:2.11-2 -- no debconf information
