After rebooting into inux-image-3.2.0-2-686-pae i dont se this problem any more.
snippet from kern.log
Jul 9 00:07:34 EV705AB69A02DA kernel: [49502.048124] ata1.00:
exception Emask 0x0 SAct 0x7003824 SErr 0x0 action 0x6 frozen
Jul 9 00:07:34 EV705AB69A02DA kernel: [49502.048133] ata1.00: failed
Package: linux-image-3.2.0-3-686-pae
Version: 3.2.21-3
Severity: grave
Justification: renders package unusable
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
I upgraded to linux-image-3.2.0-3-686-pae from linux-image-3.2.0-
On Wed, 2012-07-11 at 21:49 +0200, Hans-Juergen Mauser wrote:
> Hello,
>
>
> Ben Hutchings wrote:
> > [...]
> >
> > I think it's fine and has nothing to do with the problem.
> >
> > Since you say it has taken 1-8 days for any problem to appear, I suppose
> > you will have to wait a few week
Processing commands for cont...@bugs.debian.org:
> clone 617299 -1
Bug #617299 [dpkg] dpkg-deb: should give a hint when it fails due to filling
/tmp
Bug 617299 cloned as bug 681550
> retitle -1 kernel-handbook: encourage disabling DEBUG_INFO and setting TMPDIR
Bug #681550 [dpkg] dpkg-deb: should
clone 617299 -1
retitle -1 kernel-handbook: encourage disabling DEBUG_INFO and setting TMPDIR
submitter -1 !
reassign -1 debian-kernel-handbook 1.0.13
quit
Martin-Éric Racine wrote:
> The solution to bug #617299 is therefore to either define TMPDIR to
> some actual hard-disk with sufficient stora
2012/7/13 Ben Hutchings :
> On Fri, Jul 13, 2012 at 11:02:57PM +0300, Martin-Éric Racine wrote:
>> (putting back the CC to the bug, which will probably need to be
>> reassigned to 'linux')
>> 2012/7/13 Jonathan Nieder :
>> > (dropping dpkg maintainers from cc)
>> > Martin-Éric Racine wrote:
>> >> 2
On Thu, 2012-07-12 at 08:20 -0800, peasth...@shaw.ca wrote:
> Package: linux-2.6
> Version: 2.6.32-45
> File: linux-image-2.6.32
> Severity: normal
> Tags: upstream
>
> *** Please type your report below this line ***
>
> A firewire driver produces this complaint at system startup.
> Loading, plea
On Sat, 2012-07-14 at 07:51 +0300, Martin-Éric Racine wrote:
> 2012/7/13 Ben Hutchings :
[...]
> If I disable CONFIG_DEBUG_INFO again just before building, the kernel
> indeed is MUCH smaller (I had probably forgotten to disable it before
> attempting a new build; sorry for the confusion) and it ea
On Fri, 2012-07-13 at 13:37 -0700, Linus Torvalds wrote:
> So this has long been one of my pet configuration peeves: as a user I
> am perfectly happy answering the questions about what kinds of
> hardware I want the kernel to support (I kind of know that), but many
> of the "support infrastructure"
On 07/13/12 14:55, Dave Jones wrote:
> On Fri, Jul 13, 2012 at 11:50:25PM +0200, Paul Bolle wrote:
>
> > But just removing all the certainly unused macros probably wouldn't have
> > made a noticeable difference to anyone using those defconfig files
> > anyway.
>
> My point is that I don't thin
On Sat, 14 Jul 2012, Jesper Juhl wrote:
We are going to end up with a million+ (or something like that) "config
" options that are going to have to be kept up-to-date
regularly...
Do we really want that?
Maybe we do, maybe we don't - I'm not saying anything either way - just
pointing it out.
I
On Fri, 13 Jul 2012, Linus Torvalds wrote:
> So this has long been one of my pet configuration peeves: as a user I
> am perfectly happy answering the questions about what kinds of
> hardware I want the kernel to support (I kind of know that), but many
> of the "support infrastructure" questions ar
On 07/13/2012 10:37 PM, Linus Torvalds wrote:
> So this has long been one of my pet configuration peeves: as a user I
> am perfectly happy answering the questions about what kinds of
> hardware I want the kernel to support (I kind of know that), but many
> of the "support infrastructure" questions
On Fri, Jul 13, 2012 at 02:17:30PM -0700, Linus Torvalds wrote:
> On Fri, Jul 13, 2012 at 2:02 PM, Dave Jones wrote:
> >
> > As long as you don't mind these being added after the fact, I suppose
> > it would be workable. The reason I say that is sometimes, it even catches
> > *us*
> > by surpris
On Fri, 13 Jul 2012, Linus Torvalds wrote:
On Fri, Jul 13, 2012 at 2:17 PM, Casey Schaufler wrote:
Oh dear. I would expect Fedora to say that they require SELinux,
thereby making it unusable by anyone doing LSM development.
Oh, *absolutely*.
These options would *not* be meant for people do
On Fri, 2012-07-13 at 17:55 -0400, Dave Jones wrote:
> My point is that I don't think there's many people actually using them.
> (maybe more on the niche platforms, but x86[64] ? I'm sceptical they're used
> at all)
I guess you're right. Personally, I tend to start my journeys in self
compiled ke
I always thought that the x86 defconfig file was the one that Linus
used for his primary machine.
-Tony
--
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/ca+8mbbl9mrx
On Fri, 2012-07-13 at 17:02 -0400, Dave Jones wrote:
> I wish defconfig was actually something useful like this, instead of..
> what the hell is it exactly ? No-one even seems to agree, other than
> "random selection of options, many of which were removed n years ago"
As for the "many of which wer
On Fri, Jul 13, 2012 at 11:50:25PM +0200, Paul Bolle wrote:
> But just removing all the certainly unused macros probably wouldn't have
> made a noticeable difference to anyone using those defconfig files
> anyway.
My point is that I don't think there's many people actually using them.
(maybe m
On Fri, Jul 13, 2012 at 10:54 PM, Myklebust, Trond
wrote:
> We could at least make selection of a minimal set of drivers for the
> more common virtualised platforms a lot easier.
> Right now, you need to hunt through 30+ different menus in order to find
> what you need to run in a basic KVM virtua
On Fri, Jul 13, 2012 at 2:17 PM, Casey Schaufler wrote:
>
> Oh dear. I would expect Fedora to say that they require SELinux,
> thereby making it unusable by anyone doing LSM development.
Oh, *absolutely*.
These options would *not* be meant for people doing odd things and
experienting with config
On 7/13/2012 1:37 PM, Linus Torvalds wrote:
> So this has long been one of my pet configuration peeves: as a user I
> am perfectly happy answering the questions about what kinds of
> hardware I want the kernel to support (I kind of know that), but many
> of the "support infrastructure" questions ar
On Fri, Jul 13, 2012 at 2:02 PM, Dave Jones wrote:
>
> As long as you don't mind these being added after the fact, I suppose
> it would be workable. The reason I say that is sometimes, it even catches
> *us*
> by surprise. We recently found out our virtualisation guys started
> using sch_htb fo
On 07/13/2012 02:37 PM, Linus Torvalds wrote:
Would something like this make sense to people? I really think that
"How do I generate a kernel config file" is one of those things that
keeps normal people from compiling their own kernel. And we *want*
people to compile their own kernel so that th
On Fri, Jul 13, 2012 at 11:02 PM, Dave Jones wrote:
> I wish defconfig was actually something useful like this, instead of..
> what the hell is it exactly ? No-one even seems to agree, other than
> "random selection of options, many of which were removed n years ago"
It's just to difficult to upd
On Fri, 2012-07-13 at 13:37 -0700, Linus Torvalds wrote:
> So this has long been one of my pet configuration peeves: as a user I
> am perfectly happy answering the questions about what kinds of
> hardware I want the kernel to support (I kind of know that), but many
> of the "support infrastructure"
On Fri, Jul 13, 2012 at 01:37:41PM -0700, Linus Torvalds wrote:
> The point I'm slowly getting to is that I would actually love to have
> *distro* Kconfig-files, where the distribution would be able to say
> "These are the minimums I *require* to work".
As long as you don't mind these being ad
So this has long been one of my pet configuration peeves: as a user I
am perfectly happy answering the questions about what kinds of
hardware I want the kernel to support (I kind of know that), but many
of the "support infrastructure" questions are very opaque, and I have
no idea which of the them
2012/7/13 Jonathan Nieder :
> Martin-Éric Racine wrote:
>> 2012/7/13 Jonathan Nieder :
>
>>> Just to confirm, are you certain CONFIG_DEBUG_INFO is disabled?
>>
>> Yup.
>
> Ok. Please attach your .config so we can reproduce this.
I have already stated that the .config is copied as-is from the stoc
On Fri, Jul 13, 2012 at 11:02:57PM +0300, Martin-Éric Racine wrote:
> (putting back the CC to the bug, which will probably need to be
> reassigned to 'linux')
> 2012/7/13 Jonathan Nieder :
> > (dropping dpkg maintainers from cc)
> > Martin-Éric Racine wrote:
> >> 2012/7/13 Jonathan Nieder :
> >>> M
2012/7/13 Jonathan Nieder :
> Martin-Éric Racine wrote:
>> (putting back the CC to the bug, which will probably need to be
>> reassigned to 'linux')
>> 2012/7/13 Jonathan Nieder :
>>> (dropping dpkg maintainers from cc)
>>> Martin-Éric Racine wrote:
>
I'm already aware of the effects of stripp
Martin-Éric Racine wrote:
> I have already stated that the .config is copied as-is from the stock
> Debian 3.2 kernel's config.
Oh, interesting.
May we have a debdiff of the binary packages, too?
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe"
Martin-Éric Racine wrote:
> 2012/7/13 Jonathan Nieder :
>> Just to confirm, are you certain CONFIG_DEBUG_INFO is disabled?
>
> Yup.
Ok. Please attach your .config so we can reproduce this.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Troub
(putting back the CC to the bug, which will probably need to be
reassigned to 'linux')
2012/7/13 Jonathan Nieder :
> (dropping dpkg maintainers from cc)
> Martin-Éric Racine wrote:
>> 2012/7/13 Jonathan Nieder :
>>> Martin-Éric Racine wrote:
>
Martin-Éric Racine wrote:
> (putting back the CC to the bug, which will probably need to be
> reassigned to 'linux')
> 2012/7/13 Jonathan Nieder :
>> (dropping dpkg maintainers from cc)
>> Martin-Éric Racine wrote:
>>> I'm already aware of the effects of stripping binaries. However, you
>>> gotta
2012/7/13 Jonathan Nieder :
> Hi,
>
> Martin-Éric Racine wrote:
>
>> Actually, this feels like an upstream kernel 3.2 bug: as a test, I
>> purposely disabled TMPFS for /tmp just to see if the kernel package
>> would finally build as expected. It did, except that the resulting DEB
>> is a whopping 4
(dropping dpkg maintainers from cc)
Martin-Éric Racine wrote:
> 2012/7/13 Jonathan Nieder :
>> Martin-Éric Racine wrote:
>>> the resulting DEB
>>> is a whopping 488MB in size, compared to 22MB for the stock Debian
>>> linux-image-3.2.0-3-686-pae
Hi,
Martin-Éric Racine wrote:
> Actually, this feels like an upstream kernel 3.2 bug: as a test, I
> purposely disabled TMPFS for /tmp just to see if the kernel package
> would finally build as expected. It did, except that the resulting DEB
> is a whopping 488MB in size, compared to 22MB for the
Processing commands for cont...@bugs.debian.org:
> found 571980 linux-2.6/2.6.32-45
Bug #571980 [linux-2.6] linux-image-2.6.32-trunk-686: Kernel oops when ipmi
modules loaded on ibm 326m
Marked as found in versions linux-2.6/2.6.32-45.
> fixed 571980 linux/3.2.21-3
Bug #571980 [linux-2.6] linux-i
2012/7/13 Martin-Éric Racine :
> 2012/7/13 Martin-Éric Racine :
>> Package: dpkg
>> Version: 1.16.4.3
>> Followup-For: Bug #617299
>>
>> I also encounter the same bug when trying to build kernel 3.2.21 from
>> upstream tarball:
>>
>> $ LOCALVERSION=-git-686-pae make deb-pkg
>> [...]
>> dpkg-deb: b
On 12/07/12 21:21, Jonathan Nieder wrote:
Ian Crowther wrote:
I'm not sure what 2.6.32.y means. I've installed 2.6.32-5-686, which
seems to be recent.
Am I correct in assuming you mean version 2.6.32-45? You can check
with
dpkg-query -W linux-image-$(uname -r)
to see the v
On Fri, 13 Jul 2012, Ben Hutchings wrote:
> I certainly consider mounting of debugfs to be significant security
> liability. I'm not at all happy that people use it as the basis for
Seconded. I know of at least three ways to hardcrash boxes through
debugfs (system specific, not a kernel bug), an
Ben Hutchings writes:
> I would like to address this by backporting this feature:
>
> commit d6e486868cde585842d55ba3b6ec57af090fc343
> Author: Ludwig Nussel
> Date: Wed Jan 25 11:52:28 2012 +0100
>
> debugfs: add mode, uid and gid options
>
> and then changing the default mode (mask) to b
Bjørn Mork wrote:
> 1) mode and owner is not propagated to files below the mount point:
That's intentional to keep things simple. If you can control the x bit
on the mount point then you can control who can reach files beneath.
> 2) ownership and mode seems to be shared amoung all mount points,
44 matches
Mail list logo
