Re: [PATCH v5 2/4] deb-pkg: split debug symbols in their own package

[maximilian attems]

On Fri, Jun 14, 2013 at 11:46:55AM +0200, Anisse Astier wrote:
> This can reduce almost 3 times the size of the linux-image package,
> while keeping the debug symbols available for this particular build, in
> their own package.
> 
> This mimics the way kernels are built in debian, ubuntu, or with
> make-kpkg, and comes at the price of a small slowdown in the building of
> packages.
> 
> Signed-off-by: Anisse Astier 
> Cc: Ben Hutchings 
Acked-by: maximilian attems 
> ---
>  scripts/package/builddeb | 50 
> +++-
>  1 file changed, 49 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index 6f21ad8..7c5703a 100644
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -78,17 +78,21 @@ tmpdir="$objtree/debian/tmp"
>  fwdir="$objtree/debian/fwtmp"
>  kernel_headers_dir="$objtree/debian/hdrtmp"
>  libc_headers_dir="$objtree/debian/headertmp"
> +dbg_dir="$objtree/debian/dbgtmp"
>  packagename=linux-image-$version
>  fwpackagename=linux-firmware-image
>  kernel_headers_packagename=linux-headers-$version
>  libc_headers_packagename=linux-libc-dev
> +dbg_packagename=$packagename-dbg
>  
>  if [ "$ARCH" = "um" ] ; then
>   packagename=user-mode-linux-$version
>  fi
>  
> +BUILD_DEBUG="$(grep -s '^CONFIG_DEBUG_INFO=y' $KCONFIG_CONFIG || true)"
> +
>  # Setup the directory structure
> -rm -rf "$tmpdir" "$fwdir" "$kernel_headers_dir" "$libc_headers_dir"
> +rm -rf "$tmpdir" "$fwdir" "$kernel_headers_dir" "$libc_headers_dir" 
> "$dbg_dir"
>  mkdir -m 755 -p "$tmpdir/DEBIAN"
>  mkdir -p  "$tmpdir/lib" "$tmpdir/boot" "$tmpdir/usr/share/doc/$packagename"
>  mkdir -m 755 -p "$fwdir/DEBIAN"
> @@ -101,6 +105,10 @@ mkdir -p "$kernel_headers_dir/lib/modules/$version/"
>  if [ "$ARCH" = "um" ] ; then
>   mkdir -p "$tmpdir/usr/lib/uml/modules/$version" "$tmpdir/usr/bin"
>  fi
> +if [ -n "$BUILD_DEBUG" ] ; then
> + mkdir -p "$dbg_dir/usr/share/doc/$dbg_packagename"
> + mkdir -m 755 -p "$dbg_dir/DEBIAN"
> +fi
>  
>  # Build and install the kernel
>  if [ "$ARCH" = "um" ] ; then
> @@ -128,6 +136,20 @@ if grep -q '^CONFIG_MODULES=y' $KCONFIG_CONFIG ; then
>   mv "$tmpdir/lib/modules/$version"/* 
> "$tmpdir/usr/lib/uml/modules/$version/"
>   rmdir "$tmpdir/lib/modules/$version"
>   fi
> + if [ -n "$BUILD_DEBUG" ] ; then
> + (
> + cd $tmpdir
> + for module in $(find lib/modules/ -name *.ko); do
> + mkdir -p $(dirname 
> $dbg_dir/usr/lib/debug/$module)
> + # only keep debug symbols in the debug file
> + objcopy --only-keep-debug $module 
> $dbg_dir/usr/lib/debug/$module
> + # strip original module from debug symbols
> + objcopy --strip-debug $module
> + # then add a link to those
> + objcopy 
> --add-gnu-debuglink=$dbg_dir/usr/lib/debug/$module $module
> + done
> + )
> + fi
>  fi
>  
>  if [ "$ARCH" != "um" ]; then
> @@ -299,4 +321,30 @@ fi
>  
>  create_package "$packagename" "$tmpdir"
>  
> +if [ -n "$BUILD_DEBUG" ] ; then
> + # Build debug package
> + # Different tools want the image in different locations
> + # perf
> + mkdir -p $dbg_dir/usr/lib/debug/lib/modules/$version/
> + cp vmlinux $dbg_dir/usr/lib/debug/lib/modules/$version/
> + # systemtap
> + mkdir -p $dbg_dir/usr/lib/debug/boot/
> + ln -s ../lib/modules/$version/vmlinux 
> $dbg_dir/usr/lib/debug/boot/vmlinux-$version
> + # kdump-tools
> + ln -s lib/modules/$version/vmlinux 
> $dbg_dir/usr/lib/debug/vmlinux-$version
> +
> + cat <> debian/control
> +
> +Package: $dbg_packagename
> +Section: debug
> +Provides: linux-debug, linux-debug-$version
> +Architecture: any
> +Description: Linux kernel debugging symbols for $version
> + This package will come in handy if you need to debug the kernel. It provides
> + all the necessary debug symbols for the kernel and its modules.
> +EOF
> +
> + create_package "$dbg_packagename" "$dbg_dir"
> +fi
> +
>  exit 0
> -- 
> 1.8.3.rc1
> 


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130614135559.gl23...@vostochny.stro.at

Re: [PATCH v5 1/4] deb-pkg: use KCONFIG_CONFIG instead of .config file directly

[maximilian attems]

On Fri, Jun 14, 2013 at 11:46:54AM +0200, Anisse Astier wrote:
> Signed-off-by: Anisse Astier 
> Cc: Ben Hutchings 
Acked-by: maximilian attems 
> ---
>  scripts/package/builddeb | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index acb8650..6f21ad8 100644
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -41,9 +41,9 @@ create_package() {
>   parisc*)
>   debarch=hppa ;;
>   mips*)
> - debarch=mips$(grep -q CPU_LITTLE_ENDIAN=y .config && echo el) ;;
> + debarch=mips$(grep -q CPU_LITTLE_ENDIAN=y $KCONFIG_CONFIG && 
> echo el) ;;
>   arm*)
> - debarch=arm$(grep -q CONFIG_AEABI=y .config && echo el) ;;
> + debarch=arm$(grep -q CONFIG_AEABI=y $KCONFIG_CONFIG && echo el) 
> ;;
>   *)
>   echo "" >&2
>   echo "** ** **  WARNING  ** ** **" >&2
> @@ -106,12 +106,12 @@ fi
>  if [ "$ARCH" = "um" ] ; then
>   $MAKE linux
>   cp System.map "$tmpdir/usr/lib/uml/modules/$version/System.map"
> - cp .config "$tmpdir/usr/share/doc/$packagename/config"
> + cp $KCONFIG_CONFIG "$tmpdir/usr/share/doc/$packagename/config"
>   gzip "$tmpdir/usr/share/doc/$packagename/config"
>   cp $KBUILD_IMAGE "$tmpdir/usr/bin/linux-$version"
>  else 
>   cp System.map "$tmpdir/boot/System.map-$version"
> - cp .config "$tmpdir/boot/config-$version"
> + cp $KCONFIG_CONFIG "$tmpdir/boot/config-$version"
>   # Not all arches include the boot path in KBUILD_IMAGE
>   if [ -e $KBUILD_IMAGE ]; then
>   cp $KBUILD_IMAGE "$tmpdir/boot/vmlinuz-$version"
> @@ -120,7 +120,7 @@ else
>   fi
>  fi
>  
> -if grep -q '^CONFIG_MODULES=y' .config ; then
> +if grep -q '^CONFIG_MODULES=y' $KCONFIG_CONFIG ; then
>   INSTALL_MOD_PATH="$tmpdir" $MAKE KBUILD_SRC= modules_install
>   rm -f "$tmpdir/lib/modules/$version/build"
>   rm -f "$tmpdir/lib/modules/$version/source"
> @@ -245,7 +245,7 @@ fi
>  # Build header package
>  (cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name \*.pl > 
> "$objtree/debian/hdrsrcfiles")
>  (cd $srctree; find arch/$SRCARCH/include include scripts -type f >> 
> "$objtree/debian/hdrsrcfiles")
> -(cd $objtree; find arch/$SRCARCH/include .config Module.symvers include 
> scripts -type f >> "$objtree/debian/hdrobjfiles")
> +(cd $objtree; find arch/$SRCARCH/include $KCONFIG_CONFIG Module.symvers 
> include scripts -type f >> "$objtree/debian/hdrobjfiles")
>  destdir=$kernel_headers_dir/usr/src/linux-headers-$version
>  mkdir -p "$destdir"
>  (cd $srctree; tar -c -f - -T "$objtree/debian/hdrsrcfiles") | (cd $destdir; 
> tar -xf -)
> -- 
> 1.8.3.rc1
> 


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130614135455.gk23...@vostochny.stro.at

Re: [PATCH v5 0/4] deb-pkg: bring it a little closer to debian packaging

[maximilian attems]

On Fri, Jun 14, 2013 at 11:46:53AM +0200, Anisse Astier wrote:
> These little fixes should bring debian packaging closer to the way it's done 
> in debian.
> 
> Changes in:
> v2:
>  - only build debug packages when CONFIG_DEBUG_INFO=y
>  - build debug package last.
>  - more verbose debug package description
>  - put package in section debug
> v3:
>  - remove duplicate code from v2
> v4:
>  - fixes thanks to Ben Hutchings' review
>  - use KCONFIG_CONFIG instead of .config
>  - use installed path specific to each architecture instead of hard-coded
>/boot/vmlinuz-$version, based on
>
> http://anonscm.debian.org/viewvc/kernel/dists/wheezy/linux/debian/rules.real?view=markup
> v5:
>  - fixes thanks to Ben Hutchings' review
>  - don't use $objtree as it's redundant in build scripts
>  - add symbolic links to vmlinux to work with other tools than perf
>  - pick-up reviewed-by from ml for patch 3 and 4
> 
> 
> Anisse Astier (4):
>   deb-pkg: use KCONFIG_CONFIG instead of .config file directly
>   deb-pkg: split debug symbols in their own package
>   deb-pkg: fix installed image path on parisc, mips and powerpc
>   deb-pkg: add a hook argument to match debian hooks parameters
> 
>  scripts/package/builddeb | 91 
> 
>  1 file changed, 76 insertions(+), 15 deletions(-)

Thanks, whole series seems good to me,
Acked those that seem really worthwile.
Thanks for caring of parisc and stuff.

Rereading, I didn't see the motivation for the last change,
explained in the commit message?
IRC this distinction was done on purpose to allow distribution
specific linux images to run different hooks.

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130614135839.gm23...@vostochny.stro.at

Re: [PATCH v5 4/4] deb-pkg: add a hook argument to match debian hooks parameters

[maximilian attems]

On Fri, Jun 14, 2013 at 11:46:57AM +0200, Anisse Astier wrote:
> We now provide the installed image path to the kernel hooks.
> 
> This should allow the package to better integrate with debian hooks, and
> should not be too disruptive of hooks supporting only one parameter.
> 
> Signed-off-by: Anisse Astier 
> Reviewed-by: Ben Hutchings 
Acked-by: maximilian attems 
> ---
>  scripts/package/builddeb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index 0dbada8..06cd0c7 100644
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -184,7 +184,7 @@ set -e
>  # Pass maintainer script parameters to hook scripts
>  export DEB_MAINT_PARAMS="\$*"
>  
> -test -d $debhookdir/$script.d && run-parts --arg="$version" 
> $debhookdir/$script.d
> +test -d $debhookdir/$script.d && run-parts --arg="$version" 
> --arg="/$installed_image_path" $debhookdir/$script.d
>  exit 0
>  EOF
>   chmod 755 "$tmpdir/DEBIAN/$script"
> -- 
> 1.8.3.rc1
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/1371203217-19572-5-git-send-email-ani...@astier.eu
> 


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130614153721.gn23...@vostochny.stro.at

Bug#714694: linux-image-amd64: Could not start debian

[maximilian attems]

On Tue, Jul 02, 2013 at 03:36:16PM +0200, Sébastien Dailly wrote:
> 
> 
> I'm available if you need more information. Do not hesitate to ask me !

This is *not* the way it works.

If an error occurs the bug submitter is meant to post the error.
Also it might be nice to post which version works or worked.
Without drones we don't get an eye on your cool box. (:
Afaik Debian doesn't invest yet in such remote bug control.

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702152701.ga28...@stro.at

Bug#652459: initramfs-tools: [patch] Please support mounting of /usr in the initramfs

[maximilian attems]

On Tue, Jul 23, 2013 at 10:09:38PM +0100, Roger Leigh wrote:
> On 23/07/13 18:48, Michael Prokop wrote:
> >[Cc-ing everyone who was involved in discussing #652459]
> 
> (Also copying Adam Conrad and Steve Langasek.)
> 
> >* Roger Leigh [Sun May 12, 2013 at 06:53:11PM +0100]:
> >
> >>And one final patch to use panic rather than sulogin on fsck failure.
> >
> >Thanks for all your patches, I've applied them on top of current
> >master (and edited debian/changelog on my own, being based on your
> >patches). The result is currently sitting in branch mika/bug_652459
> >of initramfs-tools.git.
> >
> >Does anyone have any objections against the current implementation
> >of #652459 to support mounting of /usr in the initramfs?
> >If so, which objections do you have and what needs to be done to
> >resolve this issue so all involved parties are happy?

The shell parsing of /etc/fstab would run on any boot?

nitpicking read_fstab_entry():

- useless loop, please just assign:
+   for file in ${rootmnt}/etc/fstab; do

+   if [ -f "$file" ]; then
Please reverse logic and immediately return if no fstab

+   if [ "$MNT_DIR" = "$1" ]; then
similary please just unwrap that too.


thanks.

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130723233045.ga4...@stro.at

Re: recommends for apparmor in newest linux-image-4.13

[maximilian attems]

On Thu, Nov 23, 2017 at 03:00:49PM +0100, Wouter Verhelst wrote:
> On Thu, Nov 23, 2017 at 02:18:46PM +0100, Christoph Hellwig wrote:
> > Hi all,
> > 
> > is there any good reason for the recommends of apparmor in the latest
> > linux packages?
> 
> This is in response to a discussion that happened on this list. The
> thread started in august last year[1], but really picked up speed last
> month[2] and this one[3].
> 
> The idea is that, if no critical issues are found, buster would release
> with AppArmor enabled by default. If critical issues are found, however,
> I expect the decision will be reversed (or at the least, postponed).
> 
> [1] https://lists.debian.org/debian-devel/2017/08/msg00090.html
> [2] https://lists.debian.org/debian-devel/2017/10/threads.html#00086
> [3] https://lists.debian.org/debian-devel/2017/11/threads.html#0
> 

This doesn't strike me as a discussion, but looks more like a predetermined 
setup.

linux 4.0 exp

[maximilian attems]

hello,

upload sometime after 22UT today.

-- 
maks


signature.asc
Description: Digital signature

Re: [PATCH 2/2] deb-pkg: add source package

[maximilian attems]

On Fri, Apr 10, 2015 at 04:15:14PM +0300, riku.voi...@linaro.org wrote:
> From: Riku Voipio 
> 
> By passing BUILD_SOURCE=y variable, make deb-pkg builds a debian source
> package. It will generate a minimal debian/rules file that calls back
> to make deb-pkg. Generated source package will build the same kernel
> .config than what was available for make deb-pkg.
> 
> The source package is useful for gpl compliance, or for feeding to a
> automated debian package builder.
> 
> Patch depends on the "deb-pkg: move setting debarch for a separate function"
> for correct changelog filenames.
> 
> Signed-off-by: Riku Voipio 
> ---

great this is a much requested feature for wider adoption of make
deb-pkg. In general acked-by me, just minor comment below.

I do not like the BUILD_SOURCE=y variable,
I think it should just be like the other scripts and do it by default.

What we do need is a target that *only* compiles the linux image.

>  scripts/package/builddeb | 42 ++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index e397815..3d77fd3 100755
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -272,12 +272,23 @@ On Debian GNU/Linux systems, the complete text of the 
> GNU General Public
>  License version 2 can be found in \`/usr/share/common-licenses/GPL-2'.
>  EOF
>  
> +
> +build_depends="bc, "
> +if [ -n "$BUILD_TOOLS" ]

why this dual stage?

> +then
> + build_depends="$build_depends python-dev, libperl-dev, bison, flex, \
> +libaudit-dev, libdw-dev, libelf-dev, libiberty-dev, libnewt-dev, autoconf, \
> +automake, libtool, libglib2.0-dev, libudev-dev, libwrap0-dev, libiberty-dev, 
> \
> +libunwind8-dev [amd64 arm64 i386], libnuma-dev [amd64 arm64 i386 powerpc 
> ppc64 ppc64el] "

how did you generate this list, this seems bogus to me?!

python-dev should probably be python
why would you need automake?

plus I do seem to miss cpio, kmod.

> +fi
> +
>  # Generate a control file
>  cat < debian/control
>  Source: linux-upstream
>  Section: kernel
>  Priority: optional
>  Maintainer: $maintainer
> +Build-Depends: $build_depends
>  Standards-Version: 3.8.4
>  Homepage: http://www.kernel.org/
>  EOF
> @@ -425,4 +436,35 @@ EOF
>   create_package "$tools_packagename" "$tools_dir"
>  fi
>  
> +if [ -n "$BUILD_SOURCE" ]
> +then
> +cat < debian/rules
> +#!/usr/bin/make -f
> +
> +build:
> + cp debian/config .config
> + \$(MAKE) oldconfig
> +
> +binary-arch:
> + \$(MAKE) KDEB_PKGVERSION=${packageversion} BUILD_TOOLS=$BUILD_TOOLS 
> deb-pkg
> +
> +clean:
> + \$(MAKE) clean
> +
> +binary: binary-arch
> +EOF
> +
> + (cd $KBUILD_SRC; git archive --prefix=linux-upstream-${version}/ 
> HEAD)|gzip -9 > ../linux-upstream_${version}.orig.tar.gz
> + cp $KCONFIG_CONFIG debian/config
> + tar caf ../linux-upstream_${packageversion}.debian.tar.gz 
> debian/{config,copyright,rules,changelog,control}
> + dpkg-source -cdebian/control -ldebian/changelog --format="3.0 (custom)" 
> --target-format="3.0 (quilt)" \
> + -b / ../linux-upstream_${version}.orig.tar.gz  
> ../linux-upstream_${packageversion}.debian.tar.gz
> + mv linux-upstream_${packageversion}*dsc ..
> + dpkg-genchanges > ../linux-upstream_${packageversion}_${debarch}.changes
> +else
> + dpkg-genchanges -b > 
> ../linux-upstream_${packageversion}_${debarch}.changes
> +fi
> +
> +
> +
>  exit 0
> -- 
> 2.1.4
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: 
> https://lists.debian.org/34017611f8a0056a09d2c38412efd7828efe00fe.1428671643.git.riku.voi...@linaro.org
> 


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150422155057.GA32026@gluino

Re: [PATCH] deb-pkg: v2: move setting debarch for a separate function

[maximilian attems]

On Wed, Apr 22, 2015 at 04:45:38PM +0200, Michal Marek wrote:
> On 2015-04-16 15:42, riku.voi...@linaro.org wrote:
> > From: Riku Voipio 
> > 
> > create_package() function tries to resolve used architecture
> > for everry package. Split the setting the architecture to a
> > new function, set_debarch(), called once on startup.
> > 
> > This allows using debarch from other parts of script as
> > needed.
> > 
> > v2: Follow Michals suggestion on setting variables at
> > top scope and also setting the fallback $debarch in the
> > new function
> > 
> > Signed-off-by: Riku Voipio 
> 
> Thanks, applied to kbuild.git#misc. But please base your patches on
> Linus's or the maintainer's tree next time. Your patch had some
> conflicts, because it was based on some non-upstream patches.

thanks, acked.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150422155201.GB32026@gluino

Re: [PATCH 2/2] deb-pkg: add source package

[maximilian attems]

On Thu, Apr 23, 2015 at 12:01:10PM +0300, Riku Voipio wrote:
> On 22 April 2015 at 18:50, maximilian attems  wrote:
> >
> > great this is a much requested feature for wider adoption of make
> > deb-pkg. In general acked-by me, just minor comment below.
> >
> > I do not like the BUILD_SOURCE=y variable,
> > I think it should just be like the other scripts and do it by default.
> >
> > What we do need is a target that *only* compiles the linux image.
> 
> So a bin-debpkg target in scripts/package/Makefile ?

yes, please.
 
> >>  scripts/package/builddeb | 42 ++
> >>  1 file changed, 42 insertions(+)
> >>
> >> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> >> index e397815..3d77fd3 100755
> >> --- a/scripts/package/builddeb
> >> +++ b/scripts/package/builddeb
> >> @@ -272,12 +272,23 @@ On Debian GNU/Linux systems, the complete text of 
> >> the GNU General Public
> >>  License version 2 can be found in \`/usr/share/common-licenses/GPL-2'.
> >>  EOF
> >>
> >> +
> >> +build_depends="bc, "
> >> +if [ -n "$BUILD_TOOLS" ]
> 
> > why this dual stage?
> 
> That variable was introduced in "RFC: builddeb: add linux-tools
> package with perf" [1]. Building perf
> as part of deb-pkg was kind of the major motivation for these series.

With adding the very specific image target, I don't think this variable
is needed.
 
> >> +then
> >> + build_depends="$build_depends python-dev, libperl-dev, bison, flex, \
> >> +libaudit-dev, libdw-dev, libelf-dev, libiberty-dev, libnewt-dev, 
> >> autoconf, \
> >> +automake, libtool, libglib2.0-dev, libudev-dev, libwrap0-dev, 
> >> libiberty-dev, \
> >> +libunwind8-dev [amd64 arm64 i386], libnuma-dev [amd64 arm64 i386 powerpc 
> >> ppc64 ppc64el] "
> 
> > how did you generate this list, this seems bogus to me?!
> 
> > python-dev should probably be python
> > why would you need automake?
> 
> These are build-depends of linux-tools (perf etc).

Hmm, ok.
 
> > plus I do seem to miss cpio, kmod.
> 
> I'll add kmod and cpio to the non-tools case.

good.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150423104358.gr27...@stro.at

Bug#783620: initramfs-tools: initramfs broken on first boot into Jessie, "Unable to mount root fs on unknown-block(0, 0)"

[maximilian attems]

On Wed, Apr 29, 2015 at 01:06:07PM +0200, Bernhard Schmidt wrote:
> Hi,
> 
> [ copied from debian-user again ]
> 
> ---
> Got another system with the symptoms and managed to get a snapshot.
> 
> It is really extremely weird. The kernel output is
> 
> List of all partitions:
> No filesystem could mount root, tried:
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)
> 
> This is reproducible. To fix it it is enough to boot into the Wheezy
> kernel (even with init=/bin/sh), then reboot. It apparently does
> something to the root-fs (fsck?) which allows the Jessie kernel to boot.
> 
> I have asked our Windows guys to make a screencast, it is uploaded here.
> 
> http://users.birkenwald.de/~berni/volatile/783620.mkv
> 
> We still have the snapshot available, if you have an idea please drop me
> a note.

this means linux didn't get the initramfs passed by the bootloader.

In the old days this happened when lilo was not run, these days it could
be some grub modules out of sync (very wild guess).
did you try before botting into that image to run install-grub in it?


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150429144533.gd10...@stro.at

Re: Out-of-tree kernel module udeb

[maximilian attems]

On Sun, May 17, 2015 at 01:36:53PM +0100, Ben Hutchings wrote:
> On Sun, 2015-05-17 at 13:25 +0200, Cyril Brulebois wrote:
> 
> > > At the moment only spl is available in the archive, using dkms, and
> > > for zfs it's similar in the way of packaging though not uploaded yet.
> > > What we have (code ready to go) is a mechanism that detects/gets
> > > definition of a current KVERS and generate a source package with
> > > dependencies and binary packages with names corresponding to it.
> > > 
> > > What do you guys think?
> > 
> > My personal stance on kernel related things would be “upstream first”.
> > If it ain't going to be merged into mainline, or at least accepted as a
> > patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure
> > we want to support that.
> > 
> > Cc-ing debian-kernel@ to see what they think.
> 
> I strongly oppose adding OOT modules this way as a supposed workaround
> for licence incompatibility.
> 

this has been indeed our general conensus. we reject OOT modules or
patchsets that have zero or near zero probability of getting merged upstream.

-- 
maks


signature.asc
Description: Digital signature

Re: Build kernel with clang(sid)

[maximilian attems]

On Thu, Jun 04, 2015 at 04:00:18PM +0800, Joseph Lee wrote:
> 
> I am working on GSOC project "bootable clang built debian" and need to
> build Linux with clang. I used patches from LLVMLinux and add a new Kconfig
> file, modified debian/rules and debian/rules.real. May I report this as a
> bug(I attached the patch I made)?

the patch as is is unacceptable, why do you create a full new copy
of a config, this is certainly not needed.

best,

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150604101901.GA14499@gluino

Re: Build kernel with clang(sid)

[maximilian attems]

On Thu, Jun 04, 2015 at 04:00:18PM +0800, Joseph Lee wrote:
> 
> I am working on GSOC project "bootable clang built debian" and need to
> build Linux with clang. I used patches from LLVMLinux and add a new Kconfig
> file, modified debian/rules and debian/rules.real. May I report this as a
> bug(I attached the patch I made)?

dude break up this patch in logic parts. this an unreadable mess.
I don't get why a clang patch should patch a fs!?


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150604102120.GB14499@gluino

Re: Build kernel with clang(sid)

[maximilian attems]

On Thu, Jun 04, 2015 at 07:44:13PM +0800, Joseph Lee wrote:
> Hello,
> 
> Thanks for reply.
> 
> >why do you create a full new copy of a config, this is certainly not
> needed.
> An option in standard config file must be disable to pass compilation. I am
> not very familiar with how these options are used. This is the way I found.
> It's a little ugly indeed. I will try another way.

it is unneeded. Please don't add more noise.

see https://wiki.debian.org/DebianKernel for docs
 
> >dude break up this patch in logic parts. this an unreadable mess.
> Sorry for that, I gather everything in one patch make this patch a little
> big. Should I send them in different parts?

of course !

nobody is going to seriously review a 100k patch.
 
> >I don't get why a clang patch should patch a fs!?
> You mean patch files in fs? This is for removing valais that clang doesn't
> support.

I do not care about whatever patchset you want to promote, our
policy concerning that is pretty clear:
https://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines

Hence if you want any non bugfix patches, get them upstream accepted first.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150604115029.gg10...@stro.at

Re: Converting kernel svn to git

[maximilian attems]

Hello everyone,

On Wed, Aug 05, 2015 at 12:46:47PM +0100, Ben Hutchings wrote:
> We've been talking about this for at least 6 years, and it's well past
> time to do it.

thanks a lot Ben for pushing this.
 
> (I think most developers are already using git-svn, but that doesn't
> properly handle tags and merges so I've never been able to make use of
> it.)

I'd be delighted to fully forget svn usage, as git svn is still a
foreign git.
 
> I started on a conversion that would include stitching in the upstream
> history for the linux package, but that depends on how we store patches
> in git and there isn't yet an obvious winner there (git-dpm vs git
> -debcherry vs dgit vs ...).  If the patches should be applied as git
> commits, then we can't represent all of history because sometimes the
> patches didn't apply.  And featuresets don't fit into this at all.
> 
> I think that the best thing to do now is to do a straight conversion of
> the debian directory only.  We can stitch in upstream later.
> 
> Here's where I am with the conversion:
> https://anonscm.debian.org/cgit/kernel/temp/

cool.

One proposition why not keep this as linux-debian-history-git
and start from scratch with what is inside of the latest svn.
This would reduce the number of branches and tags and might
be a cleaner restart. What do you think?

 
> Known bugs:
> 
> linux.git
> -
> 
> Commits tagged 2.6.12-2, 2.6.16-{15,16,17}, 2.6.18.dfsg.1-24etch2,
> 2.6.26-{17,20} are detached.
> 
> Several weird merges in early history.
> 
> Many merges in svn are not recorded in git, but this is presumably due
> to lack of mergeinfo in old svn versions.
> 
> Commit tagged 2.6.24-7 looks like a 4-way merge which shouldn't be
> possible in svn!  This might be due to svn mergeinfo accumulating
> branches.
> 
> linux-latest.git
> 
> 
> Tip of wheezy branch is detached from its parent
> 
> Many merges from sid to wheezy-backports are not recorded
> 
> No squeeze branch
> 
> linux-tools.git
> ---
> 
> Many merges from sid to trunk are not recorded
> 
> firmware-nonfree.git
> 
> 
> Tip of wheezy branch is detached from its parent
> 
> What do we do with the sid branch?
> 
> The 0.19 tag is in a firmware-nonfree subdirectory
> 
> Merge before 0.4+etchnhalf.1 should not be recorded as a merge

On the other hand, none of the known bugs you mention is a show-stopper
for the transition from my side.

kind regards,

-- 
maks


signature.asc
Description: Digital signature

Re: Converting kernel svn to git

[maximilian attems]

On Thu, Aug 06, 2015 at 06:10:01PM +0100, Ben Hutchings wrote:
> 
> No, I want that history and a break in history will just make my life
> harder.  If you only want some of the branches you can get those.

Ok, so let's go for history.
 
> > > Known bugs:
> [...]
> > On the other hand, none of the known bugs you mention is a show-stopper
> > for the transition from my side.
> 
> Yes but they would be harder to fix later.  (git filter-branch is
> powerful but it invalidates everyone else's clones.)

can you fix some of them in svn (preimport)? or does it need git-filter
changes?


-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150810200147.GA7913@gluino

Re: Linux 4.9 will be next LTS

[maximilian attems]

On Sat, Aug 13, 2016 at 07:48:07PM +0100, Ben Hutchings wrote:
> On Fri, 2016-08-12 at 12:15 -0700, Martin Michlmayr wrote:
> > 
> > Greg KH announced that 4.9 would become the next LTS release:
> > 
> > https://plus.google.com/+gregkroahhartman/posts/DjCWwSo7kqY
> 
> Then that should be the version to use in stretch, and we have a rather
> less tight schedule to prepare for release.
 

sounds good indeed.

-- 
maks


signature.asc
Description: PGP signature

Re: Kernel version for stretch

[maximilian attems]

On Thu, Jan 28, 2016 at 08:01:13PM +0100, Moritz Mühlenhoff wrote:
> Ben Hutchings  wrote:
> > For stretch, I would very much like to choose a kernel version for
> > stretch that gets longterm maintenance by Greg Kroah-Hartman. That
> > lasts 2 years from release, after which someone else (maybe me) can
> > take over.
> 
> Luis Henriques and Kamal Mostafa maintain the ckt stable kernels
> for Ubuntu-non-LTS releases for two years.
> 

Well, those efforts have not a good track record, afais Ben is maintaining
their lts Linus.

-- 
maks

Re: Kernel version for stretch

[maximilian attems]

On Sat, Jan 30, 2016 at 03:30:37PM +0100, Moritz Muehlenhoff wrote:
> On Thu, Jan 28, 2016 at 11:42:13PM +0100, maximilian attems wrote:
> > 
> > Well, those efforts have not a good track record, afais Ben is maintaining
> > their lts Linus.
> 
> I don't really understand the second half of your sentence,

one funny typo, here s/Linus/Linux/.

> but they certainly
> have a good track record: After all Jessie is based on their ckt 3.16 series
> and their 3.19 kernel is also working very well (we're using it at work 
> on top of jessie since 3.16 has some mm problems under high load). I've been 
> forwarding patches for merging to Luis and Kamal for quite a while now and 
> they've always been really responsive and helpful.

It is not an upstream sanctioned stable release and Jessie ended up squeezed.

Re: enabling orange-fs support

[maximilian attems]

Dear Alois Schlögl,

On Sat, Oct 20, 2018 at 02:36:05PM +0200, Alois Schloegl wrote:
> 
> We are looking into distributed, parallel filesystems like beegfs and
> orangefs. I'd prefer orangefs (mainly because of its license terms).
> 
> We'd like to use Debian/stable for this set up, unfortunately, the
> current debian kernel has orange-fs support disabled.

I see it got merged in 4.9 hence stable would be possible.
 
 
> Is there a chance that orange-fs will be supported in future
> debian-kernel releases ? What is  the reason for not enabling orange-fs
> (except that the configuration resides only in the "miscellaneous
> filesystem") ?

Unless it has other dependencies, which I haven't checked,
it is very likely an oversight.
 
> What would be needed in order to enable orange-fs support in the debian
> kernel releases ?

Would you mind filling a wishlist bug against the unstable linux-image?
Then once changed this would propagate into Testing.
Afterwards this could be considered for a next stable update.
 
Thanks for your input!

Kind regards,
maximilian

Re: [PATCH v2] deb-pkg: generate correct build dependencies

[maximilian attems]

On Wed, Jan 02, 2019 at 07:48:12PM +, Ben Hutchings wrote:
> On Wed, 2019-01-02 at 11:23 +0200, riku.voi...@linaro.org wrote:
> > From: Riku Voipio 
> > 
> > bison/flex is now needed always for building for kconfig. Some build
> > dependencies depend on kernel configuration, enable them as needed:
> > 
> > - libelf-dev when UNWINDER_ORC is set
> > - libssl-dev for SYSTEM_TRUSTED_KEYRING
> > 
> > Since the libssl-dev is needed for extract_cert binary, denote with
> > :native to install the libssl-dev for the build machines
> > architecture,
> > rather than for the architecture of the kernel being built.
> > 
> > Tested-by: Manivannan Sadhasivam 
> > Signed-off-by: Riku Voipio 
> 
> Reviewed-by: Ben Hutchings 

Acked-by: maximilian attems 
 
> > ---
> > v2: commit message updated
> > ---
> >  scripts/package/mkdebian | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian
> > index edcad61fe3cd..c858abf4569e 100755
> > --- a/scripts/package/mkdebian
> > +++ b/scripts/package/mkdebian
> > @@ -134,6 +134,8 @@ fi
> >  
> >  mkdir -p debian/
> >  echo $debarch > debian/arch
> > +extra_build_depends=", $(if_enabled_echo UNWINDER_ORC libelf-dev)"
> > +extra_build_depends="$extra_build_depends, $(if_enabled_echo 
> > SYSTEM_TRUSTED_KEYRING libssl-dev:native)"
> >  
> >  # Generate a simple changelog template
> >  cat < debian/changelog
> > @@ -170,7 +172,7 @@ Source: $sourcename
> >  Section: kernel
> >  Priority: optional
> >  Maintainer: $maintainer
> > -Build-Depends: bc, kmod, cpio
> > +Build-Depends: bc, kmod, cpio, bison, flex $extra_build_depends
> >  Homepage: http://www.kernel.org/
> >  
> >  Package: $packagename
> -- 
> Ben Hutchings
> Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
> 
> 

Re: Intel Vulnerability

[maximilian attems]

Dear Ozgur,

On Fri, Jan 05, 2018 at 10:29:56AM +0300, Ozgur wrote:
> 
> thanks for reply and I'm using the stable version (Debian stretch). I updated 
> last night and I don't seen any new kernel patch yet.
> 

Please use a user list for your support, this mailing list is for development 
purpose.

thank you,

-- 
maks

[ad...@alioth-lists.debian.net: Notice of mailing list closure: kernel-svn-changes]

[maximilian attems]

Dear Ben,

Anything we'd want to migrate from the old list?

thanks,
maks

- Forwarded message from alioth lists migration team 
 -

Date: Mon, 2 Apr 2018 16:21:19 +0100
From: alioth lists migration team 
To: kernel-svn-chan...@lists.alioth.debian.org
Subject: Notice of mailing list closure: kernel-svn-changes
X-Mailer: MIME::Lite 3.030 (F2.85; T2.13; A2.18; B3.15; Q3.13)

Dear list subscribers,

As per the announcement on debian-devel-announce[1] and as part of
the shutdown of the alioth service, the migration of
lists.alioth.debian.org mailing lists to alioth-lists.debian.net is now
underway.

We tried to contact the designated list owner via
kernel-svn-changes-ow...@lists.alioth.debian.org but got either no reply,
or a bounce message. Accordingly, this list will not be migrated to the
new system and will stop working on 14th April.

Information about alternatives to this service which may be more suitable
for the list can be found at
.

In the event that this list should be migrated to the new system,
please first appoint a Debian developer as a list owner, then let us know
by replying to this email, copying in the list.

More information about the new service can be found here:


Thanks,
the alioth-lists migration team.

[1] 



___
Kernel-svn-changes mailing list
kernel-svn-chan...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/kernel-svn-changes

- End forwarded message -

Re: [ad...@alioth-lists.debian.net: Notice of mailing list closure: kernel-svn-changes]

[maximilian attems]

On Wed, Apr 04, 2018 at 01:40:09PM +0100, Ben Hutchings wrote:
> 
> 
> On 4 April 2018 11:04:33 BST, maximilian attems  wrote:
> >Dear Ben,
> >
> >Anything we'd want to migrate from the old list?
> [...]
> 
> All VCS changes on Salsa are mailed out via tracker.debian.org so there's no 
> need for a new mailing list.

right, just wanted to make sure everything is fine.
So will let the maling-list expire, just emailed out the
last held bigger changelogs.

thanks,
maks

Re: Upstream source handling

[maximilian attems]

On Tue, Sep 08, 2015 at 10:52:57PM +0200, Bastian Blank wrote:
> During the linux packaging BoF at DebConf, Ben asked for usefull
> upstream source handling.  No compeling ones were mentioned.
> 
> Some years ago (yes, years), I proposed some schema based on submodules,
> but never got around to actually implement it.  I finally managed to do
> an initial implementation.  It currently lives in the linux.git in
> branch waldi/submodule.

shouldn't one use subtrees these days and not submodules.
submodules only live in contrib. subtrees got merged in
main git. 


-- 
maks

Re: erro bluetooth

[maximilian attems]

exceptional answer in spanish below.

--

Olá,

la lista es in inglés, adémas tu mail no contiene información útil
per resolvar la causa. si tu eres fisico debe hablar inglés?

On Wed, Oct 21, 2015 at 11:30:41AM -0200, Manoel Pedro de Araújo wrote:
> Olá amigos estou com um problema em meu Bluetooth. Nao consigo
> fazer transferência de dados,
> 
> quando eu ligo meu pc aparece a mensagem: *Bluetooth hci0
>  hardware error 0x37*
> 
> Uso Debian8 com interface KDE
> 
> Ja atualizei o kernel e continua aparecendo a mesma mensagem.
> 
> Alguém sabe como resolver isso?

el bluetooth on mi thinkpad functiona, no sé quel systema no
messages lo ves.

-- 
maks

Re: language of choice for k-p packaging ...

[Maximilian Attems]

On Sun, Nov 13, 2005 at 12:38:39PM -0600, Manoj Srivastava wrote:
> On Sun, 13 Nov 2005 16:38:25 +0100, Maximilian Attems <[EMAIL PROTECTED]> 
> said: 
> 
> > On Sun, Nov 13, 2005 at 03:52:31PM +0100, Maximilian Attems wrote:
> >> > Well, not wanting to relaunch the discussion at this, but i think
> >> > Python rates really high on the most-uncomprehensible langugage
> >> > contest, or at least as a language allowing or encouraging to
> >> > write incomprehensible code :) Well, at least in the
> >> > gencontrol.py incarnation of it. :)
> >> 
> 
> > ohh you meant not kernel-package but kernel packaging sorry for my
> > confusion.
> 
> Oh, I see. I can't cancel my last post, so please accept my
>  apologies for massively misconstruing  your older mail.  I was being
>  way too defensice, I thought I was being accused of being a flamew
>  war started.

sure.
was my confusion in the first place, because of the subject "k-p"
that's automatically kernel-package for me, will be more carefull.

-- 
maks
 


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

Re: [D-I] Supporting 2.6.14 kernels in base-installer

[Maximilian Attems]

On Sun, Nov 13, 2005 at 08:01:38PM +0100, Sven Luther wrote:
> On Sun, Nov 13, 2005 at 12:32:29PM -0500, Jeff Bailey wrote:
> > On dim, 2005-11-13 at 12:46 +0100, Bastian Blank wrote:
> > > I think it is possible at least for initramfs-tools to run without sysfs
> > > on the building system.
> > 
> > Right.  The caveat to this is "dep" mode.  The default mode for
> > initramfs-tools is to include all of the modules that you're likely
> > interested in booting with in the initramfs and detecting which ones to
> > use at boot time.  If you ask it to detect which modules are needed, it
> > needs a valid sysfs tree to scan (although it is resiliant in that case
> > against module name changes)
> 
> Ah, interesting.
> 
> Notice that in some case, the "most" mode will produce to huge initrd that are
> possibly not supported by the kernel/bootloader/firmware. This may be the case
> on some prep boxes on powerpc at least.

even ozlabs has no prep boxes around.
(that means no upstream support in the kernel afaik)
are there any user evidence?

-- 
maks


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

Re: [D-I] Supporting 2.6.14 kernels in base-installer

[Maximilian Attems]

On Sun, Nov 13, 2005 at 10:34:27PM +0100, Sven Luther wrote:
> On Sun, Nov 13, 2005 at 09:23:14PM +0100, Maximilian Attems wrote:
> > On Sun, Nov 13, 2005 at 08:01:38PM +0100, Sven Luther wrote:
> > > On Sun, Nov 13, 2005 at 12:32:29PM -0500, Jeff Bailey wrote:
> > > > On dim, 2005-11-13 at 12:46 +0100, Bastian Blank wrote:
> > > > > I think it is possible at least for initramfs-tools to run without 
> > > > > sysfs
> > > > > on the building system.
> > > > 
> > > > Right.  The caveat to this is "dep" mode.  The default mode for
> > > > initramfs-tools is to include all of the modules that you're likely
> > > > interested in booting with in the initramfs and detecting which ones to
> > > > use at boot time.  If you ask it to detect which modules are needed, it
> > > > needs a valid sysfs tree to scan (although it is resiliant in that case
> > > > against module name changes)
> > > 
> > > Ah, interesting.
> > > 
> > > Notice that in some case, the "most" mode will produce to huge initrd 
> > > that are
> > > possibly not supported by the kernel/bootloader/firmware. This may be the 
> > > case
> > > on some prep boxes on powerpc at least.
> > 
> > even ozlabs has no prep boxes around.
> > (that means no upstream support in the kernel afaik)
> > are there any user evidence?
> 
> Sure, i have one, p2mate has one, Attilio has one, i have knowledge of at 
> least 10 persons
> asking about prep support on the debian-powerpc mailing lists this past year,
> and debian works flawlessly on those, they are a supported model.

well ok so you may need to invest some time to get them up again.
in 2.6.15-rc1 PREP doesn't compile
-> http://marc.theaimsgroup.com/?l=linux-kernel&m=113183511810053&w=2
 
> I mean, are your words plan to drop everything but x86 and amd64 in the near
> future ? 

wtf?
keep your ad hominem attacks for someone else.

-- 
maks


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

Bug#338973: unregister_netdevice: waiting for vpn0 to become free. Usage count = 23

[Maximilian Attems]

reassign 323860 linux-image-2.6-686-smp
reassign 338973 linux-image-2.6-686-smp
merge 338973 323860
stop

On Mon, Nov 14, 2005 at 06:11:13AM +0100, Marc Lehmann wrote:
> Package: linux-image-2.6.14-2
> Version: 2.6.14-2
> Severity: important
> 
> 
> The same bug as reported against earlier debian kernels (#323860) still
> persists with 2.6.14, and does not happen with my own compiled kernels.

please reassign in those cases. :)
 
> This happens whenever I want to upgrade gnu virtual private ethernet and
> kill it (which should free the tun interface it uses). Following ifconfig
> -a or other interface-related calls hang till the machine is rebooted hard
> (shutdown hangs for obvious reasons).
 
your .config has several ethernet card enabled which are you using,
please post the running lsmod?

also could you try to boot the debian kernel with noapic in boot cmdline?

-- 
maks


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

Bug#339295: psmouse.c: Failed to reset mouse on isa0060/serio1 - works fine with 2.6.13-1-k7

[Maximilian Attems]

On Tue, Nov 15, 2005 at 11:29:27AM +0100, Joerg Morbitzer wrote:
> 
> 
> Maximilian Attems wrote:
> >On Tue, Nov 15, 2005 at 10:37:06AM +0100, Joerg Morbitzer wrote:
> > 
> >
> >>with linux-image-2.6.14-2-k7 my Logitech USB infrared mouse does not work 
> >>any
> >>longer (the infrared light turns on though). During bootup I can see
> >>these messages:
> >>
> >>kernel: psmouse.c: Failed to reset mouse on isa0060/serio1
> >>kernel: psmouse.c: Failed to enable mouse on isa0060/serio1
> >>
> >>Full boot message can be found here:
> >>
> >>http://www.mistersixt.de/tmp/dmesg-2.6.14.txt
> >>
> >>With kernel 2.6.13-1-k7 it works like expected.
> >>
> >>Let me know if you need further information.
> >
> >
> >please append dmesg of working 2.6.13,
> >also lsmod after boot for both kernels.
> >
> >output of "cat /proc/bus/input/devices" would be cool to.
> >(we might need more ;-)
> >
> 
> Sure, this is the kernel output of 2.6.13:
> 
> http://www.mistersixt.de/tmp/dmesg-2.6.13.txt

please output of dmesg, it is a pain to diff syslog.
after boot: dmesg > dmesg-2.6.13
 
> Here lsmod for both kernel versions:
> 
> http://www.mistersixt.de/tmp/lsmod-2.6.13.txt
> http://www.mistersixt.de/tmp/lsmod-2.6.14.txt
> 
> And finally the input devices:
> 
> http://www.mistersixt.de/tmp/cat-usb-device.txt
for which kernel was that?
i see an usb mouse there.


also please _append_ the messages to your mail,
instead of putting them to a temporary webdir,
where they will disappear soonest.

while we are it the appended output of he following cmd might help
(for both kernels working and non working):
cat /proc/ioports


-- 
maks



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

Bug#339295: psmouse.c: Failed to reset mouse on isa0060/serio1 - works fine with 2.6.13-1-k7

[Maximilian Attems]

On Tue, Nov 15, 2005 at 12:22:59PM +0100, Joerg Morbitzer wrote:
> 
> 
> 
> >
> >
> >please output of dmesg, it is a pain to diff syslog.
> >after boot: dmesg > dmesg-2.6.13
> Simply do "cat dmesg-2.6.14.txt | cut -d " " -f 6- " 

cool, thanks for teaching me cut usage, never got to that..

> However, check out the attachments for the plain dmesg files.

a quick diff reveals that you boot your 2.6.14 and 2.6.13 with different
kernel parameters in ?lilo?.

please try to boot 2.6.14 too with pci=noacpi or pci=routeirq

that's more an workaround..
bug should be forwarded to acpi upstream.
 
-- 
maks


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

Re: #330191: klibc 1.1.1-4 FTBFS on sparc

[Maximilian Attems]

On Sun, Nov 20, 2005 at 02:41:11PM +0100, Roland Stigge wrote:
> now that linux-headers-2.6.12-1-* is not available in sid anymore, I
> tried it with linux-headers-2.6.14-2-* (-sparc64 in this case). Besides
> the fact that the proper asm -> asm-sparc64 symlink was missing, the
> 2.6.14-2-* package is configured for SPARC32 and therefore doesn't
> provide 64 bit options like page size etc. that is needed by klibc (build).
> 
> Is this a bug or a feature? ;-)

this is a bug in current linux-headers,
which prevents upload of updated klibc.
hope it to be resolved soon.

--
maks


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

Bug#339568: initramfs-tools: patch to support udev < 0.72-2 and udev >= 0.72-2

[Maximilian Attems]

thanks paul traina for the provided fix.

solution is implemented in a different way:
http://mentors.debian.net/debian/pool/main/i/initramfs-tools/




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

Re: Bug#267600: Is CONFIG_SOFTWARE_SUSPEND enough?

[Maximilian Attems]

[ please open new bug reports for newer issues ]
aboves bug report was about enabling swsusp.

On Tue, Nov 22, 2005 at 11:39:13AM +0100, Thomas Maier wrote:
> 
> I happily discovered that CONFIG_SOFTWARE_SUSPEND is enabled in my
> 2.6.14-2-686 kernel (version 2.6.14-3) and tried to suspend to disk.
> Unfortunately it refused to suspend and after googling for a while it
> seems to me that the problem is that the IDE drivers are still compiled
> as modules.  See LKML, thread
> 
> http://marc.theaimsgroup.com/?t=11078954241&r=1&w=2
> 
> However, it is quite old.  So am I able to suspend to disk with the
> Debian kernel image somehow or would I have to recompile with the IDE
> stuff builtin?

looks like.
suse has a swsusp patch for modular ide, will try to dig it up.

--
maks


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

Re: Bug#267600: Is CONFIG_SOFTWARE_SUSPEND enough?

[Maximilian Attems]

On Wed, Nov 23, 2005 at 12:45:47PM +0100, Thomas Maier wrote:
> [not CCing to [EMAIL PROTECTED] at the request of Maximilian
> Attems, although I still don't think this bug should be closed]
 
please open a _new_ bug report, so the issue don't get lost.
 
> Am Dienstag, den 22.11.2005, 12:55 +0100 schrieb Jonas Smedegaard: 
> Well, I *think* it won't work as swsusp even refuses to suspend (so I
> could never try to resume):
> 
> swsusp: cannot find swap device, try swapon -a

please post to that bug report the output of:
* cat /proc/mounts
* cat /proc/swaps
* cat /etc/fstab
 
aboves is a quite clear message that you are not using any
swap partition. swsusp parks your data there, so no luck without. ;)

--
maks


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

Bug#340508: missing modules on s390/s390x

[Maximilian Attems]

On Wed, Nov 23, 2005 at 11:41:02PM +0100, Frans Pop wrote:
> Submitter reported additional information re initramfs-tools to d-s390 
> mailing list [1]. Most relevant information (console messages) duplicated 
> below.

ok thanks.
 
> Freeing unused kernel memory: 120k freed
> Loading, please wait...
> Begin: Initializing /dev ...
> /sbin/udevsynthesize: 13: /lib/udev/udevsynthesize: not found

fixed in 0.40 which will be uploaded shortly.

> Done.
> Begin: Loading modules ...
> Done.
> Begin: Running /scripts/init-premount ...
> Done.
> Begin: Mounting root file system ...
> Begin: Running /scripts/local-top ...
> Done.
> ALERT× /dev/dasd/0.0.0108/part1 does not exist. Dropping to a shell×

that needs to be looked at.
 
> [1] http://lists.debian.org/debian-s390/2005/11/msg00017.html

--
maks

Re: 2.6.14 status summary, and upcoming 2.6.15 ...

[Maximilian Attems]

On Sun, Nov 27, 2005 at 07:15:22PM -0500, Kyle McMartin wrote:
> On Mon, Nov 28, 2005 at 12:13:50AM +0100, Sven Luther wrote:
> > Anyway, i will start with the powerpc situation :
> >
> 
> parisc:
>   - klibc will work after this patch is applied:
> http://www.zytor.com/pipermail/klibc/2005-November/001174.html
>   - I haven't (and won't for the next month) have time to do
> anything, as exams are underway.
>   - parisc patchset is mostly merged in 2.6.15-rc2 
> 
> Cheers,
>   Kyle

thanks i got this patch and i plan to upload parisc fixed klibc
early this week.
currently waiting for a patch from svenl to build against
linux-kernel-headers, status?

a++

--
maks


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

Bug#341014: broken with udev 0.76

[Maximilian Attems]

tags 341014 pending
stop

On Sun, Nov 27, 2005 at 08:05:35PM +0100, Heikki Henriksen wrote:
> 
> udev 0.76 failed to queue events correctly and didn't populate /dev at
> all using initramfs-tools. I only got a /dev/.udev/failed.

urggs indeed, will need another high urgency upload,
will do this afternoon.

> No devices in /dev lead to failure to find root and no boot.

initramfs-tools 0.40 works with udev 0.74,
for 0.76 we need to invoke it differently.
fix was discussed with udev Maintainer and is on its way.
 
> To get up and running again I had to build a new initrd on a remote
> system and copy it over using a live-cd.
> 
> yaird seems to have no problems with the same kernel (2.6.14-2-k7) and
> udev (0.76-2)

baah sorry for that mess.
in the middle term udev initramfs-tools hooks will be maintained
by the udev maintainer so we shouldn't run that badly out of sync.

regards

--
maks


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

Bug#341152: initrd-tools: unable to boot after replacing devfs with udev: kernel panic, unable to create null, no console

[Maximilian Attems]

On Mon, Nov 28, 2005 at 12:59:34PM -0600, Moshe Yudkowsky wrote:
> I cannot get 2.6.12 or 2.6.12 to boot because of the transition from
> devfs to udev, and the problem seems to lie with initrd.
> 

initrd-tools is phasing out, if you use testing and udev 0.74
pick initramfs-tools 0.40 from unstable.
if you use newer udev you need initramfs-tools 0.41 from debian mentors
-> http://mentors.debian.net/debian/pool/main/i/initramfs-tools/

if that doesn't work out for you check the alternative yaird.

regards maks


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

Bug#341162: initramfs-tools: add mptspi module

[Maximilian Attems]

tags 341162 patch
thanks

On Mon, Nov 28, 2005 at 01:20:18PM -0700, dann frazier wrote:
> 
> The mptspi module is required for at least some machines that use the mptscsih
> driver for the root device.
> 
> Please bzr merge http://dannf.org/bzr/initramfs-tools
> 
> (I'm new to bzr - is this the appropriate way to send you a patch?)

cool thanks out of curiosity i fetched your branch.
seems to work fine.

latest version just reached incoming with needed udev fixes,
will throw in your fix as soon 0.41 reaches testing.

--
maks


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

Re: 2.6.14 status summary, and upcoming 2.6.15 ...

[maximilian attems]

On Mon, 28 Nov 2005, Sven Luther wrote:

> On Mon, Nov 28, 2005 at 11:26:42AM +0100, Marco d'Itri wrote:
> > On Nov 28, Sven Luther <[EMAIL PROTECTED]> wrote:
> > 
> > > Well, i saw passing a couple of reports about the ramdisk not creating 
> > > needed
> > > devices, which sound RCish for this case, what about those ? Also, more
> > I discussed these today with Maximilian Attems, initramfs-tools needed
> > to be updated and now that we have /dev/.udev/queue/ will be more
> > reliable.

indeed that's very cool,
was looking for such a condition since udev 0.072..
 
> > > importantly, what are the bugs closed in the unstable udev, but open in 
> > > the
> > > testing one, which will be the one used once 2.6.14 goes to testing.
> > Today I will make a new upload with priority=high.
> 
> Which will be able to enter testing then, cool.

you are one day before initramfs-tools,
missed dinstall run shortly, latest initramfs-tools is in incoming.
 
--
maks


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

Re: 2.6.14 status summary, and upcoming 2.6.15 ...

[Maximilian Attems]

On Mon, 28 Nov 2005, Sven Luther wrote:

> On Mon, Nov 28, 2005 at 09:04:59AM +0100, Maximilian Attems wrote:
> > currently waiting for a patch from svenl to build against
> > linux-kernel-headers, status?
> 
> Nope, sorry, i had no real time to investigate this more than i did, and my
> tests didn't work out because of the asm-powerpc symlink farm breakage.

ok fine so it was good to fix that :)
 
> I believe that l-k-h needs to be setup to use another newer kernel headers, or
> better yet use the same kernel libc project headers as ubuntu uses, altough
> jbailey reported having build klibs with and older kernels (2.6.12 or
> something such). not sure what influence the pure64 patch from Andreas Jochens
> has on this, but i guess it confuses the issue more.
> 
> My own testing where hurt by the ARCH=powerpc header migration, which is now
> fixed in 2.6.14-4, and i only need to find time for it again.

jbaley mentioned needing to fix linux-kernel-headers.
so in the meantime i would be happy if we could reintroduce that
asm symlink. need to talk with waldi, didn't reach him today.

--
maks


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

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

[Maximilian Attems]

On Wed, Nov 30, 2005 at 06:51:44AM +, Horms wrote:
> Mikhail Gusarov <[EMAIL PROTECTED]> wrote:
> > 
> > You ([EMAIL PROTECTED]) wrote:
> > 
> > H> If you know more, please add your knowledge below.
> > 
> > [skip]
> > 
> > 2.6.14-2 still enables the outdated ieee80211 :(
> > 
> > Fixing this is simply a matter of disabling CONFIG_IEEE80211. This
> > will allow to use ipw2200 (ipw2100 also) drivers built using
> > module-assistant as before.
> > 
> 
> The complete list of changes needed to turn off ieee80211 seems to be:
> 
> # CONFIG_HOSTAP is not set
> # CONFIG_IPW2100 is not set
> # CONFIG_IPW2200 is not set
> # CONFIG_IEEE80211_CRYPT_TKIP is not set
> # CONFIG_IEEE80211_CRYPT_WEP is not set
> # CONFIG_IEEE80211_CRYPT_CCMP is not set
> # CONFIG_IEEE80211 is not set
> 
> Or in other words HOSTAP and IPW2100, IPW2200 and 
> HOSTAP (Prism) also needs to be disabled. Is the
> latter acceptable collateral dammage? 
> 
> I was under the impression that upstream had 
> recently updated ieee80211. Is it still out of 
> date in 2.6.14 ?

yes.
2.6.15 ipw2XXX are fine and with up2date ieee80211 stack.
there we should really enable those.

--
maks


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

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

[Maximilian Attems]

On Wed, Nov 30, 2005 at 06:22:17PM +0900, Horms wrote:
> On Wed, Nov 30, 2005 at 10:09:54AM +0100, Maximilian Attems wrote:
> > On Wed, Nov 30, 2005 at 06:51:44AM +, Horms wrote:
> > > Mikhail Gusarov <[EMAIL PROTECTED]> wrote:
> > > > 
> > > > You ([EMAIL PROTECTED]) wrote:
> > > > 
> > > > H> If you know more, please add your knowledge below.
> > > > 
> > > > [skip]
> > > > 
> > > > 2.6.14-2 still enables the outdated ieee80211 :(
> > > > 
> > > > Fixing this is simply a matter of disabling CONFIG_IEEE80211. This
> > > > will allow to use ipw2200 (ipw2100 also) drivers built using
> > > > module-assistant as before.
> > > > 
> > > 
> > > The complete list of changes needed to turn off ieee80211 seems to be:
> > > 
> > > # CONFIG_HOSTAP is not set
> > > # CONFIG_IPW2100 is not set
> > > # CONFIG_IPW2200 is not set
> > > # CONFIG_IEEE80211_CRYPT_TKIP is not set
> > > # CONFIG_IEEE80211_CRYPT_WEP is not set
> > > # CONFIG_IEEE80211_CRYPT_CCMP is not set
> > > # CONFIG_IEEE80211 is not set
> > > 
> > > Or in other words HOSTAP and IPW2100, IPW2200 and 
> > > HOSTAP (Prism) also needs to be disabled. Is the
> > > latter acceptable collateral dammage? 
> > > 
> > > I was under the impression that upstream had 
> > > recently updated ieee80211. Is it still out of 
> > > date in 2.6.14 ?
> > 
> > yes.
> > 2.6.15 ipw2XXX are fine and with up2date ieee80211 stack.
> > there we should really enable those.
> 
> Ok, so I should just go ahead and put my patch into the 2.6.14 branch?
> Or should we leave it as 2.6.15 probably isn't that far away... maybe

depends if d-i will base itself on 2.6.14 for next beta
than it's maybe nicer to have those ancient than nothing.

there are still some -rc expected,
maybe we get a christmas present? ;)

--
maks


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

Bug#341378: kernel 2.6.12 and 2.6.14 crash on boot loading usb drivers on a sis chipset

[Maximilian Attems]

On Wed, Nov 30, 2005 at 11:05:26AM +0100, giorgiove wrote:
> Package: kernel
> Severity: critical
> Justification: breaks the whole system
> 

hmm as it works for others that severity seems midly exagerated,
leave it to other d-kernel maintainer.
 
> -- System Information:
> Debian Release: testing/unstable
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.14-2-686
> Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
>  With new udev (I reported to udev maintainer but it says it's a
>  kernel problem) the kernel doesn't' boot anymore making a mess of usb
>  tree as described in the log file I attached below. the only way is
>  to deinnstall udev and use old hotplug

please send in:
working dmesg after boot, lspci output.


--
maks


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

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

[Maximilian Attems]

On Wed, Nov 30, 2005 at 12:49:28PM +0100, Frans Pop wrote:
> On Wednesday 30 November 2005 11:44, Maximilian Attems wrote:
> > On Wed, Nov 30, 2005 at 06:22:17PM +0900, Horms wrote:
> > > Ok, so I should just go ahead and put my patch into the 2.6.14 branch?
> > > Or should we leave it as 2.6.15 probably isn't that far away... maybe
> >
> > depends if d-i will base itself on 2.6.14 for next beta
> > than it's maybe nicer to have those ancient than nothing.
> 
> We will use whatever is in testing at the time of the release. So it 
> depends very much on when 2.6.15 will be uploaded (and even if 2.6.14 
> will have moved to testing before then).
> 
> Are there major changes from .14 to .15? If not, we should be able to 
> change over to .15 relatively fast.

better ntfs support, up2date ipw2XXX, vfs support "shared subtree",
fbcon console rotation + usual bunch of fixes and driver upgrades.
no acpi change.
 
> My preliminary target for d-i beta2 is 2nd half of January. We'll need at 
> least .14 in testing for the release.

.15 should come around christmas,
so it should be early enough for all archs to focus on.

--
maks



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

Bug#341393: linux-image-2.6.14-2-686 does not boot on HP Compaq nx8220 Laptop

[Maximilian Attems]

tags 341393 moreinfo
stop

On Wed, Nov 30, 2005 at 01:27:45PM +0100, [EMAIL PROTECTED] wrote:
> 
> 
> 
> 
> Package: linux-image-2.6.14-2-686
> 
> The mentioned kernel does not boot.
> It says, that IRQ routing is not possible.
> acpi=off and pci=routeirq have no effect.

what's the last error message?

can you paste log?
 
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
> unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig.
> Diese Nachricht dient lediglich dem Austausch von Informationen und
> entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten
> Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den
> Inhalt uebernehmen.
> 
> 
> This message is confidential and may be privileged. If you are not the
> intended recipient, we kindly ask you to  please inform the sender.
> Any unauthorised dissemination or copying hereof is prohibited. This
> message serves for information purposes only and shall not have any
> legally binding effect. Given that e-mails can easily be subject to
> manipulation, we can not accept any liability for the content
> provided.

wtf
your message is public, keep away such strange footers.
won't help your much.

--
maks


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

Re: [kernel] r4856 - dists/trunk/linux-2.6/debian/bin

[maximilian attems]

On Mon, 21 Nov 2005, Frederik Schüler wrote:

> Author: fschueler-guest
> Date: Mon Nov 21 07:59:55 2005
> New Revision: 4856
> 
> Modified:
>dists/trunk/linux-2.6/debian/bin/install-header
> Log:
> Comment out include/asm symlink deletion in the generic per-arch 
> linux-headers package. This symlink was present in headers packages before 
> 2.6.14-1.
> 
> 
> Modified: dists/trunk/linux-2.6/debian/bin/install-header
> ==
> --- dists/trunk/linux-2.6/debian/bin/install-header   (original)
> +++ dists/trunk/linux-2.6/debian/bin/install-header   Mon Nov 21 07:59:55 2005
> @@ -15,7 +15,7 @@
>  # we'll want to drop this bit of code.  The asm-* directories should remain.
>  DIRS="generic $(for i in $KERNEL_HEADER_DIRS; do echo -n '|' $i; done)"
>  
> -rm -f include/asm
> +#rm -f include/asm
>  eval "
>  for i in include/asm-*; do
>   case \${i#include/asm-} in

can we put that patch in?

would unbreak klibc.

--
maks


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

Bug#332824: fixed udev -> fixed initramfs-tools?

[maximilian attems]

please retest with latest initramfs-tools in unstable aka version 0.41.
it needs latest udev 0.76-3 too.
the various seen timing bugs should be fixed thanks to newer udev.

please add feedback to your bug report.

--
maks



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

Bug#336317: fixed udev -> fixed initramfs-tools?

[maximilian attems]

please retest with latest initramfs-tools in unstable aka version 0.41.
it needs latest udev 0.76-3 too.
the various seen timing bugs should be fixed thanks to newer udev.

please add feedback to your bug report.

--
maks



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

Bug#337033: fixed udev -> fixed initramfs-tools?

[maximilian attems]

please retest with latest initramfs-tools in unstable aka version 0.41.
it needs latest udev 0.76-3 too.
the various seen timing bugs should be fixed thanks to newer udev.

please add feedback to your bug report.

--
maks



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

Bug#337045: fixed initramfs-tools?

[maximilian attems]

please retest with latest initramfs-tools in unstable aka version 0.41.
it needs latest udev 0.76-3 too.
the various seen timing bugs should be fixed thanks to newer udev.

please add feedback to your bug report.

--
maks



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

Bug#338406: fixed initramfs-tools?

[maximilian attems]

please retest with latest initramfs-tools in unstable aka version 0.41. 
it needs latest udev 0.76-3 too.
the various seen timing bugs should be fixed thanks to newer udev.

please add feedback to your bug report.

--
maks



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

Bug#341559: yaird: fails to create initrd

[Maximilian Attems]

clone 341559 -1
reassign -1 initramfs-tools
stop

On Thu, Dec 01, 2005 at 01:33:10PM +0100, Hans Ekbrand wrote:
> On Thu, Dec 01, 2005 at 12:51:48PM +0100, maximilian attems wrote:
> > just saw your bugreport could you try latest initramfs-tools 
> > from unstable too?  would be cool to get it tested,
> > and report probable boot error (or success)?
> 
> Exactly the same error:
> 
> # dpkg --configure -a
> Setting up linux-image-2.6.14-2-powerpc (2.6.14-4) ...
> Using /usr/sbin/mkinitrd.yaird to build the ramdisk.

well you are still using yaird.

please try temporarly adding to /etc/kernel-img.conf
ramdisk = /usr/sbin/mkinitramfs /usr/sbin/mkinitrd
(you might need to comment that as soon as you want to test yaird).

> Other suitable ramdisk generating tools : /usr/sbin/mkinitramfs.
so it's installed ;)

--
maks



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

Bug#341559: yaird: fails to create initrd

[Maximilian Attems]

On Thu, Dec 01, 2005 at 03:16:04PM +0100, Sven Luther wrote:
> On Thu, Dec 01, 2005 at 02:08:14PM +0100, Hans Ekbrand wrote:
> > On Thu, Dec 01, 2005 at 01:41:01PM +0100, Maximilian Attems wrote:
> > > clone 341559 -1
> > > reassign -1 initramfs-tools
> > > stop
> > > 
> > > On Thu, Dec 01, 2005 at 01:33:10PM +0100, Hans Ekbrand wrote:
> > > > On Thu, Dec 01, 2005 at 12:51:48PM +0100, maximilian attems wrote:
> > > > > just saw your bugreport could you try latest initramfs-tools 
> > > > > from unstable too?  would be cool to get it tested,
> > > > > and report probable boot error (or success)?
> > > > 
> > > > Exactly the same error:
> > > > 
> > > > # dpkg --configure -a
> > > > Setting up linux-image-2.6.14-2-powerpc (2.6.14-4) ...
> > > > Using /usr/sbin/mkinitrd.yaird to build the ramdisk.
> > > 
> > > well you are still using yaird.
> > 
> > OK. I thought installing initramfs-tools would suffice, I didn't know
> > that it was an alternativ to yaird, nor that it would not be used by
> > default.
> > 
> > > please try temporarly adding to /etc/kernel-img.conf
> > > ramdisk = /usr/sbin/mkinitramfs /usr/sbin/mkinitrd
> > 
> > OK.
> > 
> > Now it worked! the initrd was created and the boot successful.
> 
> Can you try the same thing also using MODULES=dep (or whatever that option is
> called) in /etc/mkinitramfs/mkinitramfs.conf please ? 

no please dont!!

svenl stop givine bad advices to users.
#341559 is an yaird bug,
the initramfs one was cloned as #341567 and is fixede.

-- 
maks

ps one last time cc 341559, sorry for the noise jonas.



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

Bug#341559: yaird: fails to create initrd

[Maximilian Attems]

On Thu, Dec 01, 2005 at 03:50:46PM +0100, Jonas Smedegaard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Thu, 1 Dec 2005 15:27:35 +0100
> Maximilian Attems <[EMAIL PROTECTED]> wrote:
> 
> > > > Now it worked! the initrd was created and the boot successful.
> > > 
> > > Can you try the same thing also using MODULES=dep (or whatever that
> > > option is called) in /etc/mkinitramfs/mkinitramfs.conf please ? 
> > 
> > no please dont!!
> > 
> > svenl stop givine bad advices to users.
> > #341559 is an yaird bug,
> > the initramfs one was cloned as #341567 and is fixede.
> 
> Why not? Is that option somehow unsupported?
> 
> We have here a chance to test initramfs-tools on a tricky machine - and
> Sven suggests to then extend the test to not only the default setting
> but also the more compact one.
> 
> It is no secret that Sven and I is fond of yaird, but this is no
> competition: Do you prefer discovering possible bugs closer to release?


defaults are set out of *dam-good-reasons*. :)
if you wana play around with them do it on your dev machine.
if svenl is serious about his little pet option than he would have
followed up to his bug report long since 5th november.
it's none of the business of this bug reporter.

it seems like that very nice old world mac had np booting an full
featured initramfs and reporter wanted to get his machine up quickly.


-- 
maks


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

Bug#337318: initramfs-tools: No way to specify module options for initramfs

[maximilian attems]

tags 337318 moreinfo
stop

On Thu, 03 Nov 2005, Martin Wilck wrote:

> ramfs. This means that vital module options cannot be passed to the
> initramfs system. For my laptop I need the line "options libata 
> atapi_enabled=1"
> to be able to use my CD drive.

in which file to you add that line?
 
> For other systems (e.g. fibre channel with persistent binding) the
> problems will be more severe.

newer initramfs-tools ubuntu upstream copies across modprobe aliases
and will add blacklist too.

thanks for your feedback.

--
maks



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

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

[maximilian attems]

tags 337176 moreinfo
tags 337607 moreinfo
stop

On Wed, 02 Nov 2005, Daniel Jacobowitz wrote:

> The generated initrd has ld.so in /lib, but no /lib64 symlink.  But the ELF
> interpreter of all amd64 binaries points to /lib64.  So the kernel fails to
> load /bin/sh.
> 
> I'm going to try with the directory manually created next.


please retest with latest initramfs-tools and udev from unstable,
that issue should be fixed, i`ve at least 2 reported successes.

in order to regenerate your initramfs you need to
dpkg-reconfigure your linux image package.
or you want to call "update-initramfs -t -u -k 2.6.14-1-686"
replace 2.6.14-1-686 with your exact uname -r output.

thanks

--
maks


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

Bug#340508: missing modules on s390/s390x

[maximilian attems]

tags 340508 moreinfo
thanks

On Thu, 24 Nov 2005, Maximilian Attems wrote:

> On Wed, Nov 23, 2005 at 11:41:02PM +0100, Frans Pop wrote:
> > Submitter reported additional information re initramfs-tools to d-s390 
> > mailing list [1]. Most relevant information (console messages) duplicated 
> > below.
> 
> > Begin: Running /scripts/local-top ...
> > Done.
> > ALERT× /dev/dasd/0.0.0108/part1 does not exist. Dropping to a shell×
> 
> that needs to be looked at.
>  
> > [1] http://lists.debian.org/debian-s390/2005/11/msg00017.html

the udev stuff is fixed in between.
can you please retest if that device gets created?

if not working please post lsmod of a running machine.
thanks

--
maks

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

[Maximilian Attems]

tags 337176 -moreinfo
retitle 337176 troubles due to 32-bit chroot on amd64
severity 337176 important
severity 337607 normal
retitle 337607  Boot scripts tries to use not included ?mdrun?
stop

On Sun, Dec 04, 2005 at 01:24:41PM -0500, Daniel Jacobowitz wrote:
 
> I've got good news and bad news :-)

the good news goes to the closed bug report, as both submitter
reported that the old problem (no devices for lvm and raid) was solved.

the third bug report is about running binaries that are not on the
initramfs (generating harmless errors). 
i know that it is not the case anymore for evms, need 
to look into the md case, so keeping around too. ;)
 
> It basically works.  However, there was one problem.  I have a 32-bit
> Debian chroot on this amd64 machine, and its library directories are in
> /etc/ld.so.conf.  Which basically works.  But, due to a quirk in
> ldconfig and some Debian-specific rules on symlinks out of /usr, I've
> got this:

ok cool setup, thanks for the test report,
will look into this next week.
retitled your bug report accordingly, higher severity as many amd64
setups may use an 32bit chroot.

regards

--
maks


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

Bug#341930: initramfs-tools: initrd missing mptspi module for LSI scsi

[maximilian attems]

On Sun, 04 Dec 2005, Frans Pop wrote:

> Reason is that the driver mtpspi (./message/fusion/mptspi.ko) is missing 
> in the initrd.
> 
> Modules mptbase and mptscsih are present, but these are not loaded 
> automatically by udev and are anyway not sufficient to get the partitions 
> recognized.
> 
> After including mptspi in /etc/mkinitramfs/modules and regenerating the 
> initrd, the system booted normally.

that's bug #341162, which is pending and will be fixed with next upload.
 
> Note that AFAIK the module mtpspi is new in 2.6.14. There is also a number 
> of other (new) mpt* drivers in ./message/fusion, but I have no idea if 
> these should be included too.
> 
> in 2.6.12: mptbase, mptctl, mptlan, mptscsih
> new in 2.6.14: mptfc, mptsas, mptspi

keeping it open as reminder for those.


--
maks



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

Bug#341392: (fwd) Bug#341392: linux-2.6: kernel BUG at mm/slab.c:1807!

[maximilian attems]

please take a look at belows BUG_ON()
at a quick glance didn't find a patch for that in git-commits-list.
belows kernel has all fixes from the latest 2.6.14.3 stable.


- Forwarded message from Frans Pop <[EMAIL PROTECTED]> -

Subject: Bug#341392: linux-2.6: kernel BUG at mm/slab.c:1807!
Date: Wed, 30 Nov 2005 13:14:02 +0100
From: Frans Pop <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

Package: linux-2.6
Version: 2.6.14-4
Severity: serious

The following error happens on Debian Installer boot in vmware (386 kernel).
This problem was not present in -3.

The system does come up after the error, but it looks so basic (memory
management AFAICT) that I've set RC severity anyway.
Feel free to adjust if you disagree.

Cheers,
FJP

ACPI: Processor [CPU0] (supports 8 throttling states)
kmem_cache_create: duplicate cache UNIX
[ cut here ]
kernel BUG at mm/slab.c:1807!
invalid operand:  [#1]
Modules linked in: unix thermal processor fan pcnet32 mii uhci_hcd usbcore
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202   (2.6.14-2-386)
EIP is at kmem_cache_create+0x4ea/0x64c
eax: 002b   ebx: c9c26b4c   ecx: c02f8080   edx: 206b
esi: c0303829   edi: ca86fde9   ebp: c9c26980   esp: c988ff38
ds: 007b   es: 007b   ss: 0068
Process modprobe (pid: 1605, threadinfo=c988e000 task=c98c8a70)
Stack: c02ba8f8 ca86fde4 000a c9a957a0 c9c2699c ff80 0080 c000
   0080 ca870080 ca86fd60 0804e154 ca86fde4 c02410d2 ca86fde4 015c
    2000   ca804000 ca870080 0804e190 0804e154
Call Trace:
 [] proto_register+0x56/0x1b4
 [] af_unix_init+0x0/0x5f [unix]
 [] af_unix_init+0xd/0x5f [unix]
 [] sys_init_module+0x99/0x16c
 [] syscall_call+0x7/0xb
Code: c9 fc ff ff 55 e8 0f 0e 00 00 59 e9 a9 fd ff ff 90 ff 74 24 30 68 f8 a8 
2b c0 e8 6e b3
 fd ff ff 05 4c 16 39 c0 0f 8e cb 15 00 00 <0f> 0b 0f 07 0d a0 2b c0 58 5a e9 
d7 fd ff ff b8
 00 e0 ff ff 21
 <6>usbcore: registered new driver usbkbd
drivers/usb/input/usbkbd.c: :USB HID Boot Protocol keyboard driver
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid



- End forwarded message -



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

Bug#339091: initramfs-tools: lacking documentation

[maximilian attems]

ramfs. This means that most executables, unless
compiled with klibc, will automatically include glibc in the image which will
increase its size by several hundred kilobytes.


.SH BOOT SCRIPTS

Similarly to hook scripts, boot scripts can be found in two places
/usr/share/initramfs-tools/scripts/ and /etc/mkinitramfs/scripts/. There are a
number of subdirectories to these two directories which control the boot stage
at which the scripts are executed.

.SS Header
Like for hook scripts, there are no guarantees as to the order in which the
different scripts in one subdirectory (see "Subdirectories" below) are
executed. In order to define a certain order, a similar header as for hook
scripts should be used:

.RS
.nf
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}

case $1 in
prereqs)
prereqs
exit 0
;;
esac
.fi
.RE

Where PREREQ is modified to list other scripts in the same subdirectory if 
necessary.

.SS Help functions
A number of functions (mostly dealing with output) are provided to boot scripts:

.TP
\fB \fI
log_success_msg
Logs a success message
.RS
.PP
.B Example:
log_success_msg "Frobnication successful"
.RE

.TP
\fB \fI
log_failure_msg
Logs a failure message
.RS
.PP
.B Example:
log_failure_msg "Frobnication component froobz missing"
.RE

.TP
\fB \fI
log_warning_msg
Logs a warning message
.RS
.PP
.B Example:
log_warning_msg "Only partial frobnication possible"
.RE

.TP
\fB \fI
log_begin_msg
Logs a message that some processing step has begun

.TP
\fB \fI
log_end_msg
Logs a message that some processing step is finished
.RS
.PP
.B Example:
.PP
.RS
.nf
log_begin_msg "Frobnication begun"
# Do something
log_end_msg
.fi
.RE
.RE

.TP
\fB \fI
panic
Logs an error message and executes a shell in the initramfs image to allow the
user to investigate the situation.
.RS
.PP
.B Example:
panic "Frobnication failed"
.RE

.SS Subdirectories
Both /usr/share/initramfs-tools/scripts and /etc/mkinitramfs/scripts contains
the following subdirectories.

.TP
\fB \fI
init-top
the scripts in this directory are the first scripts to be executed after sysfs
and procfs have been mounted and /dev/console and /dev/null have been created.
No other device files are present yet.

.TP
\fB \fI
init-premount
runs the udev hooks for populating the /dev tree (udev will keep running until
init-bottom) after modules specified by hooks and /etc/mkinitramfs/modules have
been loaded.

.TP
\fB \fI
local-top OR nfs-top
After these scripts have been executed, the root device node is expected to be
present (local) or the network interface is expected to be usable (nfs).

.TP
\fB \fI
local-premount OR nfs-premount
are run after the sanity of the root device has been verified (local) or the
network interface has been brought up (nfs), but before the actual root fs has
been mounted.

.TP
\fB \fI
local-bottom OR nfs-bottom
are run after the rootfs has been mounted (local) or the nfs root share has
been mounted. udev is stopped.

.TP
\fB \fI
init-bottom
are the last scripts to be executed before procfs and sysfs are moved to the
real rootfs and execution is turned over to the init binary which should now be
found in the mounted rootfs.

.SH EXAMPLES

.SS Hook script
An example hook script would look something like this (and would usually be
placed in /etc/mkinitramfs/hooks/frobnicate):

.RS
.nf
#!/bin/sh
# Example frobnication hook script

PREREQ="lvm"
prereqs()
{
echo "$PREREQ"
}

case $1 in
prereqs)
prereqs
exit 0
;;
esac

. /usr/share/initramfs-tools/hook-functions
# Begin real processing below this line

if [ ! -x "/sbin/frobnicate" ]; then
exit 0
fi

force_load frobnicator interval=10
cp /sbin/frobnicate "${DESTDIR}/sbin"
exit 0
.fi
.RE

.SS Boot script
An example boot script would look something like this (and would usually be 
placed in /etc/mkinitramfs/scripts/local-top/frobnicate):

.RS
.nf
#!/bin/sh
# Example frobnication boot script

PREREQ="lvm"
prereqs()
{
echo "$PREREQ"
}

case $1 in
prereqs)
prereqs
exit 0
;;
esac

# Begin real processing below this line
if [ ! -x "/sbin/frobnicate" ]; then
panic "Frobnication executable not found"
fi

if [ ! -e "/dev/mapper/frobb" ]; then
panic "Frobnication device not found"
fi

log_begin_msg "Starting frobnication"   
/sbin/frobnicate "/dev/mapper/frobb" || panic "Frobnication failed"
log_end_msg

exit 0
.fi
.RE

.SH AUTHOR
The initramfs-tools are written by Jeff Bailey <[EMAIL PROTECTED]>.
.PP
This manual was written by David Härdeman <[EMAIL PROTECTED]>,
updated by Maximilian Attems <[EMAIL PROTECTED]>.

Bug#339091: initramfs-tools: lacking documentation

[maximilian attems]

tags 339091 pending
thanks

On Tue, 06 Dec 2005, David =?UTF-8?Q?H=C3=A4rdeman ?= wrote:

> I hope this is sufficient:
> 

yes! :)
 
> > i've included some small updates to it to match current state.
> > as it's late please proof read too ;-)
> 
> I'll try to find time to proofread it later this week. If the man page is
> already in the package by then I'll just file a new bug :)

it's already in the bzr public archive for next upload after 0.42.
bzr branch http://debian.stro.at/bzr-test/initramfs-tools/

--
maks



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

Re: [kernel] r4856 - dists/trunk/linux-2.6/debian/bin

[Maximilian Attems]

On Tue, Dec 06, 2005 at 12:39:42PM +0100, Bastian Blank wrote:
> On Wed, Nov 30, 2005 at 04:55:55PM +0100, maximilian attems wrote:
> > can we put that patch in?
> 
> No, it is NOT possible to build things against this package.

baah, it is.
please tell what is breaking because of the asm link?
 
> > would unbreak klibc.
> 
> klibc is a userspace part, not a kernel modul. The headers packages are
> there to build kernel modules against.

klibc was almost included into linux upstream,
but missed somehow the freeze before the 2.6 release.

it is usperspace, but it's build is not polished as described
in its klibc/README.
it needs a link to a fresh kernel source.
linux-headers is nicely providing those.

if you send me a patch that build klibc against linux-kernel-headers,
your revert is fine until then klibc needs to be updated for different
archs and needs unfucked linux-headers.

-- 
maks


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

Re: [kernel] r4856 - dists/trunk/linux-2.6/debian/bin

[Maximilian Attems]

On Tue, Dec 06, 2005 at 01:29:39PM +0100, Bastian Blank wrote:
> On Tue, Dec 06, 2005 at 12:49:49PM +0100, Maximilian Attems wrote:
> > On Tue, Dec 06, 2005 at 12:39:42PM +0100, Bastian Blank wrote:
> > > No, it is NOT possible to build things against this package.
> > baah, it is.
> > please tell what is breaking because of the asm link?
> 
> The asm link may point to any of the matching kernel architectures for a
> given debian architecture, which one do you want?
> 
> Bastian

well the ones it pointed for linux-headers-2.6.12 - worked fine there.
until it gets properly fixed.

-- 
maks


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

Bug#342057: initramfs-tools: initrd fails to load BusLogic module on boot

[maximilian attems]

reassign 342057 linux-2.6
tags 342057 upstream
stop

On Mon, 05 Dec 2005, Frans Pop wrote:

> After a test in vmware installing 2.6.14-4-686 using initramfs-tools, the 
> system failed to reboot.
> 
> AFAICT the initrd (udev?) failed to load the BusLogic module even though 
> it is included in the initrd.
> Note that BusLogic is known to be missing sysfs support.

well that's a kernel bug, those reasigning.

the ubuntu tree has a fix for that will commit it soon to the d-kernel repo:
- [scsi/BusLogic] Add MODULE_DEVICE_TABLE

--
maks



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

Bug#342387: oops on find_get_block with reiserfs

[Maximilian Attems]

tags 342387 important
stop

On Wed, Dec 07, 2005 at 05:54:40PM +0100, yoann wrote:
> Package: kernel-image-2.6.8-2-686
> Version: 2.6.8-16
> Severity: critical

baah works for others downgrading.
 
> I had an oops on my box :

looks like one of those reiserfs races,
with some chances they are fixed in newer kernels.
2.6.8 reiserfs is not good on the sanity checking front.

you might want to use one of those backports floating around
or change to a more stable fs.

-- 
maks



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

Bug#342387: oops on find_get_block with reiserfs

[maximilian attems]

On Wed, 07 Dec 2005, Stephen Gran wrote:

> 
> Downgrading a bug in a Debian package with the response 'use a package
> from somewhere outside Debian' doesn't feel right somehow.
> 
> I understand that the kernel team is quite busy, and you can't fix every
> bug.  If this is an ongoing issue, as I suspect, perhaps setting up
> official backport kernels somewhere would be a nice idea?
> 
> Just a thought, and take care,

if you are bound to 2.6.8 use a more stable fs like ext{2,3},
reiserfs is getting better, but not recommended for rock solid.

regarding the backports, there is an an semi-official one
-- snipp from a mail by horms to debian-kernel
I think I need to write a canned response for 2.6.8 bugs:

As upstream kernel development moves at a rapid pace its virtually
impossible to backport other than trivial fixes. Without spending
a lot of time investingating your problem, would it be possible
to see if the 2.6.12 backport to sarge, a significantly newer kernel,
helps your immediate problem.

http://packages.vergenet.net/sarge-backports/
--

2.6.8 is stoneage, it mostly works with older hardware but..

regards

-- 
maks


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

Re: Kernel 2.4.xx

[Maximilian Attems]

On Fri, Dec 09, 2005 at 01:51:15PM +0100, Matthias Erich Popp wrote:
> Why ist Kernel 2.4.27  the last Debian Kernel  
> 2.4.32 can I find on www.kernel.org

the debian 2.4.27 has all the security fixes of 2.4.32
upgrade to 2.6, welcome to the present :)

there has been some activity lately concerning the 2.4 branch,
you are more then welcome to help testing it.
h01ger will point you to his archive.

--
maks


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

Re: Setting up a server with sarge: Which kernel to use?

[Maximilian Attems]

On Fri, Dec 09, 2005 at 03:43:01PM +0100, Michael Meyer wrote:
> I would like to set up a kernel with sarge. But I do
> not know if there is a kernel available which has all
> the necessary security fixes?
> The precompiled kernel images of sarge all seem to be
> last updated before
> the release of sarge. The same goes with the
> kernel-source (both 2.4.27 
> and 2.6.8). And there does not seem to be a Security
> Advisory regarding 
> sarge kernels.
> Grapping a recent vanilla kernel (e.g. 2.6.14.3) from
> http://www.kernel.org/ does not seem to be an option
> either, as the kernel developers recommend not to use
> a vanilla kernel in a production environment, but to
> use a distribution kernel: 
> http://www.ussg.iu.edu/hypermail/linux/kernel/0512.0/0711.html
> 
> Did I miss the location for updated Kernels? Or is the
> use of sarge on a internet connected machine not an
> option any more and one has to use sid or
> RHEL/Cntos/SLES?
> Best regards,
> Mike.

hmm is the debian wiki so hard to find?

- > http://wiki.debian.org/DebianKernel
- > http://wiki.debian.org/DebianKernelSargeUpdateStatus

lg max


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

Bug#342601: Duplicate files in initramfs-tools and udev when upgrading both

[maximilian attems]

On Thu, 08 Dec 2005, Andrew Moise wrote:

>   I don't know whether this is because of initramfs-tools or udev,
> or both, but when I upgraded them together they hit a spot of trouble:

well looks like you picked a bad combination,
we have a migration from udev files to initramfs-tools

please upgrade your initramfs-tools to 0.42

 
> Preparing to replace initramfs-tools 0.40 (using 
> .../initramfs-tools_0.42_all.deb) ...

your unstable seems not update.

keeping that bug around as it seems initramfs-tools and udev
were uploaded with different priority so this trouble might end in etch.
unless an updated initramfs-tools with higher priority reaches etch
before. can it still?

-- 
maks


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

Bug#337033: fixed udev -> fixed initramfs-tools?

[Maximilian Attems]

On Fri, Dec 09, 2005 at 04:35:23PM +, Paul Brossier wrote:
> hi
> 
> On Wed, Nov 30, 2005 at 07:17:11PM +0100, maximilian attems wrote:
> > please retest with latest initramfs-tools in unstable aka version 0.41.
> > it needs latest udev 0.76-3 too.
> > the various seen timing bugs should be fixed thanks to newer udev.
> 
> i could boot a thinkpad on 2.6.14 with an xfs root partition. 

cool.

> but on the powerpc64, i still get the following messages:
> TCP reno registered
> TCP bic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> RAMDISK: cramfs filesystem found at block 0
> RAMDISK: Loading 1558KiB [1 disk] into ram disk... done
> VFS: Mounted root (cramfs filesystem) readonly.
> VFS: Cannot open root devide "sda4" or unknown-block(0,0)
> Please append a correct "root=" boot option
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
>  <0>Rebooting in 180 seconds..
> 
> i have udev 0.76-4 and initramfs-tools 0.41 installed. i suspect it is
> now sata that is making troubles.

nahh sata working fine over here with initramfs-tools.

aboves log isn't an initramfs-tools usage,
that's an image generated by initrd-tools.
initrd-tools is known to be buggy for sata discs.

please try "update-initramfs -u" and check that the initramfs image got updated
should be the last entry of
ls -lrt /boot
and repost your log then?

thanks for your feedback.

--
maks


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

drop modular-ide.patch

[maximilian attems]

this patch is an Xu legacy patch for modular ide-generic support.
build for smaller modular .configs and initrd-tools.

initrd-tools loads _all_ ide driver and lets them fight out:
the ones which don't unload stay.
the bad side effect of a winning ide-generic is !dma on that box
http://lists.debian.org/debian-kernel/2005/06/msg00100.html
fs reports his via8cxxx boards affected too.
you need to set manually the module load order as workaround.

the patch is repeatably NACKed by ide upstream:
http://article.gmane.org/gmane.linux.hotplug.devel/9014

ubuntu has thrown the patch out of his tree:
http://kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=commit;h=3bdecc3459576a8a1ff42b7cab9c3b2264a4c3ac

regarding dma the newer initramfs generating tools:
yaird has troubles with the load ordering.
initramfs-tools did hardcode ide-generic until 0.40
and had dma troubles too. (see #336103) 

newer udev doesn't bring up ide-generic.
initramfs-tools fails to boot on those without ide-generic
explicitly added to /etc/mkinitramfs/modules.
(wide range of hardware like thinkpad r40e)

so currently i'd vote for removing that patch.
happy to hear your opinion? :)

-- 
maks


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

Bug#342931: doesn't work on alpha

[Maximilian Attems]

On Sun, Dec 11, 2005 at 07:36:58PM +0100, Norbert Tretkowski wrote:

> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs: mounted filesystem with ordered data mode.
> Kernel panic - not syncing: Attempted to kill init!
> 
> The qla1280 module is the right one for my rootfilesystem, the ext3
> module is also loaded.

hmm so fstype from klibc seems to work it recognises your ext3 root fs.
 
> Using break=mount:
> 
> SCSI subsystem initialized
> qla1280: QLA1040 found on PCI bus 1, dev 8
> scsi(0:0): Resetting SCSI BUS
> scsi0 : QLogic QLA1040 PCI to SCSI Host Adapter
>Firmware version:  7.65.06, Driver version 3.25
>   Vendor: MICROPModel: 3391WSRev: X502
>   Type:   Direct-Access  ANSI SCSI revision: 02
> scsi(0:0:0:0): Sync: period 10, offset 12, Wide
> SCSI device sda: 17780058 512-byte hdwr sectors (9103 MB)
> SCSI device sda: drive cache: write back
> SCSI device sda: 17780058 512-byte hdwr sectors (9103 MB)
> SCSI device sda: drive cache: write back
>  sda: sda1 sda2 sda3 sda4
> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
> 

that is an busybox bug, is latest busybox known to work on alpha?
should drop you into a shell.
 
> Using break=init:
> 
> SCSI subsystem initialized
> qla1280: QLA1040 found on PCI bus 1, dev 8
> scsi(0:0): Resetting SCSI BUS
> scsi0 : QLogic QLA1040 PCI to SCSI Host Adapter
>Firmware version:  7.65.06, Driver version 3.25
>   Vendor: MICROPModel: 3391WSRev: X502
>   Type:   Direct-Access  ANSI SCSI revision: 02
> scsi(0:0:0:0): Sync: period 10, offset 12, Wide
> SCSI device sda: 17780058 512-byte hdwr sectors (9103 MB)
> SCSI device sda: drive cache: write back
> SCSI device sda: 17780058 512-byte hdwr sectors (9103 MB)
> SCSI device sda: drive cache: write back
>  sda: sda1 sda2 sda3 sda4
> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs: mounted filesystem with ordered data mode.
> 


ok, so the initramfs-tools bug seems to be run-init of klibc:
a bit hard to debug if it's not possible to get into the bb shell.
will think about it and reping.

thanks for your testing

--
maks


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

Bug#343048: linux-image-2.6.14-2-686: modules ide-generic and ide-disk not loading

[Maximilian Attems]

On Mon, Dec 12, 2005 at 10:26:16AM +, Ricardo Ferreira wrote:
> I have the same problem. At first I thought it might be the way yaird was
> generating the ram disk, so I tried using initramfs-tools instead. This did
> not work (the error was about the same stated in other words in the boot
> process). When I "dpkg -i" to the version that was previously working fine
> (kernel version 2.6.14-4) I was surprised to find it had now the exact same
> error. This probably means that it is not the kernel package's fault, but
> something about the way the initrd is generated (although it is giving the
> same problem with yaird and initramfs-tools). 
> 
> I repeat: The previously working fine kernel package
> linux-image-2.6.14-2-686_2.6.14-4 is _not_ working now either after I rolled
> back to it using "dpkg -i".
> 
> On boot the system does give me a console when hitting the error so it lets
> me manually load the modules. "modprobe ide-generic" and "modprobe ide-disk"
> allows the system to boot just fine.

the debian kernel package has an patch that prevents udev from properly
loading ide-generic.
that patch is on the way to be removed.

the ide-disk case needs to be looked into.
anyway as short time workaround add
-- /etc/mkinitramfs/modules
ide-generic
ide-disk
--

and dpkg-reconfigure your linux-image.

regards

--
maks


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

Re: [kernel] r5008 - in dists: sid/linux-2.6/debian sid/linux-2.6/debian/bin trunk/linux-2.6/debian trunk/linux-2.6/debian/bin

[Maximilian Attems]

On Mon, Dec 12, 2005 at 02:31:23PM +, Bastian Blank wrote:
> Author: waldi
> Date: Mon Dec 12 14:31:22 2005
> New Revision: 5008
> 
> Modified:
>dists/sid/linux-2.6/debian/bin/install-header
>dists/sid/linux-2.6/debian/changelog
>dists/trunk/linux-2.6/debian/bin/install-header
>dists/trunk/linux-2.6/debian/changelog
> Log:
> Revert revision 5007. The main header package is not usable to build anything
> against.
> 

waldi stay out of this silly game.

either you revert the revert or you provide a fix for #342690.

-- 
maks


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

Bug#343048: linux-image-2.6.14-2-686: modules ide-generic and ide-disk not loading

[Maximilian Attems]

On Mon, Dec 12, 2005 at 12:24:09PM +, Ricardo Ferreira wrote:
> 
> Yup, that works, at least with initramfs-tools, will try going back to yaird 
> later. Any comments on using one instead of the other?

they are very different.
initramfs-tools uses udev, bb and klibc and wants max hardware support
yaird like to reimplement work in perl and tries to produce minimal

for the use case of copying around your root,
pulling out your harddisc from one pc to another initramfs-tools
is your friend. the drivers need to generate uevents for udev loading.

yaird will boot your exotic archs easier, because no need to port klibc,
but you need working perl and modules outside of perl-base.
the minimal image has also advantages on broken bootloader size
assumptions. 

initramfs-tools is used by ubuntu's breezy release and
will feature dapper. the ease of hooks make it very extensible.

yaird has a pretty impressive doc section, anyway there is also a
wiki page documenting both:
-> http://wiki.debian.org/InitrdReplacementOptions

yaird is set as default for 2.6.14 to get good test coverage.
when reading this, take into account that i'm current initramfs-tools
maintainer and thus my preference is clear. :)

enjoy

-- 
maks


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

Bug#332824: fixed udev -> fixed initramfs-tools?

[Maximilian Attems]

On Mon, Dec 12, 2005 at 11:33:06AM -0500, Jonathan Brandmeyer wrote:
> On Wed, 2005-11-30 at 19:18 +0100, maximilian attems wrote:
> > please retest with latest initramfs-tools in unstable aka version 0.41.
> > it needs latest udev 0.76-3 too.
> > the various seen timing bugs should be fixed thanks to newer udev.
> 
> 0.41 with udev 0.076-4 works.  However, the latest upgrade to 0.42 with
> udev 0.076-6 rendered my AMD64 partition unbootable, so I am avoiding
> the upgrade on my IA32 partition.
> 
> 0.42 fails to find the root fs, and kicks me out to a busybox
> shell.  /dev/mapper/control exists (recall that I'm running root on
> LVM), but none of the logical volumes are available.
> 
> As a wishlist item, this shell doesn't have either "halt", "reboot", or
> "shutdown" - you have to Ctrl-Alt-Del to restart the system.

latest udev might not bring up ide-disk or/and ide-generic,
due to a debian kernel bug.
add them to /etc/initramfs/modules and update-initramfs -u

also an output of the loaded modules from the shell would help
to tell what your trouble is aka cat /proc/modules.

--
maks



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

Bug#342931: doesn't work on alpha

[Maximilian Attems]

On Mon, Dec 12, 2005 at 08:38:36AM -0700, dann frazier wrote:
> On Sun, 2005-12-11 at 20:20 +0100, Maximilian Attems wrote:
> > ok, so the initramfs-tools bug seems to be run-init of klibc:
> > a bit hard to debug if it's not possible to get into the bb shell.
> > will think about it and reping.
> 
> Do you think a sysrq+t would be useful?

well might be maybe..
might be easier to put strace into initramfs-tools and
let it spit stuff to the screen at the last init step.
maybe this time we get a better hint

-- 
maks


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

Bug#343363: package linux-image-2.6.14-2-686 won't install due to a post-installation script error.

[Maximilian Attems]

reassign 343363 kernel-package
stop

On Wed, Dec 14, 2005 at 07:33:56PM +0100, Andrea Franzese wrote:
> Package: linux-image-2.6.14-2-686
> Version: 2.6.14-5
> Severity: grave
> Justification: renders package unusable
> 
> Installing (or upgrading) the package linux-image-2.6.14-2-686 the
> post-installation script returns error code 128.
> 
> """
> Configuro linux-image-2.6.14-2-686 (2.6.14-5) ...
> Running depmod.
> Finding valid ramdisk creators.
> Using mkinitrd.yaird to build the ramdisk.
> Running postinst hook.
> Searching for GRUB installation directory ... found: /boot/grub
> dpkg: errore processando linux-image-2.6.14-2-686 (--configure):
>  il sottoprocesso post-installation script ha restituito un codice di
>  errore 128
> """
> 
> Problem cannot be fixed running "apt-get install -f", and/or "dpkg
> --configure -a".
> 
> Trying to remove the package (not fully configurated) is the
> post-removal script that returns error code 128.

the severity might be a bit exagerated.
Manoj that was the error we discussed on irc a while ago,
thus reassigning.

regards

-- 
maks



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

Bug#341516: wpasupplicant: kernel panic on start with hostap driver

[maximilian attems]

please attach to your response output of:
dmesg > dmesg.txt

-- 
maks


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

Bug#274167: kernel-image-2.6.8-1-686: appears to cause reiserfs corruption on Sid

[maximilian attems]

tags 274167 important
stop

as the bug submitter is speaking about unstable,
he should inbetween use 2.6.14 which has a much better reiserfs,
which still needs some SuSe patch massaging.

anyway if you are bound to 2.6.8 reiserfs is not a recommended
rockstable fs.

-- 
maks


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

Bug#336153: Reproduced, also using ext2 + dm-crypt on top of RAID5

[maximilian attems]

severity 336153 important
stop

2.6.8 is known to have an fucked md and doesn't stand heavy fileload
unless you are lucky.

the archive features now 2.6.14 please try it out,
beware that the new initramfs generating tools are still in dev

-- 
maks


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

Bug#292290: kernel-image-2.6.8-1-k7: XFS filesystem corruption: Input/output error

[maximilian attems]

tags #292290 important
stop

newer xfs would have needed serious core changes in 2.6.8.
the debian kernel team had been penalized by the unforseen
long sarge core freeze.
it's very unfortunate as xfs in debian's kernel had
special attention. ext2, ext3 is recommended for 2.6.8 usage.

if you are bound to 2.6.8 you'd anyway better have not
heavy io. backports.org has newer semi-official builds.
take care regarding the udev version while using such backports.

-- 
maks


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

Bug#320312: Taking LVM snapshots can lead to an unuseable system

[maximilian attems]

hmm i'm not shure it deserves the "critical" stamp.
anyway could you lvm2 maintainer look into that #320312.

thanks :)

-- 
maks


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

Bug#320312: Taking LVM snapshots can lead to an unuseable system

[maximilian attems]

severity 320312 normal
tags 320312 morinfo
stop

On Sat, Dec 17, 2005 at 03:46:58PM +0100, Bastian Blank wrote:
> On Sat, Dec 17, 2005 at 03:32:58PM +0100, maximilian attems wrote:
> > hmm i'm not shure it deserves the "critical" stamp.
> 
> No it does not. The system can boot without a working /usr.

downgraded
 
> > anyway could you lvm2 maintainer look into that #320312.
> 
> The referenced message refers to lvm 2.00.16, sarge ships with 2.01.04.
> Also I see no output which describes what happened.
> 
> Bastian

thanks waldi for your input,

can you still reproduce this bug with an up2date sarge system?
if yes please describe how?

regards

-- 
maks


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

Bug#343686: debsums: checksums mismatch + bug #343048 again

[Maximilian Attems]

reassign kernel-package
stop

On Sat, Dec 17, 2005 at 03:48:55PM +0800, LUK ShunTim wrote:
> Package: linux-image-2.6.15-rc5-686
> Version: 2.6.14+2.6.15-rc5-0experimental.1
> Severity: critical
> Justification: breaks the whole system
> 
> After installing linux-image-2.6.15-rc5-686 and rebooting, I got errors 
> similar 
> to that reported in bug #343048, that is
> 
> 
> /bin/cat: /sys/block/hda/dev: No such file or directory
> Waiting 1 seconds for /sys/block/hda/dev to show up
> /bin/cat: /sys/block/hda/dev: No such file or directory
> Waiting 2 seconds for /sys/block/hda/dev to show up"
> 
> 

well that yaird bug is known and we'll hopefully soon see a fix for that
crack. so not sure if that severity is right.
 
> However, the strange thing is when I invoke reportbug to report it, I got 
> these
> bunch of checksum errors
>   
> 
> Getting status for linux-image-2.6.15-rc5-686...
> Verifying package integrity...
> There may be a problem with your installation of linux-image-2.6.15-rc5-686;
> the following files appear to be missing or changed:
> debsums: checksum mismatch linux-image-2.6.15-rc5-686 file 
> /lib/modules/2.6.15-rc5-686/modules.pcimap
> debsums: checksum mismatch linux-image-2.6.15-rc5-686 file 
> /lib/modules/2.6.15-rc5-686/modules.dep
> debsums: checksum mismatch linux-image-2.6.15-rc5-686 file 
> /lib/modules/2.6.15-rc5-686/modules.ieee1394map
> debsums: checksum mismatch linux-image-2.6.15-rc5-686 file 
> /lib/modules/2.6.15-rc5-686/modules.usbmap
> debsums: checksum mismatch linux-image-2.6.15-rc5-686 file 
> /lib/modules/2.6.15-rc5-686/modules.isapnpmap
> debsums: checksum mismatch linux-image-2.6.15-rc5-686 file 
> /lib/modules/2.6.15-rc5-686/modules.inputmap
> debsums: checksum mismatch linux-image-2.6.15-rc5-686 file 
> /lib/modules/2.6.15-rc5-686/modules.seriomap
> debsums: checksum mismatch linux-image-2.6.15-rc5-686 file 
> /lib/modules/2.6.15-rc5-686/modules.alias
> debsums: checksum mismatch linux-image-2.6.15-rc5-686 file 
> /lib/modules/2.6.15-rc5-686/modules.symbols
> 

cool so the newer k-p adds md5sums support :)
reassigning to you Manoj.
woow thanks!!

-- 
maks


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

Re: Preparing 2.6.14-6 release, getting 2.6.15-rc into shape

[Maximilian Attems]

On Mon, Dec 19, 2005 at 04:31:33PM -0500, Kyle McMartin wrote:
> On Mon, Dec 19, 2005 at 09:50:48PM +0100, Frederik Schueler wrote:
> > - hppa 
> > 
> 
> I need to re-rename the kernel images for hppa. Somehow they got
> reverted from "parisc" and "parisc64" back to the unclear "32" and "64".
> 
> Where's the best tree to make this change, I've been out of the loop
> for a while, so I'm not sure which tree this change should be made in.
> 
> [Bdale wants this sorted out so he can update D-I, I believe]

currently d-i unstable uses 2.6.12/2.6.14 depending on arch -
next beta is planed for 2.6.15 so latest 2.6.15 is more important.

nevertheless i'm very happy that fs uploads newer 2.6.14
to fix the udev ide bug.

regards

-- 
maks


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

Bug#332824: missing ide-generic

[maximilian attems]

please try the attached patch,
should load ide-generic even if udev didn't yet bring it up:
patch -p1  /usr/share/initramfs-tools/scripts/init-premount/udev < 
ide-generic.udev.patch

for this trial please remove any ide-generic or ide-disk 
out of /etc/mkinitramfs/modules, then update-initramfs -u
and reboot,
if it doesn't work out you still need to modprobe manually
ide-generic and disc..

thanks for your feedback.

-- 
maks
--- udev-0.076/extra/initramfs.premount 2005-12-23 12:36:04.0 +0100
+++ udev-0.076-ma/extra/initramfs.premount  2005-12-23 12:35:52.0 
+0100
@@ -21,6 +21,38 @@ mkdir /dev/.udev/ /dev/.udev/db/ /dev/.u
 udevd --daemon
 
 udevsynthesize
+
+# Our job now is to make the block device for the root filesystem available.
+# This is actually a bit trickier than it first appears because we first need
+# to figure out which driver needs it, and to do that, we need to know what
+# type of bus it's on.  Fortunately we have all that information, this still
+# feels like an ungodly hack though.
+. /conf/initramfs.conf
+. /scripts/functions
+case "${BOOT}" in
+   local)
+   case "${ROOT}" in
+   /dev/root)
+   # An interesting case, this root device was specified as a
+   # major/minor pair.  Fortunately we have that information
+   case "${major}" in
+   3|22|33|34|56|57|88|89|90|91)
+   # traditional ide
+   root_type=ide
+   ;;
+   80|81|82|83|84|85|86|87)
+   # ide on i2o
+   root_type=ide
+   ;;
+   esac
+   ;;
+   /dev/hd*)
+   # Ahh, plain-old traditional ide
+   root_type=ide
+   ;;
+   esac
+esac
+
 while [ -d /dev/.udev/queue/ ]; do
 sleep 1
 udevd_timeout=$(($udevd_timeout - 1))
@@ -29,5 +61,13 @@ while [ -d /dev/.udev/queue/ ]; do
 fi
 done
 
+# If we're booting from IDE, we may need to load ide-generic.
+case "${root_type}" in
+   ide)
+   if [ ! -e "${ROOT}" -o "${ROOT}" = "/dev/root" ]; then
+   modprobe -q ide-generic
+   fi
+esac
+
 # Leave udev running to process events that come in out-of-band (like USB
 # connections)

Bug#337497: missing ide-generic

[Maximilian Attems]

unmerge 337497
severity 337497 important
tags 337497 moreinfo
stopped

On Fri, Dec 23, 2005 at 02:41:51PM +0100, Sven Luther wrote:
> 
> Notice that there is no ide-generic module on powerpc, and never has been, so
> i fail to understand what i should test ? 
> 

indeed your bug report was falsly merged,
sorry for not noticing earlier - thus decoupling.

anyway the timing bug you experienced in your bug report should be gone
since long. please retest on latest udev and initramfs-tools in
unstable regarding the pegasos support.

thanks

--
maks


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

Bug#342925: missing ide-generic

[maximilian attems]

On Sat, 24 Dec 2005, Frans Pop wrote:

> On Friday 23 December 2005 14:34, maximilian attems wrote:
> > please try the attached patch,
> > should load ide-generic even if udev didn't yet bring it up:
> 
> Although my initial report was for Sparc (which I will test tomorrow, I've 
> also tested it on my laptop.
> ide-generic is loaded, but ide-disk is not, so not quite there yet for me.
> 
> The laptop (Toshiba Satellite A40) needs piix (which is loaded):
> :00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage 
> Controller (rev 03)
> 
> Cheers,
> FJP

thanks to you all for your testing!!
indeed other test request generated the same feedback,
working on some but for others still missing ide-disk.

need to talk to the ubuntu guys what we are doing falsly as
it works on their side.
Md states that udev should pick up any ide-generic,
which su... that it doesn't do.

anyway happy christmas :)

-- 
maks


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

Bug#328534: Adaptec 2005S Hangs

[maximilian attems]

the bug your reported at the beginning of your bug report
regarding initramfs-tools was a timing bug by udev,
which is fixed since long.

please retest against latest 2.6.14 in unstable
usinig initramfs-tools?

thanks for your feedback.

-- 
maks


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

call for last 2.6.14 changes

[maximilian attems]

maybe not really the last, but 2.6.14-7 is scheduled for tomorrow.
contains 2.6.14.5 with networking, scsi and nfs security fix.

please rush in if you have any additions.

-- 
maks


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

Bug#344754: fails to load ide-disk, doesn't find hdd

[maximilian attems]

On Wed, 28 Dec 2005, Joey Hess wrote:

> I also see this bug, using initramfs-tools 0.44 and
> linux-image-2.6.14-2-386 (2.6.14-6).

could you try the attached hook file,
please place it under  /usr/share/initramfs-tools/scripts/init-premount/
and recreate the initramfs: update-initramfs -u

hope it works,
should load ide-disk and ide-generic after the udev run,
as udev currently fails to do so.
 
> It's puzzling that the changelog for this version of the kernel
> claims to have dropped the module ide patch, but all the ide modules
> including ide-disk, ide-generic and the ide/pci/* modules, are still there
> in the debian package.

removed the patch without furthere notice as your concerns weren't 
touched by it.


-- 
maks
#!/bin/sh

PREREQ="udev"

prereqs()
{
echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac

modprobe -q ide-generic

[ -e /proc/ide ] || return

for drive in /proc/ide/*; do
[ -e ${drive}/media ] || continue
# nothing to do if the device has already been took in charge
unit=${drive#/proc/ide/}
[ -d /sys/block/$unit ] && continue

read media < $drive/media
case "$media" in
disk)   MODULE=ide-disk ;;
cdrom)  MODULE=ide-cd ;;
tape)   MODULE=ide-tape ;;
floppy) MODULE=ide-floppy ;;
*)  MODULE=ide-generic ;;
esac

modprobe -q ${MODULE}
done

Bug#345129: linux-image-2.6.14-2-686 and ALI5451 module

[maximilian attems]

On Thu, 29 Dec 2005, Laurent Neiger wrote:

> Hello,
> 
> Since I upgraded from linux-image-2.6.12 to linux-image-2.6.14 my 
> ali5451 soundcard is no more able of playing any sound...
> I've tried all the successives revisions of 2.6.14 but it really seems 
> it's since the change 2.6.12/2.6.14 that the module is no longer loading 
> properly.

please try the 2.6.15 rc kernel in experimental.
2.6.15 will soon be released and replace 2.6.14


--
maks


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

Bug#345129: linux-image-2.6.14-2-686 and ALI5451 module

[maximilian attems]

cher Laurent!

On Thu, 29 Dec 2005, Laurent Neiger wrote:

> first of all many thanks for your so quick answer.
:) 

> Unfortunately, upgrading to 2.6.15 didn't solve my problem.
> Messages in /var/log/dmesg (or boot or syslog) are just the same, there 
> is an error while loading the ali5451 module.

hmm that is an usb driver.
we only disabled CONFIG_USB_BANDWIDTH two days ago,
so not yet uploaded, might be related.

please monitor experimental and feedback if next kernel upload
solves your problem.

if not you may need to bug report to the alsa folks.

-- 
maks


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