Re: which kernel version for etch?
On Sat, May 13, 2006 at 10:30:07PM +0200, Andreas Barth wrote: > Well, actually, there are reasons for both decisions. I think that in > the end, it is more important to make building packages for etch > easier. And as long as its 0-1 more package that can be autobuilt for etch, it should be just fine. > Please remember, this is only for a limited time, and at that time, > we'll be quite busy with etch issues. And, BTW, kernel developers should > know when a new kernel arrives. :) I think you've hit on a brilliant idea Andreas - let's get all sid kernel users to join the kernel team! -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365204: Please close the bug
On Thu, May 11, 2006 at 02:03:11PM -0300, Flavio Henrique Araque Gurgel wrote: > I want to let you know that I solved the bug myself. > > After updating the flash-bios the problem disappeared. > Maybe it's good to let everybody knows that it happens with the hardware: > Mainboard Asus A8V Deluxe > Processor Athlon 64 3000+ Done, thanks for the update. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365204: marked as done (Random mouse movements when seriously clicked)
Your message dated Sat, 13 May 2006 15:25:22 -0600 with message-id <[EMAIL PROTECTED]> and subject line Bug#365204: Please close the bug has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: linux-image Version: 2.6.15-1-k7 The mouse cursor starts to randomly move and click around the screen for some seconds. It happens when I make quick sequential clicks in it, for example, 4 clicks in the same click interval as a double click. I need take my hands off the mouse then it stops the random movement and clicking after one or two seconds, getting back to normal behaviour. If I need to drag and drop something like a window on the screen it happens too, not as much as subsequentially clicking but sometimes. This is a dangerous behaviour because when the mouse starts to click around it can open programs, right click icons and select operations not wanted by the user. I decided to send this to the linux-image package because: - it doesn't look to be a Xfree or Xorg bug because I have tried both in old and new Debian versions; - the same problem occours in text mode when no X is running at all; - my Xorg.conf is configured to the device /dev/mice. In the same Hardware: - this problem happened when using other Linux distros like Ubuntu and Fedora Core too. I decided to include the bug here because Debian sems to have a better bug-tracking system and is my distro of choice, better to help it; - the problem happens to me since the first time I use Debian on that hardware, Debian 3.0; - I had no success talking to the people on the linuxkernel.org; - I tried several linux-images like x86, 686, k7; - I tried Debian amd64 unnoficial and testing versions too. I have tryied some kernel patches found on the net without success. I have searched on the internet for the problem and it looks to happen to few people with the same chipset. Nobody had success. The hardware seems to have no problem because when using FreeBSD (and Xorg) or Microsoft Windows there's no problem at all. Hardware description: Athlon 64 3000+ 512MB RAM Asus A8V motherboard chipset VIA K8T800Pro + VT8237 HD Serial ATA Seagate 7200rpm 120GB DVD+CDR-RW LG 52x on the Secondary IDE. Mouse is a Satellite Intelimouse PS/2 optical. I have tried another PS/2 mouses like non-optical Logitech and the same problem occours. I have tried USB mouses and the problem disappears. I'm using Debian Testing with the linux-image above. All packages are up to date today with the ftp.br.debian.org repository. Sorry about the long description but I think that all information given is useful. --- End Message --- --- Begin Message --- On Thu, May 11, 2006 at 02:03:11PM -0300, Flavio Henrique Araque Gurgel wrote: > I want to let you know that I solved the bug myself. > > After updating the flash-bios the problem disappeared. > Maybe it's good to let everybody knows that it happens with the hardware: > Mainboard Asus A8V Deluxe > Processor Athlon 64 3000+ Done, thanks for the update. -- dann frazier --- End Message ---
Bug#367125: nfs + ext3 = possible DoS
Package: kernel-image-2.6.8-2-686-smpVersion: 2.6.8-16Hello, Our central nfs-server is running Debian/Sarge and there are ~300 nfs Clients running under Debianor Solaris. At one point we had to recreate the exported (ext3) filesystems on the server and copy the data back from backup. Although we rebooted most of the clients as well, some kept runningand unforunately obviously had cached the nfs filehandles and requested the no longerexisting inodes. This resulted in messages like this on the server: ext3_get_inode_loc: bad inode number: 30130240After some of these messages (cannot say the exact number) the filesystemwas mounted read-only which made it quite unusable, along with this message: Remounting filesystem read-onlyThis suprises me somewhat as with "tune2fs -e continue" the filesystem was supposed to ignore errors. Is that not valid for ext3 but only for ext2?We also think that this could be used as a denial of service attack: just request non-existing inodes and eventually the server will remount read-only.We also observed this behaviour with linux-image-2.6.12-1-686-smp, version2.6.12-10. I will install linux-kernel latest version of 2.6.16 in the near future.I'm not sure if this really is a bug but it would be great if there was a workaround.I think it's a bug since there actually is no error in the filesystem,there are only requests for non-existing inodes. So how can one prevent the filesystem being remounted read-only in thissituation?Thanks, Peter
Re: which kernel version for etch?
On Sat, May 13, 2006 at 08:57:06PM +0200, Andreas Barth wrote: > * dann frazier ([EMAIL PROTECTED]) [060513 02:00]: > > Of course, I do see the benefit to Bastian's suggestion - we'd have > > working metapackages for both sid & etch that pull in the latest > > available in that dist. My proposal leaves sid meta packages pointing > > at the latest kernel for etch. > > Actually, I see the sid meta packages pointing to the latest etch kernel > as a feature, as this makes sure that more boxes have these kernels > installed, and especially the d-i-build boxes will have the correct > kernel, which will help with d-i testing and final preparations for > etch. I am not convinced that this d-i buildd infrastructure is sane though. I can hardly discuss this without being accused of attacking the d-i team, but the situation always made me a bit uneasy, and this forced to do manual .udeb transitions too. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
On Sat, May 13, 2006 at 10:30:07PM +0200, Andreas Barth wrote: > * dann frazier ([EMAIL PROTECTED]) [060513 21:01]: > > On Sat, May 13, 2006 at 06:23:46AM +0200, Sven Luther wrote: > > > Mmm. Do we really want the default for sid to be something that will maybe > > > never be going into etch ? > > > I think so; there is a class of users (myself included) who want to > > run/test the latest and greatest on some machines, and its nice when > > it automatically updates. Users that just want to run what will go > > into testing should, well, just run testing :) > > Well, actually, there are reasons for both decisions. I think that in > the end, it is more important to make building packages for etch easier. > Please remember, this is only for a limited time, and at that time, > we'll be quite busy with etch issues. And, BTW, kernel developers should > know when a new kernel arrives. :) I think the plan is different. It is to have a double kernel in sid all the time, and only one in testing. I guess this second sid kernel could replace at least part of what is done currently in experimental, which would improve at least its auto-builder state. The experimental kernels hardly fullfill the definition of experimental nowaday. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
On Sat, May 13, 2006 at 12:44:36PM -0600, dann frazier wrote: > On Sat, May 13, 2006 at 06:23:46AM +0200, Sven Luther wrote: > > On Fri, May 12, 2006 at 05:08:34PM -0600, dann frazier wrote: > > > On Fri, May 12, 2006 at 01:31:30PM +0200, Sven Luther wrote: > > > > On Fri, May 12, 2006 at 09:40:37AM +0200, Bastian Blank wrote: > > > > > On Thu, May 11, 2006 at 05:00:03PM -0600, dann frazier wrote: > > > > > > I don't know what Bastian was intending; but the scenario I > > > > > > mentioned > > > > > > was to: > > > > > > 1) Upload linux-2.6.16 to sid w/o metapackages > > > > > > 2) Let linux-2.6.16 migrate to sid > > > > >3) Upload linux-latest-2.6 via t-p-u > > > > > > > > > > > Either way, yes. We should remove linux-2.6 from testing once > > > > > > linux-2.6.16 enters. > > > > > > > > > > Bastian > > > > > > > > I am not sure i like this, this means we separate the metapackages out > > > > of the > > > > common package again. Is this a good thing ? We made the inverse step > > > > earlier. > > > > > > Yes, I'd rather see us keep the metapackages bundled in linux-2.6.16. > > > The fewer packages that have to be updated for a security update, the > > > better. > > > > > > Of course, I do see the benefit to Bastian's suggestion - we'd have > > > working metapackages for both sid & etch that pull in the latest > > > available in that dist. My proposal leaves sid meta packages pointing > > > at the latest kernel for etch. > > > > Mmm. Do we really want the default for sid to be something that will maybe > > never be going into etch ? > > I think so; there is a class of users (myself included) who want to > run/test the latest and greatest on some machines, and its nice when > it automatically updates. Users that just want to run what will go > into testing should, well, just run testing :) We could have special sid-only metapackages then. This would solve the issue neatly. We would have one package aimed at etch, which is the current linux-2.6 or linux-2.6.16 or linux-2.6-etch or whatever, and exactly like current linux-2.6. And then we would have another package, aimed at unstable, and which is not supposed to go into etch. This package would be named linux-2.6-dev or something such, and have another set of metapackages, which would have the same effect as the current ones, except they are named with some suffix which clearly identicate them as the sid version, and will thus never be in confusion with the real metapackages. This would also help to avoid accidental upgrades to sid kernel from an etch user trying to get one or another sid packages in a clumsy way. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* dann frazier ([EMAIL PROTECTED]) [060513 21:01]: > On Sat, May 13, 2006 at 06:23:46AM +0200, Sven Luther wrote: > > Mmm. Do we really want the default for sid to be something that will maybe > > never be going into etch ? > I think so; there is a class of users (myself included) who want to > run/test the latest and greatest on some machines, and its nice when > it automatically updates. Users that just want to run what will go > into testing should, well, just run testing :) Well, actually, there are reasons for both decisions. I think that in the end, it is more important to make building packages for etch easier. Please remember, this is only for a limited time, and at that time, we'll be quite busy with etch issues. And, BTW, kernel developers should know when a new kernel arrives. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
On Sat, May 13, 2006 at 06:23:46AM +0200, Sven Luther wrote: > On Fri, May 12, 2006 at 05:08:34PM -0600, dann frazier wrote: > > On Fri, May 12, 2006 at 01:31:30PM +0200, Sven Luther wrote: > > > On Fri, May 12, 2006 at 09:40:37AM +0200, Bastian Blank wrote: > > > > On Thu, May 11, 2006 at 05:00:03PM -0600, dann frazier wrote: > > > > > I don't know what Bastian was intending; but the scenario I mentioned > > > > > was to: > > > > > 1) Upload linux-2.6.16 to sid w/o metapackages > > > > > 2) Let linux-2.6.16 migrate to sid > > > >3) Upload linux-latest-2.6 via t-p-u > > > > > > > > > Either way, yes. We should remove linux-2.6 from testing once > > > > > linux-2.6.16 enters. > > > > > > > > Bastian > > > > > > I am not sure i like this, this means we separate the metapackages out of > > > the > > > common package again. Is this a good thing ? We made the inverse step > > > earlier. > > > > Yes, I'd rather see us keep the metapackages bundled in linux-2.6.16. > > The fewer packages that have to be updated for a security update, the > > better. > > > > Of course, I do see the benefit to Bastian's suggestion - we'd have > > working metapackages for both sid & etch that pull in the latest > > available in that dist. My proposal leaves sid meta packages pointing > > at the latest kernel for etch. > > Mmm. Do we really want the default for sid to be something that will maybe > never be going into etch ? I think so; there is a class of users (myself included) who want to run/test the latest and greatest on some machines, and its nice when it automatically updates. Users that just want to run what will go into testing should, well, just run testing :) -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* dann frazier ([EMAIL PROTECTED]) [060513 02:00]: > Of course, I do see the benefit to Bastian's suggestion - we'd have > working metapackages for both sid & etch that pull in the latest > available in that dist. My proposal leaves sid meta packages pointing > at the latest kernel for etch. Actually, I see the sid meta packages pointing to the latest etch kernel as a feature, as this makes sure that more boxes have these kernels installed, and especially the d-i-build boxes will have the correct kernel, which will help with d-i testing and final preparations for etch. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
