Processed: evms root on lvm/md [was Re: bug 336617]

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> tags 337704 moreinfo
Bug#337704: initramfs-tools: evms root *still* broken -- only part of 336617 
resolved!
Tags were: patch
Tags added: moreinfo

> stop
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337704: evms root on lvm/md [was Re: bug 336617]

[maximilian attems]

tags 337704 moreinfo
stop

On Sat, 05 Nov 2005, Paul Traina wrote:

> You closed this bug, but it didn't fix the additional issues I reported.
> Please reopen.
> 
> Paul

hurrah for opening an separate bug.
Sesse is using plain EVMS root, you seem to use an heavier mix.

your patch also seems not to be clean enough yet,
because he removes prerequisites only to add them later on.

can you please add more info about your setup to your bug report:
/etc/fstab, pvscan and  /proc/mdstat

why is /etc/evms.conf needed?

you add lots of evms libs:
+for x in bbr bbr_seg bsd disk dos drivelink gpt lvm2 mac md multipath; do


thanks for your info.

--
maks



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd

[Harald Dunkel]

Pozsar Balazs wrote:
> On Sat, Nov 05, 2005 at 06:31:04PM +0100, Kay Sievers wrote:
> 
> 
> With my patch, modprobe waits until the needed modules come out of the 
> "Loading" or "Unloading" state.
> 
> 

For testing I have added it to Debian's
module-init-tools 3.2-pre9. Works for me.


Regards

Harri


signature.asc
Description: OpenPGP digital signature

Bug#337279: yaird: /boot != /tmp

[Anthony DeRobertis]

Sven Luther wrote:

> because i was thinking that the problem happened during boot time, and since
> there where issues of read-only filesystems. ...

This is definitely at creation time.

> 
> BTW, erik, i am not sure to have the files in non-/tmp will help
> security-wise, since it will only protect from people looking after the exact
> yaird behavior, and knowing about the situation.

Messages sent to [EMAIL PROTECTED] are not cc'd to me (this isn't
aimed at you, Sven; rather the other people who have commented in the
BTS). You have to send to [EMAIL PROTECTED] or me
directly... Darn you BTS!

A lot of the standard /tmp races don't apply to yaird because yaird uses
mkdir, not open. Concerns about races w/ tmpreaper are also not an
issue, because yaird is run with admin supervision; certainly, if the
admin does not notice someone slowing his system so that yaird runs for
days so that tmpreaper decides to remove yaird's tmpdir then, well, he
deserves what he gets.

And, for the record, I (the admin) did not decide to use /boot as a
temporary directory. Using TMPDIR is fine, but when its not set, the
default should be /tmp, because that's the way Unix programs are
supposed to work.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#327416: marked as done (CAN-2005-2490/CAN-2005-2492: Two sendmsg() related vulnerabilites)

[Debian Bug Tracking System]

Your message dated Sat, 5 Nov 2005 21:42:21 -0800 (PST)
with message-id <[EMAIL PROTECTED]>
and subject line CAN-2005-2490/CAN-2005-2492: Two sendmsg() related 
vulnerabilites
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 9 Sep 2005 23:29:08 +
>From [EMAIL PROTECTED] Fri Sep 09 16:29:08 2005
Return-path: <[EMAIL PROTECTED]>
Received: from (vserver151.vserver151.serverflex.de) [193.22.164.111] 
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1EDsIt-0002oA-00; Fri, 09 Sep 2005 16:29:07 -0700
Received: from dsl-084-059-136-208.arcor-ip.net ([84.59.136.208] 
helo=localhost.localdomain)
by vserver151.vserver151.serverflex.de with esmtpsa 
(TLS-1.0:RSA_AES_256_CBC_SHA:32)
(Exim 4.50)
id 1EDsIo-0007FW-Ph
for [EMAIL PROTECTED]; Sat, 10 Sep 2005 01:29:03 +0200
Received: from jmm by localhost.localdomain with local (Exim 4.52)
id 1EDsJe-0001ps-KU; Sat, 10 Sep 2005 01:29:54 +0200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Moritz Muehlenhoff <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: CAN-2005-2490/CAN-2005-2492: Two sendmsg() related vulnerabilites
X-Mailer: reportbug 3.17
Date: Sat, 10 Sep 2005 01:29:54 +0200
X-Debbugs-Cc: Debian Security Team <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
X-SA-Exim-Connect-IP: 84.59.136.208
X-SA-Exim-Mail-From: [EMAIL PROTECTED]
X-SA-Exim-Scanned: No (on vserver151.vserver151.serverflex.de); SAEximRunCond 
expanded to false
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level: 
X-Spam-Status: No, hits=-11.0 required=4.0 tests=BAYES_00,HAS_PACKAGE,
X_DEBBUGS_CC autolearn=ham version=2.60-bugs.debian.org_2005_01_02

Package: linux-2.6
Severity: important
Tags: security

[Severity important only, as amd64 is not yet officially in the archive]

These patches were posted as part of the stable review cycle on linux-kernel,
they're probably available in git already.

CAN-2005-2490: (local privilege escalation on amd64)
When we copy 32bit ->msg_control contents to kernel, we walk the same
userland data twice without sanity checks on the second pass.

Second version of this patch: the original broke with 64-bit arches
running 32-bit-compat-mode executables doing sendmsg() syscalls with
unaligned CMSG data areas

Another thing is that we use kmalloc() to allocate and sock_kfree_s()
to free afterwards; less serious, but also needs fixing.

Patch by Al Viro, David Miller, David Woodhouse

Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
 include/net/compat.h |2 +-
 net/compat.c |   44 ++--
 net/socket.c |3 ++-
 3 files changed, 29 insertions(+), 20 deletions(-)

Index: linux-2.6.13.y/include/net/compat.h
===
--- linux-2.6.13.y.orig/include/net/compat.h
+++ linux-2.6.13.y/include/net/compat.h
@@ -33,7 +33,7 @@ extern asmlinkage long compat_sys_sendms
 extern asmlinkage long compat_sys_recvmsg(int,struct compat_msghdr __user 
*,unsigned);
 extern asmlinkage long compat_sys_getsockopt(int, int, int, char __user *, int 
__user *);
 extern int put_cmsg_compat(struct msghdr*, int, int, int, void *);
-extern int cmsghdr_from_user_compat_to_kern(struct msghdr *, unsigned char *,
+extern int cmsghdr_from_user_compat_to_kern(struct msghdr *, struct sock *, 
unsigned char *,
int);
 
 #endif /* NET_COMPAT_H */
Index: linux-2.6.13.y/net/compat.c
===
--- linux-2.6.13.y.orig/net/compat.c
+++ linux-2.6.13.y/net/compat.c
@@ -135,13 +135,14 @@ static inline struct compat_cmsghdr __us
  * thus placement) of cmsg headers and length are different for
  * 32-bit apps.  -DaveM
  */
-int cmsghdr_from_user_compat_to_kern(struct msghdr *kmsg,
+int cmsghdr_from_user_compat_to_kern(struct msghdr *kmsg, struct sock *sk,
   unsigned char *stackbuf, int stackbuf_size)
 {
struct compat_cmsghdr __user *ucmsg;
struct cmsghdr *kcmsg, *kcmsg_base;
compat_size_t ucmlen;
__kernel_size_t kcmlen, tmp;
+   int err = -EFAULT;
 
kcmlen = 0;
kcmsg_base = kcmsg = (struct cmsghdr *)stackbuf;
@@ -156,6 +157,7 @@ int cmsghdr_from_user_com

Processed: Reassigning to proper package -- initramfs-tools

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 332824 initramfs-tools
Bug#332824: linux-image-2.6.13-1-686: Cannot find LVM root fs
Bug reassigned from package `linux-image-2.6.13-1-686' to `initramfs-tools'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#328534: Adaptec 2005S Hangs with current experiemental 2.6.13-686-smp kernel

[Jurij Smakov]

Hi,

Could you please check whether 2.6.14-2, which is currently in unstable, 
still oopses/hangs with your controllers?


Best regards,

Jurij Smakov[EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/   KeyID: C99E03CC


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#323136: linux-2.6: patch from 2.6.13

[Jurij Smakov]

Hi Lior,

Could you give 2.6.14-2 (currently in unstable) a try? All the fixes 
mentioned in the bug trail should be included in it.


Thanks,

Jurij Smakov[EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/   KeyID: C99E03CC


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd

[Rusty Russell]

On Sat, 2005-11-05 at 19:48 +0100, Pozsar Balazs wrote:
> On Sat, Nov 05, 2005 at 06:31:04PM +0100, Kay Sievers wrote:
> > I've got these messages several times on the experimental SUSE too,
> > but can't reproduce it so far, even without Rusty's patch to modprobe
> > they have disappeared. See here for the details:
> >   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333052
> 
> 
> Just to let you know, I've also met this problem (on another distro), 
> and did not know about this bugreport until now.
> So I've done another workaround: modprobe already parses /proc/modules 
> to check whether the modules needed are already loaded, and this file 
> also shows us the state of the modules, being "Loading", "Live" or 
> "Unloading".
> 
> With my patch, modprobe waits until the needed modules come out of the 
> "Loading" or "Unloading" state.

Yes, this was going to be my solution.  However, we only need to resort
to this is locking fails (read-only root filesystem).

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337724: Yaird, grub and d-i should also support dmraid devices.

[Marco Amadori]

Package: yaird
Version: any
Tags: upstream, patch
Severity: normal

As dbug:335230 this should help bringing to yaird the boot support for dmraid 
devices.

As you all know dmraid is now in debian, should be nice to add support for it 
also in partman (d-i) udeb providing and in grub, I done it manually so 
should be possibile to also patch grub-install to handle it. Also d-i should 
be trivial. 

CC:ed also maintainers of grub, dm-raid and d-i for seeing their interest in 
supporting this task and asking this question :

" Should I fill also bugs for grub and d-i (for yaird I'm like little 
authorized) ? "

---  begin yaird only part  

I know that evms support is unfinished yet, but I got this code working!
It actually booted my dmraid system, it seems that my perl skills are 
growing :-)

It is someway dirty and has poor RC checking, but works, at least worked for 
me.

Patch included, diffed from yaird-evms archive from the above dbug page.

Feel free to include in upcoming yaird 0.12 :-)

-- 
ESC:wq


yaird-dmraid.diff.bz2
Description: BZip2 compressed data

Bug#335230: More Code also Random, but less :-)

[Marco Amadori]

Alle 22:29, giovedì 3 novembre 2005, hai scritto:
> Progress update:

Really nice!

> System has no lvm2, mdadm or dmsetup installed.

I applied your patches too but I think that my system needs more care:

# yaird -t 
yaird error: Don't know how to choose between /dev/mapper/lvm2|sicuro|cache 
and /dev/evms/lvm2/sicuro/cache for dm-31 (fatal)

How should we handle that?

-- 
ESC:wq

Bug#336988: yaird: ignoring 'mesh' doesn't allow root device to be found

[Beiad Dalton]

Package: yaird
Version: 0.0.11-11
Followup-For: Bug #336988


*chuckle*

'mesh' is the onboard oldworld SCSI host adapter; my installation
happens to be on this, so when I boot 2.6.14-1-powerpc, I have no root
filesystem.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-powerpc
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages yaird depends on:
ii  cpio 2.6-9   GNU cpio -- a program to manage ar
ii  dash 0.5.2-8 The Debian Almquist Shell
ii  libc62.3.5-7 GNU C Library: Shared libraries an
ii  libhtml-template-perl2.6-2   HTML::Template : A module for usin
ii  libparse-recdescent-perl 1.94.free-1 Generates recursive-descent parser
ii  perl 5.8.7-7 Larry Wall's Practical Extraction 

yaird recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: Re: Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign #337625 yaird
Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not 
loaded in initrd
Bug reassigned from package `initramfs-tools' to `yaird'.

> stop no thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd

[maximilian attems]

reassign #337625 yaird
stop no thanks

On Sat, 05 Nov 2005, Jonas Smedegaard wrote:

> Sounds like you had initramfs-tools and not yaird installed at the time
> of initially installing the kernel.
> 
> Reassigning to initramfs-tools.

no mention of initramfs-tools in initial report.

> > Regenerating initrd with yaird solved the problem.
> 
> Yes, this has been fixed with most recent version of yaird.

then mark it fixed with the new nice Version header.
 
--
maks



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337713: linux-image-2.6.14-1-k7: Kernel panic "Fatal exception in interrupt"

[Torok Edwin]

Package: linux-image-2.6.14-1-k7
Version: 2.6.14-1
Severity: important

I have got a kernel panic, here it is: (I hand-copied it, since it wasn't saved 
to disk)
EIP: 0060: []  Not tainted VLI
EFLAGS: 00010286 (2.6.14-1-k7)
EIP is at nf_queue+0x16/0x240
eax:  ebx: 0001 ecx:  edx: 0002
esi: dece0920 edi: c03a3aa8 ebp: c0277e70 esp: cf165e78
ds:  007b es:  007b ss: 0068

Process sh (pid:5278, threadinfo=cf164000 task=dc5b4ab0)
Stack:   cf165f00 dae29000  c0277e70 0001 cf165f00 c03a3aa8 c0277e70
c02b1f7c cf165f00 dece0920 0002 0001 dae29000  c0277e70 
 dece0920  da641b40 da54bcde cc318abc c0277c10 0002

Call Trace:
[] ip_local_deliver_finish+0x0/0x230
[] ip_local_deliver_finish+0x0/0x230
[] nf_hook_slow+0x0c/0x110
[] ip_local_deliver_finish+0x0/0x230
[] ip_local_deliver+0x60/0x2c0
[] ip_rcv+0x357/0x540
[] netif_receive_skb+0x238/0x2e0
[] process_backlog+0x6e/0xf0
[] net_rx_action+0x87/0x140
[] __do_softirqq+0x43/0x90
[] do_softirq+0x26/0x30
[] do_IRQ+0x1e/0x30
[] common_interrupt+0x1a/0x20
Code: c0 75 ec e9 bd e5 e6 ff 8d b6 00 00 00 00 8d bc 27 00 00 00 00 55 57 56 53
83 ec 10 8b 54 24 2c 8b 74 24 28 8b 04 9b c0 42 3a c0 <8b> 38 85 ff 0f 84 96 01
00 00 86 44 24 2c 8b 7c 24 2c c7 44 24
<0>Kernel panic - not syncing: Fatal exception in interrupt

Bug reproducible: always.
Steps to reproduce: Start fireflierd
Result: kernel panic

What fireflierd does is try to communicate with the ip_queue module, that isn't 
loaded.
If I load the module everything is ok. 
On kernel version 2.6.12 I got an error message from fireflierd, but the kernel 
didn't panic.
If you need further info, tell please tell me how to provide it.
If you need the program fireflierd, just tell me, I can upload it somewhere 
(binary/source), it is a GPL program,
that's going to be released soon.

Offtopic: I pressed Alt+SysRQ+O, and Alt+SysRq+B, and nothing happened. If I 
pressed Alt+SysRq+H it showed me the SysRq help.


Here it is the output of /proc/modules:
ipt_TCPMSS 4288 1 - Live 0xdedd
ipt_tcpmss 2176 1 - Live 0xdedba000
iptable_filter 2816 1 - Live 0xded3
ip_tables 20160 3 ipt_TCPMSS,ipt_tcpmss,iptable_filter, Live 0xdedca000
via 40384 1 - Live 0xded54000
drm 73492 2 via, Live 0xded5f000
lp 12036 0 - Live 0xded44000
thermal 13384 0 - Live 0xded3f000
fan 4612 0 - Live 0xded2d000
button 6480 0 - Live 0xdecd5000
processor 22524 1 thermal, Live 0xded32000
ac 4676 0 - Live 0xdecd8000
battery 9412 0 - Live 0xded26000
binfmt_misc 11848 1 - Live 0xdebb6000
pppoe 14144 2 - Live 0xdecdb000
pppox 3400 1 pppoe, Live 0xdec91000
ipv6 265984 12 - Live 0xded72000
af_packet 22728 2 - Live 0xded1f000
ppp_generic 30036 6 pppoe,pppox, Live 0xded16000
slhc 7616 1 ppp_generic, Live 0xdec8e000
ntfs 210704 1 - Live 0xdece1000
nls_iso8859_1 3968 2 - Live 0xdec86000
nls_cp437 5632 1 - Live 0xdec83000
vfat 14208 1 - Live 0xdec89000
fat 54108 1 vfat, Live 0xdec94000
it87 21664 0 - Live 0xdebd9000
hwmon_vid 2624 1 it87, Live 0xdea1e000
i2c_isa 4736 1 it87, Live 0xdebad000
i2c_core 4 2 it87,i2c_isa, Live 0xdebd2000
snd_seq_dummy 3652 0 - Live 0xdea25000
snd_seq_oss 35328 0 - Live 0xdebc8000
snd_seq_midi 9312 0 - Live 0xdeba9000
snd_seq_midi_event 7168 2 snd_seq_oss,snd_seq_midi, Live 0xdea22000
snd_seq 52624 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event, Live 
0xdebba000
snd_via82xx 29824 0 - Live 0xdeada000
gameport 15048 1 snd_via82xx, Live 0xdea51000
snd_ac97_codec 97276 1 snd_via82xx, Live 0xdea98000
snd_ac97_bus 2176 1 snd_ac97_codec, Live 0xde8bf000
snd_pcm_oss 54688 0 - Live 0xdeacb000
snd_mixer_oss 19776 1 snd_pcm_oss, Live 0xde9ba000
snd_pcm 92168 3 snd_via82xx,snd_ac97_codec,snd_pcm_oss, Live 0xdeab3000
snd_timer 24772 2 snd_seq,snd_pcm, Live 0xdea9
snd_page_alloc 10952 2 snd_via82xx,snd_pcm, Live 0xde891000
snd_mpu401_uart 7360 1 snd_via82xx, Live 0xde8b9000
snd_rawmidi 25440 2 snd_seq_midi,snd_mpu401_uart, Live 0xdea88000
snd_seq_device 8780 5 
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq,snd_rawmidi, Live 0xde9b6000
shpchp 98660 0 - Live 0xdea37000
pci_hotplug 28340 1 shpchp, Live 0xdea16000
snd 55652 11 
snd_seq_oss,snd_seq,snd_via82xx,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device,
 Live 0xdea28000
via_rhine 23364 0 - Live 0xde9ee000
mii 5632 1 via_rhine, Live 0xde8bc000
via_ircc 31252 0 - Live 0xde9e5000
soundcore 9696 1 snd, Live 0xde9af000
irda 199484 1 via_ircc, Live 0xdea56000
crc_ccitt 1984 1 irda, Live 0xde895000
ehci_hcd 35528 0 - Live 0xde9db000
uhci_hcd 33040 0 - Live 0xde9d1000
usbcore 124288 3 ehci_hcd,uhci_hcd, Live 0xde9f6000
parport_pc 36868 1 - Live 0xde998000
parport 37000 2 lp,parport_pc, Live 0xde9a4000
via_agp 9920 1 - Live 0xde879000
agpgart 35528 2 drm,via_agp, Live 0xde8af000
ide_cd 43716 0 - Live 0xde8a3000
cdrom 40736 1 ide_cd, Live 0xde898000
genrtc 8712 0 - Live 0xde87d000
unix 28016 52 - Live 0xde882000
reiserfs 278576 2 - Live 0xde8c1000
ide_disk 18880 7 - Liv

Bug#337704: initramfs-tools: evms root *still* broken -- only part of 336617 resolved!

[Paul Traina]

Package: initramfs-tools
Version: 0.38
Severity: important
Tags: patch

336617 was closed out without using the additional patches I submitted.
I'm having problems re-opening the bug, so I'm just submitting a new one.

The following two patches need to be applied to evms 0.38 in order to allow
booting to evms volumes located on lvm and md regions.  Tested with stock
linux-image-2.6.14-1-686-smp.


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-686-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages initramfs-tools depends on:
ii  busybox   1:1.01-3   Tiny utilities for small and embed
ii  cpio  2.6-9  GNU cpio -- a program to manage ar
ii  klibc-utils   1.1.1-2small statically-linked utilities 
ii  mklibs-copy   0.1.18 Shared library reduction script
ii  udev  0.071-1/dev/ and hotplug management daemo

initramfs-tools recommends no packages.

-- no debconf information
--- initramfs-tools/hooks/evms  2005-11-01 22:21:25.0 -0800
+++ initramfs-tools/hooks/evms  2005-11-02 09:30:55.0 -0800
@@ -21,15 +21,16 @@
 fi
 
 cp /sbin/evms_activate ${DESTDIR}/sbin
+cp /etc/evms.conf ${DESTDIR}/etc
 
 EVMS_VERSION=$(/usr/sbin/evms_query info | grep "EVMS Version" | awk '{ print 
$3; }')
 
 mkdir -p ${DESTDIR}/lib/evms/${EVMS_VERSION}
 
-for x in disk lvm2 dos multipath; do
+for x in bbr bbr_seg bsd disk dos drivelink gpt lvm2 mac md multipath; do
cp /lib/evms/${EVMS_VERSION}/${x}* ${DESTDIR}/lib/evms/${EVMS_VERSION}
 done
 
-for x in dm_mod; do
+for x in dm_mod linear raid0 raid1 raid10 raid5 raid6; do
 manual_add_modules ${x}
 done
--- initramfs-tools/scripts/local-top/evms  2005-09-19 05:49:09.0 
-0700
+++ initramfs-tools/scripts/local-top/evms  2005-11-02 09:31:34.0 
-0800
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-PREREQ="lvm"
+PREREQ=""
 
 prereqs()
 {
@@ -16,16 +16,15 @@
 esac
 
 evms=${ROOT#/dev/evms/}
-
 case ${evms} in
-   /dev/root)
-   unset evms
-   ;;
/*)
exit 0
;;
 esac
-   
-modprobe -q dm-mod
+unset evms
+
+for module in dm-mod linear raid0 raid1 raid10 raid5 raid6 ; do
+   modprobe -q $module
+done
 
 /sbin/evms_activate

Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 5 Nov 2005 17:54:46 +0100
Sven Luther <[EMAIL PROTECTED]> wrote:

> > Sounds like you had initramfs-tools and not yaird installed at the
> > time of initially installing the kernel.
> > 
> > Reassigning to initramfs-tools.
> 
> Jonas, i believe he had an older version of yaird without the fbcon
> fix, and rebuilt with yaird or something, not sure.

If so, this bugreport could be closed right away.

Instead, I wrote that last paragraph that you cut out in your quote
above :-P


 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDbR2Kn7DbMsAkQLgRAlaGAJ0eWElH1VabOABNURH+1dLNvxj2zwCgozba
pDqaSXozrK+UDx3wjnd1Jrs=
=qL13
-END PGP SIGNATURE-

Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd

[Pozsar Balazs]

On Sat, Nov 05, 2005 at 06:31:04PM +0100, Kay Sievers wrote:
> I've got these messages several times on the experimental SUSE too,
> but can't reproduce it so far, even without Rusty's patch to modprobe
> they have disappeared. See here for the details:
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333052


Just to let you know, I've also met this problem (on another distro), 
and did not know about this bugreport until now.
So I've done another workaround: modprobe already parses /proc/modules 
to check whether the modules needed are already loaded, and this file 
also shows us the state of the modules, being "Loading", "Live" or 
"Unloading".

With my patch, modprobe waits until the needed modules come out of the 
"Loading" or "Unloading" state.


-- 
pozsy


--- module-init-tools-3.2-pre4.orig/modprobe.c  2005-05-08 09:38:52.0 
+0200
+++ module-init-tools-3.2-pre4/modprobe.c   2005-10-24 13:19:39.0 
+0200
@@ -363,6 +363,7 @@
FILE *proc_modules;
char *line;
 
+start:
/* Might not be mounted yet.  Don't fail. */
proc_modules = fopen("/proc/modules", "r");
if (!proc_modules)
@@ -373,12 +374,31 @@
 
if (entry && strcmp(entry, modname) == 0) {
/* If it exists, usecount is the third entry. */
-   if (usecount) {
-   entry = strtok(NULL, " \n");
-   if (entry
-   && (entry = strtok(NULL, " \n")) != NULL)
+   if (!(entry = strtok(NULL, " \n")))
+   goto out;
+
+   if (!(entry = strtok(NULL, " \n"))) /* usecount */
+   goto out;
+   else
+   if (usecount)
*usecount = atoi(entry);
+
+   if (!(entry = strtok(NULL, " \n"))) /* "-" */
+   goto out;
+
+   if (!(entry = strtok(NULL, " \n"))) /* status */
+   goto out;
+   else {
+   if (!strcmp(entry, "Loading") || !strcmp(entry, 
"Unloading")) {
+   usleep(10);
+   free(line);
+   fclose(proc_modules);
+   goto start;
+   }
+   goto out;
}
+
+   out:
free(line);
fclose(proc_modules);
return 1;


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337682: initramfs-tools: ROOT=probe not implemented.

[Sven Luther]

Package: initramfs-tools
Severity: wishlist


initramfs-tools generated ramdisk don't allow not passing the root filesystem
in the command line, which would be probed at ramdisk boot time. This is a
regression from initrd-tools which supported this feature.

The way it works is to have the ramdisk generation detect the root partition,
and use it as default if not overriden by the kernel command line.

Friendly,

Sven Luther


-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.12-1-powerpc
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#334123: marked as done (linux-image-2.6.13-1-k7: 2.6.12 works OK, 2.6.13 doesn't)

[Debian Bug Tracking System]

Your message dated Sat, 5 Nov 2005 19:29:03 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#334123: linux-image-2.6.13-1-k7: 2.6.12 works OK, 2.6.13 
doesn't
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 15 Oct 2005 18:15:51 +
>From [EMAIL PROTECTED] Sat Oct 15 11:15:51 2005
Return-path: <[EMAIL PROTECTED]>
Received: from port-212-202-37-43.dynamic.qsc.de (knarzkiste.dyndns.org) 
[212.202.37.43] 
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1EQqZT-00084f-00; Sat, 15 Oct 2005 11:15:51 -0700
Received: by knarzkiste.dyndns.org (Postfix, from userid 0)
id 1D078E006A91; Sat, 15 Oct 2005 20:15:49 +0200 (CEST)
Content-Type: multipart/mixed; boundary="===0015114324=="
MIME-Version: 1.0
From: Ralf Hildebrandt <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: linux-image-2.6.13-1-k7: 2.6.12 works OK, 2.6.13 doesn't
X-Mailer: reportbug 3.17
Date: Sat, 15 Oct 2005 20:15:49 +0200
Message-Id: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level: 
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
autolearn=no version=2.60-bugs.debian.org_2005_01_02

This is a multi-part MIME message sent by reportbug.

--===0015114324==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Package: linux-image-2.6.13-1-k7
Version: 2.6.13-1
Severity: normal


2.6.12-1-k7 works OK, the USB mouse works.
Booting 2.6.13-1-k7 results in problems with the USB controller and IRQ
11 issues.

I attached dmesg output for kernel 2.6.12 and 2.6.13; maybe the diff
between the two can give some insights on what exactly causes the USB
ports to utterly malfunction.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-k7
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages linux-image-2.6.13-1-k7 depends on:
ii  initrd-tools  0.1.82 tools to create initrd image for p
ii  module-init-tools 3.2-pre9-2 tools for managing Linux kernel mo

linux-image-2.6.13-1-k7 recommends no packages.

-- no debconf information

--===0015114324==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="2.6.12-1-k7"

Linux version 2.6.12-1-k7 ([EMAIL PROTECTED]) (gcc version 4.0.2 20050917 
(prerelease) (Debian 4.0.1-8)) #1 Tue Sep 27 13:22:07 JST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e4000 - 0010 (reserved)
 BIOS-e820: 0010 - 1bf4 (usable)
 BIOS-e820: 1bf4 - 1bf5 (ACPI data)
 BIOS-e820: 1bf5 - 1c00 (ACPI NVS)
 BIOS-e820: 1c00 - 2000 (reserved)
 BIOS-e820: fff8 - 0001 (reserved)
0MB HIGHMEM available.
447MB LOWMEM available.
On node 0 totalpages: 114496
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 110400 pages, LIFO batch:31
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 MSI   ) @ 0x000f8350
ACPI: RSDT (v001 MSI1013 0x08242005 MSFT 0x0097) @ 0x1bf4
ACPI: FADT (v002 MSI1013 0x08242005 MSFT 0x0097) @ 0x1bf40200
ACPI: MADT (v001 MSIOEMAPIC  0x08242005 MSFT 0x0097) @ 0x1bf40300
ACPI: WDRT (v001 MSIMSI_OEM  0x08242005 MSFT 0x0097) @ 0x1bf40360
ACPI: MCFG (v001 MSIOEMMCFG  0x08242005 MSFT 0x0097) @ 0x1bf403b0
ACPI: SSDT (v001 OEM_ID OEMTBLID 0x0001 INTL 0x02002026) @ 0x1bf43620
ACPI: OEMB (v001 MSIMSI_OEM  0x08242005 MSFT 0x0097) @ 0x1bf50040
ACPI: DSDT (v001MSI 1013 0x08242005 INTL 0x02002026) @ 0x
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 16
ACPI: Skipping IOAPIC probe due to 'noapic' option.
Allocating PCI resources starting at 2000 (gap: 2000:dff8)
Bu

Bug#337663: initramfs-tools: droping in rescue shell has no loadkeys and do not default to right keymap.

[Sven Luther]

On Sat, Nov 05, 2005 at 06:03:39PM +, Alastair McKinstry wrote:
> Sven Luther wrote:
> 
> >Package: initramfs-tools
> >Severity: normal
> >
> >
> >Well, as said, it is rather painful when one is dropped in the rescue 
> >shell,
> >to have it default to us keymap, even though you have another kind of 
> >keyboard
> >layout (azerty for me). At least it should include the loadkeys binary as 
> >well
> >as the keymaps if it fails to autodetect the right thing.
> >
> >Friendly,
> >
> >Sven Luther
> >
> > 
> >
> Little-known fact: the 'kbd-chooser' binary acts as loadkeys within d-i. 
> So we should make sure its loaded
> and there is a symlink to it from /bin/loadkeys.

Huh, this is not d-i, but initramfs-tools failback shell.

Friendly,

Sven Luther



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337663: initramfs-tools: droping in rescue shell has no loadkeys and do not default to right keymap.

[Alastair McKinstry]

Sven Luther wrote:


Package: initramfs-tools
Severity: normal


Well, as said, it is rather painful when one is dropped in the rescue shell,
to have it default to us keymap, even though you have another kind of keyboard
layout (azerty for me). At least it should include the loadkeys binary as well
as the keymaps if it fails to autodetect the right thing.

Friendly,

Sven Luther

 

Little-known fact: the 'kbd-chooser' binary acts as loadkeys within d-i. 
So we should make sure its loaded

and there is a symlink to it from /bin/loadkeys.

Regards
Alastair


-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.12-1-powerpc
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)



 





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: Re: Bug#337479: yaird: should use /usr/bin/perl, not /usr/local/bin/perl

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> severity 337479 serious
Bug#337479: yaird: should use /usr/bin/perl, not /usr/local/bin/perl
Severity set to `serious'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#337479: yaird: should use /usr/bin/perl, not /usr/local/bin/perl

[Bastian Blank]

severity 337479 serious
thanks

On Sat, Nov 05, 2005 at 04:31:02PM +0100, Mattia Dongili wrote:
> I'd say this is a problem in the submitter's build host. I's like
> configuring a package with silly ./configure options and pretending it
> works everywhere. :)

No it is not, it is perfectly valid to have a compatible file laying
around.

As this changes the output of the build process in an unpredictable way,
it needs to be fixed, I adjusted the severity to show this.

Bastian

-- 
You're too beautiful to ignore.  Too much woman.
-- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown


signature.asc
Description: Digital signature

Bug#337663: initramfs-tools: droping in rescue shell has no loadkeys and do not default to right keymap.

[Sven Luther]

Package: initramfs-tools
Severity: normal


Well, as said, it is rather painful when one is dropped in the rescue shell,
to have it default to us keymap, even though you have another kind of keyboard
layout (azerty for me). At least it should include the loadkeys binary as well
as the keymaps if it fails to autodetect the right thing.

Friendly,

Sven Luther

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.12-1-powerpc
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd

[Sven Luther]

On Sat, Nov 05, 2005 at 01:30:41PM +0100, Jonas Smedegaard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> reassign 337625 initramfs-tools
> thanks
> 
> On Sat, 05 Nov 2005 13:06:58 +0100
> Pau Capdevila <[EMAIL PROTECTED]> wrote:
> 
> > Booting with original initrd gives black screen.
> 
> Sounds like you had initramfs-tools and not yaird installed at the time
> of initially installing the kernel.
> 
> Reassigning to initramfs-tools.

Jonas, i believe he had an older version of yaird without the fbcon fix, and
rebuilt with yaird or something, not sure.

Friendly,

Sven Luther



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

kernel-package (10.004) heading for experimental

[Manoj Srivastava]

Hi folks,

This is the big one. The kernel image packages produced now
 use debconf to ask questions. This version has been tested as best I
 can -- I created all the kernel packages, individually, as well as
 the make-kpkg buildpackage; I tried both with and withoug --initrd,
 and I have installed 2.6.14 kernels on my i386 hardware to ensure the
 debconf stuff at least works for me in a brand new UML instance.

This is the last version to go into experimental; I'll wait
 for bug report, and fix some recent reports, and upload to Sid in a
 day or so. So please test this version.

manoj

kernel-package (10.004) experimental; urgency=low

  * Bug fix: "using debconf", thanks to Robert Millan  (Closes: #115884)
  * Bug fix: "does not install non-interactively", thanks to Matt Kraai
   (Closes: #247782)
  * This fine tunes the dependencies between targets. All of the package
building targets are ones that insert themselves into the normal flow
of policy specified targets, so they must hook themselves into the
stream. That means, in essence, that they must depend on the configure
and  corresponding build targets (with stamps) and ensure that the
prep work is all done before they are invoked. The advantage is that
nothing is going to be remade more often than it needs to. It also
means we do not need to produce as many stamp files. So, the only
dependencies on any of the intermediate targets are targets that have
not been registered into the ladder created in rulesets/common/targets.mk
  * The kernel image maintainer scripts have been greatly
changed. Firstly, they now use  debconf; and a number of questions
have been moved to the config file (create-kimage-link-$version,
old-initrd-link, old-dir-initrd-link, old-system-map-link) while
others are asked conditionally in the postinst (depmod-error,
depmod-error-initrd, bootloader-test-error, bootloader-error). The
postinst has also become far less verbose; the users are far better
educated a decade after this was written, and there are other sources
of information about booting than the postinst of a kernel image.
  * The preinst also uses debconf. All the questions asked are still here
-- we just use debconf to ask the user. Also, the priority, and need
to break non-interactive installs was re-evaluated, and the preinst
breaks in far fewer cases than it did before. 
  * Second, the postinst gets rid of the code that generated boot floppies
and created lilo.conf (that latter was probably illegal under current
policy anyway). The do_boot_enable and do_boot_floppy configuration
variables in /etc/kernel-img.conf are now invalid.
  * Also, the source tree is not automatically cleaned; the do_clean
configuration variable, and the environment variable CLEAN_SOURCE are
now control if the source tree is optionally cleaned after the kernel
image package is built.

 more gory details ===

* kernel/ruleset/local.mk (CONFIG-common): since some of the others
  depend on it, only stamp-conf/debian remains on this target
  (CONFIG-arch): moved .config  here -- the headers and image targets are
  the most likely to need this done.
  (CONFIG/kernel): moved conf.vars stamp-conf/kernel out here, so that
  stamp-conf/debian and .config shall be already done by the time they
  are invoked.
  (BUILD-common): Before any building is done, we should ensure that all
  the sanity checks are met -- instead of bombing out _after_ a lengthy
  build process.
  (debian): Make it depend on a target with a proper stamp, so it is not
  invoked over and over again.
  All of the package building targets are ones that insert themselves
  into the normal flow of policy specified targets, so they must hook
  themselves into the stream. That means, in essence, that they must
  depend on the configure and  corresponding build targets (with stamps)
  and ensure that the prep work is all done before they are invoked.
  (CLEAN/$(i_package)): Ensure that the templates.master, and the
  templates, are created even on clean, for the kernel image package.

* kernel/ruleset/targets/headers.mk (install/$(h_package)): Since we have
  taken care to insert this target into the flow specified in
  rulesets/common/targets.mk, we need not have any dependencies here. The
  advantage is that nothing is going tobe remade more often than it needs
  to. It also means we do not need to produce a stamp file ourselves.

* kernel/ruleset/targets/manual.mk (install/$(m_package)): Minimize the
  dependencies for this target -- we are reduced to only having targets
  that have not been registered into the ladder created in
  rulesets/common/targets.mk 

* kernel/ruleset/targets/source.mk (install/$(s_package)): Reduce
  dependencies, for the reasons cited above.
  (binary/$(s_package)): Ditto.

* ker

Bug#337497: moreinfo concerning the missing partitions ...

[Sven Luther]

Hello,

Well, i just spoke a bit with jbailey and investigated some, and founf the
reason why the partitions where missing.

It seems the ide_disk module is not loaded, which given that my disk is an ide
one is pretty broken, i wonder if it could work on powermac or something.

Also, there is no lsmod command which had me a bit baffled, and jbailey
suggested creating an alias to /proc/modules, which allowed me to investigate
this, would be cool to make it the default with :

alias lsmod="more /proc/modules"

Ok, will add ide_disk to /etc/mkinitramfs/modules, and we will see what
happens.

Friendly,

Sven Luther



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337479: yaird: should use /usr/bin/perl, not /usr/local/bin/perl

[Mattia Dongili]

On Fri, Nov 04, 2005 at 09:41:15PM +0100, Jonas Smedegaard wrote:
> tags 337479 unreproducible
> thanks
> 
> On Fri, 04 Nov 2005 15:48:20 +0100
> "Laurent Bonnaud" <[EMAIL PROTECTED]> wrote:
> 
> > I have rebuilt yaird from the Debian source package on a system where
> > /usr/local/bin/perl is a symlink to /usr/bin/perl.  In the resulting
> > binary package,  /usr/sbin/yaird begins with:

and you probably have /usr/local/bin before /usr/bin in your path
eg:
$ ln -s /usr/bin/perl ~/bin/perl
$ PATH=~/bin:${PATH} which perl
/home/mattia/bin/perl

this is used to create the yaird perl executable:
$ PATH=~/bin:${PATH} ./configure && make
...
Making all in perl
make[1]: Entering directory
`/home/mattia/devel/debian/kernel/yaird/perl'
sed -e '[EMAIL PROTECTED]@!/home/mattia/bin/perl!' ...  < main.pl > yaird

[...]
> I cannot reproduce. Please describe in detail how you rebuild the
> package.
> 
> I suspect this to either be bad packaging routines on your end or bugs
> in the packaging tools you use.

I'd say this is a problem in the submitter's build host. I's like
configuring a package with silly ./configure options and pretending it
works everywhere. :)

-- 
mattia
:wq!


signature.asc
Description: Digital signature

Re: Sid linux-2.6 in SVN (Was: linux-2.6_2.6.14-2_hppa.changes ACCEPTED)

[Stephen R Marenka]

On Fri, Nov 04, 2005 at 10:15:01AM +0100, Christian T. Steigies wrote:

> BTW another question, what is the deal with klibc? My buildd refused to
> build it, since it is marked not for m68k. What is needed to make it build
> on m68k?

Accoring to the maintainer, it hasn't been ported yet (#334917). 

FWIW, I put it on the todo .

-- 
Stephen R. Marenka If life's not fun, you're not doing it right!
<[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Processed: Re: Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 337625 initramfs-tools
Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not 
loaded in initrd
Bug reassigned from package `linux-image-2.6.14-1-k7' to `initramfs-tools'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

reassign 337625 initramfs-tools
thanks

On Sat, 05 Nov 2005 13:06:58 +0100
Pau Capdevila <[EMAIL PROTECTED]> wrote:

> Booting with original initrd gives black screen.

Sounds like you had initramfs-tools and not yaird installed at the time
of initially installing the kernel.

Reassigning to initramfs-tools.



> Regenerating initrd with yaird solved the problem.

Yes, this has been fixed with most recent version of yaird.


If this is fixed in recent initramfs-tools as well, I believe this bug
can be closed.


 - Jonas


- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDbKXxn7DbMsAkQLgRAnsYAKCVQJ2MQTHPWvGmJQQpf92cqY279wCdE1xr
w1Fv9N54GX8l5PVtlh/f+oU=
=rhZP
-END PGP SIGNATURE-

Bug#336993: more info about #336993

[Paul Brossier]

Hi

using cramfs in /etc/yaird/Default.cfg:

#FORMAT cpio
FORMAT  cramfs

and booting with: 

Linux root=/dev/ram init=/init rw

i go pass the initrd, but mounting the root partition then fails end
with messages like:

/sbin/mkdnod:  `/dev/sda': Read-only filesystem.
/sbin/mkdnod:  `/dev/sda4': Read-only filesystem.

i could boot on 2.6.14 after recompiling with the command 

fakeroot make-kpkg --append-to-version -1-powerpc64-noinitrd \
--revision 2.6.14-2.0 --arch powerpc64 kernel_image

with the following diffs to the config (change XFS to whatever your root
filesystem is):

3,4c3,4
< # Linux kernel version: 2.6.14-1-powerpc64
< # Tue Nov  1 15:37:43 2005
---
> # Linux kernel version: 2.6.14-powerpc64-noinitrd
> # Sat Nov  5 11:03:09 2005
747c747
< CONFIG_SCSI=m
---
> CONFIG_SCSI=y
753,754c753,754
< CONFIG_BLK_DEV_SD=m
< CONFIG_CHR_DEV_ST=m
---
> CONFIG_BLK_DEV_SD=y
> CONFIG_CHR_DEV_ST=y
756c756
< CONFIG_BLK_DEV_SR=m
---
> CONFIG_BLK_DEV_SR=y
758c758
< CONFIG_CHR_DEV_SG=m
---
> CONFIG_CHR_DEV_SG=y
771c771
< CONFIG_SCSI_SPI_ATTRS=m
---
> CONFIG_SCSI_SPI_ATTRS=y
801c801
< CONFIG_SCSI_SATA=m
---
> CONFIG_SCSI_SATA=y
803c803
< CONFIG_SCSI_SATA_SVW=m
---
> CONFIG_SCSI_SATA_SVW=y
2176c2176
< CONFIG_XFS_FS=m
---
> CONFIG_XFS_FS=y
2267c2267
< CONFIG_EXPORTFS=m
---
> CONFIG_EXPORTFS=y

cheers, piem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337614: CONFIG_MODVERSIONS should not be used in distro kernels

[Bastian Blank]

On Sat, Nov 05, 2005 at 12:32:02PM +0100, Eduard Bloch wrote:
> How should I know? I have even removed all the kernel equivalents and
> kept only custom versions of ieee8* and ipw22* modules, did rmmod and
> "depmod -a", and still got:

Okay, so you build ipw2200 against the symbol versions of the ieee80211
module included in the kernel from
/lib/modules/$(uname -r)/source/Module.symvers. It seems that kbuild
needs an option to disable versions for external modules.

Bastian

-- 
Insults are effective only where emotion is present.
-- Spock, "Who Mourns for Adonais?"  stardate 3468.1


signature.asc
Description: Digital signature

Bug#336450: acknowledged by developer (Bug#336450: fixed in yaird 0.0.11-11)

[Richard Burton]

Confirmed fix working. Thanks guys.

Richard.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd

[Pau Capdevila]

Package: linux-image-2.6.14-1-k7
Version: 2.6.14-2
Severity: critical
Justification: breaks the whole system

Booting with original initrd gives black screen.
Regenerating initrd with yaird solved the problem.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-k7
Locale: LANG=ca_ES, LC_CTYPE=ca_ES (charmap=ISO-8859-1)

Versions of packages linux-image-2.6.14-1-k7 depends on:
ii  module-init-tools 3.2-pre9-3 tools for managing Linux kernel mo
ii  yaird [linux-initramfs-tool]  0.0.11-11  Yet Another mkInitRD

linux-image-2.6.14-1-k7 recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337614: CONFIG_MODVERSIONS should not be used in distro kernels

[Eduard Bloch]

#include 
* Bastian Blank [Sat, Nov 05 2005, 12:22:46PM]:
> On Sat, Nov 05, 2005 at 11:33:53AM +0100, Eduard Bloch wrote:
> > please consider not using CONFIG_MODVERSIONS in future. Reason: it makes
> > installation of alternative modules with the same names hard till
> > unpossible. Current example: ipw2200, which is contained in 2.6.14 in a
> > very old version. I cannot load the new version because lots of errors
> > about conflicting versions are detected (in dependent ieee82... modules
> > which I have built as well).
> 
> Err, _why_ do you get different symbol versions? They are supposed to be
> stable.

How should I know? I have even removed all the kernel equivalents and
kept only custom versions of ieee8* and ipw22* modules, did rmmod and
"depmod -a", and still got:

Nov  5 10:26:14 debian kernel: ieee80211_crypt: unregistered algorithm 'NULL' 
(deinit)
Nov  5 10:26:24 debian kernel: ieee80211_crypt: registered algorithm 'NULL'
Nov  5 10:26:24 debian kernel: ieee80211: 802.11 data/management/control stack, 
1.1.6
Nov  5 10:26:24 debian kernel: ieee80211: Copyright (C) 2004-2005 Intel 
Corporation <[EMAIL PROTECTED]>
Nov  5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol 
ieee80211_wx_set_encode
Nov  5 10:26:24 debian kernel: ipw2200: Unknown symbol ieee80211_wx_set_encode
Nov  5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol 
ieee80211_wx_get_encode
Nov  5 10:26:24 debian kernel: ipw2200: Unknown symbol ieee80211_wx_get_encode
Nov  5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol 
ieee80211_txb_free
Nov  5 10:26:24 debian kernel: ipw2200: Unknown symbol ieee80211_txb_free
Nov  5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol 
ieee80211_wx_get_scan
Nov  5 10:26:24 debian kernel: ipw2200: Unknown symbol ieee80211_wx_get_scan
Nov  5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol 
ieee80211_rx
Nov  5 10:26:24 debian kernel: ipw2200: Unknown symbol ieee80211_rx
Nov  5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol 
ieee80211_rx_mgt
Nov  5 10:26:24 debian kernel: ipw2200: Unknown symbol ieee80211_rx_mgt
Nov  5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol 
free_ieee80211
Nov  5 10:26:24 debian kernel: ipw2200: Unknown symbol free_ieee80211
Nov  5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol 
alloc_ieee80211
Nov  5 10:26:24 debian kernel: ipw2200: Unknown symbol alloc_ieee80211

Eduard.
-- 
Marcus Cole: I am a Ranger! We walk in the dark places no others may enter! We
stand on a bridge, and no one may pass. We live for the One! We DIE for the
ONE!
 -- Quotes from Babylon 5 --

Bug#337614: CONFIG_MODVERSIONS should not be used in distro kernels

[Bastian Blank]

On Sat, Nov 05, 2005 at 11:33:53AM +0100, Eduard Bloch wrote:
> please consider not using CONFIG_MODVERSIONS in future. Reason: it makes
> installation of alternative modules with the same names hard till
> unpossible. Current example: ipw2200, which is contained in 2.6.14 in a
> very old version. I cannot load the new version because lots of errors
> about conflicting versions are detected (in dependent ieee82... modules
> which I have built as well).

Err, _why_ do you get different symbol versions? They are supposed to be
stable.

Bastian

-- 
Klingon phaser attack from front!
100% Damage to life support


signature.asc
Description: Digital signature

Bug#337497: initramfs-tools: [powerpc] doesn't work on pegasos - ALERT! /dev/hda1 does

[Sven Luther]

On Sat, Nov 05, 2005 at 10:43:56AM +0100, Norbert Tretkowski wrote:
> * Sven Luther wrote:
> > ALERT!: /dev/hda1 does not exist, Dropping to a shell!
> 
> I saw the same on my notebook (i386) when using MODULES=dep in
> initramfs.conf.

the above was with MODULES=most though. Well, whatever wasdefault, and since
it had loads of cruft ...

Friendly,

Sven Luther



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337614: CONFIG_MODVERSIONS should not be used in distro kernels

[Sven Luther]

On Sat, Nov 05, 2005 at 11:33:53AM +0100, Eduard Bloch wrote:
> Package: linux-image-2.6.14-1-686
> Version: 2.6.14-2
> Severity: normal
> 
> Hello,
> 
> please consider not using CONFIG_MODVERSIONS in future. Reason: it makes
> installation of alternative modules with the same names hard till
> unpossible. Current example: ipw2200, which is contained in 2.6.14 in a
> very old version. I cannot load the new version because lots of errors
> about conflicting versions are detected (in dependent ieee82... modules
> which I have built as well).

Well, you could just subtly modifythe name or something, and do a diversion,
not sure. The pwc module maintainer does exactly that, and has no such
problem.

Friendly,

Sven Luther



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337614: CONFIG_MODVERSIONS should not be used in distro kernels

[Eduard Bloch]

Package: linux-image-2.6.14-1-686
Version: 2.6.14-2
Severity: normal

Hello,

please consider not using CONFIG_MODVERSIONS in future. Reason: it makes
installation of alternative modules with the same names hard till
unpossible. Current example: ipw2200, which is contained in 2.6.14 in a
very old version. I cannot load the new version because lots of errors
about conflicting versions are detected (in dependent ieee82... modules
which I have built as well).

Eduard.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.14-1-686 depends on:
ii  module-init-tools 3.2-pre9-3 tools for managing Linux kernel mo
ii  yaird [linux-initramfs-tool]  0.0.11-10  Yet Another mkInitRD

linux-image-2.6.14-1-686 recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337607: initramfs-tools: Boot scripts tries to use evms_activate (and mdrun?), which isn't inside initrd.img

[Tommi Vainikainen]

Package: initramfs-tools
Version: 0.38
Severity: grave

Inside generated initrd.img /scripts/local-top/evms script tries to
execute /sbin/evms_activate. I don't use evms and I don't have evms
files installed on my computer, and probably related to this fact,
initrd.img does not contain /sbin/evms_activate and therefore booting
fails. Same is true with /scripts/local-top/md. Maybe same is true
with LVM, but vgchange gets installed to my initrd.img correctly
because I've lvm tools installed.

-- 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-1-amd64-k8
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)

Versions of packages initramfs-tools depends on:
ii  busybox   1:1.01-3   Tiny utilities for small and embed
ii  cpio  2.6-9  GNU cpio -- a program to manage ar
ii  klibc-utils   1.1.1-2small statically-linked utilities 
ii  mklibs-copy   0.1.18 Shared library reduction script
ii  udev  0.071-1/dev/ and hotplug management daemo

initramfs-tools recommends no packages.

-- no debconf information

Added by hand:
ii  lvm2   2.01.14-3  The Linux Logical Volume Manager



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: Re: Bug#337599: linux-image-2.6.13-1-k7: Please make SECURITY_CAPABILITIES as module

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 337599 realtime-lsm
Bug#337599: linux-image-2.6.13-1-k7: Please make SECURITY_CAPABILITIES as module
Bug reassigned from package `linux-image-2.6.13-1-k7' to `realtime-lsm'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337599: linux-image-2.6.13-1-k7: Please make SECURITY_CAPABILITIES as module

[Bastian Blank]

reassign 337599 realtime-lsm
thanks

On Sun, Oct 16, 2005 at 02:13:04PM +0200, Mario Izquierdo (mariodebian) wrote:
> I want to compile realtime-lsm module in 2.6.13-1-k7 but
> module-asisstant don't work:

This was already decided to be a realtime-lsm bug.

Bastian

-- 
It is undignified for a woman to play servant to a man who is not hers.
-- Spock, "Amok Time", stardate 3372.7


signature.asc
Description: Digital signature

Bug#337497: initramfs-tools: [powerpc] doesn't work on pegasos - ALERT! /dev/hda1 does

[Norbert Tretkowski]

* Sven Luther wrote:
> ALERT!: /dev/hda1 does not exist, Dropping to a shell!

I saw the same on my notebook (i386) when using MODULES=dep in
initramfs.conf.

Norbert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337176: initramfs-tools: initrd unusable on amd64

[Tommi Vainikainen]

I can confirm that adding symlink lib64 -> lib to initrd.img will fix
this problem.

-- 
Tommi Vainikainen



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337599: linux-image-2.6.13-1-k7: Please make SECURITY_CAPABILITIES as module

[Mario Izquierdo (mariodebian)]

Package: linux-image-2.6.13-1-k7
Version: 2.6.13-1
Severity: wishlist
Tags: experimental

I want to compile realtime-lsm module in 2.6.13-1-k7 but
module-asisstant don't work:

# rgrep CAPABILITIES /boot/config-2.6.12-1-k7
CONFIG_SECURITY_CAPABILITIES=m

# rgrep CAPABILITIES /boot/config-2.6.13-1-k7
CONFIG_SECURITY_CAPABILITIES=y

In 2.6.12-1-k7 is module.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13-1-k7
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) (ignored: LC_ALL 
set to es_ES.UTF-8)

Versions of packages linux-image-2.6.13-1-k7 depends on:
ii  initrd-tools  0.1.82 tools to create initrd image for p
ii  module-init-tools 3.2-pre9-2 tools for managing Linux kernel mo

linux-image-2.6.13-1-k7 recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)

[Harald Welte]

On Sat, Nov 05, 2005 at 12:21:00AM +, Christoph Hellwig wrote:
> On Fri, Nov 04, 2005 at 12:29:20PM +0900, Horms wrote:
> > do I take that comment to mean that upstream can't update the
> > drivers but Debian can? And if so, do you recommend updating 
> > Debian's kernel packages, or putting the updates elsewhere?
> 
> Well, we could upstream, but so far no one is annoyed enough to
> overrid the driver maintainer.  

This is outrageous.

Do you know any contacts at Intel to whom we could complain?  I guess
there would be many people willing to write a nice email about how
impractical (actually, insane) such a policy is?

-- 
- Harald Welte <[EMAIL PROTECTED]>  http://gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)


pgptj6y6wwuGN.pgp
Description: PGP signature