reopen 505609
reassign 505609 linux-2.6
affects 505609 lilo
thanks
Stephen Powell wrote:
> The real question is, "Why didn't the map installer get run during
> the kernel upgrade?"
[...]
> So is this a bug in the kernel maintainer scripts? Or is it a feature?
> I don't know. I'll leave that up
Package: linux-2.6
Version: 2.6.32-12
Severity: serious
Because of the IDE -> ATA transition for Squeeze the pata_cmd64x driver should
be enabled instead of the (old) cmd64x driver. AFAIK the pata_cmd64x has been
tested and is known to work correctly.
My system failed to boot after updrading to 2
reassign 580265 linux-2.6 2.6.32-9
thanks
On Tuesday 04 May 2010, Gmail Notifier wrote:
> 00:19.0 Ethernet controller [0200]: Intel Corporation 82578DC Gigabit
> Network Connection [8086:10f0] (rev 06)
> Subsystem: Intel Corporation Device [8086:0037]
> Kernel driver in use: e1000e
reassign 549681 base-installer
severity 549681 normal
tag 549681 help
user debian-b...@lists.debian.org
usertag 549681 powerpc
thanks
On Wednesday 24 March 2010, maximilian attems wrote:
> > some OpenFirmware implementations, such as the one in the PegasosII,
> > have a 12 MB size limit on kernel
On Sunday 21 March 2010, Ben Hutchings wrote:
> On Fri, 2010-03-19 at 03:29 +, Marco d'Itri wrote:
> > elen...@planet.nl wrote:
> > >I don't think the first would be a very good idea as it means that
> > > we'll still not be rid of the IDE drivers. It seems better to
> > > concentrate the
> >
>
(Please CC on replies.)
On Thursday 18 March 2010, Ben Hutchings wrote:
> On Thu, Mar 18, 2010 at 05:05:47PM +0100, Frans Pop wrote:
> > On Thursday 18 March 2010, Ben Hutchings wrote:
> > > PATA drivers of either flavour are mostly selected on a
> > > per-architectu
(Replying to the list only; please CC me on replies as I'm not subscribed)
On Thursday 18 March 2010, Ben Hutchings wrote:
> PATA drivers of either flavour are mostly selected on a per-architecture
> basis, and no change has been made to non-x86. If people are willing to
> test on the non-x86 arc
reassign 572787 linux-2.6 2.6.32-9
thanks
On Saturday 06 March 2010, Marc Haber wrote:
> a hp ProLiant DL385 G6 does not boot the daily installer image in
> 64bit mode. The box is a Dual Six-Core Opteron with 80 Gig of RAM.
>
> Trying a 64 bit expert install, vga=normal is needed to get output at
On Wednesday 03 March 2010, Moritz Muehlenhoff wrote:
> As for Lenny; is this error reproducible on your system with low memory,
> so that we can test it (e.g. by exhausting system memory)? I've tried
> to put a virtual machine under memory pressure, but couldn't trigger the
> error in my limited t
On Monday 01 March 2010, Uwe Kleine-König wrote:
> It's already fixed in 072ad3179c526b90b57719e127de851182b04c4c[1] ==
> 0.93.4-16-g02cb277.
>
> Should I report the problem anyhow?
That would seem rather pointless.
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
Uwe Kleine-König wrote:
> I created and successfully installed a custom kernel package using
> $(make deb-pkg).
>
> Then after a failed boot test I removed it and then thought that I
> actually want to purge it.
>
> Cannot delete /boot/initrd.img-2.6.33-rc8-rt, doesn't exist.
> run-parts: /etc/ke
reassign 512679 initramfs-tools 0.92o
thanks
I can reproduce the problem for Lenny in the initramfs debug shell, but
more works fine if I do 'busybox sh' and then 'find | more'.
I guess that the most likely cause of the problem is either console or
keyboard configuration in the initramfs enviro
On Friday 12 February 2010, Ben Hutchings wrote:
> Perhaps it is not included in the appropriate d-i package?
arcmsr has been included in scsi-extra-modules since Nov 2006, if available
for an architecture.
For amd64:
$ dpkg -c scsi-extra-modules-2.6.30-2-amd64-di_1.61_amd64.udeb | grep arcmsr
dr
reassign 565639 linux-2.6 2.6.30-8
severity 565639 serious
affects 565639 debian-installer
On Sunday 24 January 2010, Jurij Smakov wrote:
> Adding kernel team for comment: it looks like the value returned by
> uname -m has changed from 'sparc64' in kernel 2.6.26 to 'sparc' in
> 2.6.30 (and, probab
On Tuesday 19 January 2010, dann frazier wrote:
> This fixes the issue for me, can you verify?
>
> zelenka.debian.org:~dannf/linux-image-2.6.18-6-s390_2.6.18.dfsg.1-27~562
>525.testfix.1_s390.deb
Works for me too. Thanks.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
wit
On Sunday 17 January 2010, Frans Pop wrote:
> On Saturday 16 January 2010, ael wrote:
> > On further investigation, I find that
> > /lib/modules/2.6.30-2-686/kernel/fs/ext4/ext4.ko
> > is missing from the initramfs.
> >
> > I assume that this explains the f
reassign 565511 initramfs-tools 0.93.4
retitle 565511 ext4.ko module missing from "dep" initramfs
thanks
On Saturday 16 January 2010, ael wrote:
> On further investigation, I find that
> /lib/modules/2.6.30-2-686/kernel/fs/ext4/ext4.ko
> is missing from the initramfs.
>
> I assume that this expl
On Sunday 03 January 2010, dann frazier wrote:
> Thanks. This suggests that the fixes for CVE-2009-0029 are causal. To
> verify, can you test this kernel which drops only those fixes?
>
> zelenka.debian.org:~dannf/linux-headers-2.6.18-6-s390_2.6.18.dfsg.1-26et
>ch1+nocve20090029_s390.deb
s/header
On Saturday 02 January 2010, you wrote:
> Can you try:
> zelenka.debian.org:~dannf/linux-image-2.6.18-6-s390_2.6.18.dfsg.1-26etch
>1+div64_s390.deb
Linux version 2.6.18-6-s390 (Debian 2.6.18.dfsg.1-26etch1+div64)
[...]
Failed to execute /init
Kernel panic - not syncing: No init found. Try passing
On Tuesday 29 December 2009, dann frazier wrote:
> I don't see an obvious cause for the failure. Can you try booting
> 24etch1 in an effort to bisect the failure? In case you can't find the
> deb (I couldn't) I've built one that you can find in my home directory
> on zelenka.debian.org.
Linux vers
Package: linux-2.6
Severity: serious
Version: 2.6.18.dfsg.1-26etch1
Tags: d-i
X-Debbugs-CC: da...@debian-org
While testing the update for oldstable of debian-installer on my Hercules
s390 emulator, I found that the new kernel fails to boot.
It fails to execute init after loading the initramfs.
T
Kurt Roeckx wrote:
> Now that we have a 2.6.32 kernel in unstable, can you updates us
> on the various things mentioned in this mail?
I have another question. The naming policy for linux-image packages seems
to have changed: instead of an ABI we now have "trunk". First I thought
this was a bug,
JFYI.
Yesterday I found that the nfs-kernel-server init script will fail with
2.6.32 because a test if the kernel has NFS support fails due to the fact
that the symbol it tests for no longer exists in /proc/kallsyms.
For details: http://bugs.debian.org/554508
Cheers,
FJP
--
To UNSUBSCRIBE,
Package: initramfs-tools
Version: 0.93.4
Severity: important
I noticed that I now have what seems to be duplicate hook scripts:
/etc/kernel$ ls *
postinst.d:
10initramfs initramfs-tools
postrm.d:
10initramfs initramfs-tools
Reason is probably that these are conffiles, which don't get removed
a
Looks a lot like http://bugs.debian.org/494311 (which is still open...).
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi,
On lkml there's a discussion about unconditionally adding a "+" to the
kernel version if it is being built from a version control system and
there are commits after the last tagged release.
So, during the merge window you would no longer get '2.6.31', but
'2.6.31+'.
This is mostly targeted
Moritz Muehlenhoff wrote:
> Adding debian-hppa in the loop: Is this a known issue and
> specific to hppa? (Since otherwise I would suppose there were
> earlier reports from the more widely used archs).
A quick google for xlog_valid_rec_header suggests [1] that this is neither
a recent issue, nor
tags 539378 fixed-upstream
thanks
Fix is now in upstream mainline: b4f2e2ad5348063ef94aa623f6f09b52ecaf0990
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Saturday 01 August 2009, Carlos O'Donell wrote:
> I suggest you use Dave's patch please, it is IMO the most correct
> patch.
Right. I think the original patch is probably responsible for endless
errors on shutdown/reboot:
Bad Address (null pointer deref?): Code=15 regs=bea7cf70
(Addr=
tags 539378 patch
thanks
On Saturday 01 August 2009, Helge Deller wrote:
> Kyle, you beat me.
> Attached is my patch
>
> Tested and works.
Works for me too. Cool.
Your patch contained a few whitespace errors and, because of that, one
unnecessary change. Attached a version with those cleane
On Friday 31 July 2009, Carlos O'Donell wrote:
> I'm glad this is fixed in 2.6.31-rc4, do you need any more help from
> the porters?
Well, it might be nice if the responsible change(s) could be identified.
Possibly they could be applied/backported to .30.
Not sure if it's worth the effort. It mig
On Friday 31 July 2009, Frans Pop wrote:
> Hmm. The "Badness at smp.c" warning isn't new of course. That was also
> there with .24 and .26 (the last working kernel I have).
>
> What is new is that the boot now hangs immediately after that point.
Whatever the problem i
Package: linux-2.6
Version: 2.6.26-15
Severity: normal
Affects both stable and unstable!
kernel: Linux version 2.6.26-2-parisc64-smp [...]
kernel: nfs: Global Offset Table overflow (used 1075, allowed 1023)
kernel: Linux version 2.6.30-1-parisc64 [...]
kernel: nfs: Global Offset Table overflow (
Hmm. The "Badness at smp.c" warning isn't new of course. That was also
there with .24 and .26 (the last working kernel I have).
What is new is that the boot now hangs immediately after that point.
I also note the following in the boot messages:
unwind_init: start = 0x404b9144, end = 0x404e5204,
Package: linux-2.6
Version: 2.6.30-3
Severity: important
The 2.6.30-1-parisc64-smp kernel fails to boot on my J5600 system.
The non-smp kernel does boot correctly and the oops also indicates
an smp problem.
Boot log from serial console attached.
-- System Information:
Debian Release: squeeze/sid
On Wednesday 29 July 2009, Frans Pop wrote:
> On Wednesday 29 July 2009, you wrote:
> > > Just for the record, the following is NOT correct:
> > > 10:09 otavio: only linux-modules-extra
> > > 10:09 nothing d-i uses and nothing one should really have to
> > &
On Wednesday 29 July 2009, you wrote:
> > Just for the record, the following is NOT correct:
> > 10:09 otavio: only linux-modules-extra
> > 10:09 nothing d-i uses and nothing one should really have to
> > care.
> >
> > D-I uses the loop-aes modules (for encrypted partitioning) and that
> > is exa
On Wednesday 29 July 2009, maximilian attems wrote:
> > Are there logs of the two meetings?
>
> well the second meeting got shortcut by recent events,
> first meeting yes:
> http://charm.itp.tuwien.ac.at/~mattems/%23debian-kernel.2009-07-25.log
Thx.
Just for the record, the following is NOT corre
On Tuesday 28 July 2009, Ben Hutchings wrote:
> There will be a second kernel BoF/meeting tomorrow (29th July) at
> 16:00-18:00 local time (14:00-16:00 UTC).
>
> I would like to discuss a possible lenny-and-1/2 kernel release. There
> should be time to discuss several other issues.
Are there logs
On Monday 27 July 2009, Felix Zielcke wrote:
> Am Montag, den 27.07.2009, 22:11 +0200 schrieb Felix Zielcke:
> > Am Montag, den 27.07.2009, 14:29 -0500 schrieb David A. Greene:
> > > Boot of any install method freezes after the message "Setting
> > > console to Unicode" appears. Immediately prior
Note that an additional issue was found with 2.6.27 after the change to
-fno-strict-overflow. See http://lkml.org/lkml/2009/7/20/80 and follow-ups
for details.
The cause (compiler bug in gcc-4.2.4) was identified in
http://lkml.org/lkml/2009/7/21/423 and it looks like it's going to be
"fixed" wi
On Sunday 19 July 2009, dann frazier wrote:
> A fix has been committed in r13974 and an s390 build should appear in
> the lenny suite of the snapshot archive after the next daily build
> cycle. Can you test a 2.6.26-18~snapshot.13974 (or greater) build
> when it appears?
linux-image-2.6.26-2-s390
On Friday 17 July 2009, maximilian attems wrote:
> On Fri, 17 Jul 2009, Michalis Georgiou wrote:
> > i did what i describe above. i chose targeted, installation failed
> > and at that time i opened a console and gave :
> >
> > sh -x mkinitramfs -o /tmp/bla
> >
> > the output is :
> > sh: can't open
On Thursday 16 July 2009, Frans Pop wrote:
> On Wednesday 15 July 2009, dann frazier wrote:
> > On Mon, Jul 13, 2009 at 11:22:12AM +0200, Frans Pop wrote:
> > > Linus has committed a different solution: replacing -fwrapv by
> > > -fno-strict-overflow
On Wednesday 15 July 2009, dann frazier wrote:
> On Mon, Jul 13, 2009 at 11:22:12AM +0200, Frans Pop wrote:
> > Linus has committed a different solution: replacing -fwrapv by
> > -fno-strict-overflow.
> > See upstream commit a137802ee839ace40079bebde24cfb416f73208a.
>
>
Linus has committed a different solution: replacing -fwrapv by
-fno-strict-overflow.
See upstream commit a137802ee839ace40079bebde24cfb416f73208a.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Saturday 11 July 2009, Luk Claes wrote:
> > what are the remaining issues that you are concerned about?
>
> The ones that prevent linux-2.6 from migrating once it would be
> unblocked.
Like FTBFS of linux-modules-extra-2.6 on 3 architectures I guess? That
seemed to me like a valid reason not t
On Friday 10 July 2009, Frans Pop wrote:
> I've proposed the attached patch on lkml:
> http://lkml.org/lkml/2009/7/10/49.
The version check in the patch was incorrect. Here's an improved version
that also allows -fwrapv for gcc 4.2.
See also the follow ups on lkml.
From: Fr
On Friday 10 July 2009, Ben Hutchings wrote:
> On Fri, 2009-07-10 at 09:51 +0200, Frans Pop wrote:
> > On Friday 10 July 2009, Frans Pop wrote:
> > > On Friday 10 July 2009, dann frazier wrote:
> > > > Maybe the -fwrapv change?
> > >
> > > Bingo.
tags 536354 patch
thanks
On Friday 10 July 2009, Frans Pop wrote:
> On Friday 10 July 2009, dann frazier wrote:
> > Maybe the -fwrapv change?
>
> Bingo. Makes a lot of sense too for an issue related to gcc version.
I've proposed the attached patch on lkml: http://lkml.o
On Friday 10 July 2009, dann frazier wrote:
> Maybe the -fwrapv change?
Bingo. Makes a lot of sense too for an issue related to gcc version.
Reverting only that patch on top of -17 results in good boot too.
Gah! And it's even a known issue:
- http://bugzilla.kernel.org/show_bug.cgi?id=13012
- ht
On Thursday 09 July 2009, dann frazier wrote:
> I'd suggest the CVE-2009-0029 fixes. Lots of arch-specific stuff in
> there.
Nope. Other suggestions welcome. I'll nail it down tomorrow.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
On Thursday 09 July 2009, Frans Pop wrote:
> Here's what I currently know for certain:
> * 2.6.26-13 built with gcc-4.1 (4.1.2-24) boots [2]
> * 2.6.26-17 built with gcc-4.1 (4.1.2-25) panics
> * 2.6.26-17 built with gcc-4.2 (4.2.4-6) boots
Bisect... - the following all built wi
On Thursday 09 July 2009, dann frazier wrote:
> On Thu, Jul 09, 2009 at 10:05:15AM -0600, dann frazier wrote:
> Here's a simple rebuild from zelenka's lenny chroot:
> http://people.debian.org/~dannf/bugs/536354/
Thanks Dann. That paniced too.
After that I've managed after all to build a 4.1 cro
On Thursday 09 July 2009, dann frazier wrote:
> The buildd log shows that 2.6.26-17 was built w/ gcc-4.1_4.1.2-25. Is
> there a cross-compiler available w/ that version?
Unfortunately not that I know of. Packages currently available on emdebian
are incomplete.
And I've had very mixed results try
On Thursday 09 July 2009, Frans Pop wrote:
> > A user reported on d-s390 [1] that a Lenny installation on s390
> > failed with a kernel panic during boot. I could reproduce the panic
> > on my Hercules system using the installer.
>
> Hmmm. This is fun. If I cross-compile th
> A user reported on d-s390 [1] that a Lenny installation on s390 failed
> with a kernel panic during boot. I could reproduce the panic on my
> Hercules system using the installer.
Hmmm. This is fun. If I cross-compile the kernel myself it boots fine.
I used my own cross-build system for this, no
Package: linux-2.6
Version: 2.6.26-17
Severity: important
A user reported on d-s390 [1] that a Lenny installation on s390 failed
with a kernel panic during boot. I could reproduce the panic on my
Hercules system using the installer.
I then installed the current Lenny kernel on my installed Hercul
Package: ftp.debian.org
Severity: normal
The non-free/debian-installer section in unstable contains a number
of firmware udebs built from ancient versions of firmware-nonfree.
These udebs have never been used and should really have been automatically
cleaned from the archive ages ago.
Please rem
Package: linux-2.6
Version: 2.6.26-13lenny2
I got the following BUG in my logs. This is on a system with very
little memory.
kernel: [4205017.800545] sed[4196]: segfault at 13b0f4 ip b7e7c013 sp bfe7eb70
error 4 in libc-2.7.so[b7e21000+138000]
kernel: [4205017.801686] [ cut here ]---
reassign 513695 linux-2.6 2.6.28-1
forwarded 513695 http://www.spinics.net/lists/netdev/msg96676.html
tags 513695 patch
thanks
The cause of these errors has been traced to the kernel. The errors are
bogus and due to a test that's no longer correct after a code change in
2.6.28.
The errors have
Bastian Blank wrote:
> On Mon, May 04, 2009 at 10:50:58AM +0100, Jurij Smakov wrote:
>> 2.6.29-4 failed to build on sparc:
>
> Already known.
>
>> I can investigate, but if you know off the top of your head what can
>> be causing it (missing zImage file after the build), please let me
>> know.
>
found 525958 2.6.26-15
thanks
If I understand David Miller correctly, this also affects stable kernels.
Here's a message I received from him for #504721 against D-I's rootskel
(which was rejected because that bug's already been archived).
I'm not sure if changing this is appropriate for stable,
STEPHEN POWELL wrote:
> My problem, on the other hand, has always been that the kernel hangs
> right before the permanent root file system gets mounted. I've always
> been able to get that far but no farther. For me, the key is that the
> s390x kernel works flawlessly, but the s390 kernel hangs.
P
Could http://bugs.debian.org/511334 be related to your problem? There's a
link to patch in one of the last messages.
See especially messages #57 and #65.
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas..
Tyler MacDonald wrote:
> Darren Salt wrote:
>> > On Wed, Apr 01 2009, Frans Pop wrote:
>> [make-kpkg]
>> >> But is anyone still using it? Is there any current reason to support
>> >> it
>
> Well, there's still some kernel options that ar
Darren Salt wrote:
> I demand that Manoj Srivastava may or may not have written...
>> On Wed, Apr 01 2009, Frans Pop wrote:
>>> But is anyone still using it? Is there any current reason to support
>>> it
>
>> I think that there are Debian users who use that op
Manoj Srivastava wrote:
> On Wed, Apr 01 2009, Frans Pop wrote:
>> (i.e. is there any reason to _add_ support for it in deb-pkg or in
>> whatever the kernel team is planning)?
>
> I think so. If we do standardize on /etc/kernel/*.d directories
> as the place wh
(dropping ltsp as the list is moderated)
On Wednesday 01 April 2009, maximilian attems wrote:
> On Wed, 25 Mar 2009, Frans Pop wrote:
> > I'm not sure whether this discussion should happen here (d-kernel +
> > selected interested parties) or would be better held on d-devel.
On Wednesday 01 April 2009, maximilian attems wrote:
> On Wed, 01 Apr 2009, maximilian attems wrote:
> > what be cool would be to have it use debhelper instead of the
> > dpkg call.
I disagree. deb-pkg only creates a two binary packages. It's not a
"normal" package build process at all and the dir
(dropping ltsp as the list is moderated)
Manoj Srivastava wrote:
>> My patch series for the upstream kernel contains roughly the following
>> changes:
[...]
> Where are these patches?
Only just submitted:
http://marc.info/?l=linux-kbuild&m=123861445626856&w=2
maks has also submitted a
On Wednesday 01 April 2009, maximilian attems wrote:
> your mail was quite long, i haven't come yet to respond,
> but will tomorrow.
Thanks. I'll delay my upstream changes until then.
> anyway pushed my deb-pkg fixes, happy when things are moving on that
> front. as this needs to be recommended i
As there haven't been any replies to my mail yet, I'm just going to push
my patches for the deb-pkg target upstream.
The only really important issue is the passing of maintainer script
parameters as described below. I hope we can standardize on that.
Cheers,
FJP
Frans Pop wrote:
&g
Hi all,
I'm not sure whether this discussion should happen here (d-kernel +
selected interested parties) or would be better held on d-devel.
If ppl think it would be better on d-devel, then please let me know and
I'll restart it there.
Sorry if any of this has already been discussed or document
On Friday 20 March 2009, Michal Marek wrote:
> Frans Pop napsal(a):
> > The use case here, which I suspect is not all that uncommon, is that
> > I built a kernel from upstream source on a (Debian unstable) system
> > with the new version of depmod and then installed that ke
On Friday 20 March 2009, Jon Masters wrote:
> > Sure, if there are very strong reasons to break things, fine. But
> > whenever possible the kernel has ensured backwards compatibility,
> > mostly only _after_ someone "complained". Think of the i386 and
> > x86_64 symlinks after the x86 integration,
On Thursday 19 March 2009, Jon Masters wrote:
[...]
I understand how and why and when it works now. I can also easily avoid
the problem now that I know about it. The question here is if the
breakage is really necessary.
I ran into the problem within days of installing the new m-i-t. I don't
th
On Thursday 19 March 2009, Jon Masters wrote:
> Yes, it was a bad idea of
> mine (perhaps) to change the existing file format and I've learned
> something, but it should only have affected for example that 3.4
> release you're using.
Do you mean that earlier versions are not affected? Hasn't depmo
(lkml dropped)
On Thursday 19 March 2009, Jon Masters wrote:
> On Thu, 2009-03-19 at 21:13 +0100, maximilian attems wrote:
> > > That would mean that m-i-t has created a backwards incompatibility
> > > problem _with itself_ and that the problem actually is "installing
> > > a kernel, that was buil
On Thursday 19 March 2009, maximilian attems wrote:
> copied over that file and saw still no sign of a trouble:
> mkinitramfs -v -o /tmp/foo | head -n 12
Here's the actual depmod command executed during a kernel build:
/sbin/depmod -ae -F System.map -b
/home/fjp/projects/kernel/builds/amd64/debi
On Thursday 19 March 2009, maximilian attems wrote:
> thanks for quick feedback.
>
> On Thu, Mar 19, 2009 at 05:15:06PM +0100, Frans Pop wrote:
> > You have to build a kernel from source while having the new m-i-t
> > installed. And then install that kernel *without* running
On Thursday 19 March 2009, maximilian attems wrote:
> > Recently kernels I built from upstream kernel source failed to boot
> > after unpacking them because no modules got included in the initramfs
> > initrd (and thus no root file system).
> > This problem was solved after downgrading to m-i-t 3.4
tags 511334 patch
thanks
On Thursday 19 March 2009, Adam Thornton wrote:
> This appears to fix the problem, in that I get much farther and then
> get stuck in the init-premount scripts because it can't vary my root
> disk online. But *that* is probably because, on this host, I've been
> using by-
Adam,
Can you test if the following patch on top of the Debian 2.6.26 kernel
fixes the problem for you?
http://lkml.org/lkml/2009/3/18/79
Please CC me when you reply!
Thanks,
FJP
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Co
I think this bug is related to an issue I've seen myself with 2.6.28. The
symptoms (point where the boot hangs) are somewhat similar at least.
There seems to be a bug in the kernel's timekeeping code which can
manifest itself differently depending on the (emulated) hardware clock.
My issue was r
On Friday 06 March 2009, Marco d'Itri wrote:
> On Mar 05, Frans Pop wrote:
> > The problem seems to be that depmod, which is run as part of the
> > build, generates a modules.dep file with incomplete paths. These
> > incomplete paths in turn cause initramfs-tools to
reassign 515695 iso-scan
thanks
On Tuesday 17 February 2009, Rohan Dhruva wrote:
> Comments/Problems:
> My /dev/hda5 is a vfat partition having many (upwards of 15) ISOs. They
> are all present in a single directory in the root, so debian installer
> did check them.
That is an extremely unusual s
As requested during the meeting here are two links that explain udeb
migration.
The first also has a proposal how to improve udeb support in britney.
Please ignore the introductory comment about the python implementation of
britney.
Note that the proposal is not a perfect solution. For that we
On Thursday 05 February 2009, Steve McIntyre wrote:
> >On Sun, Feb 01, 2009 at 02:53:58PM +, Steve McIntyre wrote:
> >>Hi folks,
> >>
> >>Apologies for the massive cross-posting, but I'm trying to arrange
> >>some discussions between the various teams, or at least those members
> >>who will be
reassign 511334 linux-2.6 2.6.26-12
thanks
On Friday 09 January 2009, Adam Thornton wrote:
> S390 boot fails (sometimes just after detecting memory, sometimes after
> detecting devices) on z/VM 5.2 and a Flex-ES machine.
>
> Since there are reports of d-i working on z9 boxes, I suspect the issue
>
reassign 509202 linux-2.6 2.6.26-12
thanks
Reassigning to the kernel team and informing Sparc porters.
Original report contains full log with kernel oopses.
Cheers,
FJP
On Wednesday 07 January 2009, Adrian Knoth wrote:
> When trying to boot the debian sparc kernels
> linux-image-2.6.26-1-spa
On Wednesday 24 December 2008, Moritz Muehlenhoff wrote:
> > Is it possible that someone from the debian-installer teams add this
> > "modprobe hilkbd" somewhere to the bootup process? This modprobe
> > should also be carried over to the installed system afterwards.
> >
> > I'm willing to test any
On Monday 24 November 2008, Manoj Srivastava wrote:
> Could you provide more detail, please? This is not enough to
> indicate where the fault lies. At a minimum, the kernel package
> invocation line, and the full logs of the build where failure was
> noticed should be provided to the bug
Package: kernel-package
Version: 11.0011
Severity: serious
Tags: d-i
Justification: kernels built using this break sparc D-I builds
Daily builds of D-I for sparc have been failing with:
gzip: ./tmp/netboot/vmlinuz-2.6.26-1-sparc64: not in gzip format
This has been traced to the fact that the kern
reassign 504655 linux-2.6 2.6.26-8
thanks
On Wednesday 05 November 2008, Axel Beckert wrote:
> Tried to install Debian Lenny on a VIA EPIA SN (VIA C7, i386 arch)
> board today. This one has a VIA Rhine II (VT6102) and a VIA Velocity
> (VT6120/VT6121/VT6122) NIC.
>
> When detecting the network card
reassign 504016 linux-2.6
thanks
On Saturday 01 November 2008, Hans-Joachim Zierke wrote:
> But I found it by completely disabling almost everything in the BIOS,
> getting a success, then systematically reenabling stuff.
>
> It's the Promise ATA-100 BIOS. If I reset that BIOS from "Auto" to
> "Dis
reopen 502346
thanks
This RC BR was closed silently (using 'close' to control), without giving
any explanation and without the issue being fixed. IMO that's not an
acceptable way to deal with RC bugs.
I'm reopening the BR as the virtualbox-ose kernel modules in testing are
still not usable wit
reassign 501023 linux-2.6 2.6.26-5
thanks
Reassigning to the kernel team.
On Friday 03 October 2008, Ade King wrote:
> Comments/Problems:
> After a fresh install of Lenny i upgraded the kernel to 2.6.26-1-amd64.
> During the boot process i get a hang here is the result from dmesg:
>
> [ 19.1654
# No longer assign to linux-2.6 as the issue has been confirmed for VBox
reassign 497505 virtualbox-ose 1.6.2-dfsg-4
tags 497505 patch fixed-upstream
thanks
On Friday 12 September 2008, Frans Pop wrote:
> I've taken a look at the upstream SVN repository and it looks like the
> fix is i
I've taken a look at the upstream SVN repository and it looks like the fix
is in changeset 12305 [1].
There are differences between the code there and the source in Debian.
That changeset seems to e.g. depend on changeset 12299 [2].
I have not looked much deeper, but at first glance it looks lik
1 - 100 of 461 matches
Mail list logo