Processed: severity of 465812 is important

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.10.13
> severity 465812 important
Bug#465812: linux-image-2.6.22-3-686: [Regression] LuKS passphrase not accepted 
anymore
Severity set to `important' from `critical'

>
End of message, 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: Please add following hint to block linux-2.6 until Beta1 is out

[maximilian attems]

On Thu, 14 Feb 2008, Philippe Cloutier wrote:

> > that is totally untrue.
> > linux-2.6 always needs hint from the release team to migrate.
> > properly set up it can happen in less then a week.
> What do you mean? What "it" can happen in less than one week?
 
omg, what are we talking about?
migration of linux-2.6 to testing.

i repeat that with proper urgency hints from the release team
linux-2.6 can be in a week in testing.

nobody gave a proper reason why this upper late beta1 needs
to happen with a retarted kernel.


signature.asc
Description: Digital signature

Bug#465812: linux-image-2.6.22-3-686: [Regression] LuKS passphrase not accepted anymore

[maximilian attems]

On Fri, 15 Feb 2008, Martin Ammermüller wrote:

> Setup my system with etch, whole root encrypted, seperate partition for / and 
> /home inside LuKS LVM. Can enter my LuKS passphrase on boot but it's not 
> accepted. Does not happen with 2.6.22-2. Does also happen with all 2.6.24 
> linux-images from unstable (some message about via_padlock_* modules failing 
> to 
> load with 2.6.24, i have an ATI based board).

try to regenerate your initramfs:
update-initramfs -u


the padlock messages are harmless.

Re: Please add following hint to block linux-2.6 until Beta1 is out

[Neil McGovern]

On Thu, Feb 14, 2008 at 04:49:51PM -0200, Otavio Salvador wrote:
> I hereby ask for a block on linux-2.6 source package until d-i Beta1
> gets out. If it migrates before we do the final images we can need to
> delay d-i release.
> 

Block added, but I'd like to stress the urgency of getting beta1 out so
that 2.6.24 can migrate without any further delays.

Neil
-- 
 I miss a computer physically... I can ping it, but don't know where 
it is...


signature.asc
Description: Digital signature

Bug#465838: linux-2.6: New PATA drivers are disabled

[Yauhen Kharuzhy]

Package: linux-2.6
Version: 2.6.24-4
Severity: normal


The pata_pcmcia driver is missing in latest kernel, but the ide-cs driver
doesn't work properly on my hardware (IBM ThinkPad T23).

I know that PATA drivers have been disabled due fixing bug #419458, but
this "fix" don't give a freedom of choice to users. I want to use the
ata_piix for my IDE controller, but I need to recompile this module by
hands.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=be_BY.CP1251, LC_CTYPE=be_BY.CP1251 (charmap=CP1251)
Shell: /bin/sh linked to /bin/bash



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

why the asix module disapear from linux-image-2.6.24-1-ixp4xx ?

[wahnby depinkou]

Hello,

I was using the asix module and I see that it was removed from the unstable
kernel package for nslu2.
Why ? does it move elsewhere ?

Re: Please add following hint to block linux-2.6 until Beta1 is out

[Otavio Salvador]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Neil McGovern <[EMAIL PROTECTED]> writes:

> On Thu, Feb 14, 2008 at 04:49:51PM -0200, Otavio Salvador wrote:
>> I hereby ask for a block on linux-2.6 source package until d-i Beta1
>> gets out. If it migrates before we do the final images we can need to
>> delay d-i release.
>> 
>
> Block added, but I'd like to stress the urgency of getting beta1 out so
> that 2.6.24 can migrate without any further delays.

We're all doing our best. I do also want to get 2.6.24 out and Beta2
moving as soon as possible.

Thanks a lot.

- -- 
O T A V I OS A L V A D O R
- -
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
- -
"Microsoft sells you Windows ... Linux gives
 you the whole house."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iD8DBQFHtXEuLqiZQEml+FURAm2TAKCMeA+DVpS9Pp0mqmSx7CIjKtojqQCgg9ju
m6OUh9O7N+smt6YJKL6rnjA=
=p1zO
-END PGP SIGNATURE-


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

Bug#465843: linux-image-2.6.24-1-amd64: snd-hdsp: Multiface II matrix mixer broken

[Mario Lang]

Package: linux-image-2.6.24-1-amd64
Version: 2.6.24-4
Severity: important

When I upgraded to 2.6.24 the matrix mixer of my
RME Multiface II suddenly stopped working.
The card itself seems to be operational, but
I am no longer able to route signals from apps that output
audio to the actual output channels of my card, and
some input channels can no longer be routed to certain output channels.

For instance, I can route audio from the 5th analog input
to the 1st analog output, but I can not route audio from the
6th analog input to the 2nd analog output.

There were no obvious error messages or warnings in the dmesg.

I had to downgrade to 2.6.22-3 (which I was running previously)
to get my soundcard fully operational again.

I've been told on #lad on freenode that this is reproducible
by other RME Multiface users and alsa-driver 1.0.16 is supposed
to fix it, while 1.0.15 is what 2.6.24 ships with.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages linux-image-2.6.24-1-amd64 depends on:
ii  debconf [debconf-2.0]1.5.19  Debian configuration management sy
ii  initramfs-tools [linux-initr 0.91d   tools for generating an initramfs
ii  module-init-tools3.3-pre11-4 tools for managing Linux kernel mo

linux-image-2.6.24-1-amd64 recommends no packages.

-- debconf information:
  linux-image-2.6.24-1-amd64/preinst/abort-overwrite-2.6.24-1-amd64:
  linux-image-2.6.24-1-amd64/postinst/old-dir-initrd-link-2.6.24-1-amd64: true
  linux-image-2.6.24-1-amd64/preinst/failed-to-move-modules-2.6.24-1-amd64:
  linux-image-2.6.24-1-amd64/postinst/bootloader-test-error-2.6.24-1-amd64:
  linux-image-2.6.24-1-amd64/postinst/create-kimage-link-2.6.24-1-amd64: true
  linux-image-2.6.24-1-amd64/postinst/depmod-error-initrd-2.6.24-1-amd64: false
  linux-image-2.6.24-1-amd64/preinst/overwriting-modules-2.6.24-1-amd64: true
  linux-image-2.6.24-1-amd64/postinst/bootloader-error-2.6.24-1-amd64:
  linux-image-2.6.24-1-amd64/postinst/old-initrd-link-2.6.24-1-amd64: true
  linux-image-2.6.24-1-amd64/postinst/kimage-is-a-directory:
  linux-image-2.6.24-1-amd64/preinst/bootloader-initrd-2.6.24-1-amd64: true
  linux-image-2.6.24-1-amd64/preinst/initrd-2.6.24-1-amd64:
  linux-image-2.6.24-1-amd64/prerm/removing-running-kernel-2.6.24-1-amd64: true
  linux-image-2.6.24-1-amd64/postinst/depmod-error-2.6.24-1-amd64: false
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.24-1-amd64/preinst/lilo-initrd-2.6.24-1-amd64: true
  linux-image-2.6.24-1-amd64/postinst/old-system-map-link-2.6.24-1-amd64: true
  linux-image-2.6.24-1-amd64/preinst/lilo-has-ramdisk:
  linux-image-2.6.24-1-amd64/preinst/abort-install-2.6.24-1-amd64:
  linux-image-2.6.24-1-amd64/prerm/would-invalidate-boot-loader-2.6.24-1-amd64: 
true
  linux-image-2.6.24-1-amd64/preinst/elilo-initrd-2.6.24-1-amd64: true

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Debian Developer http://debian.org/>
  .''`. | Get my public key via finger [EMAIL PROTECTED]
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-  http://delysid.org/>  http://www.staff.tugraz.at/mlang/>

Processed: severity of 465843 is normal

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.9.26
> severity 465843 normal
Bug#465843: linux-image-2.6.24-1-amd64: snd-hdsp: Multiface II matrix mixer 
broken
Severity set to `normal' from `important'

>
End of message, 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]

Future of the linux udebs

[Bastian Blank]

Hi folks

The kernel team made it possible for a long time to build the udebs from
the binary linux images. This was done be providing the possibility to
go back to every released revision with the linux-patch-debian package.
Because this needs a lot of time to get it correctly I intend to drop
this as requirement. This will destroy the possibility to use linux-2.6
as legal source for the udebs for more than the exact version.

There are at least three possibilities to handle that.

No change.
Pros: None.
Cons: No source for the udebs during development. Release versions needs to be
rebuilt anyway.

Rebuild for every release.
Pros: None.
Cons for the d-i team: This needs a lot of time with the current setup.

Build the udebs from the linux-2.6/linux-modules-extra-2.6 sources.
Pros:
- Only one step.
- Problems in the module selection can be found during the kernel development
  cycle. This includes added modules.
Cons for the kernel team:
- Another list to handle and which will kill the build if someone got
  it wrong.
- The additional configs for the build can't be checked without a real
  build.
Cons for the d-i team:
- They have to trust another instance to don't get it completely
  wrong.
- Changes in the module selection may need a full rebuild.
- Out-of-dateness of modules and buildsystem during the introdution of a
  new abiname.

Bastian

-- 
Our way is peace.
-- Septimus, the Son Worshiper, "Bread and Circuses",
   stardate 4040.7.


signature.asc
Description: Digital signature

Re: Future of the linux udebs

[Otavio Salvador]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bastian Blank <[EMAIL PROTECTED]> writes:

While I'm not nacking it right now, I nack it to happen before Beta2
with 2.6.24 gets out.

<...>
> Build the udebs from the linux-2.6/linux-modules-extra-2.6 sources.
> Pros:
> - Only one step.
> - Problems in the module selection can be found during the kernel development
>   cycle. This includes added modules.
> Cons for the kernel team:
> - Another list to handle and which will kill the build if someone got
>   it wrong.
> - The additional configs for the build can't be checked without a real
>   build.
> Cons for the d-i team:
> - They have to trust another instance to don't get it completely
>   wrong.
> - Changes in the module selection may need a full rebuild.
> - Out-of-dateness of modules and buildsystem during the introdution of a
>   new abiname.
  - Is impossible to release d-i with a different kernel from sid
without a lot of hassle
  - If a bad kernel, with a bunch of ugly bugs, gets uploaded, all d-i
development is affected

This last item is where I worry a lot. Obviously, kernel team want to
put newest kernel on sid however, when he does it, d-i will be forced
to change it too. For it to work testing images, _before_ the kernel
upload to happen, would be required to at least reduce the risk of a
kernel upload to stop all d-i development until it gets fixed.

Another thihk that I see as a _must_ is that d-i team could nack a
kernel upload. This is requred since d-i won't be allowed to diverge
from sid kernels anymore (I mean during development) and those
migrations would need to be much more coordinated with d-i RM and d-i
porters.

linux-2.6/linux-modules-extra-2.6 would build the udebs using what
list? Still using kernel-wedge?

How the uploads of kernel would be coordinated? Will kernel team allow
d-i to _nack_ a kernel upload?

- -- 
O T A V I OS A L V A D O R
- -
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
- -
"Microsoft sells you Windows ... Linux gives
 you the whole house."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iD8DBQFHtaImLqiZQEml+FURAoJEAKCrFV2EuCgLH45/zouGG0k6whkGawCgpfnp
/So/qOzYfRyGUWWmdc8u2b4=
=QBkE
-END PGP SIGNATURE-


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

Bug#464410: marked as done (cryptoroot remote unlocking: network configuration without nfs, sshd)

[Debian Bug Tracking System]

Your message dated Fri, 15 Feb 2008 15:42:02 +0100
with message-id <[EMAIL PROTECTED]>
and subject line obsoleted
has caused the Debian Bug report #464410,
regarding cryptoroot remote unlocking: network configuration without nfs, sshd
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
464410: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464410
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---

Package: initramfs-tools
Version: 0.91d
Severity: wishlist

hi!

for remote boot/remote unlocking of a cryptoroot system there should be
initrd support at least for a ssh login. i'd suggest:

move the configure_networking (from /script/functions) call from
/script/nfs to /init, after init-premount (just before maybe_break mount):
[ -n "$IPOPTS" ] && configure_networking

(off-topic but relating, so just for completeness: installer should add
an ip=... argument corresponding to the network config to the kernel
boot parameters in menu.lst in case of a cryptoroot install)

mkinitramfs has to add the respective nic-module to the initrd modules
and add the respective entry to /conf/modules if the kernel-entry in
menu.lst has boot parameters containing an ip=... argument.

mkinitramfs schould install dropbear, either just in case of a
cryptoroot setup, or in case of an ip=... kernel boot parameter.
a statically linked minimal version of dropbear probably comes to mind
first. the existing dropbear package contains a dynamically linked
version, but installing this plus the dependencies (libc6 and zlib1g)
proved to work, with a probably acceptable increase in size of the
initrd (here: 6.1m to 9.7m).

add dropbear to the configure_networking line in /init mentioned above:
[ -n "$IPOPTS" ] && configure_networking && /usr/sbin/dropbear

mkinitramfs should add a /etc/passwd with an entry for root, create
/root/.ssh, and copy an authorized_keys file there. i don't have a
conclusion yet where this authorized_keys file should come from, but
thinking of the installer again, the installer should probably create
the keypair in case of a cryptoroot install, and just save them
somewhere in /etc, probably somewhere in /etc/initramfs-tools. the same
location is probably also a good idea to put the
dropbear_[dss|rsa]_host_key files which should be copied by mkinitramfs
to /etc/dropbear (which should be generated by the installer in case of
a cryptoroot install).

this way issuing a cryptsetup luksOpen followed by a vgchange -a y, and
then killing the console's cryptsetup via ssh works.



Chris



--- End Message ---
--- Begin Message ---
obsolete wishlist-report, replaced by a new wishlist-report providing a 
patch which does the job and matches the relating patches provided for 
the other packages involved (cryptsetup, dropbear).


--- End Message ---

Bug#465901: cryptroot remote unlocking on boot feature

[debian]

Package: initramfs-tools
Version: 0.91e
Severity: wishlist
Tags: patch

this patch is part of three patches (initramfs-tools, cryptsetup, 
dropbear) which enable mkinitramfs to create initramfss that provide the 
ability to log in and unlock a cryptroot during the boot process from 
remote via ssh.


calling configure_networking from /scripts/functions might appear more 
than once, so just try if it hasn't been done/wasn't successful yet. 
check that by testing for existence of /tmp/net-$DEVICE.conf which is 
created by ipconfig.
in mkinitramfs CONFDIR is exported, as this is necessary for hooks (see 
related dropbear patch) to find the config without relying on something 
hardcoded that's otherwise (mkinitramfs) dynamic.
diff -rNc initramfs-tools.orig/mkinitramfs initramfs-tools/mkinitramfs
*** initramfs-tools.orig/mkinitramfs	2007-12-25 17:03:57.0 +0100
--- initramfs-tools/mkinitramfs	2008-02-14 14:01:07.0 +0100
***
*** 168,173 
--- 168,174 
  
  # Export environment for hook scripts.
  #
+ export CONFDIR
  export MODULESDIR
  export version
  export CONFDIR
diff -rNc initramfs-tools.orig/scripts/functions initramfs-tools/scripts/functions
*** initramfs-tools.orig/scripts/functions	2007-12-25 17:03:57.0 +0100
--- initramfs-tools/scripts/functions	2008-02-14 13:58:53.0 +0100
***
*** 273,307 
  
  configure_networking()
  {
! 	# support ip options see linux sources Documentation/nfsroot.txt
! 	case ${IPOPTS} in
! 	none|off)
! 		# Do nothing
! 		;;
! 	""|on|any)
! 		# Bring up device
! 		ipconfig ${DEVICE}
! 		;;
! 	dhcp|bootp|rarp|both)
! 		ipconfig -c ${IPOPTS} -d ${DEVICE}
! 		;;
! 	*)
! 		ipconfig -d $IPOPTS
  
! 		# grab device entry from ip option
! 		NEW_DEVICE=${IPOPTS#*:*:*:*:*:*}
! 		if [ "${NEW_DEVICE}" != "${IPOPTS}" ]; then
! 			NEW_DEVICE=${NEW_DEVICE%:*}
! 		else
! 			# wrong parse, possibly only a partial string
! 			NEW_DEVICE=
! 		fi
! 		if [ -n "${NEW_DEVICE}" ]; then
! 			DEVICE="${NEW_DEVICE}"
! 		fi
! 		;;
! 	esac
  
! 	# source relevant ipconfig output
! 	. /tmp/net-${DEVICE}.conf
  }
--- 273,310 
  
  configure_networking()
  {
! 	if [ ! -e /tmp/net-${DEVICE}.conf ]; then
  
! 		# support ip options see linux sources Documentation/nfsroot.txt
! 		case ${IPOPTS} in
! 		none|off)
! 			# Do nothing
! 			;;
! 		""|on|any)
! 			# Bring up device
! 			ipconfig ${DEVICE}
! 			;;
! 		dhcp|bootp|rarp|both)
! 			ipconfig -c ${IPOPTS} -d ${DEVICE}
! 			;;
! 		*)
! 			ipconfig -d $IPOPTS
  
! 			# grab device entry from ip option
! 			NEW_DEVICE=${IPOPTS#*:*:*:*:*:*}
! 			if [ "${NEW_DEVICE}" != "${IPOPTS}" ]; then
! NEW_DEVICE=${NEW_DEVICE%:*}
! 			else
! # wrong parse, possibly only a partial string
! NEW_DEVICE=
! 			fi
! 			if [ -n "${NEW_DEVICE}" ]; then
! DEVICE="${NEW_DEVICE}"
! 			fi
! 			;;
! 		esac
! 
! 		# source relevant ipconfig output
! 		. /tmp/net-${DEVICE}.conf
! 	fi
  }

Bug#465901: cryptroot remote unlocking on boot feature

[debian]

relating reports:

cryptsetup: 465902
dropbear: 465903



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

Re: why the asix module disapear from linux-image-2.6.24-1-ixp4xx ?

[Gordon Farquharson]

Hi Wahnby

On Fri, Feb 15, 2008 at 3:52 AM, wahnby depinkou <[EMAIL PROTECTED]> wrote:

> I was using the asix module and I see that it was removed from the unstable
> kernel package for nslu2.
> Why ? does it move elsewhere ?

It is probably just got lost in the reorganization of the config
files. I'll have a look this evening.

Gordon

-- 
Gordon Farquharson
GnuPG Key ID: 32D6D676


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

Bug#463606: Test results on Geode

[Graham]

Thanks for the report, Bill.

Based on the CPUID [1] and core speed [2], I am guessing that this is
a Geode LX 800; can you confirm this?

Have you tried running the "long NOP" test app, posted at bug 464962?

Thanks

-- graham

[1] http://www.sandpile.org/ia32/cpuid.htm
[2] http://en.wikipedia.org/wiki/Geode_(processor)



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

Bug#465901: cryptroot remote unlocking on boot feature

[maximilian attems]

On Fri, Feb 15, 2008 at 03:47:40PM +0100, [EMAIL PROTECTED] wrote:

> diff -rNc initramfs-tools.orig/mkinitramfs initramfs-tools/mkinitramfs

thanks haven't read it yet, but *please* send that it in with unified
format unified diffs are so much easier to read:

u .. unified
p .. function context

aka output
diff -pruN initramfs-tools.org/ initramfs-tools

if you want do yourself a favour of course you can clone the git repo
and use git for it aka:
(as root apt-get install git-core gitk git-email git-gui)
git clone git://git.debian.org/git/kernel/initramfs-tools.git
# add a new local branch
git checkout -b ssh
# see the diff
git diff
# hack + test + commit
git commit -a
# get the patches in mail format
git format-patch -M master
# send them over
git send-email --to [EMAIL PROTECTED] --cc [EMAIL PROTECTED] 
0001-ssh-subject.patch


i must say i'm not a big fan of shipping ssh in initramfs
enabled by default needed fixes in networking and such are of
course taken.

thanks



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

Bug#465812: linux-image-2.6.22-3-686: [Regression] LuKS passphrase not accepted anymore

[Martin Ammermüller]

On Friday 15 February 2008 11:16:58 maximilian attems wrote:
> On Fri, 15 Feb 2008, Martin Ammermüller wrote:
> > Setup my system with etch, whole root encrypted, seperate partition for /
> > and /home inside LuKS LVM. Can enter my LuKS passphrase on boot but it's
> > not accepted. Does not happen with 2.6.22-2. Does also happen with all
> > 2.6.24 linux-images from unstable (some message about via_padlock_*
> > modules failing to load with 2.6.24, i have an ATI based board).
>
> try to regenerate your initramfs:
> update-initramfs -u

Tried that for 2.6.22-3-686 and 2.6.24 with no effect. And I'm pretty sure 
that i didn't enter the passphrase wrong :) (works still with 2.6.22-2, did 
not try my luck with update-initramfs on this kernel-image, though).

Best Regards,
Martin

Re: Future of the linux udebs

[Bastian Blank]

On Fri, Feb 15, 2008 at 12:31:05PM -0200, Otavio Salvador wrote:
> While I'm not nacking it right now, I nack it to happen before Beta2
> with 2.6.24 gets out.

I did not setup a timeline yet. Because of the status of .24, it won't
get the support anyway. So .25 is the minimum.

>   - Is impossible to release d-i with a different kernel from sid
> without a lot of hassle

d-i releases are built with testing udebs. Or do you mean something
else?

| ifeq (${SUITE},UNRELEASED)
| USE_UDEBS_FROM=unstable
| else
| USE_UDEBS_FROM=lenny
| endif

>   - If a bad kernel, with a bunch of ugly bugs, gets uploaded, all d-i
> development is affected

If a bad glibc is uploaded, anything is affected. With such sort of
arguments you can kill anything because the propability that something
will get wrong is always larger than zero. We do a lot to not let really
broken things through and I don't think you will be able to catch more
problems.

>   For it to work testing images, _before_ the kernel
> upload to happen, would be required to at least reduce the risk of a
> kernel upload to stop all d-i development until it gets fixed.

We provide a snapshots archive which can be used through the whole
development cycle.

> Another thihk that I see as a _must_ is that d-i team could nack a
> kernel upload. This is requred since d-i won't be allowed to diverge
> from sid kernels anymore (I mean during development) and those
> migrations would need to be much more coordinated with d-i RM and d-i
> porters.

We coordinate the uploads on d-kernel@, for security uploads the waiting
period is usualy a lot shorter. If someone have a problem, he can speak
up and his concerns will get heard.

> linux-2.6/linux-modules-extra-2.6 would build the udebs using what
> list? Still using kernel-wedge?

They need to include the list themself, it will get version dependant.

> How the uploads of kernel would be coordinated? Will kernel team allow
> d-i to _nack_ a kernel upload?

Not for uploads which fixes bugs like CVE-2008-0600. A "nack" without
anything may also not have any effect. But if there are concerns we
should be able to find a solution which both sides can live with.

Bastian

-- 
There are some things worth dying for.
-- Kirk, "Errand of Mercy", stardate 3201.7


signature.asc
Description: Digital signature

Processed: reassign 465812 to cryptsetup

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.10.13
> reassign 465812 cryptsetup
Bug#465812: linux-image-2.6.22-3-686: [Regression] LuKS passphrase not accepted 
anymore
Bug reassigned from package `linux-image-2.6.22-3-686' to `cryptsetup'.

>
End of message, 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: Future of the linux udebs

[Otavio Salvador]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bastian Blank <[EMAIL PROTECTED]> writes:

> On Fri, Feb 15, 2008 at 12:31:05PM -0200, Otavio Salvador wrote:
<...>
>>   - Is impossible to release d-i with a different kernel from sid
>> without a lot of hassle
>
> d-i releases are built with testing udebs. Or do you mean something
> else?

Not during development cycle.

And the udebs on testing migrated to it from sid. I hope to not need
to do uploads to t-p-u for d-i kernel ;-)

<...>
>>   - If a bad kernel, with a bunch of ugly bugs, gets uploaded, all d-i
>> development is affected
>
> If a bad glibc is uploaded, anything is affected. With such sort of
> arguments you can kill anything because the propability that something
> will get wrong is always larger than zero. We do a lot to not let really
> broken things through and I don't think you will be able to catch more
> problems.

Right. But it is a cons since currently we only migrate to the new
kernel when it's already widly tested on sid.

>>   For it to work testing images, _before_ the kernel
>> upload to happen, would be required to at least reduce the risk of a
>> kernel upload to stop all d-i development until it gets fixed.
>
> We provide a snapshots archive which can be used through the whole
> development cycle.

Yes, right. We'd need to setup some way to get d-i builds against
those images and do testing using it before major kernel version
uploads.

>> Another thihk that I see as a _must_ is that d-i team could nack a
>> kernel upload. This is requred since d-i won't be allowed to diverge
>> from sid kernels anymore (I mean during development) and those
>> migrations would need to be much more coordinated with d-i RM and d-i
>> porters.
>
> We coordinate the uploads on d-kernel@, for security uploads the waiting
> period is usualy a lot shorter. If someone have a problem, he can speak
> up and his concerns will get heard.

I'm not wondering about security uploads but about ABI changes and
major kernel version updates. Those would need to be coordinated on
debian-boot too.

I guess that a notice about upload, few days before, to debian-boot ml
should be enough, for ABI changes. For major versions, we'd need much
larger coordination since it would affect whole d-i.

Obviously, as already spot by you, we can get images built against the
kernel snapshots but we'd need  to get an infrastructure to get d-i
images built against it and tested before approval for the kernel
upload.

>> linux-2.6/linux-modules-extra-2.6 would build the udebs using what
>> list? Still using kernel-wedge?
>
> They need to include the list themself, it will get version dependant.

So your idea is to this list be placed inside each source package?

This means kernel-wedge will be useless and _any_ change would be need
to be done on kernel team svn. This is a big regression from my POV
since d-i team does need to be able to change the list by himself.

>> How the uploads of kernel would be coordinated? Will kernel team allow
>> d-i to _nack_ a kernel upload?
>
> Not for uploads which fixes bugs like CVE-2008-0600. A "nack" without
> anything may also not have any effect. But if there are concerns we
> should be able to find a solution which both sides can live with.

I agree that security uploads are exception here however any other ABI
or major version update would must to be acked by d-i team. This looks
logical since we'll be directly affected by it and the installer might
break.

- -- 
O T A V I OS A L V A D O R
- -
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
- -
"Microsoft sells you Windows ... Linux gives
 you the whole house."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iD8DBQFHtboLLqiZQEml+FURAonUAJwNMZNYsOEqYLvNFrf+brBOMdOvXgCghMdX
Tr/IltraJ/QKXpLXLlRwVis=
=9+UD
-END PGP SIGNATURE-


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

Bug#465812: linux-image-2.6.22-3-686: [Regression] LuKS passphrase not accepted anymore

[maximilian attems]

On Fri, 15 Feb 2008, Martin Ammermüller wrote:

> 
> Tried that for 2.6.22-3-686 and 2.6.24 with no effect. And I'm pretty sure 
> that i didn't enter the passphrase wrong :) (works still with 2.6.22-2, did 
> not try my luck with update-initramfs on this kernel-image, though).

well then it can only be a cryptetup bug of newer version.
as newer cryptsetup land on both of those.

Bug#463606: Test results on Geode

[Bill Gatliff]

Graham wrote:

Thanks for the report, Bill.

Based on the CPUID [1] and core speed [2], I am guessing that this is
a Geode LX 800; can you confirm this?
  


Correct.  The board is an Advantech PCM3353:

http://www.advantech.com/applied/products/PCM-3353.pdf


Have you tried running the "long NOP" test app, posted at bug 464962?
  


Nope.  I'll try to get to that.


b.g.

--
Bill Gatliff
[EMAIL PROTECTED]





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

Bug#465901: [PATCH] 465901 (cryptroot remote unlocking on boot feature)

[debian]

From: <[EMAIL PROTECTED]>

---
 mkinitramfs   |1 +
 scripts/functions |   63 +++-
 2 files changed, 34 insertions(+), 30 deletions(-)

diff --git a/mkinitramfs b/mkinitramfs
index 06d2149..13219af 100755
--- a/mkinitramfs
+++ b/mkinitramfs
@@ -168,6 +168,7 @@ DPKG_ARCH=`dpkg --print-installation-architecture`
 
 # Export environment for hook scripts.
 #
+export CONFDIR
 export MODULESDIR
 export version
 export CONFDIR
diff --git a/scripts/functions b/scripts/functions
index fdd808f..bbfb2b8 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -273,35 +273,38 @@ parse_numeric() {
 
 configure_networking()
 {
-   # support ip options see linux sources Documentation/nfsroot.txt
-   case ${IPOPTS} in
-   none|off)
-   # Do nothing
-   ;;
-   ""|on|any)
-   # Bring up device
-   ipconfig ${DEVICE}
-   ;;
-   dhcp|bootp|rarp|both)
-   ipconfig -c ${IPOPTS} -d ${DEVICE}
-   ;;
-   *)
-   ipconfig -d $IPOPTS
-
-   # grab device entry from ip option
-   NEW_DEVICE=${IPOPTS#*:*:*:*:*:*}
-   if [ "${NEW_DEVICE}" != "${IPOPTS}" ]; then
-   NEW_DEVICE=${NEW_DEVICE%:*}
-   else
-   # wrong parse, possibly only a partial string
-   NEW_DEVICE=
-   fi
-   if [ -n "${NEW_DEVICE}" ]; then
-   DEVICE="${NEW_DEVICE}"
-   fi
-   ;;
-   esac
+   if [ ! -e /tmp/net-${DEVICE}.conf ]; then
 
-   # source relevant ipconfig output
-   . /tmp/net-${DEVICE}.conf
+   # support ip options see linux sources Documentation/nfsroot.txt
+   case ${IPOPTS} in
+   none|off)
+   # Do nothing
+   ;;
+   ""|on|any)
+   # Bring up device
+   ipconfig ${DEVICE}
+   ;;
+   dhcp|bootp|rarp|both)
+   ipconfig -c ${IPOPTS} -d ${DEVICE}
+   ;;
+   *)
+   ipconfig -d $IPOPTS
+
+   # grab device entry from ip option
+   NEW_DEVICE=${IPOPTS#*:*:*:*:*:*}
+   if [ "${NEW_DEVICE}" != "${IPOPTS}" ]; then
+   NEW_DEVICE=${NEW_DEVICE%:*}
+   else
+   # wrong parse, possibly only a partial string
+   NEW_DEVICE=
+   fi
+   if [ -n "${NEW_DEVICE}" ]; then
+   DEVICE="${NEW_DEVICE}"
+   fi
+   ;;
+   esac
+
+   # source relevant ipconfig output
+   . /tmp/net-${DEVICE}.conf
+   fi
 }
-- 
1.5.3.8




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

Bug#465901: [PATCH] 465901 (cryptroot remote unlocking on boot feature)

[maximilian attems]

On Fri, 15 Feb 2008, [EMAIL PROTECTED] wrote:

> From: <[EMAIL PROTECTED]>
> 

ok read the description from the other mail,
for quicker response description above patch helps :)
> ---
>  mkinitramfs   |1 +
>  scripts/functions |   63 +++-
>  2 files changed, 34 insertions(+), 30 deletions(-)
> 
> diff --git a/mkinitramfs b/mkinitramfs
> index 06d2149..13219af 100755
> --- a/mkinitramfs
> +++ b/mkinitramfs
> @@ -168,6 +168,7 @@ DPKG_ARCH=`dpkg --print-installation-architecture`
>  
>  # Export environment for hook scripts.
>  #
> +export CONFDIR
>  export MODULESDIR
>  export version
>  export CONFDIR

why should it be exported twice?

> diff --git a/scripts/functions b/scripts/functions
> index fdd808f..bbfb2b8 100644
> --- a/scripts/functions
> +++ b/scripts/functions
> @@ -273,35 +273,38 @@ parse_numeric() {
>  
>  configure_networking()
>  {
> - # support ip options see linux sources Documentation/nfsroot.txt
> - case ${IPOPTS} in
> - none|off)
> - # Do nothing
> - ;;
> - ""|on|any)
> - # Bring up device
> - ipconfig ${DEVICE}
> - ;;
> - dhcp|bootp|rarp|both)
> - ipconfig -c ${IPOPTS} -d ${DEVICE}
> - ;;
> - *)
> - ipconfig -d $IPOPTS
> -
> - # grab device entry from ip option
> - NEW_DEVICE=${IPOPTS#*:*:*:*:*:*}
> - if [ "${NEW_DEVICE}" != "${IPOPTS}" ]; then
> - NEW_DEVICE=${NEW_DEVICE%:*}
> - else
> - # wrong parse, possibly only a partial string
> - NEW_DEVICE=
> - fi
> - if [ -n "${NEW_DEVICE}" ]; then
> - DEVICE="${NEW_DEVICE}"
> - fi
> - ;;
> - esac
> + if [ ! -e /tmp/net-${DEVICE}.conf ]; then

i prefer the more readable version at the start of the function:

# networking already configured thus bail out
[ -e /tmp/net-${DEVICE}.conf ] && return 0

care to resend that hook?



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

Bug#338459: marked as done (On an HP nx6125, ACPI thermal events are not processed until one does an acpi -t)

[Debian Bug Tracking System]

Your message dated Fri, 15 Feb 2008 19:47:28 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Re: On an HP nx6125, ACPI thermal events are not processed 
until one does an acpi -t
has caused the Debian Bug report #338459,
regarding On an HP nx6125, ACPI thermal events are not processed until one does 
an acpi -t
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
338459: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338459
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---

Package: linux-image-2.6.12-1-amd64-k8
  Version: 2.6.12-1 (and I suspect also later kernels)

Hardware Environment: HP nx6125 (AMD Turion ML 34, ATI Radeon express 200M
chipset, onboard ATI X300)

Software Environment: Kernel 2.6.12-1-amd64-k8 (booting with no_timer_check to 
avoid double timer interrupts), Debian amd64 (testing/unstable), WM = KDE 
3.4.2. 

Problem Description: ACPI thermal events rarely get processed, especially 
under moderate to high CPU load. This results in *no* or erratic fan use and 
potential (cumulative) damage to the machine/electronics. However, if the CPU 
temperature exceeds a thermal trip point and then one issues a cat
/proc/acpi/thermal_zone/TZ?/temperature or an acpi -t, then, after a brief
machine pause, the thermal event is processed by the kernel and the fans
respond. This can be observed by stopping acpid and doing a cat
/proc/acpi/event, which gives the most graphic evidence. A further and more
detailed desciption/diagnosis of the problem can be found here ==>
http://lists.debian.org/debian-amd64/2005/10/msg01002.html

Steps to reproduce: With a warm processor < 58 degrees C (less than first
thermal trip point), run glxgears and wait about a minute or so. Your fan will
90% of the time not kick in. Then execute an acpi -t or a 
cat /proc/acpi/thermal_zone/TZ?/temperature and almost immediately you will 
observe that (i) at least one of your thermal trip points have been exceeded 
and (ii) as a response to the cat command, the fans immediately turn on. 
Visual evidence can be had by first, before you do anything, stopping acpid 
and doing a cat /proc/acpi/event (as root). Then do the above procedure. You 
will observe no thermal event register *until* you do the cat or acpi -t.
 
Background info: I am using Debian GNU/Linux 3.1 (testing/unstable) with 
kernel 2.6.12-1-amd64-k8. I have also tried vanilla kernels from 
(www.kernel.org) up to 2.6.14.1 and all exhibit this same problem. I have 
reported this bug to bugzilla.kernel.org (bug # 5534), but nothing has been 
done as yet.

I have looked very briefly at the amd64 acpi thermal code and it seems that 
the behaviour is to poll the thermal zones (TZs) at various time intervals (I 
could be wrong). My guess is that somehow the time interval calculation gives 
a time interval which is too large and hence the kernel seldom polls the TZs. 
I will gladly provide other info if required. I'd really like to get this bug 
fixed.


Richard
-- 
Richard Mace
School of Physics, University of KwaZulu-Natal, Howard College Campus
Durban 4041, South Africa
Tel.: +27 (0)31 260 1402FAX: +27 (0)31 261 6550

Please find our disclaimer at http://www.ukzn.ac.za/disclaimer

<<<>>>

--- End Message ---
--- Begin Message ---
Version: 2.6.22-1

newer upstream has support for it.


--- End Message ---

Bug#346604: marked as done (kernel errors after reboot)

[Debian Bug Tracking System]

Your message dated Fri, 15 Feb 2008 19:51:17 +0100
with message-id <[EMAIL PROTECTED]>
and subject line ALC880 errors
has caused the Debian Bug report #346604,
regarding kernel errors after reboot
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
346604: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346604
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: linux-image-2.6.14-2-686
Version: 2.6.14-7

I have ALC880. When turn on machine it works fine. kern.log:
"Jan  9 03:20:07 newarrow kernel: hda_codec: Unknown model for ALC880, trying 
auto-probe from BIOS...
Jan  9 03:20:07 newarrow kernel: hda_codec: Cannot set up configuration from 
BIOS.  Using 3-stack mode..."

After reboot i have no sound. kern.log:
"Jan  9 03:04:36 newarrow kernel: hda_codec: Unknown model for ALC880, trying 
auto-probe from BIOS...
Jan  9 03:04:36 newarrow kernel: hda_codec: num_steps = 0 for NID=0x8
Jan  9 03:04:36 newarrow last message repeated 3 times
Jan  9 03:04:36 newarrow kernel: hda_codec: num_steps = 0 for NID=0xb
Jan  9 03:04:36 newarrow last message repeated 19 times"

If i reboot again, i have same probs. this happens untill i halt machine. Then, 
it works fine again till next reboot.

I am using Debian GNU/Linux 3.1 with few upgrades from testing: alsa-base 
1.0.10-3, libc6 2.3.5-6 (and its dependences) and linux-image-2.6.14-2-686 from 
unstable.

Sergey Nivarov


--- End Message ---
--- Begin Message ---
Version: 2.6.22-1

> "Jan  9 03:20:07 newarrow kernel: hda_codec: Unknown model for ALC880,
> trying auto-probe from BIOS...
> Jan  9 03:20:07 newarrow kernel: hda_codec: Cannot set up configuration
> from BIOS.  Using 3-stack mode..."

certainly fixed in newer alsa, thus closing.


--- End Message ---

Bug#465901: [PATCH] 465901 (cryptroot remote unlocking on boot feature)

[debian]

+export CONFDIR
 export MODULESDIR
 export version
 export CONFDIR


why should it be exported twice?


just to _really_ be sure... ;)
no, honestly, i have no idea why i thought that was missing. probably 
got confused with the /scripts/*/* scripts where it's hardcoded.



i prefer the more readable version at the start of the function:

# networking already configured thus bail out
[ -e /tmp/net-${DEVICE}.conf ] && return 0

care to resend that hook?


done



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

Bug#465901: [PATCH] configure_network: do nothing if device has been configured already

[debian]

From: <[EMAIL PROTECTED]>

---
 scripts/functions |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/scripts/functions b/scripts/functions
index fdd808f..b4bd8cd 100644
--- a/scripts/functions
+++ b/scripts/functions
@@ -273,6 +273,9 @@ parse_numeric() {
 
 configure_networking()
 {
+   # networking already configured thus bail out
+   [ -e /tmp/net-${DEVICE}.conf ] && return 0
+
# support ip options see linux sources Documentation/nfsroot.txt
case ${IPOPTS} in
none|off)
-- 
1.5.3.8




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

Re: Changes for 2.6.25

[Nate Carlson]

On Thu, 14 Feb 2008, Bastian Blank wrote:
I intend to do the following changes to the linux-2.6 core before 
2.6.25.


Just curious - any ETA on a 2.6.25-rc in the kernel archive? I see that 
it's in trunk, but don't want to build my own yet.  ;)


[BTW - are there a set of instructions out there on the 'proper' way to 
build from trunk, to include the SVN number, etc?]



| nate carlson | [EMAIL PROTECTED] | http://www.natecarlson.com |
|   depriving some poor village of its idiot since 1981|



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

Re: Please add following hint to block linux-2.6 until Beta1 is out

[Philippe Cloutier]

Le February 15, 2008 05:15:16 am maximilian attems, vous avez écrit :
> On Thu, 14 Feb 2008, Philippe Cloutier wrote:
> > > that is totally untrue.
> > > linux-2.6 always needs hint from the release team to migrate.
> > > properly set up it can happen in less then a week.
> >
> > What do you mean? What "it" can happen in less than one week?
>
> omg, what are we talking about?
> migration of linux-2.6 to testing.
OMG, we were talking about migration of Linux 2.6.24 to testing.
>
> i repeat that with proper urgency hints from the release team
> linux-2.6 can be in a week in testing.
Of course, linux-2.6 can migrate in less than a week if there's an urgent 
update needed, but we were talking about 2.6.24, which has no such urgency.

Processed: Re: [PATCH] configure_network: do nothing if device has been configured already

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> tags 465901 pending
Bug#465901: cryptroot remote unlocking on boot feature
Tags were: patch
Tags added: pending

> 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#353679: marked as done (linux-image-2.6.15-1-686 can't boot from partitioned RAID1 (partitions not discovered))

[Debian Bug Tracking System]

Your message dated Fri, 15 Feb 2008 19:53:47 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Re: linux-image-2.6.15-1-686 can't boot from partitioned RAID1 
(partitions not discovered)
has caused the Debian Bug report #353679,
regarding linux-image-2.6.15-1-686 can't boot from partitioned RAID1 
(partitions not discovered)
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
353679: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=353679
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: linux-image-2.6.15-1-686
Version: 2.6.15-4
Severity: normal


Problem:
For a file server, we want to have everything on sw RAID1.
Having /home on a raid1 made from /dev/sda and /dev/sdb works fine.
�(Note that I used the whole devices not partitions.  So no
"raid autodetect" partition type)

The machine in question also have /dev/hda and /dev/hdb on
which I want to install linux on raid1, with several partitions.

The cumbersome way is to use partitions and create one md device for /, 
one for /usr, one for /var, one for swap, and one for /usr/src.  
I know this will work though.

The ideal way is to create a partitionable md device from /dev/hda+/dev/hdb,
and then partition this md device into several components.

The problem with this, is that the initrd does not sufficiently recognize
such a setup, so I can't have root on the partitioned md device.

While testing, I have been using a plain root on /dev/hda1, and a
raid1 in degraded mode on /dev/hdb.  I have noticed that the
initrd seems to detect the raid1 on hdb, but does not run mdadm
in the way required to detect the partitions on the md device.

Therefore, I can't have root on /dev/md1p1 as I hope.


The problem will probably not be solved in time for this server,
which will use a more cumbersome setup lots of little md devices instead.

But I am interested in working with debian developers to improve this
for the future.  I have a home machine where I can experiment with
partitionable md device and even try booting from them. (That machine
will have to use a amd64 kernel though.)

I could use some advice on changing an initrd - the simple and 
hurried approach of unpacking the existing one with gzip+cpio, 
adding an mdadm command and repacking with cpio+gzip didn't work.  

Anyway, a general solution for this problem probably shouldn't 
hardcode an mdadm command either.  Ideally, the partitionable
md device(s) should be detected and have the partitions recognized
because they exist.  I am interested in looking at this,
unless someone else already is busy doing it.  Is there
some documentation on the proper way to change the initrd,
so that the changes might get merged back for the benefit
of others?


Helge Hafting

-- System Information:
Removed, for we don't run email on the server in question. Reportbug
ran on a different machine. The server has kernel 2.6.15-1-686 
from debian, and runs debian testing.  The risk of running 'testing'
on this server is ok.

--- End Message ---
--- Begin Message ---

not a kernel bug, if still reproducible in unstable,
report against mdadm, closing as since quite some
initramfs work happend.


--- End Message ---

Bug#465901: cryptroot remote unlocking on boot feature

[debian]

[...]

git send-email --to [EMAIL PROTECTED] --cc [EMAIL PROTECTED] 
0001-ssh-subject.patch


ok thanks for directions


i must say i'm not a big fan of shipping ssh in initramfs
enabled by default needed fixes in networking and such are of
course taken.


the hook script in the dropbear patch will only add dropbear to the 
initramfs if it's explicitly enabled (which it isn't by default), or a 
cryptroot is detected (and dropbear isn't explicitly disabled).
adding to the initramfs is certainly generally to be avoided, but not 
being able to bring a machine up again from remote is quite some 
motivation, i guess ;) plus it turns out the increase in size and 
complexity is a lot less than (at least i) expected.


Chris



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

Bug#336183: marked as done (linux-source-2.6.12: Partitions not detected on Software RAID)

[Debian Bug Tracking System]

Your message dated Fri, 15 Feb 2008 19:46:09 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Re: linux-source-2.6.12: Partitions not detected on Software 
RAID
has caused the Debian Bug report #336183,
regarding linux-source-2.6.12: Partitions not detected on Software RAID
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
336183: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336183
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: linux-source-2.6.12
Version: 2.6.12-10
Severity: normal


Starting 2 (or 1) single device RAID arrays with following script does not 
result
in the partitions being detected, and therefore they do not appear in sysfs or 
/dev.

losetup /dev/loop6 gpt.img
losetup /dev/loop7 mbr.img

mdadm -A -a /dev/md_d0 /dev/loop6
mdadm -A -a /dev/md_d1 /dev/loop7

Using the w command in fdisk causes the partitions to be detected.

The RAID arrays were created like:
mdadm --create -a /dev/md_d0 --force --level=linear --raid-devices=1 /dev/loop6


PS. This is going to be used for testing software with uses the sysfs
and ioctl interfaces to read partition infomation.

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

Versions of packages linux-source-2.6.12 depends on:
ii  binutils 2.16.1cvs20050902-1 The GNU assembler, linker and bina
ii  bzip21.0.2-10high-quality block-sorting file co
ii  coreutils [fileutils 5.2.1-2.1   The GNU core utilities
ii  fileutils5.2.1-2.1   The GNU file management utilities 

Versions of packages linux-source-2.6.12 recommends:
ii  gcc   4:4.0.2-1  The GNU C compiler
ii  libc6-dev [libc-dev]  2.3.5-7GNU C Library: Development Librari
ii  make  3.80-11The GNU version of the "make" util

-- no debconf information

--- End Message ---
--- Begin Message ---
closing as if this still happens this is a userspace mdadm
trouble and not a kernel problem.


--- End Message ---

Bug#463610: closed by Bastian Blank <[EMAIL PROTECTED]> (Re: Bug#463610: linux-image-2.6.24-1-686: DVD Burn is very very slow.)

[David Keegan]

Hi,

This is still a problem with debian package linux-image-2.6.24-1-686
downloaded 14 February 2008 which aptitude show indicates is version
2.6.24-4.

Regards,
David Keegan.
-- 



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

linux-2.6_2.6.18.dfsg.1-18etch1_i386.changes ACCEPTED

[Debian Installer]

Accepted:
linux-headers-2.6.18-6-486_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-486_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6-686-bigmem_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-686-bigmem_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6-686_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-686_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6-all-i386_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-all-i386_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6-all_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-all_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6-amd64_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-amd64_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6-k7_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-k7_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6-vserver-686_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-vserver-686_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6-vserver-k7_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-vserver-k7_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6-vserver_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-vserver_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6-xen-686_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-xen-686_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6-xen-vserver-686_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-xen-vserver-686_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6-xen-vserver_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-xen-vserver_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6-xen_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-xen_2.6.18.dfsg.1-18etch1_i386.deb
linux-headers-2.6.18-6_2.6.18.dfsg.1-18etch1_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-6_2.6.18.dfsg.1-18etch1_i386.deb
linux-image-2.6.18-6-486_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-486_2.6.18.dfsg.1-18etch1_i386.deb
linux-image-2.6.18-6-686-bigmem_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-686-bigmem_2.6.18.dfsg.1-18etch1_i386.deb
linux-image-2.6.18-6-686_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-686_2.6.18.dfsg.1-18etch1_i386.deb
linux-image-2.6.18-6-amd64_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-amd64_2.6.18.dfsg.1-18etch1_i386.deb
linux-image-2.6.18-6-k7_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-k7_2.6.18.dfsg.1-18etch1_i386.deb
linux-image-2.6.18-6-vserver-686_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-vserver-686_2.6.18.dfsg.1-18etch1_i386.deb
linux-image-2.6.18-6-vserver-k7_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-vserver-k7_2.6.18.dfsg.1-18etch1_i386.deb
linux-image-2.6.18-6-xen-686_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-xen-686_2.6.18.dfsg.1-18etch1_i386.deb
linux-image-2.6.18-6-xen-vserver-686_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-xen-vserver-686_2.6.18.dfsg.1-18etch1_i386.deb
linux-modules-2.6.18-6-xen-686_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-modules-2.6.18-6-xen-686_2.6.18.dfsg.1-18etch1_i386.deb
linux-modules-2.6.18-6-xen-vserver-686_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/linux-modules-2.6.18-6-xen-vserver-686_2.6.18.dfsg.1-18etch1_i386.deb
xen-linux-system-2.6.18-6-xen-686_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/xen-linux-system-2.6.18-6-xen-686_2.6.18.dfsg.1-18etch1_i386.deb
xen-linux-system-2.6.18-6-xen-vserver-686_2.6.18.dfsg.1-18etch1_i386.deb
  to 
pool/main/l/linux-2.6/xen-linux-system-2.6.18-6-xen-vserver-686_2.6.18.dfsg.1-18etch1_i386.deb


Override entries for your package:
linux-headers-2.6.18-6-486_2.6.18.dfsg.1-18etch1_i386.deb - optional devel
linux-headers-2.6.18-6-686-bigmem_2.6.18.dfsg.1-18etch1_i386.deb - optional 
devel
linux-headers-2.6.18-6-686_2.6.18.dfsg.1-18etch1_i386.deb - optional devel
linux-headers-2.6.18-6-all-i386_2.6.18.dfsg.1-18etch1_i386.deb - optional devel
linux-headers-2.6.18-6-all_2.6.18.dfsg.1-18etch1_i386.deb - optional devel
linux-headers-2.6.18-6-amd64_2.6.18.dfsg.1-18etch1_i386.deb - optional devel
linux-headers-2.6.18-6-k7_2.6.18.dfsg.1-18etch1_i386.deb - optional devel
linux-headers-2.6.18-6-vserver-686_2.6.18.dfsg.1-18etch1_i386.deb - optional 
devel
linux-headers-2.6.18-6-vserver-k7_2.6.18.dfsg.1-18etch1_i386.deb - optional

linux-2.6_2.6.18.dfsg.1-18etch1_amd64.changes ACCEPTED

[Debian Installer]

Accepted:
linux-2.6_2.6.18.dfsg.1-18etch1.diff.gz
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-18etch1.diff.gz
linux-2.6_2.6.18.dfsg.1-18etch1.dsc
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-18etch1.dsc
linux-doc-2.6.18_2.6.18.dfsg.1-18etch1_all.deb
  to pool/main/l/linux-2.6/linux-doc-2.6.18_2.6.18.dfsg.1-18etch1_all.deb
linux-headers-2.6.18-6-all-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-all-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
linux-headers-2.6.18-6-all_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-all_2.6.18.dfsg.1-18etch1_amd64.deb
linux-headers-2.6.18-6-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
linux-headers-2.6.18-6-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
linux-headers-2.6.18-6-vserver_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-vserver_2.6.18.dfsg.1-18etch1_amd64.deb
linux-headers-2.6.18-6-xen-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-xen-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
linux-headers-2.6.18-6-xen-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-xen-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
linux-headers-2.6.18-6-xen-vserver_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-xen-vserver_2.6.18.dfsg.1-18etch1_amd64.deb
linux-headers-2.6.18-6-xen_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-xen_2.6.18.dfsg.1-18etch1_amd64.deb
linux-headers-2.6.18-6_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6_2.6.18.dfsg.1-18etch1_amd64.deb
linux-image-2.6.18-6-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
linux-image-2.6.18-6-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
linux-image-2.6.18-6-xen-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-xen-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
linux-image-2.6.18-6-xen-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-xen-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
linux-manual-2.6.18_2.6.18.dfsg.1-18etch1_all.deb
  to pool/main/l/linux-2.6/linux-manual-2.6.18_2.6.18.dfsg.1-18etch1_all.deb
linux-modules-2.6.18-6-xen-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-modules-2.6.18-6-xen-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
linux-modules-2.6.18-6-xen-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/linux-modules-2.6.18-6-xen-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
linux-patch-debian-2.6.18_2.6.18.dfsg.1-18etch1_all.deb
  to 
pool/main/l/linux-2.6/linux-patch-debian-2.6.18_2.6.18.dfsg.1-18etch1_all.deb
linux-source-2.6.18_2.6.18.dfsg.1-18etch1_all.deb
  to pool/main/l/linux-2.6/linux-source-2.6.18_2.6.18.dfsg.1-18etch1_all.deb
linux-support-2.6.18-6_2.6.18.dfsg.1-18etch1_all.deb
  to pool/main/l/linux-2.6/linux-support-2.6.18-6_2.6.18.dfsg.1-18etch1_all.deb
linux-tree-2.6.18_2.6.18.dfsg.1-18etch1_all.deb
  to pool/main/l/linux-2.6/linux-tree-2.6.18_2.6.18.dfsg.1-18etch1_all.deb
xen-linux-system-2.6.18-6-xen-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/xen-linux-system-2.6.18-6-xen-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
xen-linux-system-2.6.18-6-xen-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb
  to 
pool/main/l/linux-2.6/xen-linux-system-2.6.18-6-xen-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb


Override entries for your package:
linux-2.6_2.6.18.dfsg.1-18etch1.dsc - optional devel
linux-doc-2.6.18_2.6.18.dfsg.1-18etch1_all.deb - optional doc
linux-headers-2.6.18-6-all-amd64_2.6.18.dfsg.1-18etch1_amd64.deb - optional 
devel
linux-headers-2.6.18-6-all_2.6.18.dfsg.1-18etch1_amd64.deb - optional devel
linux-headers-2.6.18-6-amd64_2.6.18.dfsg.1-18etch1_amd64.deb - optional devel
linux-headers-2.6.18-6-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb - optional 
devel
linux-headers-2.6.18-6-vserver_2.6.18.dfsg.1-18etch1_amd64.deb - optional devel
linux-headers-2.6.18-6-xen-amd64_2.6.18.dfsg.1-18etch1_amd64.deb - optional 
devel
linux-headers-2.6.18-6-xen-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb - 
optional devel
linux-headers-2.6.18-6-xen-vserver_2.6.18.dfsg.1-18etch1_amd64.deb - optional 
devel
linux-headers-2.6.18-6-xen_2.6.18.dfsg.1-18etch1_amd64.deb - optional devel
linux-headers-2.6.18-6_2.6.18.dfsg.1-18etch1_amd64.deb - optional devel
linux-image-2.6.18-6-amd64_2.6.18.dfsg.1-18etch1_amd64.deb - optional admin
linux-image-2.6.18-6-vserver-amd64_2.6.18.dfsg.1-18etch1_amd64.deb - optional 
admin
linux-image-2.6.18-6-xen-am

linux-2.6_2.6.18.dfsg.1-18etch1_sparc.changes ACCEPTED

[Debian Installer]

Accepted:
linux-headers-2.6.18-6-all-sparc_2.6.18.dfsg.1-18etch1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-all-sparc_2.6.18.dfsg.1-18etch1_sparc.deb
linux-headers-2.6.18-6-all_2.6.18.dfsg.1-18etch1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-all_2.6.18.dfsg.1-18etch1_sparc.deb
linux-headers-2.6.18-6-sparc32_2.6.18.dfsg.1-18etch1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-sparc32_2.6.18.dfsg.1-18etch1_sparc.deb
linux-headers-2.6.18-6-sparc64-smp_2.6.18.dfsg.1-18etch1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-sparc64-smp_2.6.18.dfsg.1-18etch1_sparc.deb
linux-headers-2.6.18-6-sparc64_2.6.18.dfsg.1-18etch1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-sparc64_2.6.18.dfsg.1-18etch1_sparc.deb
linux-headers-2.6.18-6-vserver-sparc64_2.6.18.dfsg.1-18etch1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-vserver-sparc64_2.6.18.dfsg.1-18etch1_sparc.deb
linux-headers-2.6.18-6-vserver_2.6.18.dfsg.1-18etch1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6-vserver_2.6.18.dfsg.1-18etch1_sparc.deb
linux-headers-2.6.18-6_2.6.18.dfsg.1-18etch1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-6_2.6.18.dfsg.1-18etch1_sparc.deb
linux-image-2.6.18-6-sparc32_2.6.18.dfsg.1-18etch1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-sparc32_2.6.18.dfsg.1-18etch1_sparc.deb
linux-image-2.6.18-6-sparc64-smp_2.6.18.dfsg.1-18etch1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-sparc64-smp_2.6.18.dfsg.1-18etch1_sparc.deb
linux-image-2.6.18-6-sparc64_2.6.18.dfsg.1-18etch1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-sparc64_2.6.18.dfsg.1-18etch1_sparc.deb
linux-image-2.6.18-6-vserver-sparc64_2.6.18.dfsg.1-18etch1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-6-vserver-sparc64_2.6.18.dfsg.1-18etch1_sparc.deb


Override entries for your package:
linux-headers-2.6.18-6-all-sparc_2.6.18.dfsg.1-18etch1_sparc.deb - optional 
devel
linux-headers-2.6.18-6-all_2.6.18.dfsg.1-18etch1_sparc.deb - optional devel
linux-headers-2.6.18-6-sparc32_2.6.18.dfsg.1-18etch1_sparc.deb - optional devel
linux-headers-2.6.18-6-sparc64-smp_2.6.18.dfsg.1-18etch1_sparc.deb - optional 
devel
linux-headers-2.6.18-6-sparc64_2.6.18.dfsg.1-18etch1_sparc.deb - optional devel
linux-headers-2.6.18-6-vserver-sparc64_2.6.18.dfsg.1-18etch1_sparc.deb - 
optional devel
linux-headers-2.6.18-6-vserver_2.6.18.dfsg.1-18etch1_sparc.deb - optional devel
linux-headers-2.6.18-6_2.6.18.dfsg.1-18etch1_sparc.deb - optional devel
linux-image-2.6.18-6-sparc32_2.6.18.dfsg.1-18etch1_sparc.deb - optional admin
linux-image-2.6.18-6-sparc64-smp_2.6.18.dfsg.1-18etch1_sparc.deb - optional 
admin
linux-image-2.6.18-6-sparc64_2.6.18.dfsg.1-18etch1_sparc.deb - optional admin
linux-image-2.6.18-6-vserver-sparc64_2.6.18.dfsg.1-18etch1_sparc.deb - optional 
admin



Thank you for your contribution to Debian.


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

Bug#460337: marked as done (Fix ethernet interrupts for Cobalt RaQ1)

[Debian Bug Tracking System]

Your message dated Fri, 15 Feb 2008 19:53:09 +
with message-id <[EMAIL PROTECTED]>
and subject line Bug#460337: fixed in fai-kernels 1.17+etch.18etch1
has caused the Debian Bug report #460337,
regarding Fix ethernet interrupts for Cobalt RaQ1
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
460337: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460337
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: linux-2.6
Version: 2.6.18.dfsg.1-12
Severity: important

The network interface on Cobalt RaQ1 has not worked since we moved
from 2.4 to 2.6.  There were quite a few reports about this on the
debian-mips list.  Thomas Bogendoerfer just posted a patch for this
problem.


- Forwarded message from Thomas Bogendoerfer <[EMAIL PROTECTED]> -

From: Thomas Bogendoerfer <[EMAIL PROTECTED]>
Subject: [PATCH] Fix ethernet interrupts for Cobalt RaQ1
Date: Sat, 12 Jan 2008 00:25:14 +0100 (CET)
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]

RAQ1 uses the same interrupt routing as qube2.

Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
---

 arch/mips/pci/fixup-cobalt.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/mips/pci/fixup-cobalt.c b/arch/mips/pci/fixup-cobalt.c
index f7df114..9553b14 100644
--- a/arch/mips/pci/fixup-cobalt.c
+++ b/arch/mips/pci/fixup-cobalt.c
@@ -177,7 +177,7 @@ static char irq_tab_raq2[] __initdata = {
 
 int __init pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
-   if (cobalt_board_id < COBALT_BRD_ID_QUBE2)
+   if (cobalt_board_id <= COBALT_BRD_ID_QUBE1)
return irq_tab_qube1[slot];
 
if (cobalt_board_id == COBALT_BRD_ID_RAQ2)

- End forwarded message -

-- 
Martin Michlmayr
http://www.cyrius.com/


--- End Message ---
--- Begin Message ---
Source: fai-kernels
Source-Version: 1.17+etch.18etch1

We believe that the bug you reported is fixed in the latest version of
fai-kernels, which is due to be installed in the Debian FTP archive:

fai-kernels_1.17+etch.18etch1.dsc
  to pool/main/f/fai-kernels/fai-kernels_1.17+etch.18etch1.dsc
fai-kernels_1.17+etch.18etch1.tar.gz
  to pool/main/f/fai-kernels/fai-kernels_1.17+etch.18etch1.tar.gz
fai-kernels_1.17+etch.18etch1_i386.deb
  to pool/main/f/fai-kernels/fai-kernels_1.17+etch.18etch1_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
dann frazier <[EMAIL PROTECTED]> (supplier of updated fai-kernels package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 12 Feb 2008 09:59:43 -0700
Source: fai-kernels
Binary: fai-kernels
Architecture: source i386
Version: 1.17+etch.18etch1
Distribution: stable-security
Urgency: high
Maintainer: Holger Levsen <[EMAIL PROTECTED]>
Changed-By: dann frazier <[EMAIL PROTECTED]>
Description: 
 fai-kernels - special kernels for FAI (Fully Automatic Installation)
Closes: 460337 461493
Changes: 
 fai-kernels (1.17+etch.18etch1) stable-security; urgency=high
 .
   * Rebuild against linux-source-2.6.18 (2.6.18.dfsg.1-18etch1)
 * bugfix/vmsplice-security.patch
   [SECURITY] Fix missing access check in vmsplice.
   See CVE-2008-0010, CVE-2008-0600
 * bugfix/all/vserver/proc-link-security.patch
   [SECURITY][vserver] Fix access checks for the links in /proc/$pid.
   * Changes from linux-source-2.6.18 (2.6.18.dfsg.1-18)
 [ Martin Michlmayr ]
 * [mips] Fix network on Cobalt RaQ1, thanks Thomas Bogendoerfer
   (closes: #460337).
 .
 [ dann frazier ]
 * [ia64] Fix an issue with unaligned accesses and certain floating point
   instructions that can result in silent user data corruption
   (closes: #461493).
 * Update abi reference files for ABI 6
Files: 
 42ad7f3b4925c86466a12f6af1f60d34 740 admin extra 
fai-kernels_1.17+etch.18etch1.dsc
 1d940e99b60ea13d97af2a2c7091b7ca 56178 admin extra 
fai-kernels_1.17+etch.18etch1.tar.gz
 f19755f1460aadb94f355e4b601e90e5 5503064 admin extra 
fai-kernels_1.17+etch.18etch1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHsgPjhuANDBmkLRkRAhllAJ4ws/6hlYtCuBq9u3YHVpjEoQ0DHwCbB8Lt
HMTbm1UMBp9kLHIG5gw+Jus=
=oF8O
-END PGP SIGN

Re: Future of the linux udebs

[Otavio Salvador]

Bastian Blank <[EMAIL PROTECTED]> writes:

> On Fri, Feb 15, 2008 at 02:13:02PM -0200, Otavio Salvador wrote:
<...>
>> And the udebs on testing migrated to it from sid. I hope to not need
>> to do uploads to t-p-u for d-i kernel ;-)
>
> I still don't get you.

Kernel udebs on testing came from sid. So they're suppose to be
uploaded there and migrate.

If a unwanted kernel is uploaded to sid and we wanted to update the
udebs, for a release or something, we would end up doing it
t-p-u. This would be done with minor testing and possible breaking
lenny installer.

That's why it should be avoided as possible.

>> >> linux-2.6/linux-modules-extra-2.6 would build the udebs using what
>> >> list? Still using kernel-wedge?
>> > They need to include the list themself, it will get version dependant.
>> So your idea is to this list be placed inside each source package?
>
> It's the only solution which will not kill new versions without code to
> ignore udebs if the definitions are broken.

Didn get you here. Could you elaborate it a bit?

>> This means kernel-wedge will be useless and _any_ change would be need
>> to be done on kernel team svn.
>
> The list needs to be available during build of the source package, it is
> not possible to change them after that.

Sure. But it could be available from kernel-wedge or something? This
would allow us to keep control about what would be end in d-i kernel
modules packages.

>>This is a big regression from my POV
>> since d-i team does need to be able to change the list by himself.
>
> There are two sorts of changes:
> - Modules got renamed/merged/removed.
>   This will kill the build if not fixed, so we need to be able to do
>   such changes on ourself.

Right.

> - Modules got added.
>   This may have an effect, but usualy it is new hardware support.
>
> Now please explain why you _need_ to change that directly and produce
> the following workflow
> "mailto:d-i, commit, upload k-w, mailto:kernel, commit, upload l"
> instead of
> "mailto:kernel, commit, upload l".
> This is a classical indirection.

The problem of doing it directly inside of kernel is that we'll lose
the control of what is being deployed and we'll then need to get
informated about every change inside of kernel packages to get this
information sorted out.

If this could be done from a d-i package (k-w or anything) it gives us
a cannonical place to look at and don't force us to follow another
commit mailing list to get the need information.

>> This looks
>> logical since we'll be directly affected by it and the installer might
>> break.
>
> Everything might break.

And we need to try to avoid it as possible.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


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

kexec_load failed: Device or resource busy

[Emil Natan]

Hi,

I hope it is the right list for that question. Debian Etch running "Linux
test1 2.6.18-5-686 #1 SMP Fri Jun 1 00:47:00 UTC 2007 i686 GNU/Linux". If
this can be of any interest, it is running from the memory (the root
filesystem is tmpfs). I use kexec for week to reboot the machine without any
problem until yesterday when I got this error trying to load the kernel:

kexec -l /boot/vmlinuz-2.6.18-5-686 --append="boot=stage2 rootfstype=tmpfs
rootflags=size=1g rootdelay=30 rw panic=60" --initrd=/boot/initrd.img-
2.6.18-5-686
kexec_load failed: Device or resource busy
entry   = 0x96498 flags = 0
nr_segments = 4
segment[0].buf   = 0x806e6f0
segment[0].bufsz = 204e
segment[0].mem   = 0x92000
segment[0].memsz = 3000
segment[1].buf   = 0x8067528
segment[1].bufsz = 7100
segment[1].mem   = 0x96000
segment[1].memsz = 9000
segment[2].buf   = 0xb7cb9008
segment[2].bufsz = 131a7e
segment[2].mem   = 0x10
segment[2].memsz = 132000
segment[3].buf   = 0xb7871008
segment[3].bufsz = 445ec0
segment[3].mem   = 0x1fbb9000
segment[3].memsz = 446000

I didn't try to reboot and try again, because I'm afraid I should not
reproduce the error and until this is only a test machine, I do not want to
get this error again when I go production.  I get the same error no matter
which kernel I try to load and which flags I provide to it.
Here is what I get from "kexec -u".

kexec -u
kexec_load (0 segments) failed: Device or resource busy

Here is strace of the error, hope it can help.

execve("/sbin/kexec", ["kexec", "-l", "/boot/vmlinuz-2.6.18-5-686",
"--append=boot=stage2 rootf"..., "--initrd=/boot/initrd.img-2.6.18"...], [/*
15 vars */]) = 0
uname({sys="Linux", node="test1", ...}) = 0
brk(0)  = 0x8067000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or
directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f23000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=10732, ...}) = 0
mmap2(NULL, 10732, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f2
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or
directory)
open("/lib/tls/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240O\1"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1241392, ...}) = 0
mmap2(NULL, 1251484, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7dee000
mmap2(0xb7f16000, 28672, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x127) = 0xb7f16000
mmap2(0xb7f1d000, 10396, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f1d000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7ded000
mprotect(0xb7f16000, 20480, PROT_READ)  = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ded8e0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
munmap(0xb7f2, 10732)   = 0
open("/boot/vmlinuz-2.6.18-5-686", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1260158, ...}) = 0
mmap2(NULL, 1261568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7cb9000
read(3, "f\352\10\0\0\0\300\7\214\310\216\330\216\300\216\320\274"...,
1260158) = 1260158
close(3)= 0
brk(0)  = 0x8067000
brk(0x8088000)  = 0x8088000
open("/proc/iomem", O_RDONLY)   = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f22000
read(3, "0100-0009f3ff : System RAM\n0"..., 1024) = 1024
read(3, "1\nfde6-fde6 : tg3\n  "..., 1024) = 448
read(3, "", 1024)   = 0
close(3)= 0
munmap(0xb7f22000, 4096)= 0
open("/boot/initrd.img-2.6.18-5-686", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=4480704, ...}) = 0
mmap2(NULL, 4481024, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7873000
read(3, "\37\213\10\0\2352TG\2\3\304

Bug#465901: [PATCH] configure_network: do nothing if device has been configured already

[maximilian attems]

tags 465901 pending
stop

On Fri, 15 Feb 2008, [EMAIL PROTECTED] wrote:

> From: <[EMAIL PROTECTED]>
> 
> ---
>  scripts/functions |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 

applied, with the appropriate patch description,
please next time add directly the commit message. :)

thanks, see
http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary



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

Bug#461493: marked as done (linux-2.6: [ia64] FP instructions/misaligned access cause silent user data corruption)

[Debian Bug Tracking System]

Your message dated Fri, 15 Feb 2008 19:53:09 +
with message-id <[EMAIL PROTECTED]>
and subject line Bug#461493: fixed in fai-kernels 1.17+etch.18etch1
has caused the Debian Bug report #461493,
regarding linux-2.6: [ia64] FP instructions/misaligned access cause silent user 
data corruption
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
461493: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461493
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: linux-2.6
Version: 2.6.18.dfsg.1-17
Severity: critical
Tags: patch
Justification: causes serious data loss

References:
  
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1a499150e4ec1299232e24389f648d059ce5617a
  https://bugzilla.redhat.com/show_bug.cgi?id=428920
  https://bugzilla.novell.com/show_bug.cgi?id=354069

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: ia64

Kernel: Linux 2.6.22-3-mckinley (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash


--- End Message ---
--- Begin Message ---
Source: fai-kernels
Source-Version: 1.17+etch.18etch1

We believe that the bug you reported is fixed in the latest version of
fai-kernels, which is due to be installed in the Debian FTP archive:

fai-kernels_1.17+etch.18etch1.dsc
  to pool/main/f/fai-kernels/fai-kernels_1.17+etch.18etch1.dsc
fai-kernels_1.17+etch.18etch1.tar.gz
  to pool/main/f/fai-kernels/fai-kernels_1.17+etch.18etch1.tar.gz
fai-kernels_1.17+etch.18etch1_i386.deb
  to pool/main/f/fai-kernels/fai-kernels_1.17+etch.18etch1_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
dann frazier <[EMAIL PROTECTED]> (supplier of updated fai-kernels package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 12 Feb 2008 09:59:43 -0700
Source: fai-kernels
Binary: fai-kernels
Architecture: source i386
Version: 1.17+etch.18etch1
Distribution: stable-security
Urgency: high
Maintainer: Holger Levsen <[EMAIL PROTECTED]>
Changed-By: dann frazier <[EMAIL PROTECTED]>
Description: 
 fai-kernels - special kernels for FAI (Fully Automatic Installation)
Closes: 460337 461493
Changes: 
 fai-kernels (1.17+etch.18etch1) stable-security; urgency=high
 .
   * Rebuild against linux-source-2.6.18 (2.6.18.dfsg.1-18etch1)
 * bugfix/vmsplice-security.patch
   [SECURITY] Fix missing access check in vmsplice.
   See CVE-2008-0010, CVE-2008-0600
 * bugfix/all/vserver/proc-link-security.patch
   [SECURITY][vserver] Fix access checks for the links in /proc/$pid.
   * Changes from linux-source-2.6.18 (2.6.18.dfsg.1-18)
 [ Martin Michlmayr ]
 * [mips] Fix network on Cobalt RaQ1, thanks Thomas Bogendoerfer
   (closes: #460337).
 .
 [ dann frazier ]
 * [ia64] Fix an issue with unaligned accesses and certain floating point
   instructions that can result in silent user data corruption
   (closes: #461493).
 * Update abi reference files for ABI 6
Files: 
 42ad7f3b4925c86466a12f6af1f60d34 740 admin extra 
fai-kernels_1.17+etch.18etch1.dsc
 1d940e99b60ea13d97af2a2c7091b7ca 56178 admin extra 
fai-kernels_1.17+etch.18etch1.tar.gz
 f19755f1460aadb94f355e4b601e90e5 5503064 admin extra 
fai-kernels_1.17+etch.18etch1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHsgPjhuANDBmkLRkRAhllAJ4ws/6hlYtCuBq9u3YHVpjEoQ0DHwCbB8Lt
HMTbm1UMBp9kLHIG5gw+Jus=
=oF8O
-END PGP SIGNATURE-


--- End Message ---

Bug#461493: marked as done (linux-2.6: [ia64] FP instructions/misaligned access cause silent user data corruption)

[Debian Bug Tracking System]

Your message dated Fri, 15 Feb 2008 19:53:07 +
with message-id <[EMAIL PROTECTED]>
and subject line Bug#461493: fixed in user-mode-linux 2.6.18-1um-2etch.18etch1
has caused the Debian Bug report #461493,
regarding linux-2.6: [ia64] FP instructions/misaligned access cause silent user 
data corruption
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
461493: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461493
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: linux-2.6
Version: 2.6.18.dfsg.1-17
Severity: critical
Tags: patch
Justification: causes serious data loss

References:
  
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1a499150e4ec1299232e24389f648d059ce5617a
  https://bugzilla.redhat.com/show_bug.cgi?id=428920
  https://bugzilla.novell.com/show_bug.cgi?id=354069

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: ia64

Kernel: Linux 2.6.22-3-mckinley (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash


--- End Message ---
--- Begin Message ---
Source: user-mode-linux
Source-Version: 2.6.18-1um-2etch.18etch1

We believe that the bug you reported is fixed in the latest version of
user-mode-linux, which is due to be installed in the Debian FTP archive:

user-mode-linux_2.6.18-1um-2etch.18etch1.diff.gz
  to 
pool/main/u/user-mode-linux/user-mode-linux_2.6.18-1um-2etch.18etch1.diff.gz
user-mode-linux_2.6.18-1um-2etch.18etch1.dsc
  to pool/main/u/user-mode-linux/user-mode-linux_2.6.18-1um-2etch.18etch1.dsc
user-mode-linux_2.6.18-1um-2etch.18etch1_i386.deb
  to 
pool/main/u/user-mode-linux/user-mode-linux_2.6.18-1um-2etch.18etch1_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
dann frazier <[EMAIL PROTECTED]> (supplier of updated user-mode-linux package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 12 Feb 2008 09:57:25 -0700
Source: user-mode-linux
Binary: user-mode-linux
Architecture: source i386
Version: 2.6.18-1um-2etch.18etch1
Distribution: stable-security
Urgency: high
Maintainer: User Mode Linux Maintainers <[EMAIL PROTECTED]>
Changed-By: dann frazier <[EMAIL PROTECTED]>
Description: 
 user-mode-linux - User-mode Linux (kernel)
Closes: 460337 461493
Changes: 
 user-mode-linux (2.6.18-1um-2etch.18etch1) stable-security; urgency=high
 .
   * Rebuild against linux-source-2.6.18 (2.6.18.dfsg.1-18etch1)
 * bugfix/vmsplice-security.patch
   [SECURITY] Fix missing access check in vmsplice.
   See CVE-2008-0010, CVE-2008-0600
 * bugfix/all/vserver/proc-link-security.patch
   [SECURITY][vserver] Fix access checks for the links in /proc/$pid.
   * Changes from linux-source-2.6.18 (2.6.18.dfsg.1-18)
 [ Martin Michlmayr ]
 * [mips] Fix network on Cobalt RaQ1, thanks Thomas Bogendoerfer
   (closes: #460337).
 .
 [ dann frazier ]
 * [ia64] Fix an issue with unaligned accesses and certain floating point
   instructions that can result in silent user data corruption
   (closes: #461493).
 * Update abi reference files for ABI 6
Files: 
 a316e3449f9cd0bbf497ad704c1d78ec 892 misc extra 
user-mode-linux_2.6.18-1um-2etch.18etch1.dsc
 b62c78f80dbe59c81827b4d7cf1c3997 16048 misc extra 
user-mode-linux_2.6.18-1um-2etch.18etch1.diff.gz
 1d2290c410d6d56c0e698f217ddb1dc6 25585940 misc extra 
user-mode-linux_2.6.18-1um-2etch.18etch1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHsgQJhuANDBmkLRkRApscAKCJNCn9DnLiOPi8SLIrW8REOafUVACgkt7P
ncqNS55G+rHbBayQAA7ts68=
=4zjq
-END PGP SIGNATURE-


--- End Message ---

Bug#465901: cryptroot remote unlocking on boot feature

[maximilian attems]

On Fri, 15 Feb 2008, [EMAIL PROTECTED] wrote:

>
> [...]
>> git send-email --to [EMAIL PROTECTED] --cc [EMAIL PROTECTED] 
>> 0001-ssh-subject.patch
>
> ok thanks for directions

np, cool you picked it up so nicely :)

>> i must say i'm not a big fan of shipping ssh in initramfs
>> enabled by default needed fixes in networking and such are of
>> course taken.
>
> the hook script in the dropbear patch will only add dropbear to the  
> initramfs if it's explicitly enabled (which it isn't by default), or a  
> cryptroot is detected (and dropbear isn't explicitly disabled).
> adding to the initramfs is certainly generally to be avoided, but not  
> being able to bring a machine up again from remote is quite some  
> motivation, i guess ;) plus it turns out the increase in size and  
> complexity is a lot less than (at least i) expected.
>
>   Chris

ack

-- 
maks



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

Bug#338615: marked as done (udev: psmouse should be loaded after usb-stuff)

[Debian Bug Tracking System]

Your message dated Fri, 15 Feb 2008 19:48:45 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Re: udev: psmouse should be loaded after usb-stuff
has caused the Debian Bug report #338615,
regarding udev: psmouse should be loaded after usb-stuff
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
338615: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338615
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: udev
Version: 0.074-2
Severity: normal


Ciao,
After the switch to a recent release of udev, I have some problems with my
Synaptics Touchpad. It is handled by the psmouse module but the "special
features" of a synaptics device is detected at runtime. 
The problem is that psmouse is loaded too early by recent udev, more 
specifically:
it is loaded BEFORE the loading of usb-stuff. 
This is known issue of psmouse module:
http://www.ussg.iu.edu/hypermail/linux/kernel/0407.1/0862.html
My Xserver doesn't start if the touchpad is detect as a simple mouse (it is
configured as a synaptics device in xorg.conf). 
If I remove the module ('rmmod psmouse') and then I load it ('modprobe 
psmouse'),
and I restart X: it works. 
This happens only if at boot-time I have my usb-mouse plugged.

In a "bad run" lsmod reports (psmouse is loaded before usbcore):
...
soundcore   8288  1 snd
shpchp 96612  0
ehci_hcd   31624  0
intel_agp  21276  1
uhci_hcd   31888  0
snd_page_alloc  8712  3 snd_intel8x0m,snd_intel8x0,snd_pcm
i2c_i8017948  0
pci_hotplug12036  1 shpchp
mousedev   10272  0
usbcore   115840  5 usbhid,hci_usb,ehci_hcd,uhci_hcd
psmouse37380  0
i2c_core   18576  1 i2c_i801
agpgart29768  1 intel_agp
rtc11320  0

To delay the loading of psmouse I've added it in a file of 
/etc/hotplug/blacklist.d/
(this folder it is still working) and in /etc/modules.
In this way, the output of lsmod is:
ieee80211_crypt_tkip10240  3
rfcomm 37404  2
l2cap  24196  5 rfcomm
vmnet  27684  0
vmmon 173100  0
ipt_ULOG6660  1
ip_tables  20736  1 ipt_ULOG
pcmcia 33828  2
nls_iso8859_1   3968  1
nls_cp437   5632  1
psmouse37380  0
eth139418440  0
hci_usb14224  2
bluetooth  44932  7 rfcomm,l2cap,hci_usb
usbhid 36960  0
evdev   7808  1
ohci1394   2  0
8139cp 17920  0
ieee1394   91576  2 eth1394,ohci1394
snd_intel8x0   31200  0
snd_intel8x0m  15812  0
snd_ac97_codec 95484  2 snd_intel8x0,snd_intel8x0m
snd_ac97_bus2048  1 snd_ac97_codec
yenta_socket   25100  2
rsrc_nonstatic 12160  1 yenta_socket
pcmcia_core37776  3 pcmcia,yenta_socket,rsrc_nonstatic
ipw2200   184256  0
snd_pcm_oss51232  0
snd_mixer_oss  17920  1 snd_pcm_oss
8139too23040  0
mii 4864  2 8139cp,8139too
ieee80211  46312  1 ipw2200
ieee80211_crypt 5380  2 ieee80211_crypt_tkip,ieee80211
snd_pcm85640  4 
snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss
snd_timer  22660  1 snd_pcm
snd49380  7 
snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore   8288  1 snd
uhci_hcd   31888  0
ehci_hcd   31624  0
i2c_i8017948  0
snd_page_alloc  8712  3 snd_intel8x0,snd_intel8x0m,snd_pcm
intel_agp  21276  1
agpgart29768  2 intel_agp
shpchp 96612  0
pci_hotplug12036  1 shpchp
mousedev   10272  1
usbcore   115840  5 hci_usb,usbhid,uhci_hcd,ehci_hcd
i2c_core   18576  1 i2c_i801
rtc11320  0

Another strange behaviour is: during the boot I can see strange messages (not 
always the same!)
about unresolved symbols as you can see from the following dmesg output. 
The modules that create these messages are later loaded without any problem. :|
It looks as something (udev?) is trying to load a module with an insmod 
(instead of modprobe).

Kernel command line: root=/dev/hda5 ro noapic resume2=swap:/dev/hda7 vga=791 
splash=silente,theme:current CONSOLE=/dev/tty1 SELINUX_INIT=NO 
Initializing CPU#0
CPU 0 irqstacks, hard=c043c000

Bug#460337: marked as done (Fix ethernet interrupts for Cobalt RaQ1)

[Debian Bug Tracking System]

Your message dated Fri, 15 Feb 2008 19:53:07 +
with message-id <[EMAIL PROTECTED]>
and subject line Bug#460337: fixed in user-mode-linux 2.6.18-1um-2etch.18etch1
has caused the Debian Bug report #460337,
regarding Fix ethernet interrupts for Cobalt RaQ1
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
460337: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460337
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: linux-2.6
Version: 2.6.18.dfsg.1-12
Severity: important

The network interface on Cobalt RaQ1 has not worked since we moved
from 2.4 to 2.6.  There were quite a few reports about this on the
debian-mips list.  Thomas Bogendoerfer just posted a patch for this
problem.


- Forwarded message from Thomas Bogendoerfer <[EMAIL PROTECTED]> -

From: Thomas Bogendoerfer <[EMAIL PROTECTED]>
Subject: [PATCH] Fix ethernet interrupts for Cobalt RaQ1
Date: Sat, 12 Jan 2008 00:25:14 +0100 (CET)
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]

RAQ1 uses the same interrupt routing as qube2.

Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
---

 arch/mips/pci/fixup-cobalt.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/mips/pci/fixup-cobalt.c b/arch/mips/pci/fixup-cobalt.c
index f7df114..9553b14 100644
--- a/arch/mips/pci/fixup-cobalt.c
+++ b/arch/mips/pci/fixup-cobalt.c
@@ -177,7 +177,7 @@ static char irq_tab_raq2[] __initdata = {
 
 int __init pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
-   if (cobalt_board_id < COBALT_BRD_ID_QUBE2)
+   if (cobalt_board_id <= COBALT_BRD_ID_QUBE1)
return irq_tab_qube1[slot];
 
if (cobalt_board_id == COBALT_BRD_ID_RAQ2)

- End forwarded message -

-- 
Martin Michlmayr
http://www.cyrius.com/


--- End Message ---
--- Begin Message ---
Source: user-mode-linux
Source-Version: 2.6.18-1um-2etch.18etch1

We believe that the bug you reported is fixed in the latest version of
user-mode-linux, which is due to be installed in the Debian FTP archive:

user-mode-linux_2.6.18-1um-2etch.18etch1.diff.gz
  to 
pool/main/u/user-mode-linux/user-mode-linux_2.6.18-1um-2etch.18etch1.diff.gz
user-mode-linux_2.6.18-1um-2etch.18etch1.dsc
  to pool/main/u/user-mode-linux/user-mode-linux_2.6.18-1um-2etch.18etch1.dsc
user-mode-linux_2.6.18-1um-2etch.18etch1_i386.deb
  to 
pool/main/u/user-mode-linux/user-mode-linux_2.6.18-1um-2etch.18etch1_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
dann frazier <[EMAIL PROTECTED]> (supplier of updated user-mode-linux package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 12 Feb 2008 09:57:25 -0700
Source: user-mode-linux
Binary: user-mode-linux
Architecture: source i386
Version: 2.6.18-1um-2etch.18etch1
Distribution: stable-security
Urgency: high
Maintainer: User Mode Linux Maintainers <[EMAIL PROTECTED]>
Changed-By: dann frazier <[EMAIL PROTECTED]>
Description: 
 user-mode-linux - User-mode Linux (kernel)
Closes: 460337 461493
Changes: 
 user-mode-linux (2.6.18-1um-2etch.18etch1) stable-security; urgency=high
 .
   * Rebuild against linux-source-2.6.18 (2.6.18.dfsg.1-18etch1)
 * bugfix/vmsplice-security.patch
   [SECURITY] Fix missing access check in vmsplice.
   See CVE-2008-0010, CVE-2008-0600
 * bugfix/all/vserver/proc-link-security.patch
   [SECURITY][vserver] Fix access checks for the links in /proc/$pid.
   * Changes from linux-source-2.6.18 (2.6.18.dfsg.1-18)
 [ Martin Michlmayr ]
 * [mips] Fix network on Cobalt RaQ1, thanks Thomas Bogendoerfer
   (closes: #460337).
 .
 [ dann frazier ]
 * [ia64] Fix an issue with unaligned accesses and certain floating point
   instructions that can result in silent user data corruption
   (closes: #461493).
 * Update abi reference files for ABI 6
Files: 
 a316e3449f9cd0bbf497ad704c1d78ec 892 misc extra 
user-mode-linux_2.6.18-1um-2etch.18etch1.dsc
 b62c78f80dbe59c81827b4d7cf1c3997 16048 misc extra 
user-mode-linux_2.6.18-1um-2etch.18etch1.diff.gz
 1d2290c410d6d56c0e698f217ddb1dc6 25585940 misc extra 
user-mode-linux_2.6.18-1um-2etch.18etch1_i386.deb

-BEGIN PGP SIGNA

Re: Future of the linux udebs

[Bastian Blank]

On Fri, Feb 15, 2008 at 02:13:02PM -0200, Otavio Salvador wrote:
> Bastian Blank <[EMAIL PROTECTED]> writes:
> > On Fri, Feb 15, 2008 at 12:31:05PM -0200, Otavio Salvador wrote:
> >>   - Is impossible to release d-i with a different kernel from sid
> >> without a lot of hassle
> > d-i releases are built with testing udebs. Or do you mean something
> > else?
> Not during development cycle.

For development it is still possible to add different apt sources and
pull in whatever is wanted. Just pull unstable _and_ testing in and you
would not see the new version if testing was uptodate before.

> And the udebs on testing migrated to it from sid. I hope to not need
> to do uploads to t-p-u for d-i kernel ;-)

I still don't get you.

> >> linux-2.6/linux-modules-extra-2.6 would build the udebs using what
> >> list? Still using kernel-wedge?
> > They need to include the list themself, it will get version dependant.
> So your idea is to this list be placed inside each source package?

It's the only solution which will not kill new versions without code to
ignore udebs if the definitions are broken.

> This means kernel-wedge will be useless and _any_ change would be need
> to be done on kernel team svn.

The list needs to be available during build of the source package, it is
not possible to change them after that.

>This is a big regression from my POV
> since d-i team does need to be able to change the list by himself.

There are two sorts of changes:
- Modules got renamed/merged/removed.
  This will kill the build if not fixed, so we need to be able to do
  such changes on ourself.
- Modules got added.
  This may have an effect, but usualy it is new hardware support.

Now please explain why you _need_ to change that directly and produce
the following workflow
"mailto:d-i, commit, upload k-w, mailto:kernel, commit, upload l"
instead of
"mailto:kernel, commit, upload l".
This is a classical indirection.

> This looks
> logical since we'll be directly affected by it and the installer might
> break.

Everything might break.

Bastian

-- 
Virtue is a relative term.
-- Spock, "Friday's Child", stardate 3499.1


signature.asc
Description: Digital signature

Bug#465775: Not a bug

[Luis R. Rodriguez]

This is not a bug in the kernel but a udev problem. If you delete the
generated rename rules, it should create the correct ones on the next
boot. Alternately, you could add:

ATTRS{type}="1"

selector to your current rule. Debian puts these autogenerated udev
rules in /etc/udev/rules.d/z25_persistent-net.rules.

For further details please see:

http://linuxwireless.org/en/developers/Documentation/mac80211#Themasterdevicewmaster0

  Luis



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