Re: powerpc d-i daily builds reactivated, use 2.6.12 kernels, including 64bit kernels, miboot floppies dropped for now.
On Tue, Aug 23, 2005 at 02:18:07AM -0300, Rogério Brito wrote: > On Aug 22 2005, Sven Luther wrote: > > On Mon, Aug 22, 2005 at 11:23:39AM -0300, Rogério Brito wrote: > > > So, I do think that it would be possible to get it smaller. Want to > > > see my .config? I just posted it to linux-kernel in a reply to > > > Andrew Morton. > > > > Remember the debian kernel is generic for all powerpc plateforms, from > > old world to prep boxes, to powerbooks to the last 32bit IBM chrps and > > the genesi pegasos machine, so there is a bit more constraints here, > > but it is assuredly doable. > > I thought that the kernel in the miboot floppies were specific just to > OldWorld machines. And you already have many flavours of it being built. Nope, it was specific in 2.4 (since we where not doing a modular kernel back then), but the 2.6 miboot kernel was just the plain -powerpc flavour. > I understand that the kernels have to be generic, but, say, including > one specific feature of a pegasos machine in a miboot floppy isn't > something that I would expect (even if it can be offloaded to a > ramdisk). Which specific feature ? We moved (almost) everything to modules. The problem is with things like the pmac_ide whose code cannot be modularized. There is a lot of pmac drivers which probably don't make sense on oldworld, and whose cannot be modularized. The only thing from the pegasos and other chrp that is builtin is the serial driver, in order to get the serial console, but that is it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: powerpc d-i daily builds reactivated, use 2.6.12 kernels, including 64bit kernels, miboot floppies dropped for now.
On Aug 22 2005, Sven Luther wrote: > On Mon, Aug 22, 2005 at 11:23:39AM -0300, Rogério Brito wrote: > > So, I do think that it would be possible to get it smaller. Want to > > see my .config? I just posted it to linux-kernel in a reply to > > Andrew Morton. > > Remember the debian kernel is generic for all powerpc plateforms, from > old world to prep boxes, to powerbooks to the last 32bit IBM chrps and > the genesi pegasos machine, so there is a bit more constraints here, > but it is assuredly doable. I thought that the kernel in the miboot floppies were specific just to OldWorld machines. And you already have many flavours of it being built. I understand that the kernels have to be generic, but, say, including one specific feature of a pegasos machine in a miboot floppy isn't something that I would expect (even if it can be offloaded to a ramdisk). -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324550: Needs dependency fix [linux-image-2.6.12-1-686: install fails with "cannot stat `(0xffffe000)': No such file or directory"]
At Tue, 23 Aug 2005 12:54:13 +0900, Horms wrote: > > So the dependency isn't on e2fsprogs, per-se, but rather that > > e2fsprogs's initrd script has to filter out the linux-gate.so.1 entry, > > but if you have a newer than a certain glibc, it is incompatible with > > e2fsprogs 1.35-2, and you need to upgrade to a newer version of > > e2fsprogs. > > > > I originally added the linux-gate.so filtration in response to a bug > > filed from the amd64 port, but apparently it is now required for all > > platforms given the newer glibc in unstable. The only way to fix this > > with dependencies is to ask glibc to add a conflicts with (e2fsprogs < > > 1.35-7). > > Hi Ted, > > Thanks for that, certainly saved me a lot of bother not having > to track it down. I've CCed the glibc maintainers for their > consideration. I don't know what the actual problem is, but I fixed this kind of ldd filtering problem for mkinitrd during the final stage of sarge development. Does this help you? * GOTO Masanori - Make mkinitrd work with new ldd format which change is introduced in glibc 2.3.4. (Closes: #301455, #303281) This change also fixes amd64 mkinitrd breakage. (Closes: #279382, #292080, #295412, #295422, #297724) Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Secure-testing-team] Re: Moving forward with the 2.4.27 and 2.6.8 kernels
* dann frazier wrote: > On Mon, 2005-08-22 at 11:58 -0600, dann frazier wrote: > > 2.4.27 is building. > > And done: > http://people.debian.org/~dannf/kernel/sparc/2.4.27 Works fine on my sparc64. Thanks, Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324550: Needs dependency fix [linux-image-2.6.12-1-686: install fails with "cannot stat `(0xffffe000)': No such file or directory"]
On Mon, Aug 22, 2005 at 11:31:37PM -0400, Theodore Ts'o wrote:
> On Tue, Aug 23, 2005 at 10:48:53AM +0900, Horms wrote:
> > On Mon, Aug 22, 2005 at 04:47:14PM -0700, Tony Godshall wrote:
> > >
> > > Hi.
> > >
> > > Looks like building the initrd required an upgraded
> > > Depends: directly or indirectly to e2fsprogs.
> > >
> > > Not sure the minimum version required, but I had
> > > 1.35-6 when installing linux-image-2.6.12-1-686 failed
> > > and 1.38-1.1 when installing linux-image-2.6.12-1-686
> > > succeeded.
> >
> > I'm not sure either. Could you give some more details
> > of how it failed with 1.35-6?
>
> What's going on is that ldd running on unstable now produces a
> pseudo-entry for linux-gate.so.1:
>
> <[EMAIL PROTECTED]> {/usr/projects/e2fsprogs/e2fsprogs}
> 521% ldd /usr/lib/e2initrd_helper
> linux-gate.so.1 => (0xe000)
> libext2fs.so.2 => /lib/libext2fs.so.2 (0x46d18000)
> libcom_err.so.2 => /lib/libcom_err.so.2 (0x4737c000)
> libblkid.so.1 => /lib/libblkid.so.1 (0x46404000)
> libuuid.so.1 => /lib/libuuid.so.1 (0x4642b000)
> libe2p.so.2 => /lib/libe2p.so.2 (0x463fd000)
> libc.so.6 => /lib/tls/libc.so.6 (0x462c3000)
> /lib/ld-linux.so.2 (0x462aa000)
>
> It doesn't do this if you run ldd on the exact same binary on sarge:
>
> <[EMAIL PROTECTED]> {/vicepa/home/tytso/src}
> 733% ldd /tmp/e2initrd_helper
> libext2fs.so.2 => /lib/libext2fs.so.2 (0x40021000)
> libcom_err.so.2 => /lib/libcom_err.so.2 (0x4003a000)
> libblkid.so.1 => /lib/libblkid.so.1 (0x4003d000)
> libuuid.so.1 => /lib/libuuid.so.1 (0x40045000)
> libe2p.so.2 => /lib/libe2p.so.2 (0x40048000)
> libc.so.6 => /lib/libc.so.6 (0x4004e000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
>
> I think it's based on which version of glibc happens to be installed.
>
> So the dependency isn't on e2fsprogs, per-se, but rather that
> e2fsprogs's initrd script has to filter out the linux-gate.so.1 entry,
> but if you have a newer than a certain glibc, it is incompatible with
> e2fsprogs 1.35-2, and you need to upgrade to a newer version of
> e2fsprogs.
>
> I originally added the linux-gate.so filtration in response to a bug
> filed from the amd64 port, but apparently it is now required for all
> platforms given the newer glibc in unstable. The only way to fix this
> with dependencies is to ask glibc to add a conflicts with (e2fsprogs <
> 1.35-7).
Hi Ted,
Thanks for that, certainly saved me a lot of bother not having
to track it down. I've CCed the glibc maintainers for their
consideration.
--
Horms
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324550: Needs dependency fix [linux-image-2.6.12-1-686: install fails with "cannot stat `(0xffffe000)': No such file or directory"]
On Tue, Aug 23, 2005 at 10:48:53AM +0900, Horms wrote:
> On Mon, Aug 22, 2005 at 04:47:14PM -0700, Tony Godshall wrote:
> >
> > Hi.
> >
> > Looks like building the initrd required an upgraded
> > Depends: directly or indirectly to e2fsprogs.
> >
> > Not sure the minimum version required, but I had
> > 1.35-6 when installing linux-image-2.6.12-1-686 failed
> > and 1.38-1.1 when installing linux-image-2.6.12-1-686
> > succeeded.
>
> I'm not sure either. Could you give some more details
> of how it failed with 1.35-6?
What's going on is that ldd running on unstable now produces a
pseudo-entry for linux-gate.so.1:
<[EMAIL PROTECTED]> {/usr/projects/e2fsprogs/e2fsprogs}
521% ldd /usr/lib/e2initrd_helper
linux-gate.so.1 => (0xe000)
libext2fs.so.2 => /lib/libext2fs.so.2 (0x46d18000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x4737c000)
libblkid.so.1 => /lib/libblkid.so.1 (0x46404000)
libuuid.so.1 => /lib/libuuid.so.1 (0x4642b000)
libe2p.so.2 => /lib/libe2p.so.2 (0x463fd000)
libc.so.6 => /lib/tls/libc.so.6 (0x462c3000)
/lib/ld-linux.so.2 (0x462aa000)
It doesn't do this if you run ldd on the exact same binary on sarge:
<[EMAIL PROTECTED]> {/vicepa/home/tytso/src}
733% ldd /tmp/e2initrd_helper
libext2fs.so.2 => /lib/libext2fs.so.2 (0x40021000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x4003a000)
libblkid.so.1 => /lib/libblkid.so.1 (0x4003d000)
libuuid.so.1 => /lib/libuuid.so.1 (0x40045000)
libe2p.so.2 => /lib/libe2p.so.2 (0x40048000)
libc.so.6 => /lib/libc.so.6 (0x4004e000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
I think it's based on which version of glibc happens to be installed.
So the dependency isn't on e2fsprogs, per-se, but rather that
e2fsprogs's initrd script has to filter out the linux-gate.so.1 entry,
but if you have a newer than a certain glibc, it is incompatible with
e2fsprogs 1.35-2, and you need to upgrade to a newer version of
e2fsprogs.
I originally added the linux-gate.so filtration in response to a bug
filed from the amd64 port, but apparently it is now required for all
platforms given the newer glibc in unstable. The only way to fix this
with dependencies is to ask glibc to add a conflicts with (e2fsprogs <
1.35-7).
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324368: kernel-source-2.6.10: kernel doesn't build (gcc 4.0, fbmem.c / fb.h)
On Mon, Aug 22, 2005 at 08:47:42PM +0200, Alexandre Pineau wrote: > On Mon, 22 Aug 2005 11:50:20 +0900 > Horms <[EMAIL PROTECTED]> wrote: > > > > Its an issue with the kernel. 2.6.10 does not compile cleanly > > with gcc-4.0. 2.6.10 is being debricated and is no longer supported, > > please consider using 2.6.12 or later. If you really need to > > compile 2.6.10 for some reason, please use gcc-3.3. > > Thanks for your reponse. Maybe you can remove this package from > unstable then. We are in the process of doing just that. There is a bug open with the ftpmasters to remove the package, which is the mechanism used to remove packages from the archive. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324550: Needs dependency fix [linux-image-2.6.12-1-686: install fails with "cannot stat `(0xffffe000)': No such file or directory"]
On Mon, Aug 22, 2005 at 04:47:14PM -0700, Tony Godshall wrote: > > Hi. > > Looks like building the initrd required an upgraded > Depends: directly or indirectly to e2fsprogs. > > Not sure the minimum version required, but I had > 1.35-6 when installing linux-image-2.6.12-1-686 failed > and 1.38-1.1 when installing linux-image-2.6.12-1-686 > succeeded. I'm not sure either. Could you give some more details of how it failed with 1.35-6? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324591: kernel-source-2.4.27: FTBFS: Missing Build-Depends
tags 324591 +pending thanks On Mon, Aug 22, 2005 at 02:29:56PM -0700, Daniel Schepler wrote: > Package: kernel-source-2.4.27 > Severity: serious > Version: 2.4.27-11 > > >From my build log (reproduced using pbuilder in an i386 chroot): > > ... > make[5]: Entering directory `/tmp/buildd/kernel-source-2.4.27-2.4.27/scripts' > gcc-3.3 -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o docproc.o > docproc.c > make[5]: gcc-3.3: Command not found > make[5]: *** [docproc.o] Error 127 > make[5]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27/scripts' > make[4]: *** [/tmp/buildd/kernel-source-2.4.27-2.4.27/scripts/docproc] Error 2 > make[4]: Leaving directory > `/tmp/buildd/kernel-source-2.4.27-2.4.27/Documentation/DocBook' > make[3]: *** [sgmldocs] Error 2 > make[3]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27' > make[2]: *** [real_stamp_doc] Error 2 > make[2]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27' > make[1]: *** [stamp-doc] Error 2 > make[1]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27' > make: *** [binary-indep] Error 2 Thanks for bringing this to my attention, I have added gcc-3.3 as a build dependancy in SVN and it should appear in the next release. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Secure-testing-team] Re: Moving forward with the 2.4.27 and 2.6.8 kernels
On Mon, 2005-08-22 at 11:58 -0600, dann frazier wrote: > On Fri, 2005-08-19 at 15:00 -0600, dann frazier wrote: > > On Fri, 2005-08-19 at 14:00 -0600, dann frazier wrote: > > > On Fri, 2005-08-19 at 10:21 -0400, Andres Salomon wrote: > > > > On Fri, 2005-08-19 at 09:30 +0200, Norbert Tretkowski wrote: > > > > > * Horms wrote: > > > > > > 2. 2.6.8-16sarge1 for stable-security > > > > > > 3. 2.4.27-10sarge1 for stable-security > > > > > > > > > > > > > I can do sparc builds mid-next-week; probably not before then, unless > > > > someone can make (reasonably fast) hardware available to me. > > > > > > I've got a 2.6.8 going on a slow sparc - I predict it will be done in > > > 2-3 days. Changes are committed. > > > > Frans Pop hooked me up w/ access to a faster sparc; build ETA greatly > > shortened. I should be able to get 2.4.27 done as well. > > sparc 2.6.8 build here: > http://people.debian.org/~dannf/kernel/sparc/2.6.8/ > > 2.4.27 is building. And done: http://people.debian.org/~dannf/kernel/sparc/2.4.27 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324550: Needs dependency fix [linux-image-2.6.12-1-686: install fails with "cannot stat `(0xffffe000)': No such file or directory"]
Hi. Looks like building the initrd required an upgraded Depends: directly or indirectly to e2fsprogs. Not sure the minimum version required, but I had 1.35-6 when installing linux-image-2.6.12-1-686 failed and 1.38-1.1 when installing linux-image-2.6.12-1-686 succeeded. Best Regards, Tony -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324595: linux-image-2.6.12-1-amd64-k8: GPF in kswapd on AMD64
Package: kernel
Version: 2.6.12-5
Severity: important
Hi,
I was installing a package with dpkg when the kernel had a GPF. dpkg
was then stuck and I had to reboot the system. This is with the
Debian provided linux-image:
$ uname -a
Linux jophur 2.6.12-1-amd64-k8 #1 Thu Aug 18 03:05:27 CEST 2005 x86_64 GNU/Linux
Aug 22 20:27:45 localhost kernel: general protection fault: [1]
Aug 22 20:27:45 localhost kernel: CPU 0
Aug 22 20:27:45 localhost kernel: Modules linked in: nls_cp437 isofs udf lp
binfmt_misc thermal fan button ac battery ip_tables af_packet tsdev parp
ort_pc parport floppy pcspkr psmouse ehci_hcd evdev usbhid uhci_hcd bt878
snd_bt87x eth1394 tuner tvaudio msp3400 bttv video_buf firmware_class i2c_
algo_bit v4l2_common btcx_risc tveeprom videodev snd_ice1724 snd_ice17xx_ak4xxx
snd_ac97_codec snd_ak4114 snd_pcm_oss snd_mixer_oss snd_pcm snd_time
r snd_page_alloc snd_ak4xxx_adda snd_mpu401_uart snd_rawmidi snd_seq_device snd
soundcore ohci1394 shpchp pci_hotplug dm_mod sbp2 ieee1394 ide_gener
ic ide_disk ide_cd rtc via82cxxx ide_core w83627hf i2c_sensor i2c_isa i2c_core
cpufreq_userspace powernow_k8 freq_table processor md5 ipv6 sk98lin e
xt3 jbd mbcache sr_mod cdrom sd_mod sata_via sata_promise libata scsi_mod unix
fbcon tileblit font bitblit vesafb cfbcopyarea cfbimgblt cfbfillrect
softcursor raid1 md
Aug 22 20:27:45 localhost kernel: Pid: 145, comm: kswapd0 Not tainted
2.6.12-1-amd64-k8
Aug 22 20:27:45 localhost kernel: RIP: 0010:[iput+24/144]
{iput+24}
Aug 22 20:27:45 localhost kernel: RSP: 0018:81003faa1dc8 EFLAGS: 00010283
Aug 22 20:27:45 localhost kernel: RAX: 26a7d0001410 RBX: 81002244c100
RCX: 81002244c130
Aug 22 20:27:45 localhost kernel: RDX: 81002244c130 RSI: 81002244c100
RDI: 81002244c100
Aug 22 20:27:45 localhost kernel: RBP: 81003b59b560 R08: fffa
R09: 81003faa1ac0
Aug 22 20:27:45 localhost kernel: R10: 0002 R11: 8018a870
R12: 0056
Aug 22 20:27:45 localhost kernel: R13: 0080 R14: 0080
R15: 000368ae
Aug 22 20:27:45 localhost kernel: FS: 2abddad0()
GS:80417b00() knlGS:555a7fc0
Aug 22 20:27:45 localhost kernel: CS: 0010 DS: 0018 ES: 0018 CR0:
8005003b
Aug 22 20:27:45 localhost kernel: CR2: 0059b000 CR3: 11c2
CR4: 06e0
Aug 22 20:27:45 localhost kernel: Process kswapd0 (pid: 145, threadinfo
81003faa, task 81003fa5c760)
Aug 22 20:27:45 localhost kernel: Stack: 810022449a70 8018877b
81003faa1dd8 008d
Aug 22 20:27:45 localhost kernel:81003ffa9480 00d0
000368af 801887c7
Aug 22 20:27:45 localhost kernel:0202 8015c9c1
Aug 22 20:27:45 localhost kernel: Call
Trace:{prune_dcache+331}
{shrink_dcache_memory+23}
Aug 22 20:27:45 localhost kernel:{shrink_slab+193}
{balance_pgdat+623}
Aug 22 20:27:45 localhost kernel:{kswapd+295}
{autoremove_wake_function+0}
Aug 22 20:27:45 localhost kernel:{child_rip+8}
{kswapd+0}
Aug 22 20:27:45 localhost kernel:{child_rip+0}
Aug 22 20:27:45 localhost kernel:
Aug 22 20:27:45 localhost kernel: Code: 48 8b 40 40 75 12 0f 0b ba 0d 2e 80 ff
ff ff ff 46 04 66 66
Aug 22 20:27:45 localhost kernel: RIP {iput+24} RSP
and a few seconds later:
Aug 22 20:28:50 localhost kernel: <0>general protection fault: [2]
Aug 22 20:28:50 localhost kernel: CPU 0
Aug 22 20:28:50 localhost kernel: Modules linked in: nls_cp437 isofs udf lp
binfmt_misc thermal fan button ac battery ip_tables af_packet tsdev parp
ort_pc parport floppy pcspkr psmouse ehci_hcd evdev usbhid uhci_hcd bt878
snd_bt87x eth1394 tuner tvaudio msp3400 bttv video_buf firmware_class i2c_
algo_bit v4l2_common btcx_risc tveeprom videodev snd_ice1724 snd_ice17xx_ak4xxx
snd_ac97_codec snd_ak4114 snd_pcm_oss snd_mixer_oss snd_pcm snd_time
r snd_page_alloc snd_ak4xxx_adda snd_mpu401_uart snd_rawmidi snd_seq_device snd
soundcore ohci1394 shpchp pci_hotplug dm_mod sbp2 ieee1394 ide_gener
ic ide_disk ide_cd rtc via82cxxx ide_core w83627hf i2c_sensor i2c_isa i2c_core
cpufreq_userspace powernow_k8 freq_table processor md5 ipv6 sk98lin e
xt3 jbd mbcache sr_mod cdrom sd_mod sata_via sata_promise libata scsi_mod unix
fbcon tileblit font bitblit vesafb cfbcopyarea cfbimgblt cfbfillrect
softcursor raid1 md
Aug 22 20:28:50 localhost kernel: Pid: 22956, comm: dpkg-query Not tainted
2.6.12-1-amd64-k8
Aug 22 20:28:50 localhost kernel: RIP: 0010:[find_inode_fast+60/96]
{find_inode_fast+60}
Aug 22 20:28:50 localhost kernel: RSP: 0018:810023c51c68 EFLAGS: 00010202
Aug 22 20:28:50 localhost kernel: RAX: 26a9b0001410 RBX: 01aed2b2
RCX: 0011
Aug 22 20:28:50 localhost kernel: RDX: 26a9b0001410 RSI: 81000208e7a8
RDI: 81003f27d800
Aug 22 20:28:50 localhost kernel: RBP: 81003f27d800 R08: 00090758
R09: 81000a8ee000
Aug 22 20:2
Bug#324591: kernel-source-2.4.27: FTBFS: Missing Build-Depends
Package: kernel-source-2.4.27 Severity: serious Version: 2.4.27-11 >From my build log (reproduced using pbuilder in an i386 chroot): ... make[5]: Entering directory `/tmp/buildd/kernel-source-2.4.27-2.4.27/scripts' gcc-3.3 -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o docproc.o docproc.c make[5]: gcc-3.3: Command not found make[5]: *** [docproc.o] Error 127 make[5]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27/scripts' make[4]: *** [/tmp/buildd/kernel-source-2.4.27-2.4.27/scripts/docproc] Error 2 make[4]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27/Documentation/DocBook' make[3]: *** [sgmldocs] Error 2 make[3]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27' make[2]: *** [real_stamp_doc] Error 2 make[2]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27' make[1]: *** [stamp-doc] Error 2 make[1]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27' make: *** [binary-indep] Error 2 -- System Information: Debian Release: testing/unstable Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-amd64-k8 Locale: LANG=en, LC_CTYPE=en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324583: linux-patch-debian-2.6.12: missing default version numbers in unpatch/apply script break make-kpkg
Package: linux-patch-debian-2.6.12
Version: 2.6.12-5
Severity: important
Somehow the @upstream@ and @version@ macros didn't get expanded in
debian/bin/unpatch and debian/bin/apply which causes
PATCH_THE_KERNEL=YES make-kpkg cleab
to fail with the following message:
/usr/bin/make -f /usr/share/kernel-package/rules unpatch_now
make[2]: Entering directory `/usr/src/linux-source-2.6.12'
for patch in /usr/src/kernel-patches/all/2.6.12/unpatch/debian ; do
\
if test -x $patch; then\
if $patch; then \
echo "Removed Patch $patch "; \
else \
echo "Patch $patch failed."; \
echo "Hit return to Continue"; \
read ans; \
fi; \
fi; \
done
/usr/src/kernel-patches/all/2.6.12/unpatch/debian: line 8:
/usr/src/kernel-patches/all//apply/debian: No such file or directory
Patch /usr/src/kernel-patches/all/2.6.12/unpatch/debian failed.
Hit return to Continue
(Note the missing version between /all/ and /apply/ in the error message.)
Building a kernel
PATCH_THE_KERNEL=YES make-kpkg kernel-image
fails with with
for patch in /usr/src/kernel-patches/all/2.6.12/apply/debian ; do\
if test -x $patch; then\
if $patch; then \
echo "Patch $patch processed fine"; \
echo "$patch" >> applied_patches; \
else \
echo "Patch $patch failed."; \
echo "Hit return to Continue"; \
read ans; \
fi; \
fi; \
done
E: Can't patch to nonexistent revision (wait until 2006)
Patch /usr/src/kernel-patches/all/2.6.12/apply/debian failed.
Hit return to Continue
Changing line 158 in /usr/src/kernel-patches/all/2.6.12/apply/debian from
version=${override_version:-}
to
version=${override_version:-2.6.12-5}
and line 6 in /usr/src/kernel-patches/all/2.6.12/unpatch/debian
upstream=${override_upstream:-}
to
upstream=${override_upstream:-2.6.12}
fixes the problem.
Of course the real problem lies somewhere in the build process for this
patch, since @upstream@ and @version@ where expanded to empty strings
instead of the correct values.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-251
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages linux-patch-debian-2.6.12 depends on:
ii bash 3.0-15 The GNU Bourne Again SHell
ii bzip2 1.0.2-8high-quality block-sorting file co
ii grep-dctrl2.6.7 Grep Debian package information
ii patch 2.5.9-2Apply a diff file to an original
linux-patch-debian-2.6.12 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: powerpc d-i daily builds reactivated, use 2.6.12 kernels, including 64bit kernels, miboot floppies dropped for now.
On Mon, Aug 22, 2005 at 11:23:39AM -0300, Rogério Brito wrote: > On Aug 22 2005, Sven Luther wrote: > > A bit of reality check here, we have around 1.3MB space on the miboot > > floppies, and current compressed miboot floppies arer 1.6MB or so, so > > we just need to unbloat it further 200/300kb (compressed though), > > which should be possible by modularizing lot of stuff, among those the > > pmac-ide is a good candidate. > > Well, my custom kernel is around 1200KB compressed (and about 100KB free > on the floppy) and it has many things hardcoded that could be offloaded > to an initramdisk, if I wanted to get my hands dirty. > > So, I do think that it would be possible to get it smaller. Want to see > my .config? I just posted it to linux-kernel in a reply to Andrew > Morton. Remember the debian kernel is generic for all powerpc plateforms, from old world to prep boxes, to powerbooks to the last 32bit IBM chrps and the genesi pegasos machine, so there is a bit more constraints here, but it is assuredly doable. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324368: kernel-source-2.6.10: kernel doesn't build (gcc 4.0, fbmem.c / fb.h)
On Mon, 22 Aug 2005 11:50:20 +0900 Horms <[EMAIL PROTECTED]> wrote: > Its an issue with the kernel. 2.6.10 does not compile cleanly > with gcc-4.0. 2.6.10 is being debricated and is no longer supported, > please consider using 2.6.12 or later. If you really need to > compile 2.6.10 for some reason, please use gcc-3.3. Thanks for your reponse. Maybe you can remove this package from unstable then. Alexandre Pineau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324550: linux-image-2.6.12-1-686: install fails with "cannot stat `(0xffffe000)': No such file or directory"
Package: linux-image-2.6.12-1-686 Version: 2.6.12-5 Severity: important sena:~# apt-get -V install linux-image-2.6.12-1-686 Reading Package Lists... Done Building Dependency Tree... Done Suggested packages: lilo (22.6.1-6.2) The following NEW packages will be installed: linux-image-2.6.12-1-686 (2.6.12-5) 0 upgraded, 1 newly installed, 0 to remove and 938 not upgraded. Need to get 0B/16.7MB of archives. After unpacking 46.9MB of additional disk space will be used. Selecting previously deselected package linux-image-2.6.12-1-686. (Reading database ... 173388 files and directories currently installed.) Unpacking linux-image-2.6.12-1-686 (from .../linux-image-2.6.12-1-686_2.6.12-5_i386.deb) ... Setting up linux-image-2.6.12-1-686 (2.6.12-5) ... cp: cannot stat `(0xe000)': No such file or directory run-parts: /usr/share/initrd-tools/scripts/e2fsprogs exited with return code 1 Failed to create initrd image. dpkg: error processing linux-image-2.6.12-1-686 (--configure): subprocess post-installation script returned error exit status 9 Errors were encountered while processing: linux-image-2.6.12-1-686 E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Versions of packages linux-image-2.6.12-1-686 depends on: ii coreutils [fileutils]5.0.91-2The GNU core utilities ii initrd-tools 0.1.82 tools to create initrd image for p ii module-init-tools3.0-pre10-4 tools for managing Linux kernel mo linux-image-2.6.12-1-686 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324351: initrd-tools: /etc/mkinitrd/scripts files not executed if files contain a "."
Quoting Horms <[EMAIL PROTECTED]>: > No, I do not believe so. > but it is documented in run-parts(8). Perhaps this > should be reflected in mknitrd(8). Do you want I tried to fix that, see attached patch. -- Simon 173c173,175 < Scripts in this directory are run just before the image is generated from. --- > Scripts in this directory matching the > .BR run-parts (8) > naming convention are run just before the image is generated from.
Re: [Secure-testing-team] Re: Moving forward with the 2.4.27 and 2.6.8 kernels
On Fri, 2005-08-19 at 15:00 -0600, dann frazier wrote: > On Fri, 2005-08-19 at 14:00 -0600, dann frazier wrote: > > On Fri, 2005-08-19 at 10:21 -0400, Andres Salomon wrote: > > > On Fri, 2005-08-19 at 09:30 +0200, Norbert Tretkowski wrote: > > > > * Horms wrote: > > > > > 2. 2.6.8-16sarge1 for stable-security > > > > > 3. 2.4.27-10sarge1 for stable-security > > > > > > > > > > I can do sparc builds mid-next-week; probably not before then, unless > > > someone can make (reasonably fast) hardware available to me. > > > > I've got a 2.6.8 going on a slow sparc - I predict it will be done in > > 2-3 days. Changes are committed. > > Frans Pop hooked me up w/ access to a faster sparc; build ETA greatly > shortened. I should be able to get 2.4.27 done as well. sparc 2.6.8 build here: http://people.debian.org/~dannf/kernel/sparc/2.6.8/ 2.4.27 is building. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322705: Problemas reproduting the problem
Here in the University other machines with the same NIC, have the same problems with newer kernels. I have tried using netperf to see if the NIC stops to send or receive network traffic, but it worked without problems for 12 hours in each test. The best I can do to reproduce the problem is: In one I test the openafs-client the NIC stops after 11 hours, after 6 hours the kernel gives an error and the NIC resumes. This are the errors messages: tg3: tg3_stop_block timed out, ofs=2000 enable_bit=2 tg3: eth0: Link is up at 100 Mbps, full duplex. tg3: eth0: Flow control is off for TX and off for RX. I need help to find why and when the NIC stops. Netperf generating traffic in only one direction is not enough for the NIC to stop. José Calhariz -- Quando as contas são pagas, ninguém presta atenção no tamanho delas --Marion Davies signature.asc Description: Digital signature
Re: CAN-2005-2555: 2.6.x does not properly restrict socket policy access to users with the CAP_NET_ADMIN capability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Horms, > Thanks as always. Thanks to you for the quick reply! > I have added [X] to SVN. > - In the linux-2.6 directory in trunk > *This should appear in linux-2.6 2.6.12-6 in unstable. Noted. > - In the linux-2.6-devel (perhaps renamed linux-2.6-experimental by now) > directory > - The sarge-security 2.6.8 branch > * It should appear in kernel-source-2.6.8 2.6.8-16sarge2 in sarge-security > (still working on how the security and kernel team can do this) Noted. > - The sarge 2.6.8 branch Does this appear anywhere as a package in unstable? I know that 2.6.8 is being requested for removal, but why add it to this branch if its never going to be used? > - The sarge-security 2.4.27 branch > * It should appear in kernel-source-2.4.27 2.4.27-10sarge2 in sarge-security > (again, still working on how the security and kernel team can do this) Noted. > - The 2.4.27 directory in trunk > * This should appear as kernel-source-2.4.27 2.6.12-12 in unstable This one doesn't look right, I assume you mean to say "kernel-source-2.4.27 2.4.27-12 in unstable"? > Man, thats too many branches to be adding stuff to. > Need to do something about that. No kidding! Is it me just paying more attention to kernel security things, or are there just a significant number of kernel security holes now days? micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDCeRU9n4qXRzy1ioRAgckAKC0Q2nB4LzNvG8gZqQLcG7UbMO2ZQCcCkIA SsXxNpO3xW7opqMtb2rBCTs= =yFzZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324517: usb works not properly
Package: linux-source-2.6.12 Version: 2.6.12-5 Severity: normal -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-100-amd64-k8 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages linux-source-2.6.12 depends on: ii binutils 2.16.1-2 The GNU assembler, linker and bina ii bzip2 1.0.2-8high-quality block-sorting file co ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities Versions of packages linux-source-2.6.12 recommends: ii gcc 4:4.0.1-3 The GNU C compiler ii libc6-dev [libc-dev] 2.3.5-3GNU C Library: Development Librari ii make 3.80-11The GNU version of the "make" util -- no debconf information Strange thing, I want to describe it: Situation: USB-Mouse works, the loaded modules are "usb-uhci" and "usb-ehci" for USB2.0-support. When connecting a mass-storage system , like a usb-harddrive or a usb-sd-card (in adapter) , these are not seen and thus, cannot be mounted. Lsusb shows only the usb-mouse. My tries: Then, when unloading the usb-ehci module, and only loaded usb-uhci module, the mass-storage device is seen, but still cannot be mounted. In the same time, the usb-mouse will not work any more, and is not seen when making lsusb. My ideas: As this worked still kernel-2.6.9, I suppose the mistake in a conflict within the kernel itself, the hotplug package (playing together with the kernel), scsi in the kernel or udev. Additionally it could be my fault, too. Did I do something wrong ??? I hope not.. Best regards Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324510: initrd size too small for d-i
Package: kernel-image-2.4.27-sparc Version: 2.4.27-9 Severity: important Tags: d-i * Change default ramdisk size for sparc to 16,384K to accomodate a fatter d-i initrd for netboot installs. (Joshua Kwan) This change has been made for the 2.6 kernel, but 2.4 is still using the old 8 mb initrd size which is unfortunatly too small for the post-sarge d-i. This kernel needs to be changed also to use a larger default initrd, otherwise we will need to document that users have to pass the ramdisk_size to silo when netbooting the installer on sparc. -- see shy jo signature.asc Description: Digital signature
Re: powerpc d-i daily builds reactivated, use 2.6.12 kernels, including 64bit kernels, miboot floppies dropped for now.
On Aug 22 2005, Sven Luther wrote: > A bit of reality check here, we have around 1.3MB space on the miboot > floppies, and current compressed miboot floppies arer 1.6MB or so, so > we just need to unbloat it further 200/300kb (compressed though), > which should be possible by modularizing lot of stuff, among those the > pmac-ide is a good candidate. Well, my custom kernel is around 1200KB compressed (and about 100KB free on the floppy) and it has many things hardcoded that could be offloaded to an initramdisk, if I wanted to get my hands dirty. So, I do think that it would be possible to get it smaller. Want to see my .config? I just posted it to linux-kernel in a reply to Andrew Morton. Cheers, Rogério. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Debian mkinitrd patch for saving kdump - take2
On Wed, Aug 17, 2005 at 03:56:09PM +0530, Rachita Kothiyal wrote:
> Hi Jeff,
>
> As Vivek discussed with you in OLS regarding saving dump images
> from initrd, I have come up with an initial patch to mkinitrd on
> Debian unstable. This modifies the mkinitrd script to generate a
> custom initrd for dump capture kernel aka second kernel. This can
> help in saving the kdump memory image to the specified device
> and filesystem before mounting root filesystem.
>
> This is quite a crude patch just to convey the approach and has some
> things in the todo list. As of now it assumes that the dump device
> (disk partition) uses the same modules as the root device.
>
> ToDo:
> 1. Refine the script by providing better error handling
> 2. Automatically detecting filesystem for the dump device, if possible.
> 3. Finding required modules for accessing the dump device.
> 4. Network based dump device
>
> Usage:
> mkinitrd -k -o -c -f kernel_version
>
> Example:
> mkinitrd -k -o /boot/initrd-capture-kernel.img -c /dev/hda7 -f ext2
> 2.6.13-rc5
>
In this attempt, I have tried to provide better error handling and also
handle the module loading required for accessing the dump device.
Please let me know your comments.
Thanks
Rachita
--- ../../mkinitrd-orig 2005-08-16 16:13:34.0 +0530
+++ ../../mkinitrd-mod/mkinitrd-8.182005-08-22 19:35:27.0 +0530
@@ -99,6 +99,8 @@ Options:
-m command Set the command to make an initrd image.
-o outfile Write to outfile.
-r root Override ROOT setting in mkinitrd.conf.
+ -c dump_device Copy dump to this device
+ -f dump_dev_fs Filesystem on the dump device
See mkinitrd(8) for further details.
EOF
@@ -1122,6 +1124,15 @@ gendir() {
} >&3
[ -z "$ROOT" ] || probe
+ if [ $dump_enable -eq 1 ]; then
+ root_maj=$(ls -l $device | cut -d " " -f 6 | cut -d "," -f 1)
+ dump_maj=$(ls -l $dump_dev | cut -d " " -f 6 | cut -d "," -f 1)
+ dump_min=$(ls -l $dump_dev | cut -d " " -f 7)
+
+ if [ $root_maj -ne $dump_maj ]; then
+ getroot $dump_dev
+ fi
+ fi
exec 3>&- 4>&- 5>&- 6>&-
mkdir initrd
@@ -1206,6 +1217,7 @@ gendir() {
/bin/mount /bin/umount \
/sbin/pivot_root /bin/cat /bin/mknod \
/usr/sbin/chroot /bin/uname \
+ $([ $dump_enable -eq 1 ] && find /bin /sbin -name dd
&& find /bin /sbin -name reboot) \
`command -v stat` $readlink \
`cat "$@" exe`
do
@@ -1277,10 +1289,15 @@ gendir() {
esac
cd initrd
- mkdir -p dev2 devfs etc keyscripts mnt proc scripts sys tmp var
+ mkdir -p dev2 devfs etc keyscripts mnt proc scripts sys tmp var `[
$dump_enable -eq 1 ] && echo 'dump'`
> etc/mtab
+ if [ $dump_enable -eq 1 -a ! -b "${dump_dev#/}" ]; then
+ dev_type=$(ls -l $dump_dev | cut -c 1)
+ mknod "${dump_dev#/}" $dev_type $dump_maj $dump_min
+ DEVLINKS="$DEVLINKS ${dump_dev#/dev/}"
+ fi
devices=
for i in \
cciss ida ide scsi md mapper $DEVLINKS
@@ -1299,15 +1316,28 @@ gendir() {
fi
INITRDDIR=$dir/initrd MODULEDIR=$MODULEDIR VERSION=$VERSION \
run-parts "$CONFDIR"/scripts
+
+ if [ $dump_enable -eq 1 ]; then
+ echo "mount -t $dump_fs $dump_dev /dump
+echo Copying the dump
+dd if=/proc/vmcore of=/dump/dumpfile
+umount /dump
+echo Rebooting the system
+reboot -f" >> script
+ fi
}
ORIGDIR=`pwd`
PROG="$0"
+dump_dev=""
+dump_fs=""
+dump_enable=0
+
CONFDIR=/etc/mkinitrd
unset keep croot cmkimage out || :
-while getopts "d:km:o:r:" flag; do
+while getopts "d:km:o:r:c:f:" flag; do
case $flag in
d)
CONFDIR="$OPTARG"
@@ -1330,6 +1360,12 @@ while getopts "d:km:o:r:" flag; do
r)
croot=$OPTARG
;;
+ c)
+ dump_dev=$OPTARG
+ ;;
+ f)
+ dump_fs=$OPTARG
+ ;;
*)
usage
;;
@@ -1341,6 +1377,20 @@ if ! [ $out ] || [ $# -gt 1 ]; then
usage
fi
+if [ -z "$dump_dev" -a -z "$dump_fs" ]; then
+ dump_enable=0
+elif [ -z "$dump_dev" -a ! -z "$dump_fs" ]; then
+ echo 'Please specify a dump device'
+ usage
+ exit 1
+elif [ ! -z "$dump_dev" -a -z "$dump_fs" ]; then
+ echo 'Please specify a filesystem for the dump device'
+ usage
+ exit 1
+else
+ dump_enable=1
+fi
+
VERSION=$1
[ $# -gt 0 ] || unset VERSION
case $VERSION in
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8)
2005-08-21, v keltezéssel 12.12-kor maximilian attems ezt írta: > urrgs, but that seem to match upstream bugs thread. I don't know whether I should be happy about this.. > could you try out that bios workaround: > http://www.ussg.iu.edu/hypermail/linux/kernel/0403.1/1537.html I can test it on tuesday. (I don't have physical access to the machine right now.) > your lspci -v would be nice for the record. Attached. Kristof :00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 :00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: d600-d8ff Prefetchable memory behind bridge: d400-d5ff Capabilities: [80] Power Management version 2 :00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 :00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at 9000 [size=16] Capabilities: [c0] Power Management version 2 :00:07.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 10) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at 9400 [size=32] Capabilities: [80] Power Management version 2 :00:07.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 10) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at 9800 [size=32] Capabilities: [80] Power Management version 2 :00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel, IRQ 9 Capabilities: [68] Power Management version 2 :00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 20) Subsystem: VIA Technologies, Inc. VT82C686 AC97 Audio Controller Flags: medium devsel, IRQ 11 I/O ports at 9c00 [size=256] I/O ports at a000 [size=4] I/O ports at a400 [size=4] Capabilities: [c0] Power Management version 2 :00:0c.0 Unknown mass storage controller: Promise Technology, Inc. PDC20265 (FastTrak100 Lite/Ultra100) (rev 02) Subsystem: Promise Technology, Inc. Ultra100 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ac00 [size=8] I/O ports at b000 [size=4] I/O ports at b400 [size=8] I/O ports at b800 [size=4] I/O ports at bc00 [size=64] Memory at da00 (32-bit, non-prefetchable) [size=128K] Capabilities: [58] Power Management version 1 :00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at c000 [size=256] Memory at da02 (32-bit, non-prefetchable) [size=256] :01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc. Millennium G450 Dual Head LE Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at d400 (32-bit, prefetchable) [size=32M] Memory at d600 (32-bit, non-prefetchable) [size=16K] Memory at d700 (32-bit, non-prefetchable) [size=8M] Capabilities: [dc] Power Management version 2 Capabilities: [f0] AGP version 2.0
Re: 2.6.12 upload
On Mon, Jul 18, 2005 at 03:19:05PM +0200, Thiemo Seufer wrote: > Andres Salomon wrote: > > Alright folks, I think the packaging is ready to be beaten on by people. > > So, unless anyone has any concerns/problems/etc, I'm going to assume > > everything's a go for uploading 2.6.12. > > > > The current changes and state of the packaging: > > - source package is called linux-2.6 > > - binary image packages have been renamed from kernel-image-* to > > linux-image-*. binary header packages have been renamed from > > kernel-headers-* to linux-headers-*. kfreebsd/hurd folks, if you have > > any comments/concerns/requirements, please be sure to let us know. > > - debian/control is generated from debian/templates/control.*.in, and > > naming/descriptions should be consistent across the various archs. > > - config files are generated from the pieces in debian/arch, with > > management of configs made a lot easier via tools in trunk/scripts > > (initconfig and split-config). I will probably tweak settings for > > the global config a bit more; expect some FTBFS for architectures > > until we figure out which options are safe for everyone, and which > > options are suitable only for certain archs. > > - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0 > > miscompiling things. however, if any architectures require gcc-4.0, > > either let me know, or update svn directly. > > - debian/README* and trunks/docs/ has information that kernel team > > members will find useful to understand the new packaging. > > - there are 3 patches that were in 2.6.11 that have been dropped due to > > lack of interest; sparc, alpha, and powerpc folks should determine > > their value, at some point. > > FWIW, I gave up on the common kernel package for mips/mipsel for now, > and will build mips kernels via a linux-patch package which > build-depends on the source .deb. The reasons which prompted me to > do so are listed below, vaguely in order of importance. Would you reconsider after a discussion of your points, and work together to bring them to a satisfactory point for all instead of going your own lone way ? A few comments on your problems, in light of the 2.6.12-5 packages and over a month of development since you wrote this. I believe that all but mips/mipsel are already in the main linux-2.6 package, so you are the only one having problems with this. > Issues of the common kernel package: > > General problems: > - The 2.6 (instead of 2.6.12 etc.) versioning means previous versions > are thrown out of the archive, anything which isn't ready until then > will lose support. > It is IMHO not realistic to expect the rest of the world to wait for > some obscure subarchitecture. Ok, this is a valid point, the current argument from Andres is that we have one set in unstable and one in testing, and that we keep arches with problems artificially outside of testing, so the older version remain. This causes indeed problems with d-i, but this is more a d-i build bug than anything else, and needs to be checked or adapted. This whole point may need more thought maybe, but for 2.6.12 is no problem as there is no 2.6.11 we are removing. > - Coupling the smallest fix for a subarchitecture to a full upload of > the whole arch any package puts pressure on the autobuilder network > without much gain, and causes many users to download "new" kernels > identical to the old ones because of the version bump. -> E.g. > disable CONFIG_PREEMPT for ia64 and let everyone upgrade their kernel. This can and should be fixed with the so called arch-specific uploads (-x.0.0.1 or something such), which is a mechanism supposedly documented for this exact purpose (for example, powerpc could have rebuilt -3 in this way). Upto recently this was not supported by the infrastructure script, but i believe either it was fixed for the sarge packages, or it can easily be. Not sure about the ftp-master/buildd admin side of this however. Any comment on this are welcome. > Implementation problems: > - A generic header package is used, plus architecture-specific header > packages which add some bits like configuration defines and process > structure offsets. Architecture-specific header patches aren't taken > into account, but are needed for patches outside include/asm-$arch. Well, hppa and m68k already have arch-specific patches, and there is a post-install hook for headers which allows you to install your own stuff. This is a false problem that can easily be fixed. > - Flavour names are assumed to be unique, this doesn't work well for > bi-endian machines (e.g. sb1-swarm-bn for mips/mipsel) and 32/64 > bit kernels. I think Andres already fixed this, but i will let him comment on this. > - Architecture-specific patches are restricted to a single patch per > arch/subarch, with an $arch.* naming. This means to copy an identical > patch with different name to
applying kernel Raid patch to Vanilla 2.2.20
I'm getting really confused. I can't install anything but Vanilla kernel 2.2.20 because 3.0ra5 and 3.1 hand during install on my advancesys scsi card. And i want to run a raid drive, mdadm keeps telling me it needs ver 0.9 of summat. So i got the file kernel-patch-2.2.20-raid_4_all.deb. i was reading an article at http://homex.subnet.at/~max/comp-15_raid.php and it says, Get the raid-0.90-patch "raid-2.2.19-A1" from http://people.redhat.com/mingo/raid-patches/ and copy it to /usr/src. cd /usr/src patch -p0 < raid-2.2.19-A1 I got the suggested copy, but one called raid-2.2.2--A0 and did what he suggested but i got several hump fails. Humps are quite daunting whey you don't know what your doing :o( So i then found the .deb package, which i thought would be more suitable, cos it's deb So i downloaded it and did a dpkg-deb -x kernel-patch-2.2.20-radi_4_all.deb /usr/src/ but it gave me lots and lots of subdirectories under /usr/src and files called apply, unpatch and raid.bz2, which isn't mentioned in the how to above. It created /usr/src/usr /usr/src/usr/share /usr/src/usr/src /usr/src/usr/share/doc /usr/src/usr/share/doc/kernel-patch-2.2.20-raid /usr/src/usr/src/kernel-patches /usr/src/usr/src/kernel-patches/i386 /usr/src/usr/src/kernel-patches/i386/2.2.20 /usr/src/usr/src/kernel-patches/i386/2.2.20/apply raid.bz2 unpatch So i'm confused as to what to do. Can anybody point me in the right direction for applying the raid patch and going from there. Many thanks Ken -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
On Mon, Aug 22, 2005 at 12:58:51PM +0200, Bastian Blank wrote: > On Mon, Aug 22, 2005 at 12:24:14PM +0200, Sven Luther wrote: > > > General problems: > > > - The 2.6 (instead of 2.6.12 etc.) versioning means previous versions > > > are thrown out of the archive, anything which isn't ready until then > > > will lose support. > > > It is IMHO not realistic to expect the rest of the world to wait for > > > some obscure subarchitecture. > > > > Ok, this is a valid point, the current argument from Andres is that we have > > one set in unstable and one in testing, and that we keep arches with > > problems > > artificially outside of testing, so the older version remain. > > You can just disable the build of that images and the old packages will > remain until dak is fixed to remove such sourceless packages (Okay, the > headers will be not installable further). I was under the impression that the older source would stau in such cases. But this doesn't solve all, since it is nice to have a known working subset of kernels, maybe we could have a scheme where the two last are always there, and before the release, we freeze, remove the not wanted from testing, keep it there, and also as copy in sid until the release, and stay with the two latest kernels in sid for the next-gen development. > > > - Coupling the smallest fix for a subarchitecture to a full upload of > > > the whole arch any package puts pressure on the autobuilder network > > > without much gain, and causes many users to download "new" kernels > > > identical to the old ones because of the version bump. -> E.g. > > > disable CONFIG_PREEMPT for ia64 and let everyone upgrade their kernel. > > > > This can and should be fixed with the so called arch-specific uploads > > (-x.0.0.1 or something such), which is a mechanism supposedly documented for > > this exact purpose (for example, powerpc could have rebuilt -3 in this way). > > No, bin-NMUs are only allowed to have a updated changelog. Ok. Maybe we can discuss to have something else with the buildd/ftp guys, as our need is specific. This is mostly a buildd admin problem anyway. > > Not sure about the ftp-master/buildd admin side of this however. Any comment > > on this are welcome. > > x-y.0.1 is mapped to source x-y. Ok, so this is fixed, thanks, i can now do local builds more easily yoo :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: r4021 - trunk/kernel
On Mon, Aug 22, 2005 at 11:59:51AM +0200, Sven Luther wrote: > Ok, this is a mess, so we probably need to hold a little flamewar about how we > want the tree organized or something, before we start moving stuff back and > fort. > > I believe that the trunk is for main development, and it is important that we > keep the version we are actually using in trunk, and not the next version as > the linux-2.6.13-rcsomething. > > Also, i am not overly convinced about the branch stuff, especially for main > branches where we are going to work on, and not some obscure stuff only some > will want to play with. > > Furthermore, now that the kernel subdir is going to be emptied of its content, > in favour of the single linux-2.6 package, we could as well move linux-2.6 > into the toplevel. > > So, my proposal was to have : > > /trunk/linux-2.6 <- main 2.6 kernel being uploaded to sid I liked that, I always hated the enormous hierachies in the old repository. > /trunk/linux-2.6-experimental <- the experimental version. SVN allows branches to reside anywhere freely, including under /trunk, right? In that case this is okay, just make sure it really is a branch so merges work fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 upload
On Mon, Aug 22, 2005 at 12:24:14PM +0200, Sven Luther wrote: > > General problems: > > - The 2.6 (instead of 2.6.12 etc.) versioning means previous versions > > are thrown out of the archive, anything which isn't ready until then > > will lose support. > > It is IMHO not realistic to expect the rest of the world to wait for > > some obscure subarchitecture. > > Ok, this is a valid point, the current argument from Andres is that we have > one set in unstable and one in testing, and that we keep arches with problems > artificially outside of testing, so the older version remain. You can just disable the build of that images and the old packages will remain until dak is fixed to remove such sourceless packages (Okay, the headers will be not installable further). > > - Coupling the smallest fix for a subarchitecture to a full upload of > > the whole arch any package puts pressure on the autobuilder network > > without much gain, and causes many users to download "new" kernels > > identical to the old ones because of the version bump. -> E.g. > > disable CONFIG_PREEMPT for ia64 and let everyone upgrade their kernel. > > This can and should be fixed with the so called arch-specific uploads > (-x.0.0.1 or something such), which is a mechanism supposedly documented for > this exact purpose (for example, powerpc could have rebuilt -3 in this way). No, bin-NMUs are only allowed to have a updated changelog. > Not sure about the ftp-master/buildd admin side of this however. Any comment > on this are welcome. x-y.0.1 is mapped to source x-y. > > - Flavour names are assumed to be unique, this doesn't work well for > > bi-endian machines (e.g. sb1-swarm-bn for mips/mipsel) and 32/64 > > bit kernels. > > I think Andres already fixed this, but i will let him comment on this. They need to be unique per debian architecture. > > - Same goes for the control file generation, some moved away directory > > gets searched for control.in files as well, no check for valid arch > > names or the resulting duplicate package definitions. > > Also easily fixable, if not fixed already. Fixed. It now spits if you move the original version away to disable them. > > - The resulting control file suggests every available bootloader for > > each image, with an [ $arch ] specifier. This is generally ugly and > > doesn't help for e.g. mipsel subarches with per-subarch bootloaders > > (colo, delo, sibyl). > > Well, i am sure waldi's arch//defines will yield a satisfying resolution > to this, i belive this is already possible, as -powerpc and -powerpc-smp > depend on mkvmlinuz, while -powerpc64 does not. Yes, it does. Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0 signature.asc Description: Digital signature
Re: r4021 - trunk/kernel
On Mon, Aug 22, 2005 at 12:24:14PM +0200, Christoph Hellwig wrote: > On Mon, Aug 22, 2005 at 11:59:51AM +0200, Sven Luther wrote: > > Ok, this is a mess, so we probably need to hold a little flamewar about how > > we > > want the tree organized or something, before we start moving stuff back and > > fort. > > > > I believe that the trunk is for main development, and it is important that > > we > > keep the version we are actually using in trunk, and not the next version as > > the linux-2.6.13-rcsomething. > > > > Also, i am not overly convinced about the branch stuff, especially for main > > branches where we are going to work on, and not some obscure stuff only some > > will want to play with. > > > > Furthermore, now that the kernel subdir is going to be emptied of its > > content, > > in favour of the single linux-2.6 package, we could as well move linux-2.6 > > into the toplevel. > > > > So, my proposal was to have : > > > > /trunk/linux-2.6 <- main 2.6 kernel being uploaded to sid > > I liked that, I always hated the enormous hierachies in the old > repository. :) And we had already trimmed them from the first design. > > /trunk/linux-2.6-experimental <- the experimental version. > > SVN allows branches to reside anywhere freely, including under /trunk, > right? In that case this is okay, just make sure it really is a branch > so merges work fine. svn cp should be a branch. Merges are really a bit messy in svn, but i hear svk can do miracles for you there. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323999: Dangling Symlink in /lib/modules/2.6.8-2-386/source in kernel-image-2.6.8-16
On Aug 22, Horms <[EMAIL PROTECTED]> wrote: > I was under the impression that /lib/modules/2.6.8-2-686/build/ > was used rather than /lib/modules/2.6.8-2-686/source/ > > Is this incorrect? No, you are right. -- ciao, Marco signature.asc Description: Digital signature
Bug#283919: Wrong solution!
Maybe give a _warning_ (rather than an error) if "$rootdev = 0" but this is not great for the case that $rootdev should be zero (see bug #310316). Alternativly we could wait untill after the call to mount_root (or whatever it is) and check that a root filesystem has been mounted on /mnt. Something like this ? $INIT would normally be /sbin/init but if there is a kernel command line parameter to say different then we should place that in $INIT first... [ -x /mnt$INIT ] || ( echo "WARNING: $INIT not found on root device major=$major minor=$minor" ; sleep 5) Just a thought... Alex Owen On 22/08/05, Horms <[EMAIL PROTECTED]> wrote: > On Sun, Aug 21, 2005 at 01:27:50PM +0100, Alex Owen wrote: > > The bug title is still valid: "initrd-tools: Should warn if root > > device is not found". > > However as the discussion in bug #310316 shows checking for "$rootdev > > = 0" is not the was to find out if the root device has been found or > > not! > > Do you have any ideas on a valid check for no root dev?
