Debian Bug report logs - #505609
Unbootable after kernel upgrade: Lilo can't load kernel

version graph

Package: linux-2.6; Maintainer for linux-2.6 is Debian Kernel Team <debian-kernel@lists.debian.org>;

Reported by: Xavier Brochard <xavier@alternatif.org>

Date: Thu, 13 Nov 2008 19:57:02 UTC

Severity: critical

Tags: lenny

Merged with 535331

Found in versions 2.6.26-17, 2.6.26-19

Fixed in version linux-2.6/2.6.26-24

Done: dann frazier <dannf@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-image-2.6.26-1-amd64. (Thu, 13 Nov 2008 19:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Xavier Brochard <xavier@alternatif.org>:
New Bug report received and forwarded. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 13 Nov 2008 19:57:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Xavier Brochard <xavier@alternatif.org>
To: submit@bugs.debian.org
Subject: Unbootable after kernel upgrade: Lilo can't load kernel
Date: Thu, 13 Nov 2008 20:54:32 +0100
Package: linux-image-2.6.26-1-amd64
Version: 2.6.26-10
Severity: critical

I've did an upgrade on 2008-11-09, on a new installed system, upgrading kernel 
2.6.26-09 to 2.6.26.10. Apt was also upgraded.
I've seen nothing strange during upgrade and in the apt and dpkg logs. The 
system is entirely on LVM partitions.

When reboting I obtain this message from Lilo:
"Loading LinuxEBDA is big; kernel setup stack overlaps LILO second stage".
and the computer halt.


regards
-- 
Xavier
xavier@alternatif.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-image-2.6.26-1-amd64. (Thu, 13 Nov 2008 21:48:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 13 Nov 2008 21:48:09 GMT) Full text and rfc822 format available.

Message #10 received at 505609@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Xavier Brochard <xavier@alternatif.org>
Cc: 505609@bugs.debian.org
Subject: Re: Bug#505609: Unbootable after kernel upgrade: Lilo can't load kernel
Date: Thu, 13 Nov 2008 21:48:10 +0000
[Message part 1 (text/plain, inline)]
On Thu, 2008-11-13 at 20:54 +0100, Xavier Brochard wrote:
> Package: linux-image-2.6.26-1-amd64
> Version: 2.6.26-10
> Severity: critical
> 
> I've did an upgrade on 2008-11-09, on a new installed system, upgrading kernel 
> 2.6.26-09 to 2.6.26.10. Apt was also upgraded.
> I've seen nothing strange during upgrade and in the apt and dpkg logs. The 
> system is entirely on LVM partitions.
> 
> When reboting I obtain this message from Lilo:
> "Loading LinuxEBDA is big; kernel setup stack overlaps LILO second stage".
> and the computer halt.

I think this might be bug 479607 <http://bugs.debian.org/479607>.  Did
you add "large-memory" to /etc/lilo.conf?  If not, does that fix the
problem?

Ben.

[signature.asc (application/pgp-signature, inline)]

Reply sent to Bastian Blank <waldi@debian.org>:
You have taken responsibility. (Fri, 14 Nov 2008 11:42:06 GMT) Full text and rfc822 format available.

Notification sent to Xavier Brochard <xavier@alternatif.org>:
Bug acknowledged by developer. (Fri, 14 Nov 2008 11:42:06 GMT) Full text and rfc822 format available.

Message #15 received at 505609-done@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: 505609-done@bugs.debian.org
Subject: Re: Bug#505609: Unbootable after kernel upgrade: Lilo can't load kernel
Date: Fri, 14 Nov 2008 12:42:22 +0100
On Thu, Nov 13, 2008 at 08:54:32PM +0100, Xavier Brochard wrote:
> When reboting I obtain this message from Lilo:
> "Loading LinuxEBDA is big; kernel setup stack overlaps LILO second stage".
> and the computer halt.

Bug in lilo. It does not properly check the size of the initrd and fails
to load it.

Bastian

-- 
The sight of death frightens them [Earthers].
		-- Kras the Klingon, "Friday's Child", stardate 3497.2




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-image-2.6.26-1-amd64. (Fri, 14 Nov 2008 15:09:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Xavier Brochard <xavier@alternatif.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 14 Nov 2008 15:09:09 GMT) Full text and rfc822 format available.

Message #20 received at 505609@bugs.debian.org (full text, mbox):

From: Xavier Brochard <xavier@alternatif.org>
To: 505609@bugs.debian.org
Subject: Re: Bug#505609: Unbootable after kernel upgrade: Lilo can't load kernel
Date: Fri, 14 Nov 2008 15:41:39 +0100
Le jeudi 13 novembre 2008 22:48:10, vous avez écrit :
> On Thu, 2008-11-13 at 20:54 +0100, Xavier Brochard wrote:
> > Package: linux-image-2.6.26-1-amd64
> > Version: 2.6.26-10
> > Severity: critical
> >
> > I've did an upgrade on 2008-11-09, on a new installed system, upgrading
> > kernel 2.6.26-09 to 2.6.26.10. Apt was also upgraded.
> > I've seen nothing strange during upgrade and in the apt and dpkg logs.
> > The system is entirely on LVM partitions.
> >
> > When reboting I obtain this message from Lilo:
> > "Loading LinuxEBDA is big; kernel setup stack overlaps LILO second
> > stage". and the computer halt.
>
> I think this might be bug 479607 <http://bugs.debian.org/479607>.  Did
> you add "large-memory" to /etc/lilo.conf?  If not, does that fix the
> problem?

hello
yes, I thought about something like that, but it fail before booting the 
kernel, at the LILO prompt.
It's exactly the same that this old bug report: #360011

"large-memory" was already in the lilo.conf

regards
-- 
Xavier
xavier@alternatif.org





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-image-2.6.26-1-amd64. (Fri, 14 Nov 2008 16:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Xavier Brochard <xavier@alternatif.org>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 14 Nov 2008 16:09:04 GMT) Full text and rfc822 format available.

Message #25 received at 505609@bugs.debian.org (full text, mbox):

From: Xavier Brochard <xavier@alternatif.org>
To: 505609@bugs.debian.org
Subject: Re: Bug#505609 closed by Bastian Blank <waldi@debian.org> (Re: Bug#505609: Unbootable after kernel upgrade: Lilo can't load kernel)
Date: Fri, 14 Nov 2008 17:06:20 +0100
reopen 505609
reassign 505609 lilo
thanks

Le vendredi 14 novembre 2008 12:42:06 Debian Bug Tracking System, vous avez 
écrit :
> De : Bastian Blank <waldi@debian.org>
> On Thu, Nov 13, 2008 at 08:54:32PM +0100, Xavier Brochard wrote:
> > When reboting I obtain this message from Lilo:
> > "Loading LinuxEBDA is big; kernel setup stack overlaps LILO second
> > stage". and the computer halt.
>
> Bug in lilo. It does not properly check the size of the initrd and fails
> to load it.

-- 
Xavier
xavier@alternatif.org




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sat, 13 Dec 2008 07:27:38 GMT) Full text and rfc822 format available.

Bug unarchived. Request was from Tomas Pospisek <tpo_deb@sourcepole.ch> to control@bugs.debian.org. (Wed, 03 Feb 2010 12:03:02 GMT) Full text and rfc822 format available.

Did not alter fixed versions and reopened. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 03 Feb 2010 12:03:03 GMT) Full text and rfc822 format available.

Bug reassigned from package 'linux-image-2.6.26-1-amd64' to 'lilo'. Request was from Tomas Pospisek <tpo_deb@sourcepole.ch> to control@bugs.debian.org. (Wed, 03 Feb 2010 12:03:04 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions linux-2.6/2.6.26-10. Request was from Tomas Pospisek <tpo_deb@sourcepole.ch> to control@bugs.debian.org. (Wed, 03 Feb 2010 12:03:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, William Pitcock <nenolod@dereferenced.org>:
Bug#505609; Package lilo. (Wed, 03 Feb 2010 12:33:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tomas Pospisek <tpo@sourcepole.ch>:
Extra info received and forwarded to list. Copy sent to William Pitcock <nenolod@dereferenced.org>. (Wed, 03 Feb 2010 12:33:02 GMT) Full text and rfc822 format available.

Message #40 received at 505609@bugs.debian.org (full text, mbox):

From: Tomas Pospisek <tpo@sourcepole.ch>
To: 505609@bugs.debian.org
Subject: more on the lilo boot failure
Date: Wed, 3 Feb 2010 13:08:54 +0100 (CET)
After a standard security/stability upgrade of lenny I witnessed the same 
problem as Xavier, namely that lilo would stop with:

  liloLoading LinuxEBDA is big; kernel setup stack overlaps LILO second
  stage

(I am not sure whether there were any points after "lilo". I think not,
 but if there were, then there were only very few - i.e. not a line or
 half a line or such)

What I did exactly was upgrading from linux-image-2.6.26-2-686 
2.6.26-19lenny1 to 2.6.26-21 inside aptitude and *at the same time* 
deinstalling the old linux-image-2.6.18-6-686 2.6.18.dfsg.1-26etch1.

Aptitude did what I told it to do and did not complain, and ended without 
error. The only thing indicating a problem were the following lines (from 
/var/log/apt.log - since I did not catch them during the down/upgrade, 
and translated from czech, since that's how the locale is set):

  Preparing to replace linux-image-2.6.26-2-686 2.6.26-19lenny1 (with
  .../linux-image-2.6.26-2-686_2.6.26-21_i386.deb) ...
  The directory /lib/modules/2.6.26-2-686 still exists. Continuing as
  directed.
  Done.
  Unpacking replacement linux-image-2.6.26-2-686 ...
  ...
  Configuring package linux-image-2.6.26-2-686 (2.6.26-21) ...
  Running depmod.
  Running mkinitramfs-kpkg.
  Not updating initrd symbolic links since we are being updated/reinstalled
  (2.6.26-19lenny1 was configured last, according to dpkg)
  Not updating image symbolic links since we are being updated/reinstalled
  (2.6.26-19lenny1 was configured last, according to dpkg)
  ...
  Removing package linux-image-2.6.18-6-686
  The link /vmlinuz.old is a damaged link
  Removing symbolic link vmlinuz.old
  Unless you used the optional flag in lilo,
   you may need to re-run your boot loader[lilo]
  The link /initrd.img.ol is a damaged link
  Removing symbolic link initrd.img.ol
  Unless you used the optional flag in lilo,
   you may need to re-run your boot loader[lilo]
  Removing configuration directory of package linux-image-2.6.18-6-686 ...
  ...

And that's it, no errors anywhere.

After upgrading I rebooted and ended up with the lilo error reported by 
Xavier and repeated above.

Strangely enough (!!!) I could *still* boot into the removed (!) 2.6.18-6 
kernel and allthough the bootprocess complained about a lot of missing 
kernel modules (or modules.dep ? I don't know, I can't find it anywhere 
in the logs), but somehow miraculously (!) it was able to install the 
networking stack... Then, from the shell I issued:

  # lilo
  Fatal: open /boot/vmlinuz-2.6.18-6-686

After that I reinstalled the old linux-image-2.6.18-6-686 
2.6.18.dfsg.1-26etch1 package and rebooted.

Now everything was fine and I could boot into the new 2.6.26 kernel 
without lilo complaining.

Running lilo from the command line would show me the bootable kernels:

  # lilo
  Added 2618-6-hda5
  Added 2626-hda5
  Added windows

  # ls -l /
  [...]
  initrd.img -> boot/initrd.img-2.6.18-6-686
  initrd.img.old -> boot/initrd.img-2.6.26-2-686
  [...]
  vmlinuz -> boot/vmlinuz-2.6.18-6-686
  vmlinuz.old -> boot/vmlinuz-2.6.26-2-686

It seems that even if lilo.conf is half broken - i.e. it's missing some of 
the kernels, the install process will nevertheless install the new kernel 
but somehow break halfway through the process and not properly install the 
new kernel.

*t





Information forwarded to debian-bugs-dist@lists.debian.org, William Pitcock <nenolod@dereferenced.org>:
Bug#505609; Package lilo. (Wed, 26 May 2010 12:42:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christian Hammers <ch@debian.org>:
Extra info received and forwarded to list. Copy sent to William Pitcock <nenolod@dereferenced.org>. (Wed, 26 May 2010 12:42:06 GMT) Full text and rfc822 format available.

Message #45 received at 505609@bugs.debian.org (full text, mbox):

From: Christian Hammers <ch@debian.org>
To: 505609@bugs.debian.org
Subject: Re: Unbootable after kernel upgrade: Lilo can't load kernel
Date: Wed, 26 May 2010 14:08:28 +0200
Hello

I also encountered this bug after upgrading the kernel today.

A quick workaround was to 
 * boot using a grml64 CD
 * mount the /, /usr and /var partions
 * chroot to the partions
 * execute "lilo -v"
 * reboot

I now wonder if the system is permanently "fixed" or if it might randomly
hang on the next reboots again.

And if it's fixable by just running "lilo -v" then why couldn't the lilo
postinst script do this (or if it does why didn't that work).

bye,

-christian-





Reply sent to Stephen Powell <zlinuxman@wowway.com>:
You have taken responsibility. (Sun, 30 May 2010 14:39:09 GMT) Full text and rfc822 format available.

Notification sent to Xavier Brochard <xavier@alternatif.org>:
Bug acknowledged by developer. (Sun, 30 May 2010 14:39:09 GMT) Full text and rfc822 format available.

Message #50 received at 505609-done@bugs.debian.org (full text, mbox):

From: Stephen Powell <zlinuxman@wowway.com>
To: 505609-done@bugs.debian.org
Cc: debian-devel@lists.debian.org, debian-boot@lists.debian.org, debian-user@lists.debian.org
Subject: [SOLVED] Unbootable after kernel upgrade: Lilo can't load kernel
Date: Sun, 30 May 2010 10:35:37 -0400 (EDT)
This is not a lilo bug.  The problem is that lilo's map installer
did not get run during the kernel upgrade process.  The fact that
the user was able to boot his old de-installed kernel is proof of
this.  The /boot/map file still pointed to the blocks in the file
system which formerly contained the old kernel and its initial RAM
file system image.  And since, fortunately, those blocks had not yet
been reused, the data was still there.  Modules which were
loaded from the initial RAM file system image loaded OK.  But once
the switch was made from the initial RAM file system to the
permanent root file system, further module loads could not be done,
since the modules had been erased.  When the user manually ran lilo's
map installer at the command line, the problem disappeared.

The real question is, "Why didn't the map installer get run during
the kernel upgrade?"  There is not sufficient data in the bug log
to determine the answer to that question, but I have observed that
"do_bootloader = yes" in /etc/kernel-img.conf no longer causes
lilo to be run when a new kernel is installed.  I believe that this
change in behavior was caused by changes to the kernel maintainer
scripts made around the time of the switch to grub version 1 as
the default boot loader.  "do_bootloader = yes" in /etc/kernel-img.conf
still causes zipl to be run on the s390 port, a port that neither
version of grub supports.  "do_bootloader = yes" should still be
specified in /etc/kernel-img.conf, however, so that "update-initramfs -u"
will cause lilo's map installer to be run when an initial RAM file
system is updated (but not when it is initially created).

So is this a bug in the kernel maintainer scripts?  Or is it a feature?
I don't know.  I'll leave that up to the kernel maintainers to decide.
A full discussion of how to make sure that lilo's map installer gets
run during the installation of a new kernel, taking into account all
types of kernels (official stock Debian kernels, custom kernels created
by make-kpkg, custom kernels created by "make deb-pkg", etc., is beyond
the scope of this bug log.  Interested readers may wish to look at my
web page on kernel building, particularly step 10, for further
information.  http://www.wowway.com/~zlinuxman/Kernel.htm  The instructions
for "customizing the Lenny environment" will work in Squeeze or Sid also,
provided that you use only official stock Debian kernels.  If you use
custom kernels in Squeeze or later, you *must* use hook scripts to ensure
that any post-installation activities, such as the creation of an initial
RAM file system, updating symlinks, or running a boot loader, take place.

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-




Information forwarded to debian-bugs-dist@lists.debian.org, William Pitcock <nenolod@dereferenced.org>:
Bug#505609; Package lilo. (Sun, 30 May 2010 19:03:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Frans Pop <elendil@planet.nl>:
Extra info received and forwarded to list. Copy sent to William Pitcock <nenolod@dereferenced.org>. (Sun, 30 May 2010 19:03:10 GMT) Full text and rfc822 format available.

Message #55 received at 505609@bugs.debian.org (full text, mbox):

From: Frans Pop <elendil@planet.nl>
To: 505609@bugs.debian.org
Cc: debian-devel@lists.debian.org, debian-boot@lists.debian.org, debian-kernel@lists.debian.org, debian-user@lists.debian.org
Subject: Re: [SOLVED] Unbootable after kernel upgrade: Lilo can't load kernel
Date: Sun, 30 May 2010 20:59:15 +0200
reopen 505609 
reassign 505609 linux-2.6
affects 505609 lilo
thanks

Stephen Powell wrote:
> The real question is, "Why didn't the map installer get run during
> the kernel upgrade?"
[...]
> So is this a bug in the kernel maintainer scripts?  Or is it a feature?
> I don't know.  I'll leave that up to the kernel maintainers to decide.

Reopening and reassigning to the kernel team.




Did not alter fixed versions and reopened. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 30 May 2010 19:03:21 GMT) Full text and rfc822 format available.

Bug reassigned from package 'lilo' to 'linux-2.6'. Request was from Frans Pop <elendil@planet.nl> to control@bugs.debian.org. (Sun, 30 May 2010 19:03:21 GMT) Full text and rfc822 format available.

Added indication that 505609 affects lilo Request was from Frans Pop <elendil@planet.nl> to control@bugs.debian.org. (Sun, 30 May 2010 19:03:22 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Fri, 04 Jun 2010 15:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Powell <zlinuxman@wowway.com>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 04 Jun 2010 15:27:03 GMT) Full text and rfc822 format available.

Message #66 received at 505609@bugs.debian.org (full text, mbox):

From: Stephen Powell <zlinuxman@wowway.com>
To: 505609@bugs.debian.org
Subject: Re: [SOLVED] Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
Date: Fri, 4 Jun 2010 11:24:06 -0400 (EDT)
After examining the maintainer scripts, this does appear to be a bug in
the maintainer scripts.  I compared output of dpkg-reconfigure between
two different systems: one running Etch and the other running Lenny.
Both had lilo installed as the boot loader.  In both cases, the contents
of /etc/kernel-img.conf were as follows:

----------

# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
relative_links = yes
do_bootloader = yes
do_bootfloppy = no
do_initrd = yes
link_in_boot = yes

----------

Here is the output of dpkg-reconfigure on Etch:

----------

# dpkg-reconfigure linux-image-2.6.18-5-686
Running depmod.
Finding valid ramdisk creators.
Using mkinitramfs-kpkg to build the ramdisk.
Not updating initrd symbolic links since we are being updated/reinstalled
(2.6.18.dfsg.1-13 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled
(2.6.18.dfsg.1-13 was configured last, according to dpkg)
You already have a LILO configuration in /etc/lilo.conf
Running boot loader as requested
Testing lilo.conf ...
Testing successful.
Installing the partition boot sector...
Running /sbin/lilo ...
Installation successful.
#

----------

Here is the output of dpkg-reconfigure on Lenny:

----------

# dpkg-reconfigure linux-image-2.6.26-2-686
Running depmod.
Running mkinitramfs-kpkg.
Not updating initrd symbolic links since we are being updated/reinstalled
(2.6.26-21lenny4 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled
(2.6.26-21lenny4 was configured last, according to dpkg)
#

----------

Notice the absence of any information about running the boot loader in the
Lenny output!  The boot loader simply was not run, despite a request in
/etc/kernel-img.conf to run it.

I compared the two relevant maintainer scripts:

   /var/lib/dpkg/info/linux-image.2.6.18-5-686.postinst

and

   /var/lib/dpkg/info/linux-image.2.6.26-2-686.postinst

and quickly discovered the reason.  The maintainer scripts for the
2.6.26 kernel define the $loader variable to be the null string.
The 2.6.18 maintainer script defines the $loader variable to be lilo.

To be specific,
line 38 of /var/lib/dpkg/info/linux-image-2.6.26-2-686.postinst
currently says:

my $loader            = ""; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo

I changed it to say:

my $loader            = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo

The new output is as follows:

----------

# dpkg-reconfigure linux-image-2.6.26-2-686
Running depmod.
Running mkinitramfs-kpkg.
Not updating initrd symbolic links since we are being updated/reinstalled
(2.6.26-21lenny4 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled
(2.6.26-21lenny4 was configured last, according to dpkg)
You already have a LILO configuration in /etc/lilo.conf
Running boot loader as requested
Testing lilo.conf ...
Testing successful.
Installing the partition boot sector...
Running /sbin/lilo ...
Installation successful.
#

----------

There is no conflict with grub version 1 or grub version 2 here.  If the user
has either version of grub installed, then the user will set

do_bootloader = no

in /etc/kernel-img.conf.  In the case of grub version 1, he will also add

postinst_hook = update-grub
postrm_hook   = update-grub

A similar change should be made to the preinst, prerm, and postrm scripts
for consistency.  The Squeeze and Sid scripts have the same problem.

OK, I solved the mystery.  Now someone on the kernel team actually has
to fix it.

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-




Bug reassigned from package 'linux-2.6' to 'initramfs-tools'. Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Mon, 07 Jun 2010 14:39:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#505609; Package initramfs-tools. (Mon, 07 Jun 2010 15:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Powell <zlinuxman@wowway.com>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Mon, 07 Jun 2010 15:39:04 GMT) Full text and rfc822 format available.

Message #73 received at 505609@bugs.debian.org (full text, mbox):

From: Stephen Powell <zlinuxman@wowway.com>
To: Holger Levsen <holger@layer-acht.org>
Cc: debian-devel@lists.debian.org, debian-kernel@lists.debian.org, 505609@bugs.debian.org, debian-user@lists.debian.org
Subject: Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
Date: Mon, 7 Jun 2010 11:37:57 -0400 (EDT)
On Mon, 07 Jun 2010 10:33:52 -0400 (EDT), Holger Levsen wrote:
> 
> Hi Stephen,
>
> thanks for stepping up maintaining lilo in Debian! I hope you'll manage this 
> well.

Um, thanks; but I don't understand the reassignment of bug number 505609 to
package initramfs-tools.  If you read my previous posts to the bug log, it
is clear that this problem started with a change to the maintainer scripts
between Etch and Lenny.  Please read my posts again carefully.  Then consider
whether this is really a bug in initramfs-tools or a bug in the kernel maintainer
scripts.  initramfs-tools only gets involved when

   update-initramfs -u

is issued.  And it *does* invoke the boot loader under these conditions, if
"do_bootloader = yes" is present in /etc/kernel-img.conf and lilo is installed.
But for a kernel install or reconfigure, it is the responsibility of the
kernel maintainer scripts to invoke the bootloader.  See also, for example,
linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
on line 38.  This really is an "open and shut case", if only I can the kernel
people to actually look at it!  Please look at it!




-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#505609; Package initramfs-tools. (Mon, 07 Jun 2010 23:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Prokop <mika@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. (Mon, 07 Jun 2010 23:09:03 GMT) Full text and rfc822 format available.

Message #78 received at 505609@bugs.debian.org (full text, mbox):

From: Michael Prokop <mika@debian.org>
To: Stephen Powell <zlinuxman@wowway.com>, 505609@bugs.debian.org
Cc: Holger Levsen <holger@layer-acht.org>
Subject: Re: Bug#505609: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
Date: Tue, 8 Jun 2010 01:03:52 +0200
[Message part 1 (text/plain, inline)]
[Dropped the @lists.debian.org from Cc]

* Stephen Powell <zlinuxman@wowway.com> [Mon Jun 07, 2010 at 11:37:57AM -0400]:
> On Mon, 07 Jun 2010 10:33:52 -0400 (EDT), Holger Levsen wrote:

> > thanks for stepping up maintaining lilo in Debian! I hope you'll manage this 
> > well.

> Um, thanks; but I don't understand the reassignment of bug number 505609 to
> package initramfs-tools.  If you read my previous posts to the bug log, it
> is clear that this problem started with a change to the maintainer scripts
> between Etch and Lenny.  Please read my posts again carefully.  Then consider
> whether this is really a bug in initramfs-tools or a bug in the kernel maintainer
> scripts.
[...]

ACK. I don't think this is an i-t issue.
Any objections against reassigning back to linux-2.6?

regards,
-mika-
[signature.asc (application/pgp-signature, inline)]

Bug reassigned from package 'initramfs-tools' to 'linux-2.6'. Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Tue, 08 Jun 2010 07:48:11 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Tue, 08 Jun 2010 11:42:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Danjean <vdanjean.ml@free.fr>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Tue, 08 Jun 2010 11:42:05 GMT) Full text and rfc822 format available.

Message #85 received at 505609@bugs.debian.org (full text, mbox):

From: Vincent Danjean <vdanjean.ml@free.fr>
To: 505609@bugs.debian.org
Cc: debian-devel@lists.debian.org, debian-kernel@lists.debian.org
Subject: Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
Date: Tue, 08 Jun 2010 13:39:58 +0200
On 07/06/2010 17:37, Stephen Powell wrote:
> But for a kernel install or reconfigure, it is the responsibility of the
> kernel maintainer scripts to invoke the bootloader.  See also, for example,
> linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
> on line 38.  This really is an "open and shut case", if only I can the kernel
> people to actually look at it!  Please look at it!

If I recall correctly, kernel maintainers have introduced
/etc/kernel/post{inst,rm}.d/ in order to avoid to hardcode each possible
bootloader in their script.
Can't lilo provide a script here ?

  Regards,
    Vincent

-- 
Vincent Danjean                 Adresse: Laboratoire d'Informatique de Grenoble
Téléphone:  +33 4 76 61 20 11            ENSIMAG - antenne de Montbonnot
Fax:        +33 4 76 61 20 99            ZIRST 51, avenue Jean Kuntzmann
Email: Vincent.Danjean@imag.fr           38330 Montbonnot Saint Martin




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Tue, 08 Jun 2010 11:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Tue, 08 Jun 2010 11:57:03 GMT) Full text and rfc822 format available.

Message #90 received at 505609@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Vincent Danjean <vdanjean.ml@free.fr>
Cc: 505609@bugs.debian.org, debian-devel@lists.debian.org, debian-kernel@lists.debian.org
Subject: Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
Date: Tue, 08 Jun 2010 12:53:50 +0100
[Message part 1 (text/plain, inline)]
On Tue, 2010-06-08 at 13:39 +0200, Vincent Danjean wrote:
> On 07/06/2010 17:37, Stephen Powell wrote:
> > But for a kernel install or reconfigure, it is the responsibility of the
> > kernel maintainer scripts to invoke the bootloader.  See also, for example,
> > linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
> > on line 38.  This really is an "open and shut case", if only I can the kernel
> > people to actually look at it!  Please look at it!
> 
> If I recall correctly, kernel maintainers have introduced
> /etc/kernel/post{inst,rm}.d/ in order to avoid to hardcode each possible
> bootloader in their script.
> Can't lilo provide a script here ?

It could, but that should be redundant in squeeze since update-initramfs
already runs lilo.

This appears to be a problem in lenny, where by default neither the
kernel postinst nor the initramfs builder runs lilo.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Tue, 08 Jun 2010 13:45:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Powell <zlinuxman@wowway.com>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Tue, 08 Jun 2010 13:45:12 GMT) Full text and rfc822 format available.

Message #95 received at 505609@bugs.debian.org (full text, mbox):

From: Stephen Powell <zlinuxman@wowway.com>
To: Vincent Danjean <vdanjean.ml@free.fr>
Cc: 505609@bugs.debian.org, debian-devel@lists.debian.org, debian-kernel@lists.debian.org
Subject: Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
Date: Tue, 8 Jun 2010 09:43:19 -0400 (EDT)
On Tue, 08 Jun 2010 07:39:58 -0400 (EDT), Vincent Danjean wrote:
> On 07/06/2010 17:37, Stephen Powell wrote:
>> But for a kernel install or reconfigure, it is the responsibility of the
>> kernel maintainer scripts to invoke the bootloader.  See also, for example,
>> linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
>> on line 38.  This really is an "open and shut case", if only I can the kernel
>> people to actually look at it!  Please look at it!
> 
> If I recall correctly, kernel maintainers have introduced
> /etc/kernel/post{inst,rm}.d/ in order to avoid to hardcode each possible
> bootloader in their script.
> Can't lilo provide a script here ?

   do_bootloader = yes

in /etc/kernel-img.conf means "run the historic boot loader for this platform".
For the i386 platform (and amd64) the historic boot loader is lilo.  For
the s390 platform, that boot loader is zipl.  The kernel maintainer scripts
for the s390 platform still specify zipl as the boot loader

   my $loader            = "zipl"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo

so that

   do_bootloader = yes

in /etc/kernel-img.conf will work.  The kernel maintainer scripts for i386 and amd64
for Lenny and beyond specify a null string.  That is inconsistent.  It should specify

   my $loader            = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo

for consistency between platforms.  For non-historic boot loaders, the method used is to set

   do_bootloader = no

in /etc/kernel-img.conf and supply a hook script of some kind, if needed.  For example,
grub version 1 in Lenny invokes it's hook scripts via

   do_bootloader = no
   postinst_hook = update-grub
   postrm_hook   = update-grub

in /etc/kernel-img.conf.  Grub version 2 does not need a hook script; so it simply sets

   do_bootloader = no

in /etc/kernel-img.conf.  In Squeeze and later, there is an alternate method for running
hook scripts (so that more than one hook script can be invoked).  Simply install the
script in /etc/kernel/preinst.d, /etc/kernel/prerm.d, /etc/kernel/postinst.d, or
/etc/kernel/postrm.d.  But even in Squeeze/Sid, the historic boot loader can still be run
by setting

   do_bootloader = yes

in /etc/kernel-img.conf.  That still works for zipl on the s390 platform.  But it's
been broken since Lenny on the i386 and amd64 platforms for lilo.

initramfs-tools also examines this variable and runs the historic boot loader
when

   update-initramfs -u

is invoked.  That still works, even on the i386 and amd64 platforms, provided that

   do_bootloader = yes

is specified in /etc/kernel-img.conf.  But

   update-initramfs -c

does not invoke the boot loader.  Running the historic boot loader during installation,
reconfiguration, or upgrade of a kernel is still the responsibility of the kernel
maintainer scripts.  And it cannot do so unless "my $loader" is set to the name of
the historic boot loader.  On s390, that variable is set properly.  On i386 and amd64,
it is not.

The kernel maintainer scripts provided by kernel image packages created by make-kpkg
on Squeeze and later are another story.  They no longer do *any* post-installation
actions unless user-provided hook scripts cause it to happen.  But the maintainer
scripts for official stock Debian kernel images still support these historic
post-installation activities.

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Wed, 16 Jun 2010 03:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 16 Jun 2010 03:27:04 GMT) Full text and rfc822 format available.

Message #100 received at 505609@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Stephen Powell <zlinuxman@wowway.com>
Cc: Vincent Danjean <vdanjean.ml@free.fr>, 505609@bugs.debian.org
Subject: Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
Date: Wed, 16 Jun 2010 04:25:45 +0100
[Message part 1 (text/plain, inline)]
On Tue, 2010-06-08 at 09:43 -0400, Stephen Powell wrote:
> On Tue, 08 Jun 2010 07:39:58 -0400 (EDT), Vincent Danjean wrote:
> > On 07/06/2010 17:37, Stephen Powell wrote:
> >> But for a kernel install or reconfigure, it is the responsibility of the
> >> kernel maintainer scripts to invoke the bootloader.  See also, for example,
> >> linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
> >> on line 38.  This really is an "open and shut case", if only I can the kernel
> >> people to actually look at it!  Please look at it!
> > 
> > If I recall correctly, kernel maintainers have introduced
> > /etc/kernel/post{inst,rm}.d/ in order to avoid to hardcode each possible
> > bootloader in their script.
> > Can't lilo provide a script here ?
> 
>    do_bootloader = yes
> 
> in /etc/kernel-img.conf means "run the historic boot loader for this platform".
> For the i386 platform (and amd64) the historic boot loader is lilo.  For
> the s390 platform, that boot loader is zipl.  The kernel maintainer scripts
> for the s390 platform still specify zipl as the boot loader
> 
>    my $loader            = "zipl"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
> 
> so that
> 
>    do_bootloader = yes
> 
> in /etc/kernel-img.conf will work.  The kernel maintainer scripts for i386 and amd64
> for Lenny and beyond specify a null string.  That is inconsistent.  It should specify
> 
>    my $loader            = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
> 
> for consistency between platforms.
[...]

This code and the file /etc/kernel-img.conf are vestiges of
kernel-package which are gradually being removed from the official
kernel packages.  Therefore I don't think we should reinstate this idea
of the default loader but we should change the code so that it doesn't
silently fail if do_loader is set and loader is not.

All packages that need to react to kernel installation or removal should
install appropriate hook scripts in the directories under /etc/kernel
instead of relying on specific support in the kernel maintainer scripts.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Wed, 16 Jun 2010 04:06:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Wed, 16 Jun 2010 04:06:06 GMT) Full text and rfc822 format available.

Message #105 received at 505609@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Stephen Powell <zlinuxman@wowway.com>, Bastian Blank <waldi@debian.org>, Maximilian Attems <mattems@hep.itp.tuwien.ac.at>
Cc: Vincent Danjean <vdanjean.ml@free.fr>, 505609@bugs.debian.org
Subject: Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
Date: Wed, 16 Jun 2010 04:48:47 +0100
[Message part 1 (text/plain, inline)]
I wrote:
> This code and the file /etc/kernel-img.conf are vestiges of
> kernel-package which are gradually being removed from the official
> kernel packages.  Therefore I don't think we should reinstate this idea
> of the default loader but we should change the code so that it doesn't
> silently fail if do_loader is set and loader is not.

How does this change look?

Ben.

--- linux-2.6/debian/templates/temp.image.plain/postinst	(revision 15874)
+++ linux-2.6/debian/templates/temp.image.plain/postinst	(working copy)
@@ -1180,25 +1180,32 @@
 LOADER: {
   last unless $do_boot_enable; # Exit if explicitly asked to
 
-  last if $loader =~ /silo/i; # SILO does not have to be executed.
-  last if $loader =~ /yaboot/i; # yaboot does not have to be executed.
-  last if $loader =~ /milo/i; # MILO does not have to be executed.
-  last if $loader =~ /nettrom/i; # NETTROM does not have to be executed.
-  last if $loader =~ /arcboot/i; # ARCBOOT does not have to be executed.
-  last if $loader =~ /delo/i; # DELO does not have to be executed.
-  if ($official_image =~ /^\s*YES\s*$/o) {
-    last if $loader =~ /quik/i; # maintainer asked quik invocation to be ignored
+  if (!$explicit_do_loader) {
+    last if $loader =~ /silo/i; # SILO does not have to be executed.
+    last if $loader =~ /yaboot/i; # yaboot does not have to be executed.
+    last if $loader =~ /milo/i; # MILO does not have to be executed.
+    last if $loader =~ /nettrom/i; # NETTROM does not have to be executed.
+    last if $loader =~ /arcboot/i; # ARCBOOT does not have to be executed.
+    last if $loader =~ /delo/i; # DELO does not have to be executed.
+    if ($official_image =~ /^\s*YES\s*$/o) {
+      last if $loader =~ /quik/i; # maintainer asked quik invocation to be ignored
+    }
   }
 
-  last unless $loaderloc;
-  last unless -x $loaderloc;
   last unless $do_bootloader;
 
-  if (-T "/etc/$loader.conf") {
+  if ($loaderloc && -x $loaderloc && -T "/etc/$loader.conf") {
     # Trust and use the existing lilo.conf.
     print STDERR "You already have a $Loader configuration in /etc/$loader.conf\n";
     my $ret = &run_lilo();
     exit $ret if $ret;
+  } else {
+    if ($loader) {
+      print STDERR "$Loader was not found and has not been updated\n";
+    } else if ($explicit_do_loader || !$postinst_hook) {
+      print STDERR "No bootloader has been configured in /etc/kernel-img.conf\n"
+	. "The bootloader may need to be updated manually\n";
+    }
   }
 }
 
--- END ---

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Thu, 17 Jun 2010 16:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Powell <zlinuxman@wowway.com>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 17 Jun 2010 16:36:03 GMT) Full text and rfc822 format available.

Message #110 received at 505609@bugs.debian.org (full text, mbox):

From: Stephen Powell <zlinuxman@wowway.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Vincent Danjean <vdanjean.ml@free.fr>, 505609@bugs.debian.org, debian-s390@lists.debian.org, waldi@debian.org, Joachim Wiedorn <ad_debian@joonet.de>
Subject: Re: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
Date: Thu, 17 Jun 2010 12:33:58 -0400 (EDT)
On Tue, 15 Jun 2010 23:25:45 -0400 (EDT), Ben Hutchings wrote:
> On Tue, 2010-06-08 at 09:43 -0400, Stephen Powell wrote:
>> 
>>    do_bootloader = yes
>> 
>> in /etc/kernel-img.conf means "run the historic boot loader for this platform".
>> For the i386 platform (and amd64) the historic boot loader is lilo.  For
>> the s390 platform, that boot loader is zipl.  The kernel maintainer scripts
>> for the s390 platform still specify zipl as the boot loader
>> 
>>    my $loader            = "zipl"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
>> 
>> so that
>> 
>>    do_bootloader = yes
>> 
>> in /etc/kernel-img.conf will work.  The kernel maintainer scripts for i386 and amd64
>> for Lenny and beyond specify a null string.  That is inconsistent.  It should specify
>> 
>>    my $loader            = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
>> 
>> for consistency between platforms.
>> [...]
> 
> This code and the file /etc/kernel-img.conf are vestiges of
> kernel-package which are gradually being removed from the official
> kernel packages.  Therefore I don't think we should reinstate this idea
> of the default loader but we should change the code so that it doesn't
> silently fail if do_loader is set and loader is not.

Well, I agree that the maintainer script should not silently fail.
But removing support for the historic boot loader actually makes the
official stock Debian kernel image package maintainer scripts *more*
like kernel-package, not less.  To be more precise, it makes them
more like the *Squeeze* version of kernel-package.  The maintainer
scripts which get packaged with a kernel image package created by
make-kpkg under Squeeze and later releases no longer perform *any*
post installation activities.  They do not create an initial RAM file
system (even if the --initrd option was specified on the make-kpkg
command line), they do not maintain symbolic links (even if
"do_symlinks = yes" is specified in /etc/kernel-img.conf), and they
do not run the historic boot loader (even if "do_bootloader = yes" is
specified in /etc/kernel-img.conf).  If you want any of these things
done, then either the user or an installed package must provide hook
scripts to accomplish this.  The maintainer scripts packaged
with kernel image packages created by make-kpkg under Lenny and
previous releases still do all these things.

I can maybe accept your proposal for Squeeze.  But for Lenny, I believe
that the maintainer scripts should be changed back they way they
were.  In other words,

   my $loader            = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
   
should be set in the maintainer scripts.  After all, Lenny does
not have the generalized hook script environment that Squeeze does.
I believe that this bug is severe enough to warrant inclusion of the
fix in stable-proposed-updates.

> 
> All packages that need to react to kernel installation or removal should
> install appropriate hook scripts in the directories under /etc/kernel
> instead of relying on specific support in the kernel maintainer scripts.
>

Again, I can maybe accept that argument for Squeeze, but not for Lenny.
However, to be consistent, if you're going to leave "my $loader" set to the null
string in i386 and amd64 kernel maintainer scripts, you should also set
it to the null string for s390 kernel maintainer scripts.
This will affect the s390-tools package, which includes the zipl boot
loader for the s390 platform; so I'm copying them in on this.  If your
proposed solution goes through, they will need to create some kind of
hook script too, or at least document the need for one.  And so will lilo.
And when we're all done, that leaves us with one foot in the old way
of doing things and one foot in the new way of doing things.  The initial
RAM file system will still be created automatically, symlinks will still
be maintained (if requested in /etc/kernel-img.conf), but the historic
boot loader will not be run.

I would rather see the the stock kernel
maintainer scripts do none of the above, like the new kernel-package,
or all of the above, like the historic stock kernel maintainer scripts.
And this is pretty late in the Squeeze development cycle to start making
design changes.  We're getting pretty close to a freeze, are we not?
It sure seems to me like a one-line change in the kernel maintainer
scripts is a much faster and much simpler fix, not to mention more
consistent.  The maintainer scripts' support for the historic boot
loader should be retained, in my opinion, at least for Squeeze.  Then,
if you want to change the design of how kernel maintainer scripts
work, that can be done in Squeeze+1.

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Thu, 17 Jun 2010 22:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Thu, 17 Jun 2010 22:15:03 GMT) Full text and rfc822 format available.

Message #115 received at 505609@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Stephen Powell <zlinuxman@wowway.com>, 505609@bugs.debian.org
Cc: Vincent Danjean <vdanjean.ml@free.fr>, debian-s390@lists.debian.org, waldi@debian.org, Joachim Wiedorn <ad_debian@joonet.de>
Subject: Re: Bug#505609: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
Date: Thu, 17 Jun 2010 23:11:04 +0100
On Thu, Jun 17, 2010 at 12:33:58PM -0400, Stephen Powell wrote:
[...]
> I can maybe accept your proposal for Squeeze.  But for Lenny, I believe
> that the maintainer scripts should be changed back they way they
> were.  In other words,
>
>    my $loader            = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
>    
> should be set in the maintainer scripts.  After all, Lenny does
> not have the generalized hook script environment that Squeeze does.

But it does allow users to configure the loader to be run, using either
the 'loader' or 'postinst_hook' variable.

> I believe that this bug is severe enough to warrant inclusion of the
> fix in stable-proposed-updates.

The fact that the historical bootloader is not automatically run is not a
bug; it is an intentional change.  Only the silent failure is a bug.

> > 
> > All packages that need to react to kernel installation or removal should
> > install appropriate hook scripts in the directories under /etc/kernel
> > instead of relying on specific support in the kernel maintainer scripts.
> >
> 
> Again, I can maybe accept that argument for Squeeze, but not for Lenny.
> However, to be consistent, if you're going to leave "my $loader" set to the null
> string in i386 and amd64 kernel maintainer scripts, you should also set
> it to the null string for s390 kernel maintainer scripts.

Yes. I think that's probably a reasonable change for squeeze.

[...]
> The maintainer scripts' support for the historic boot
> loader should be retained, in my opinion, at least for Squeeze.  Then,
> if you want to change the design of how kernel maintainer scripts
> work, that can be done in Squeeze+1.
 
It cannot be 'retained' because it is not there at present.  Nor will it
be reinstated.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Fri, 18 Jun 2010 00:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Powell <zlinuxman@wowway.com>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 18 Jun 2010 00:39:03 GMT) Full text and rfc822 format available.

Message #120 received at 505609@bugs.debian.org (full text, mbox):

From: Stephen Powell <zlinuxman@wowway.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: 505609@bugs.debian.org, Vincent Danjean <vdanjean.ml@free.fr>, debian-s390@lists.debian.org, waldi@debian.org, Joachim Wiedorn <ad_debian@joonet.de>
Subject: loader varialbe in kernel maintainer scripts
Date: Thu, 17 Jun 2010 20:37:22 -0400 (EDT)
On Thu, 17 Jun 2010 18:11:04 -0400 (EDT), Ben Hutchings wrote:
> On Thu, Jun 17, 2010 at 12:33:58PM -0400, Stephen Powell wrote:
>> [...]
>> I can maybe accept your proposal for Squeeze.  But for Lenny, I believe
>> that the maintainer scripts should be changed back they way they
>> were.  In other words,
>>
>>    my $loader            = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
>>    
>> should be set in the maintainer scripts.  After all, Lenny does
>> not have the generalized hook script environment that Squeeze does.
> 
> But it does allow users to configure the loader to be run, using either
> the 'loader' or 'postinst_hook' variable.

And how would one go about setting this "loader" variable?
The "loader" variable is not documented in the man page for
/etc/kernel-img.conf in Lenny, which appears to be the closest thing
there is to documentation for the variables supported by official
Debian stock kernel images.  Nevertheless, at your suggestion, I tried
putting

   loader = lilo

in /etc/kernel-img.conf.  ("do_bootloader = yes" was also set.)  Then I
issued

   dpkg-reconfigure linux-image-2.6.26-2-686

There was no evidence from the output that lilo was run.  As for the
postinst_hook and postrm_hook variables, they do work, but one can't
simply specify

   postinst_hook = lilo
   postrm_hook = lilo

in /etc/kernel-img.conf.
That won't work because lilo doesn't like the parameters passed to it.
It is necessary to create a wrapper script around lilo that strips off
the parameters passed to it and redirects standard output to standard
error.  For example, on my unofficial kernel building web page, I
recommend that lilo users create a hook script called
/usr/sbin/lilo-update that looks like this:

   #!/bin/sh
   # The purpose of this script is to strip off any
   # arguments passed and simply invoke lilo, redirecting
   # standard output to standard error.  It is intended
   # to be referenced by /etc/kernel-img.conf in the
   # postinst_hook and postrm_hook variables.
   #
   lilo >&2

Then mark it executable with

   chmod +x /usr/sbin/lilo-update

Then edit /etc/kernel-img.conf and specify

   postinst_hook = lilo-update
   postrm_hook = lilo-update

That is how I have been recommending that users circumvent
this bug (or feature, depending on your point of view).

>> I believe that this bug is severe enough to warrant inclusion of the
>> fix in stable-proposed-updates.
> 
> The fact that the historical bootloader is not automatically run is not a
> bug; it is an intentional change.  Only the silent failure is a bug.

Preventing the historic boot loader from being run could have been
accomplished by simply setting

   do_bootloader = no

in /etc/kernel-img.conf.  By setting "my $loader" to the null string, you
made it *impossible* for the user to request that the historic boot loader
be run.  But OK, if you say it's a feature, not a bug, then I'll have to
accept that.  I must say I'm disappointed though.

>>
>> However, to be consistent, if you're going to leave "my $loader" set to the null
>> string in i386 and amd64 kernel maintainer scripts, you should also set
>> it to the null string for s390 kernel maintainer scripts.
> 
> Yes. I think that's probably a reasonable change for squeeze.

I was trying to use that argument to convince you to change it back for
i386 and amd64, not to convince you to "break" it for s390!  Oh well.
Now it appears that s390 users will be able to look forward to this
"feature" also.

>> [...]
>> The maintainer scripts' support for the historic boot
>> loader should be retained, in my opinion, at least for Squeeze.  Then,
>> if you want to change the design of how kernel maintainer scripts
>> work, that can be done in Squeeze+1.
>  
> It cannot be 'retained' because it is not there at present.  Nor will it
> be reinstated.

OK, if you're determined not to set "my $loader" to the name of the
historic boot loader, then please do make a change similar to the
one you proposed so that it will tell the user to manually
run the boot loader.  Then close this bug report.

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Fri, 18 Jun 2010 01:06:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 18 Jun 2010 01:06:03 GMT) Full text and rfc822 format available.

Message #125 received at 505609@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Stephen Powell <zlinuxman@wowway.com>
Cc: 505609@bugs.debian.org, Vincent Danjean <vdanjean.ml@free.fr>, debian-s390@lists.debian.org, waldi@debian.org, Joachim Wiedorn <ad_debian@joonet.de>
Subject: Re: loader varialbe in kernel maintainer scripts
Date: Fri, 18 Jun 2010 02:02:54 +0100
[Message part 1 (text/plain, inline)]
On Thu, 2010-06-17 at 20:37 -0400, Stephen Powell wrote:
> On Thu, 17 Jun 2010 18:11:04 -0400 (EDT), Ben Hutchings wrote:
> > On Thu, Jun 17, 2010 at 12:33:58PM -0400, Stephen Powell wrote:
> >> [...]
> >> I can maybe accept your proposal for Squeeze.  But for Lenny, I believe
> >> that the maintainer scripts should be changed back they way they
> >> were.  In other words,
> >>
> >>    my $loader            = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
> >>    
> >> should be set in the maintainer scripts.  After all, Lenny does
> >> not have the generalized hook script environment that Squeeze does.
> > 
> > But it does allow users to configure the loader to be run, using either
> > the 'loader' or 'postinst_hook' variable.
> 
> And how would one go about setting this "loader" variable?
> The "loader" variable is not documented in the man page for
> /etc/kernel-img.conf in Lenny, which appears to be the closest thing
> there is to documentation for the variables supported by official
> Debian stock kernel images.  Nevertheless, at your suggestion, I tried
> putting
> 
>    loader = lilo
> 
> in /etc/kernel-img.conf.  ("do_bootloader = yes" was also set.)  Then I
> issued
> 
>    dpkg-reconfigure linux-image-2.6.26-2-686
> 
> There was no evidence from the output that lilo was run.
[...]

I'm sorry, you're right.  Most of the other variables at the top of the
postinst script can be overridden by /etc/kernel-img.conf, but not this
one.  Given that, I think you are right that the 'historical' bootloader
setting should be restored in an update to lenny.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Fri, 18 Jun 2010 01:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Powell <zlinuxman@wowway.com>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 18 Jun 2010 01:24:03 GMT) Full text and rfc822 format available.

Message #130 received at 505609@bugs.debian.org (full text, mbox):

From: Stephen Powell <zlinuxman@wowway.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: 505609@bugs.debian.org, Vincent Danjean <vdanjean.ml@free.fr>, debian-s390@lists.debian.org, waldi@debian.org, Joachim Wiedorn <ad_debian@joonet.de>
Subject: Re: loader varialbe in kernel maintainer scripts
Date: Thu, 17 Jun 2010 21:22:20 -0400 (EDT)
On Thu, 17 Jun 2010 21:02:54 -0400 (EDT), Ben Hutchings wrote:
> 
> I'm sorry, you're right.  Most of the other variables at the top of the
> postinst script can be overridden by /etc/kernel-img.conf, but not this
> one.  Given that, I think you are right that the 'historical' bootloader
> setting should be restored in an update to lenny.

Great!  What about Squeeze?  It still supports creating the initial RAM
file system and updating symlinks via variables in /etc/kernel-img.conf.
Doesn't it make sense to allow the historical boot loader code to work
as well?

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Fri, 18 Jun 2010 08:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joachim Wiedorn <ad_debian@joonet.de>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 18 Jun 2010 08:30:04 GMT) Full text and rfc822 format available.

Message #135 received at 505609@bugs.debian.org (full text, mbox):

From: Joachim Wiedorn <ad_debian@joonet.de>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Stephen Powell <zlinuxman@wowway.com>, 505609@bugs.debian.org, Vincent Danjean <vdanjean.ml@free.fr>, Bastian Blank <waldi@debian.org>
Subject: Re: loader varialbe in kernel maintainer scripts
Date: Fri, 18 Jun 2010 10:25:38 +0200
[Message part 1 (text/plain, inline)]
Ben Hutchings <ben@decadent.org.uk> wrote on 2010-06-18 02:02:

> On Thu, 2010-06-17 at 20:37 -0400, Stephen Powell wrote:
> > On Thu, 17 Jun 2010 18:11:04 -0400 (EDT), Ben Hutchings wrote:
:
:
> > And how would one go about setting this "loader" variable?
> > The "loader" variable is not documented in the man page for
> > /etc/kernel-img.conf in Lenny, which appears to be the closest thing
> > there is to documentation for the variables supported by official
> > Debian stock kernel images.  Nevertheless, at your suggestion, I tried
> > putting
> > 
> >    loader = lilo
> > 
> > in /etc/kernel-img.conf.  ("do_bootloader = yes" was also set.)  Then I
> > issued
> > 
> >    dpkg-reconfigure linux-image-2.6.26-2-686
> > 
> > There was no evidence from the output that lilo was run.
> [...]
> 
> I'm sorry, you're right.  Most of the other variables at the top of the
> postinst script can be overridden by /etc/kernel-img.conf, but not this
> one.  Given that, I think you are right that the 'historical' bootloader
> setting should be restored in an update to lenny.

Now I am a little confused. How is the recommended procedure for using the
LILO bootloader within squeeze/sid ? 
How I understand the normal installation of lilo package have the result,
that lilo doesn't be started after an kernel update (and also after update
of initramfs-tools ?). 
What must I config on my squeeze machine that lilo bootloader will be
automatically updated after kernel update?


Fondest regards,
 Joachim Wiedorn

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Fri, 18 Jun 2010 14:57:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Powell <zlinuxman@wowway.com>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 18 Jun 2010 14:57:07 GMT) Full text and rfc822 format available.

Message #140 received at 505609@bugs.debian.org (full text, mbox):

From: Stephen Powell <zlinuxman@wowway.com>
To: Joachim Wiedorn <ad_debian@joonet.de>
Cc: Ben Hutchings <ben@decadent.org.uk>, 505609@bugs.debian.org, Vincent Danjean <vdanjean.ml@free.fr>, Bastian Blank <waldi@debian.org>
Subject: Re: loader varialbe in kernel maintainer scripts
Date: Fri, 18 Jun 2010 10:55:35 -0400 (EDT)
On Fri, 18 Jun 2010 04:25:38 -0400 (EDT), Joachim Wiedorn wrote:
> Ben Hutchings <ben@decadent.org.uk> wrote on 2010-06-18 02:02:
>> On Thu, 2010-06-17 at 20:37 -0400, Stephen Powell wrote:
>>> And how would one go about setting this "loader" variable?
>>> The "loader" variable is not documented in the man page for
>>> /etc/kernel-img.conf in Lenny, which appears to be the closest thing
>>> there is to documentation for the variables supported by official
>>> Debian stock kernel images.  Nevertheless, at your suggestion, I tried
>>> putting
>>> 
>>>    loader = lilo
>>> 
>>> in /etc/kernel-img.conf.  ("do_bootloader = yes" was also set.)  Then I
>>> issued
>>> 
>>>    dpkg-reconfigure linux-image-2.6.26-2-686
>>> 
>>> There was no evidence from the output that lilo was run.
>>> [...]
>> 
>> I'm sorry, you're right.  Most of the other variables at the top of the
>> postinst script can be overridden by /etc/kernel-img.conf, but not this
>> one.  Given that, I think you are right that the 'historical' bootloader
>> setting should be restored in an update to lenny.
> 
> Now I am a little confused. How is the recommended procedure for using the
> LILO bootloader within squeeze/sid? 
> How I understand the normal installation of lilo package have the result,
> that lilo doesn't be started after an kernel update (and also after update
> of initramfs-tools?). 
> What must I config on my squeeze machine that lilo bootloader will be
> automatically updated after kernel update?

So far, Ben has only agreed to reinstate the historic function of

   do_bootloader = yes

in /etc/kernel-img.conf for Lenny kernel maintainer scripts.
It hasn't actually happened yet, but
he has agreed to restore its former function in Lenny as it was in Etch
and previous releases.  I am trying to persuade him to restore its
function in Squeeze too.  Whether or not I am successful remains to be
seen.  In the mean time, for lilo users of Squeeze/Sid who use *only* official
stock Debian kernels, I recommend that they use the hook script described
in an earlier post to this bug log in conjunction with other appropriate
settings in /etc/kernel-img.conf.

For lilo users of Squeeze/Sid who use
custom kernels created by make-kpkg, I recommend that they use the hook
scripts provided on my unofficial kernel building web page,
http://www.wowway.com/~zlinuxman/Kernel.htm, under "Step 10: Customize
the Kernel Installation Environment".  I must add that this recommendation
is my own and not official Debian advice.  I have never used the
upstream-provided "make deb-pkg" way of building a custom kernel; so
I don't have any hook scripts pre-made for that purpose.  There doesn't
seem to be a "one size fits all" solution at this point.  If Ben agrees
to reinstate the historic function of "do_bootloader = yes" for Squeeze,
then there will be a "one size fits all" solution for lilo users, at least
as it pertains to stock kernels.  Users of custom kernels are on their own.
They need to figure out what hook scripts they need and how to customize
and configure them.  And if they don't do it right, you may be sure that
they will blame lilo!  (That's one of the reasons why I think it would
be a good idea for lilo to implement a "check sum" method of figuring
out if something changed in the kernel image or initial RAM file system
image without lilo being re-run.  But I digress.)

As for "update-initramfs -u", it *will* invoke lilo if lilo is installed
and "do_bootloader = yes" is specified in /etc/kernel-img.conf, which I
highly recommend.  There are types of upgrades which do not affect the
kernel itself but which do require that the initial RAM file system
be re-built.  And for lilo users, it is essential that lilo be run after
any changes are made to the initial RAM file system.  "update-initramfs -c"
and "update-initramfs -d", however, will *not* invoke lilo, even if
"do_bootloader = yes" is specified in /etc/kernel-img.conf.

HTH

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Fri, 18 Jun 2010 16:03:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <max@stro.at>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 18 Jun 2010 16:03:07 GMT) Full text and rfc822 format available.

Message #145 received at 505609@bugs.debian.org (full text, mbox):

From: maximilian attems <max@stro.at>
To: Stephen Powell <zlinuxman@wowway.com>, 505609@bugs.debian.org
Cc: Joachim Wiedorn <ad_debian@joonet.de>, Ben Hutchings <ben@decadent.org.uk>, Vincent Danjean <vdanjean.ml@free.fr>, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#505609: loader varialbe in kernel maintainer scripts
Date: Fri, 18 Jun 2010 17:51:11 +0200
On Fri, Jun 18, 2010 at 10:55:35AM -0400, Stephen Powell wrote:
> 
> So far, Ben has only agreed to reinstate the historic function of
> 
>    do_bootloader = yes
> 
> in /etc/kernel-img.conf for Lenny kernel maintainer scripts.
> It hasn't actually happened yet, but
> he has agreed to restore its former function in Lenny as it was in Etch
> and previous releases.  I am trying to persuade him to restore its
> function in Squeeze too.  Whether or not I am successful remains to be
> seen. 

it is gone, get over it.

> In the mean time, for lilo users of Squeeze/Sid who use *only* official
> stock Debian kernels, I recommend that they use the hook script described
> in an earlier post to this bug log in conjunction with other appropriate
> settings in /etc/kernel-img.conf.

it is about time that lilo gets an hook script.
even extlinux has one although that one seems to trigger funny bug
reports, but we are used to forward such bugs.
 
> For lilo users of Squeeze/Sid who use
> custom kernels created by make-kpkg,

k-p is deprecated, use upstream way: make deb-pkg
needs no strange debian scripting and is maintained in linux-2.6 itself.

> As for "update-initramfs -u", it *will* invoke lilo if lilo is installed
> and "do_bootloader = yes" is specified in /etc/kernel-img.conf, which I
> highly recommend. 

this fall back will be gone as soon as squeeze is out.
so you'd really need to gear up.

>There are types of upgrades which do not affect the
> kernel itself but which do require that the initial RAM file system
> be re-built.  And for lilo users, it is essential that lilo be run after
> any changes are made to the initial RAM file system.  "update-initramfs -c"
> and "update-initramfs -d", however, will *not* invoke lilo, even if
> "do_bootloader = yes" is specified in /etc/kernel-img.conf.

yes in those case either you have valid hooks or an intelligent
postinst.

thanks

-- 
maks




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>:
Bug#505609; Package linux-2.6. (Fri, 18 Jun 2010 20:48:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stephen Powell <zlinuxman@wowway.com>:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>. (Fri, 18 Jun 2010 20:48:07 GMT) Full text and rfc822 format available.

Message #150 received at 505609@bugs.debian.org (full text, mbox):

From: Stephen Powell <zlinuxman@wowway.com>
To: maximilian attems <max@stro.at>
Cc: 505609@bugs.debian.org, Joachim Wiedorn <ad_debian@joonet.de>, Ben Hutchings <ben@decadent.org.uk>, Vincent Danjean <vdanjean.ml@free.fr>, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#505609: loader varialbe in kernel maintainer scripts
Date: Fri, 18 Jun 2010 16:44:57 -0400 (EDT)
On Fri, 18 Jun 2010 11:51:11 -0400 (EDT), maximilian attems wrote:
> On Fri, Jun 18, 2010 at 10:55:35AM -0400, Stephen Powell wrote:
>> As for "update-initramfs -u", it *will* invoke lilo if lilo is installed
>> and "do_bootloader = yes" is specified in /etc/kernel-img.conf, which I
>> highly recommend. 
> 
> this fall back will be gone as soon as squeeze is out.
> so you'd really need to gear up.

That is interesting.  Suppose that the user issues an

   aptitude update
   aptitude full-upgrade

sequence.  And suppose something other than the kernel gets updated that
requires that the initial RAM file system be updated.  Somehow, aptitude
knows to run "update-initramfs -u".  But if "update-initramfs -u" does
not invoke lilo, and the kernel is not updated, what will cause lilo to
get run?  The kernel hook scripts won't be run because the kernel itself
was not updated.  The same principle applies to zipl on the s390 platform,
which is the *only* supported boot loader on this platform, by the way.

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-




Added tag(s) pending. Request was from Ben Hutchings <benh@alioth.debian.org> to control@bugs.debian.org. (Sat, 19 Jun 2010 23:33:03 GMT) Full text and rfc822 format available.

Forcibly Merged 505609 535331. Request was from Ben Hutchings <ben@decadent.org.uk> to control@bugs.debian.org. (Sat, 19 Jun 2010 23:36:04 GMT) Full text and rfc822 format available.

Bug Marked as found in versions 2.6.26-17. Request was from Ben Hutchings <ben@decadent.org.uk> to control@bugs.debian.org. (Sat, 19 Jun 2010 23:39:05 GMT) Full text and rfc822 format available.

Bug Marked as found in versions 2.6.26-19. Request was from Ben Hutchings <ben@decadent.org.uk> to control@bugs.debian.org. (Sat, 19 Jun 2010 23:39:06 GMT) Full text and rfc822 format available.

Bug Marked as found in versions 2.6.26-10. Request was from Ben Hutchings <ben@decadent.org.uk> to control@bugs.debian.org. (Sat, 19 Jun 2010 23:39:07 GMT) Full text and rfc822 format available.

Reply sent to dann frazier <dannf@debian.org>:
You have taken responsibility. (Mon, 21 Jun 2010 01:57:09 GMT) Full text and rfc822 format available.

Notification sent to Xavier Brochard <xavier@alternatif.org>:
Bug acknowledged by developer. (Mon, 21 Jun 2010 01:57:09 GMT) Full text and rfc822 format available.

Message #165 received at 505609-close@bugs.debian.org (full text, mbox):

From: dann frazier <dannf@debian.org>
To: 505609-close@bugs.debian.org
Subject: Bug#505609: fixed in linux-2.6 2.6.26-24
Date: Mon, 21 Jun 2010 01:53:10 +0000
Source: linux-2.6
Source-Version: 2.6.26-24

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

linux-2.6_2.6.26-24.diff.gz
  to main/l/linux-2.6/linux-2.6_2.6.26-24.diff.gz
linux-2.6_2.6.26-24.dsc
  to main/l/linux-2.6/linux-2.6_2.6.26-24.dsc
linux-doc-2.6.26_2.6.26-24_all.deb
  to main/l/linux-2.6/linux-doc-2.6.26_2.6.26-24_all.deb
linux-headers-2.6.26-2-all-amd64_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-headers-2.6.26-2-all-amd64_2.6.26-24_amd64.deb
linux-headers-2.6.26-2-all_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-headers-2.6.26-2-all_2.6.26-24_amd64.deb
linux-headers-2.6.26-2-amd64_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-headers-2.6.26-2-amd64_2.6.26-24_amd64.deb
linux-headers-2.6.26-2-common-openvz_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-headers-2.6.26-2-common-openvz_2.6.26-24_amd64.deb
linux-headers-2.6.26-2-common-vserver_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-headers-2.6.26-2-common-vserver_2.6.26-24_amd64.deb
linux-headers-2.6.26-2-common-xen_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-headers-2.6.26-2-common-xen_2.6.26-24_amd64.deb
linux-headers-2.6.26-2-common_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-headers-2.6.26-2-common_2.6.26-24_amd64.deb
linux-headers-2.6.26-2-openvz-amd64_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-headers-2.6.26-2-openvz-amd64_2.6.26-24_amd64.deb
linux-headers-2.6.26-2-vserver-amd64_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-headers-2.6.26-2-vserver-amd64_2.6.26-24_amd64.deb
linux-headers-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-headers-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
linux-image-2.6.26-2-amd64_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-image-2.6.26-2-amd64_2.6.26-24_amd64.deb
linux-image-2.6.26-2-openvz-amd64_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-image-2.6.26-2-openvz-amd64_2.6.26-24_amd64.deb
linux-image-2.6.26-2-vserver-amd64_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-image-2.6.26-2-vserver-amd64_2.6.26-24_amd64.deb
linux-image-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-image-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
linux-libc-dev_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-libc-dev_2.6.26-24_amd64.deb
linux-manual-2.6.26_2.6.26-24_all.deb
  to main/l/linux-2.6/linux-manual-2.6.26_2.6.26-24_all.deb
linux-modules-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
  to main/l/linux-2.6/linux-modules-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
linux-patch-debian-2.6.26_2.6.26-24_all.deb
  to main/l/linux-2.6/linux-patch-debian-2.6.26_2.6.26-24_all.deb
linux-source-2.6.26_2.6.26-24_all.deb
  to main/l/linux-2.6/linux-source-2.6.26_2.6.26-24_all.deb
linux-support-2.6.26-2_2.6.26-24_all.deb
  to main/l/linux-2.6/linux-support-2.6.26-2_2.6.26-24_all.deb
linux-tree-2.6.26_2.6.26-24_all.deb
  to main/l/linux-2.6/linux-tree-2.6.26_2.6.26-24_all.deb
xen-linux-system-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
  to main/l/linux-2.6/xen-linux-system-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb



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

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 505609@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
dann frazier <dannf@debian.org> (supplier of updated linux-2.6 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sun, 20 Jun 2010 13:54:25 -0600
Source: linux-2.6
Binary: linux-source-2.6.26 linux-doc-2.6.26 linux-manual-2.6.26 linux-patch-debian-2.6.26 linux-tree-2.6.26 linux-support-2.6.26-2 linux-libc-dev linux-headers-2.6.26-2-all linux-headers-2.6.26-2-all-alpha linux-headers-2.6.26-2-common linux-image-2.6.26-2-alpha-generic linux-headers-2.6.26-2-alpha-generic linux-image-2.6.26-2-alpha-smp linux-headers-2.6.26-2-alpha-smp linux-image-2.6.26-2-alpha-legacy linux-headers-2.6.26-2-alpha-legacy linux-headers-2.6.26-2-all-amd64 linux-image-2.6.26-2-amd64 linux-headers-2.6.26-2-amd64 linux-headers-2.6.26-2-common-openvz linux-image-2.6.26-2-openvz-amd64 linux-headers-2.6.26-2-openvz-amd64 linux-headers-2.6.26-2-common-vserver linux-image-2.6.26-2-vserver-amd64 linux-headers-2.6.26-2-vserver-amd64 linux-headers-2.6.26-2-common-xen linux-image-2.6.26-2-xen-amd64 linux-modules-2.6.26-2-xen-amd64 linux-headers-2.6.26-2-xen-amd64 xen-linux-system-2.6.26-2-xen-amd64 linux-headers-2.6.26-2-all-arm linux-image-2.6.26-2-footbridge linux-headers-2.6.26-2-footbridge linux-image-2.6.26-2-iop32x linux-headers-2.6.26-2-iop32x linux-image-2.6.26-2-ixp4xx linux-headers-2.6.26-2-ixp4xx linux-image-2.6.26-2-orion5x linux-headers-2.6.26-2-orion5x linux-headers-2.6.26-2-all-armel linux-image-2.6.26-2-versatile linux-headers-2.6.26-2-versatile linux-headers-2.6.26-2-all-hppa linux-image-2.6.26-2-parisc linux-headers-2.6.26-2-parisc linux-image-2.6.26-2-parisc-smp linux-headers-2.6.26-2-parisc-smp linux-image-2.6.26-2-parisc64 linux-headers-2.6.26-2-parisc64 linux-image-2.6.26-2-parisc64-smp linux-headers-2.6.26-2-parisc64-smp linux-headers-2.6.26-2-all-i386 linux-image-2.6.26-2-486 linux-headers-2.6.26-2-486 linux-image-2.6.26-2-686 linux-headers-2.6.26-2-686 linux-image-2.6.26-2-686-bigmem linux-headers-2.6.26-2-686-bigmem linux-image-2.6.26-2-openvz-686 linux-headers-2.6.26-2-openvz-686 linux-image-2.6.26-2-vserver-686 linux-headers-2.6.26-2-vserver-686 linux-image-2.6.26-2-vserver-686-bigmem linux-headers-2.6.26-2-vserver-686-bigmem linux-image-2.6.26-2-xen-686 linux-modules-2.6.26-2-xen-686 linux-headers-2.6.26-2-xen-686 xen-linux-system-2.6.26-2-xen-686 linux-headers-2.6.26-2-all-ia64 linux-image-2.6.26-2-itanium linux-headers-2.6.26-2-itanium linux-image-2.6.26-2-mckinley linux-headers-2.6.26-2-mckinley linux-image-2.6.26-2-vserver-itanium linux-headers-2.6.26-2-vserver-itanium linux-image-2.6.26-2-vserver-mckinley linux-headers-2.6.26-2-vserver-mckinley linux-headers-2.6.26-2-all-m68k linux-image-2.6.26-2-amiga linux-headers-2.6.26-2-amiga linux-image-2.6.26-2-atari linux-headers-2.6.26-2-atari linux-image-2.6.26-2-bvme6000 linux-headers-2.6.26-2-bvme6000 linux-image-2.6.26-2-mac linux-headers-2.6.26-2-mac linux-image-2.6.26-2-mvme147 linux-headers-2.6.26-2-mvme147 linux-image-2.6.26-2-mvme16x linux-headers-2.6.26-2-mvme16x linux-headers-2.6.26-2-all-mips linux-image-2.6.26-2-r4k-ip22 linux-headers-2.6.26-2-r4k-ip22 linux-image-2.6.26-2-r5k-ip32 linux-headers-2.6.26-2-r5k-ip32 linux-image-2.6.26-2-sb1-bcm91250a linux-headers-2.6.26-2-sb1-bcm91250a linux-image-2.6.26-2-sb1a-bcm91480b linux-headers-2.6.26-2-sb1a-bcm91480b linux-image-2.6.26-2-4kc-malta linux-headers-2.6.26-2-4kc-malta linux-image-2.6.26-2-5kc-malta linux-headers-2.6.26-2-5kc-malta linux-headers-2.6.26-2-all-mipsel linux-image-2.6.26-2-r5k-cobalt linux-headers-2.6.26-2-r5k-cobalt linux-headers-2.6.26-2-all-powerpc linux-image-2.6.26-2-powerpc linux-headers-2.6.26-2-powerpc linux-image-2.6.26-2-powerpc-smp linux-headers-2.6.26-2-powerpc-smp linux-image-2.6.26-2-powerpc64 linux-headers-2.6.26-2-powerpc64 linux-image-2.6.26-2-vserver-powerpc linux-headers-2.6.26-2-vserver-powerpc linux-image-2.6.26-2-vserver-powerpc64 linux-headers-2.6.26-2-vserver-powerpc64 linux-headers-2.6.26-2-all-s390 linux-image-2.6.26-2-s390 linux-headers-2.6.26-2-s390 linux-image-2.6.26-2-s390-tape linux-image-2.6.26-2-s390x linux-headers-2.6.26-2-s390x linux-image-2.6.26-2-vserver-s390x linux-headers-2.6.26-2-vserver-s390x linux-headers-2.6.26-2-all-sparc linux-image-2.6.26-2-sparc64 linux-headers-2.6.26-2-sparc64 linux-image-2.6.26-2-sparc64-smp linux-headers-2.6.26-2-sparc64-smp linux-image-2.6.26-2-vserver-sparc64 linux-headers-2.6.26-2-vserver-sparc64
Architecture: source all amd64
Version: 2.6.26-24
Distribution: stable
Urgency: high
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Changed-By: dann frazier <dannf@debian.org>
Description: 
 linux-doc-2.6.26 - Linux kernel specific documentation for version 2.6.26
 linux-headers-2.6.26-2-486 - Header files for Linux 2.6.26-2-486
 linux-headers-2.6.26-2-4kc-malta - Header files for Linux 2.6.26-2-4kc-malta
 linux-headers-2.6.26-2-5kc-malta - Header files for Linux 2.6.26-2-5kc-malta
 linux-headers-2.6.26-2-686 - Header files for Linux 2.6.26-2-686
 linux-headers-2.6.26-2-686-bigmem - Header files for Linux 2.6.26-2-686-bigmem
 linux-headers-2.6.26-2-all - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-all-alpha - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-all-amd64 - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-all-arm - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-all-armel - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-all-hppa - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-all-i386 - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-all-ia64 - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-all-m68k - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-all-mips - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-all-mipsel - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-all-powerpc - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-all-s390 - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-all-sparc - All header files for Linux 2.6.26
 linux-headers-2.6.26-2-alpha-generic - Header files for Linux 2.6.26-2-alpha-generic
 linux-headers-2.6.26-2-alpha-legacy - Header files for Linux 2.6.26-2-alpha-legacy
 linux-headers-2.6.26-2-alpha-smp - Header files for Linux 2.6.26-2-alpha-smp
 linux-headers-2.6.26-2-amd64 - Header files for Linux 2.6.26-2-amd64
 linux-headers-2.6.26-2-amiga - Header files for Linux 2.6.26-2-amiga
 linux-headers-2.6.26-2-atari - Header files for Linux 2.6.26-2-atari
 linux-headers-2.6.26-2-bvme6000 - Header files for Linux 2.6.26-2-bvme6000
 linux-headers-2.6.26-2-common - Common header files for Linux 2.6.26-2
 linux-headers-2.6.26-2-common-openvz - Common header files for Linux 2.6.26-2-openvz
 linux-headers-2.6.26-2-common-vserver - Common header files for Linux 2.6.26-2-vserver
 linux-headers-2.6.26-2-common-xen - Common header files for Linux 2.6.26-2-xen
 linux-headers-2.6.26-2-footbridge - Header files for Linux 2.6.26-2-footbridge
 linux-headers-2.6.26-2-iop32x - Header files for Linux 2.6.26-2-iop32x
 linux-headers-2.6.26-2-itanium - Header files for Linux 2.6.26-2-itanium
 linux-headers-2.6.26-2-ixp4xx - Header files for Linux 2.6.26-2-ixp4xx
 linux-headers-2.6.26-2-mac - Header files for Linux 2.6.26-2-mac
 linux-headers-2.6.26-2-mckinley - Header files for Linux 2.6.26-2-mckinley
 linux-headers-2.6.26-2-mvme147 - Header files for Linux 2.6.26-2-mvme147
 linux-headers-2.6.26-2-mvme16x - Header files for Linux 2.6.26-2-mvme16x
 linux-headers-2.6.26-2-openvz-686 - Header files for Linux 2.6.26-2-openvz-686
 linux-headers-2.6.26-2-openvz-amd64 - Header files for Linux 2.6.26-2-openvz-amd64
 linux-headers-2.6.26-2-orion5x - Header files for Linux 2.6.26-2-orion5x
 linux-headers-2.6.26-2-parisc - Header files for Linux 2.6.26-2-parisc
 linux-headers-2.6.26-2-parisc-smp - Header files for Linux 2.6.26-2-parisc-smp
 linux-headers-2.6.26-2-parisc64 - Header files for Linux 2.6.26-2-parisc64
 linux-headers-2.6.26-2-parisc64-smp - Header files for Linux 2.6.26-2-parisc64-smp
 linux-headers-2.6.26-2-powerpc - Header files for Linux 2.6.26-2-powerpc
 linux-headers-2.6.26-2-powerpc-smp - Header files for Linux 2.6.26-2-powerpc-smp
 linux-headers-2.6.26-2-powerpc64 - Header files for Linux 2.6.26-2-powerpc64
 linux-headers-2.6.26-2-r4k-ip22 - Header files for Linux 2.6.26-2-r4k-ip22
 linux-headers-2.6.26-2-r5k-cobalt - Header files for Linux 2.6.26-2-r5k-cobalt
 linux-headers-2.6.26-2-r5k-ip32 - Header files for Linux 2.6.26-2-r5k-ip32
 linux-headers-2.6.26-2-s390 - Header files for Linux 2.6.26-2-s390
 linux-headers-2.6.26-2-s390x - Header files for Linux 2.6.26-2-s390x
 linux-headers-2.6.26-2-sb1-bcm91250a - Header files for Linux 2.6.26-2-sb1-bcm91250a
 linux-headers-2.6.26-2-sb1a-bcm91480b - Header files for Linux 2.6.26-2-sb1a-bcm91480b
 linux-headers-2.6.26-2-sparc64 - Header files for Linux 2.6.26-2-sparc64
 linux-headers-2.6.26-2-sparc64-smp - Header files for Linux 2.6.26-2-sparc64-smp
 linux-headers-2.6.26-2-versatile - Header files for Linux 2.6.26-2-versatile
 linux-headers-2.6.26-2-vserver-686 - Header files for Linux 2.6.26-2-vserver-686
 linux-headers-2.6.26-2-vserver-686-bigmem - Header files for Linux 2.6.26-2-vserver-686-bigmem
 linux-headers-2.6.26-2-vserver-amd64 - Header files for Linux 2.6.26-2-vserver-amd64
 linux-headers-2.6.26-2-vserver-itanium - Header files for Linux 2.6.26-2-vserver-itanium
 linux-headers-2.6.26-2-vserver-mckinley - Header files for Linux 2.6.26-2-vserver-mckinley
 linux-headers-2.6.26-2-vserver-powerpc - Header files for Linux 2.6.26-2-vserver-powerpc
 linux-headers-2.6.26-2-vserver-powerpc64 - Header files for Linux 2.6.26-2-vserver-powerpc64
 linux-headers-2.6.26-2-vserver-s390x - Header files for Linux 2.6.26-2-vserver-s390x
 linux-headers-2.6.26-2-vserver-sparc64 - Header files for Linux 2.6.26-2-vserver-sparc64
 linux-headers-2.6.26-2-xen-686 - Header files for Linux 2.6.26-2-xen-686
 linux-headers-2.6.26-2-xen-amd64 - Header files for Linux 2.6.26-2-xen-amd64
 linux-image-2.6.26-2-486 - Linux 2.6.26 image on x86
 linux-image-2.6.26-2-4kc-malta - Linux 2.6.26 image on MIPS Malta
 linux-image-2.6.26-2-5kc-malta - Linux 2.6.26 image on MIPS Malta (64-bit)
 linux-image-2.6.26-2-686 - Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4
 linux-image-2.6.26-2-686-bigmem - Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4
 linux-image-2.6.26-2-alpha-generic - Linux 2.6.26 image on Alpha
 linux-image-2.6.26-2-alpha-legacy - Linux 2.6.26 image on Alpha Legacy
 linux-image-2.6.26-2-alpha-smp - Linux 2.6.26 image on Alpha SMP
 linux-image-2.6.26-2-amd64 - Linux 2.6.26 image on AMD64
 linux-image-2.6.26-2-amiga - Linux 2.6.26 image on Amiga
 linux-image-2.6.26-2-atari - Linux 2.6.26 image on Atari
 linux-image-2.6.26-2-bvme6000 - Linux 2.6.26 image on BVM BVME4000 and BVME6000
 linux-image-2.6.26-2-footbridge - Linux 2.6.26 image on Footbridge
 linux-image-2.6.26-2-iop32x - Linux 2.6.26 image on IOP32x
 linux-image-2.6.26-2-itanium - Linux 2.6.26 image on Itanium
 linux-image-2.6.26-2-ixp4xx - Linux 2.6.26 image on IXP4xx
 linux-image-2.6.26-2-mac - Linux 2.6.26 image on Macintosh
 linux-image-2.6.26-2-mckinley - Linux 2.6.26 image on Itanium II
 linux-image-2.6.26-2-mvme147 - Linux 2.6.26 image on Motorola MVME147
 linux-image-2.6.26-2-mvme16x - Linux 2.6.26 image on Motorola MVME162/6/7, MVME172/7
 linux-image-2.6.26-2-openvz-686 - Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4, OpenVZ support
 linux-image-2.6.26-2-openvz-amd64 - Linux 2.6.26 image on AMD64, OpenVZ support
 linux-image-2.6.26-2-orion5x - Linux 2.6.26 image on Orion
 linux-image-2.6.26-2-parisc - Linux 2.6.26 image on 32-bit PA-RISC
 linux-image-2.6.26-2-parisc-smp - Linux 2.6.26 image on multiprocessor 32-bit PA-RISC
 linux-image-2.6.26-2-parisc64 - Linux 2.6.26 image on 64-bit PA-RISC
 linux-image-2.6.26-2-parisc64-smp - Linux 2.6.26 image on multiprocessor 64-bit PA-RISC
 linux-image-2.6.26-2-powerpc - Linux 2.6.26 image on uniprocessor 32-bit PowerPC
 linux-image-2.6.26-2-powerpc-smp - Linux 2.6.26 image on multiprocessor 32-bit PowerPC
 linux-image-2.6.26-2-powerpc64 - Linux 2.6.26 image on 64-bit PowerPC
 linux-image-2.6.26-2-r4k-ip22 - Linux 2.6.26 image on SGI IP22
 linux-image-2.6.26-2-r5k-cobalt - Linux 2.6.26 image on Cobalt
 linux-image-2.6.26-2-r5k-ip32 - Linux 2.6.26 image on SGI IP32
 linux-image-2.6.26-2-s390 - Linux 2.6.26 image on IBM S/390
 linux-image-2.6.26-2-s390-tape - Linux 2.6.26 image on IBM S/390, IPL from tape
 linux-image-2.6.26-2-s390x - Linux 2.6.26 image on IBM zSeries
 linux-image-2.6.26-2-sb1-bcm91250a - Linux 2.6.26 image on BCM91250A
 linux-image-2.6.26-2-sb1a-bcm91480b - Linux 2.6.26 image on BCM91480B
 linux-image-2.6.26-2-sparc64 - Linux 2.6.26 image on uniprocessor 64-bit UltraSPARC
 linux-image-2.6.26-2-sparc64-smp - Linux 2.6.26 image on multiprocessor 64-bit UltraSPARC
 linux-image-2.6.26-2-versatile - Linux 2.6.26 image on Versatile
 linux-image-2.6.26-2-vserver-686 - Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4, Linux-VServer sup
 linux-image-2.6.26-2-vserver-686-bigmem - Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4, Linux-VServer sup
 linux-image-2.6.26-2-vserver-amd64 - Linux 2.6.26 image on AMD64, Linux-VServer support
 linux-image-2.6.26-2-vserver-itanium - Linux 2.6.26 image on Itanium, Linux-VServer support
 linux-image-2.6.26-2-vserver-mckinley - Linux 2.6.26 image on Itanium II, Linux-VServer support
 linux-image-2.6.26-2-vserver-powerpc - Linux 2.6.26 image on uniprocessor 32-bit PowerPC, Linux-VServer 
 linux-image-2.6.26-2-vserver-powerpc64 - Linux 2.6.26 image on 64-bit PowerPC, Linux-VServer support
 linux-image-2.6.26-2-vserver-s390x - Linux 2.6.26 image on IBM zSeries, Linux-VServer support
 linux-image-2.6.26-2-vserver-sparc64 - Linux 2.6.26 image on uniprocessor 64-bit UltraSPARC, Linux-VServ
 linux-image-2.6.26-2-xen-686 - Linux 2.6.26 image on i686, oldstyle Xen support
 linux-image-2.6.26-2-xen-amd64 - Linux 2.6.26 image on AMD64, oldstyle Xen support
 linux-libc-dev - Linux support headers for userspace development
 linux-manual-2.6.26 - Linux kernel API manual pages for version 2.6.26
 linux-modules-2.6.26-2-xen-686 - Linux 2.6.26 modules on i686
 linux-modules-2.6.26-2-xen-amd64 - Linux 2.6.26 modules on AMD64
 linux-patch-debian-2.6.26 - Debian patches to version 2.6.26 of the Linux kernel
 linux-source-2.6.26 - Linux kernel source for version 2.6.26 with Debian patches
 linux-support-2.6.26-2 - Support files for Linux 2.6.26
 linux-tree-2.6.26 - Linux kernel source tree for building Debian kernel images
 xen-linux-system-2.6.26-2-xen-686 - XEN system with Linux 2.6.26 image on i686
 xen-linux-system-2.6.26-2-xen-amd64 - XEN system with Linux 2.6.26 image on AMD64
Closes: 505609 511892 583139
Changes: 
 linux-2.6 (2.6.26-24) stable; urgency=high
 .
   [ Ben Hutchings ]
   * usbhid: Reduce the race condition between disconnect and ioctl
     (Closes: #511892)
   * r8169: Fix MDIO timing (Closes: #583139)
   * [x86] Restore automatic update of LILO on kernel installation, upgrade
     or removal (Closes: #505609)
Checksums-Sha1: 
 935f8ca296709e082b3bb24bf4c6577ef365dd79 5754 linux-2.6_2.6.26-24.dsc
 1368dd88d99ba5b11ac183bba8489bd929965e9c 7914539 linux-2.6_2.6.26-24.diff.gz
 79b480802b7ff536b934b4ec642460336d106ccb 4628908 linux-doc-2.6.26_2.6.26-24_all.deb
 0bf8be407f29a6276e2261ab55a9d287e968989e 1768836 linux-manual-2.6.26_2.6.26-24_all.deb
 d9f5e4566e4b44a4ac84bed02352b624a809a87a 2904336 linux-patch-debian-2.6.26_2.6.26-24_all.deb
 b424e2965c49ca04dd31ddb220fe6d43872674fa 48766778 linux-source-2.6.26_2.6.26-24_all.deb
 74b713fcedbd85cfa2426b94881f5fdd1d707790 126848 linux-support-2.6.26-2_2.6.26-24_all.deb
 629c985edb7060dc58e8c521f609138204033d14 111574 linux-tree-2.6.26_2.6.26-24_all.deb
 b97d4a16193b96edb0553ff1c4f11b20fc40fa42 20931720 linux-image-2.6.26-2-amd64_2.6.26-24_amd64.deb
 e96911fe217353b6e93023fea0920f21df864b7f 392950 linux-headers-2.6.26-2-amd64_2.6.26-24_amd64.deb
 1dfa0e011888d00f036c45b0addb036284f434aa 3725264 linux-headers-2.6.26-2-common_2.6.26-24_amd64.deb
 1f56f3e9975234face54e7b7a9f04b9ee3216c52 21103054 linux-image-2.6.26-2-openvz-amd64_2.6.26-24_amd64.deb
 21c7d6f3b209135ad2c86aafe978fd8bcfea5260 397630 linux-headers-2.6.26-2-openvz-amd64_2.6.26-24_amd64.deb
 491bcc3c49dc52b10e05c3b3713e4538046630e3 3780976 linux-headers-2.6.26-2-common-openvz_2.6.26-24_amd64.deb
 3a706fe6f2d529bf2f82e3db1bd9660af766b527 111002 linux-headers-2.6.26-2-all_2.6.26-24_amd64.deb
 46f28ccaf7a5d3a3322ed0a77fe2bcaf561c9a32 111032 linux-headers-2.6.26-2-all-amd64_2.6.26-24_amd64.deb
 c8bf947c24506338bbe37eed54ebefd14ca0d658 753792 linux-libc-dev_2.6.26-24_amd64.deb
 e602dd7980ee426e24ca2b394dbfeb608deca380 20950646 linux-image-2.6.26-2-vserver-amd64_2.6.26-24_amd64.deb
 ac73e44d7423fbb4bb27f6a5ea1b41fd8bfb98dc 392588 linux-headers-2.6.26-2-vserver-amd64_2.6.26-24_amd64.deb
 0b238a2ee49f6d0bdfe6736d1dc2a2c9c219cc91 3757862 linux-headers-2.6.26-2-common-vserver_2.6.26-24_amd64.deb
 ce3f2fe4511e5336baf6aad07227ee82e68b39b5 1809844 linux-image-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
 a090339bdc2f507a48273aa812a11c12e33f4614 19315684 linux-modules-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
 6d725d93a5119d0207742a4b47b429a94dc99372 388028 linux-headers-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
 145ac95ce96c9a759b36913c9dad351610129dc2 110986 xen-linux-system-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
 f25923b49893a47a7989b32ee8a3eee8256176a8 3857376 linux-headers-2.6.26-2-common-xen_2.6.26-24_amd64.deb
Checksums-Sha256: 
 eb7bb137756f83e28b92aa8037d22ab6391d4c8261c97e8de27e4c7c4057e6da 5754 linux-2.6_2.6.26-24.dsc
 ecc9162361c4b3771a81c41cceb31a9d4567a08d77f54f4537acd9e4dc7821de 7914539 linux-2.6_2.6.26-24.diff.gz
 d73e454da611f7c21b900d26712fc73c36a477de71c89b6634f5d06f573baac3 4628908 linux-doc-2.6.26_2.6.26-24_all.deb
 0f703d72694f45d8097088b98936ff77f0b806abd6bfde6fc2915b465cf7f668 1768836 linux-manual-2.6.26_2.6.26-24_all.deb
 553a4d24591ba6f298babd7f0c851114f54529a77566dcbc7c9ad89b38e5f339 2904336 linux-patch-debian-2.6.26_2.6.26-24_all.deb
 c9565af3bfa06bb17cac07184f2428c0cf397e414560a32a4ccb7f7a00b2ddd9 48766778 linux-source-2.6.26_2.6.26-24_all.deb
 fc0c9baa144ef88a10f6abc57c20fca547898f8c433000412f6e25450ede351f 126848 linux-support-2.6.26-2_2.6.26-24_all.deb
 bf22610a43d7ff2b20cf587fd89291a2977d9cdd6a14632969df2b25451f0551 111574 linux-tree-2.6.26_2.6.26-24_all.deb
 d719715c155d413ba8a614f14f9606c253d4c1205c0dc974686632f242016045 20931720 linux-image-2.6.26-2-amd64_2.6.26-24_amd64.deb
 7213fdb9fc8a80f31f2c013587274a94ec9602d924ac040b511d9fe0099dc3db 392950 linux-headers-2.6.26-2-amd64_2.6.26-24_amd64.deb
 2748ceafff6a90ff21c93d7572964061577ab0aa2e32bef6656b21762b329a92 3725264 linux-headers-2.6.26-2-common_2.6.26-24_amd64.deb
 a574e6bb5f5e65d8a83abc5e9205863de5fe2ca3df6cc9d2b6a3d32de5fcf91b 21103054 linux-image-2.6.26-2-openvz-amd64_2.6.26-24_amd64.deb
 c7a78fe58c9f137059eac33e93328ac55a8da46b19eb1c0e26672d3eede7cac6 397630 linux-headers-2.6.26-2-openvz-amd64_2.6.26-24_amd64.deb
 0c3d66a600827e4c8ae55cbede1dd2f617033c93eb791de19a7fc0acb2743fcc 3780976 linux-headers-2.6.26-2-common-openvz_2.6.26-24_amd64.deb
 4062fac127b06b3b9a4a46ee7ded1986a6c26173edc7789b8d707485876db23e 111002 linux-headers-2.6.26-2-all_2.6.26-24_amd64.deb
 dff9a4a9dc3decaa693c658543d32db027d4f68131df560b71b833c9c912fd51 111032 linux-headers-2.6.26-2-all-amd64_2.6.26-24_amd64.deb
 20307398562582ad4fc17679ddf50a5978d936cca8adc9e0a30084c7716e8ced 753792 linux-libc-dev_2.6.26-24_amd64.deb
 d3a70516e312ad9056939f9674f4f431254da4d8ed9afee8871b1bc3626bf30f 20950646 linux-image-2.6.26-2-vserver-amd64_2.6.26-24_amd64.deb
 46ab3b19f260a4263ec3c5d37e1e6b4ac65298a630e335878f9c3c8e5bd29c1f 392588 linux-headers-2.6.26-2-vserver-amd64_2.6.26-24_amd64.deb
 3ce10cc81fb64336ae7d4e6541a1766730dda0db9136b1e12cc5161e391ec831 3757862 linux-headers-2.6.26-2-common-vserver_2.6.26-24_amd64.deb
 3a89aff007806815bfd1b6f11a34eca2a0ae2e5c473289ad0950e9d05ae13812 1809844 linux-image-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
 5c0a41c2dbb784572f15e50e07822ec9750364b33f8b03456a238b51b0a02db0 19315684 linux-modules-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
 9446df1ec84cb07650ddba819e726d997a0d5026f4427ab84c83ded7763f463f 388028 linux-headers-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
 b12a8d4d2e18ce35484805359521e23122b45d4a6ca603e27a526dd8326a63be 110986 xen-linux-system-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
 537be82d0f8f4b1bbadcf0a8579102971d9d35be94cc2571f7597b23d760b9a7 3857376 linux-headers-2.6.26-2-common-xen_2.6.26-24_amd64.deb
Files: 
 57d2eb3c359b365347379ff283968a56 5754 devel optional linux-2.6_2.6.26-24.dsc
 d03d53ed801556b9a0a4fc0b12976332 7914539 devel optional linux-2.6_2.6.26-24.diff.gz
 67d98ab19a6e1fdec4278d53bb4819c7 4628908 doc optional linux-doc-2.6.26_2.6.26-24_all.deb
 8c2b74da480bd126f1d48545d9d49360 1768836 doc optional linux-manual-2.6.26_2.6.26-24_all.deb
 a75dae4ca6a8c32c65f1aae8c03e87f7 2904336 devel optional linux-patch-debian-2.6.26_2.6.26-24_all.deb
 f563a2caa8591838994886984bd6a3ce 48766778 devel optional linux-source-2.6.26_2.6.26-24_all.deb
 8e43ae0bcd82d02e2b21dc7f66d33515 126848 devel optional linux-support-2.6.26-2_2.6.26-24_all.deb
 2b4cacbc65e78121ce6c239355ee4f52 111574 devel optional linux-tree-2.6.26_2.6.26-24_all.deb
 5052848d592d338185cdbc83b09af147 20931720 admin optional linux-image-2.6.26-2-amd64_2.6.26-24_amd64.deb
 f907d3530d524538aacef78c70343e2e 392950 devel optional linux-headers-2.6.26-2-amd64_2.6.26-24_amd64.deb
 64e0e95ad06f36963159f6cd1604c15c 3725264 devel optional linux-headers-2.6.26-2-common_2.6.26-24_amd64.deb
 b98aa4d6ccc339739b151b391c38ca29 21103054 admin optional linux-image-2.6.26-2-openvz-amd64_2.6.26-24_amd64.deb
 cbe76a3d5587cd26f15e3693e4b636c2 397630 devel optional linux-headers-2.6.26-2-openvz-amd64_2.6.26-24_amd64.deb
 17fd31e3bd066aeeb7815bdf65717acf 3780976 devel optional linux-headers-2.6.26-2-common-openvz_2.6.26-24_amd64.deb
 ff0c473dbff1424a9806039c738e1960 111002 devel optional linux-headers-2.6.26-2-all_2.6.26-24_amd64.deb
 569cf527ec38d0b562153593f7cc75bb 111032 devel optional linux-headers-2.6.26-2-all-amd64_2.6.26-24_amd64.deb
 085fa2494b95d04df67fb7db6ec9f677 753792 devel optional linux-libc-dev_2.6.26-24_amd64.deb
 09ad8a84d7b33e94421b5b05c9e9ea8f 20950646 admin optional linux-image-2.6.26-2-vserver-amd64_2.6.26-24_amd64.deb
 1d0912477ea73859da54c6ad0afa78fe 392588 devel optional linux-headers-2.6.26-2-vserver-amd64_2.6.26-24_amd64.deb
 04434caffac411ca5361d5f5173bd4e0 3757862 devel optional linux-headers-2.6.26-2-common-vserver_2.6.26-24_amd64.deb
 af18aa515401f3ec3d1aa6ffdea3f504 1809844 admin optional linux-image-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
 1a347636e73521d5c1acda67b403508b 19315684 admin optional linux-modules-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
 7a8e2392db57b7e79ca321b98e027c0f 388028 devel optional linux-headers-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
 ca0fd441cee7209297f521d8f2e4e54c 110986 admin extra xen-linux-system-2.6.26-2-xen-amd64_2.6.26-24_amd64.deb
 acf0224b9f1fece0b30e3b733ce11276 3857376 devel optional linux-headers-2.6.26-2-common-xen_2.6.26-24_amd64.deb

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

iD8DBQFMHo/chuANDBmkLRkRAtkeAJ96sh3quRBa6gJ5sPWzxhukAuHlsQCdFBBu
0Thhyc157SPOIyIHJyJA6Nk=
=UNir
-----END PGP SIGNATURE-----





Reply sent to dann frazier <dannf@debian.org>:
You have taken responsibility. (Mon, 21 Jun 2010 01:57:10 GMT) Full text and rfc822 format available.

Notification sent to Matus UHLAR - fantomas <uhlar@fantomas.sk>:
Bug acknowledged by developer. (Mon, 21 Jun 2010 01:57:10 GMT) Full text and rfc822 format available.

Added tag(s) lenny. Request was from Ben Hutchings <ben@decadent.org.uk> to control@bugs.debian.org. (Thu, 29 Jul 2010 04:00:03 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions 2.6.26-10. Request was from Luk Claes <luk@debian.org> to control@bugs.debian.org. (Sun, 10 Oct 2010 08:06:06 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 08 Nov 2010 07:30:47 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 16 23:34:09 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.