Debian Bug report logs - #481542
please use triggers for update-grub

Reply or subscribe to this bug.

Toggle useless messages

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

From: Jon Dowland <jon+bts@alcopop.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: grub2: please user triggers for menu.lst update

Date: Fri, 16 May 2008 21:29:53 +0100

Package: grub2
Severity: wishlist

please consider using dpkg triggers to update the menu.lst
file, rather than do it for each kernel image install or
remove.

a disclaimer. I'm not using grub2 on this
machine at present. I was going to file the following
against grub 1 when I saw the disclaimer. I checked the
changelog and bts for mention of triggers, and checked the
source for a triggers file (which I couldn't find). From
when I did use grub2 (I had to back out at the time) I
believe this is relevant to grub2. There is a chance I am
wrong in which case I apologise.

However, if I'm not, hopefully this will then avoid
situations like the following:


21:15:23# aptitude
(Reading database ... 353294 files and directories currently installed.)
Removing kqemu-modules-2.6.22-3-686 ...
Removing linux-image-2.6.18-4-686 ...
Running postrm hook script /sbin/update-grub.
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz
Found kernel: /boot/vmlinuz.old
Found kernel: /boot/vmlinuz-2.6.24-1-686
Found kernel: /boot/vmlinuz-2.6.23-rc1
Found kernel: /boot/vmlinuz-2.6.22.old
Found kernel: /boot/vmlinuz-2.6.22-3-686
Found kernel: /boot/vmlinuz-2.6.22-2-686
Found kernel: /boot/vmlinuz-2.6.22-1-686
Found kernel: /boot/vmlinuz-2.6.22
Found kernel: /boot/vmlinuz-2.6.21-2-686
Found kernel: /boot/vmlinuz-2.6.21-1-686
Updating /boot/grub/menu.lst ... done

Removing linux-image-2.6.21-1-686 ...
Running postrm hook script /sbin/update-grub.
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz
Found kernel: /boot/vmlinuz.old
Found kernel: /boot/vmlinuz-2.6.24-1-686
Found kernel: /boot/vmlinuz-2.6.23-rc1
Found kernel: /boot/vmlinuz-2.6.22.old
Found kernel: /boot/vmlinuz-2.6.22-3-686
Found kernel: /boot/vmlinuz-2.6.22-2-686
Found kernel: /boot/vmlinuz-2.6.22-1-686
Found kernel: /boot/vmlinuz-2.6.22
Found kernel: /boot/vmlinuz-2.6.21-2-686
Updating /boot/grub/menu.lst ... done

Removing linux-image-2.6.21-2-686 ...
Running postrm hook script /sbin/update-grub.
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz
Found kernel: /boot/vmlinuz.old
Found kernel: /boot/vmlinuz-2.6.24-1-686
Found kernel: /boot/vmlinuz-2.6.23-rc1
Found kernel: /boot/vmlinuz-2.6.22.old
Found kernel: /boot/vmlinuz-2.6.22-3-686
Found kernel: /boot/vmlinuz-2.6.22-2-686
Found kernel: /boot/vmlinuz-2.6.22-1-686
Found kernel: /boot/vmlinuz-2.6.22
Updating /boot/grub/menu.lst ... done

Removing linux-image-2.6.22-1-686 ...
Running postrm hook script /sbin/update-grub.
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz
Found kernel: /boot/vmlinuz.old
Found kernel: /boot/vmlinuz-2.6.24-1-686
Found kernel: /boot/vmlinuz-2.6.23-rc1
Found kernel: /boot/vmlinuz-2.6.22.old
Found kernel: /boot/vmlinuz-2.6.22-3-686
Found kernel: /boot/vmlinuz-2.6.22-2-686
Found kernel: /boot/vmlinuz-2.6.22
Updating /boot/grub/menu.lst ... done

Removing linux-image-2.6.22-2-686 ...
Running postrm hook script /sbin/update-grub.
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz
Found kernel: /boot/vmlinuz.old
Found kernel: /boot/vmlinuz-2.6.24-1-686
Found kernel: /boot/vmlinuz-2.6.23-rc1
Found kernel: /boot/vmlinuz-2.6.22.old
Found kernel: /boot/vmlinuz-2.6.22-3-686
Found kernel: /boot/vmlinuz-2.6.22
Updating /boot/grub/menu.lst ... done

Removing linux-image-2.6.22-3-686 ...
Running postrm hook script /sbin/update-grub.
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz
Found kernel: /boot/vmlinuz.old
Found kernel: /boot/vmlinuz-2.6.24-1-686
Found kernel: /boot/vmlinuz-2.6.23-rc1
Found kernel: /boot/vmlinuz-2.6.22.old
Found kernel: /boot/vmlinuz-2.6.22
Updating /boot/grub/menu.lst ... done

The link /vmlinuz.old is a damaged link
Removing symbolic link vmlinuz.old 
 you may need to re-run your boot loader
The link /initrd.img.old is a damaged link
Removing symbolic link initrd.img.old 
 you may need to re-run your boot loader
Removing rt2570-modules-2.6.18-2-686 ...
Removing rt2570-modules-2.6.18-3-686 ...
Removing rt2570-modules-2.6.22-3-686 ...
Press return to continue.


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

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Message #8 received at 481542@bugs.debian.org (full text, mbox, reply):

From: Robert Millan <rmh@aybabtu.com>

To: Jon Dowland <jon+bts@alcopop.org>, 481542@bugs.debian.org

Subject: Re: Bug#481542: grub2: please user triggers for menu.lst update

Date: Fri, 16 May 2008 23:39:00 +0200

On Fri, May 16, 2008 at 09:29:53PM +0100, Jon Dowland wrote:
> Package: grub2
> Severity: wishlist
> 
> please consider using dpkg triggers to update the menu.lst
> file, rather than do it for each kernel image install or
> remove.

Sounds ok, but I don't have time to look into this at the moment.  A patch
would be welcome.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)

Message #13 received at 481542@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Robert Millan <rmh@aybabtu.com>, 481542@bugs.debian.org

Cc: Jon Dowland <jon+bts@alcopop.org>

Subject: Re: Bug#481542: grub2: please user triggers for menu.lst update

Date: Fri, 16 May 2008 18:11:24 -0400

[Message part 1 (text/plain, inline)]

Robert Millan wrote:
> Sounds ok, but I don't have time to look into this at the moment.  A patch
> would be welcome.

IMHO it's important to consider how triggers would handle a situation
such as an apt run that removed the running kernel added a new kernel,
and then failed. In this case, the grub trigger might not run, which
would leave a menu.lst that contained only a nonexistent kernel.

(This is also potentially a problem with the initramfs-tools triggers, I
guess..)

Note that ubuntu has triggerised grub; I don't know how/if they deal
with that case.

-- 
see shy jo

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

Message #18 received at 481542@bugs.debian.org (full text, mbox, reply):

From: Felix Zielcke <fzielcke@z-51.de>

To: 481542@bugs.debian.org

Cc: Joey Hess <joeyh@debian.org>, Jon Dowland <jon+bts@alcopop.org>

Subject: grub2: please user triggers

Date: Thu, 31 Jul 2008 20:55:16 +0200

retitle 481542 please use triggers for update-grub
thanks

I looked now at the man-db package which is a very easy implementation
for triggers.
I think it would be enough for us to do it like they did.

debian/triggers:
interest /boot

debian/*.postinst:
if [ "$1" = triggered ]; then
  update-grub
fi

>IMHO it's important to consider how triggers would handle a situation
>such as an apt run that removed the running kernel added a new kernel,
>and then failed. In this case, the grub trigger might not run, which
>would leave a menu.lst that contained only a nonexistent kernel.

Well if removing the current installed kernel suceeded, but installing the new one failed,
then I think you don't have any kernel at all in /boot
Removing the current kernel should tell dpkg to run our trigger.
I don't think that if installing a new kernel fails, that the trigger doestn't get called,
as long as the whole install/update apt/dpkg process keeps running
But I try to reproduce this.

Luckly we currently have currently anyway a package in experimental.

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

From: Joey Hess <joeyh@debian.org>

To: Felix Zielcke <fzielcke@z-51.de>

Cc: 481542@bugs.debian.org, Jon Dowland <jon+bts@alcopop.org>

Subject: Re: grub2: please user triggers

Date: Thu, 31 Jul 2008 16:46:34 -0400

[Message part 1 (text/plain, inline)]

Felix Zielcke wrote:
> >IMHO it's important to consider how triggers would handle a situation
> >such as an apt run that removed the running kernel added a new kernel,
> >and then failed. In this case, the grub trigger might not run, which
> >would leave a menu.lst that contained only a nonexistent kernel.
> 
> Well if removing the current installed kernel suceeded, but installing the new one failed,
> then I think you don't have any kernel at all in /boot

I didn't say that adding the new kernel failed. A later package could
fail.

Or the power could fail before dpkg got around to calling the triggers.

Once apt trigger deferral is implemented, all the triggers will run at
the very end of the apt run, which can be quite a long time after the
kernel packages are removed and installed.

-- 
see shy jo

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

Message #30 received at 481542@bugs.debian.org (full text, mbox, reply):

From: Felix Zielcke <fzielcke@z-51.de>

To: Joey Hess <joeyh@debian.org>

Cc: 481542@bugs.debian.org, Jon Dowland <jon+bts@alcopop.org>

Subject: Re: grub2: please user triggers

Date: Thu, 31 Jul 2008 22:56:54 +0200

Am Donnerstag, den 31.07.2008, 16:46 -0400 schrieb Joey Hess:


> I didn't say that adding the new kernel failed. A later package could
> fail.
> 
> Or the power could fail before dpkg got around to calling the triggers.
> 
> Once apt trigger deferral is implemented, all the triggers will run at
> the very end of the apt run, which can be quite a long time after the
> kernel packages are removed and installed.

Urm yeah sorry that i misunderstood you.
That's really a good question how to deal with that.
But I doubt we could anything do on that case.

Either we use triggers and risk that it's not run by a powerloss,
or some apt/dpkg error elsewhere.
Or we just stay with the old method which is btw. not grub's fault,
but the kernel-team's which declare a postinst and postrm hook in
/etc/kernel-img.conf which get run on a kernel install or remove.

Message #35 received at 481542@bugs.debian.org (full text, mbox, reply):

From: Felix Zielcke <fzielcke@z-51.de>

To: Joey Hess <joeyh@debian.org>

Cc: 481542@bugs.debian.org, Jon Dowland <jon+bts@alcopop.org>, Robert Millan <rmh@aybabtu.com>

Subject: Re: grub2: please user triggers

Date: Fri, 01 Aug 2008 01:25:03 +0200

>(This is also potentially a problem with the initramfs-tools triggers, I
>guess..)

I have now installed etch in a VM and then used aptitude to update it to lenny
As soon as the kernel is configured, there's a mkinitramfs-kpkg call
and after everything is finished the update-initramfs trigger is run.


>Note that ubuntu has triggerised grub; I don't know how/if they deal0
>with that case.

I just started to learn about these triggers.

I looked at the ubuntu packages.

grub2 doestn't have a trigger.
But grub-legacy has a "interest update-grub" trigger.

If that means that when another package runs update-grub then not the
real one is called,
but just dpkg informed to run this trigger, then this would be probable
better then my "interest /boot" trigger.
Their linux_2.6.26-5.13 package doestn't have any trigger update-grub
stuff, only the postinst_hook and postrm_hook,
that our kernel packages probable has too.

Their grub-legacy has a kernel-helper and last-good-boot script which
hardlinks the last working kernel to /boot/last-good-boot/
so on ubuntu you probable always have a working boot entry on at least
grub-legacy.

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

From: Felix Zielcke <fzielcke@z-51.de>

To: Joey Hess <joeyh@debian.org>

Cc: 481542@bugs.debian.org, Jon Dowland <jon+bts@alcopop.org>, Robert Millan <rmh@aybabtu.com>

Subject: Re: grub2: please user triggers

Date: Fri, 01 Aug 2008 16:41:53 +0200

Am Donnerstag, den 31.07.2008, 16:46 -0400 schrieb Joey Hess:

> Once apt trigger deferral is implemented, all the triggers will run at
> the very end of the apt run, which can be quite a long time after the
> kernel packages are removed and installed.

What exactly is this apt trigger derral which will be implemented?

Luckly I had to do now a apt-get build-dep grub2 and I noticed the
man-db trigger is called after every package is extracted and not after
the whole apt/dpkg process after everything setting up.
And man-db uses just directory triggers which I first thought of.

A trigger which runs after every package has been extracted and not yet
configured should work fine for us, too.
Will apt change something with that or might there be a problem which I
currently can't think of with that method?

If it works then I/we only need to find a way that update-grub is run on
a grub2 update too but only once if there's kernel update too.

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

From: Joey Hess <joeyh@debian.org>

To: Felix Zielcke <fzielcke@z-51.de>

Cc: 481542@bugs.debian.org, Jon Dowland <jon+bts@alcopop.org>, Robert Millan <rmh@aybabtu.com>

Subject: Re: grub2: please user triggers

Date: Fri, 1 Aug 2008 12:44:03 -0400

[Message part 1 (text/plain, inline)]

Felix Zielcke wrote:
> What exactly is this apt trigger derral which will be implemented?

#473461

> A trigger which runs after every package has been extracted and not yet
> configured should work fine for us, too.

You can't count on triggers doing this, ever.

-- 
see shy jo

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

Message #50 received at 481542@bugs.debian.org (full text, mbox, reply):

From: Felix Zielcke <fzielcke@z-51.de>

To: Joey Hess <joeyh@debian.org>

Cc: 481542@bugs.debian.org, Jon Dowland <jon+bts@alcopop.org>, Robert Millan <rmh@aybabtu.com>

Subject: Re: grub2: please user triggers

Date: Fri, 01 Aug 2008 19:03:50 +0200

Am Freitag, den 01.08.2008, 12:44 -0400 schrieb Joey Hess:
> Felix Zielcke wrote:
> > What exactly is this apt trigger derral which will be implemented?
> 
> #473461
> 
> > A trigger which runs after every package has been extracted and not yet
> > configured should work fine for us, too.
> 
> You can't count on triggers doing this, ever.

Well, then I think this should be tagged wontfix and we just stay with
the current method, that the kernel .deb itself calls update-grub when
it's configured.

If anyone has an idea how to change the current used method so
update-grub gets only called once instead of multiple times, but it does
gets called even when dpkg/apt fails to configure every package and so
fails probable to run the trigger then please tell us.

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

From: Felix Zielcke <fzielcke@z-51.de>

To: 481542@bugs.debian.org

Cc: Joey Hess <joeyh@debian.org>, Jon Dowland <jon+bts@alcopop.org>, Robert Millan <rmh@aybabtu.com>

Subject: Re: grub2: please user triggers

Date: Fri, 01 Aug 2008 20:43:06 +0200

tag 481542 wontfix
thanks

Am Freitag, den 01.08.2008, 19:03 +0200 schrieb Felix Zielcke:

> Well, then I think this should be tagged wontfix and we just stay with
> the current method, that the kernel .deb itself calls update-grub when
> it's configured.

Ok I talked now with Robert and we both are not changing anything now on
the grub-legacy and grub2 packages.

I forgot that after the extracting stage there's no initrd for the
kernel so we would need to modify update-grub to assume one if the
kernel version number seems to be a Debian one.

So if anyone wants that there's only one call to update-grub in the
whole update process, then please provide a patch against the trunk SVN
which avoids the problem that the update-grub trigger might be not run.
And please don't forget that /etc/kernel-img.conf which belongs to the
kernel-team and not to us needs a change too.

Message #62 received at 481542@bugs.debian.org (full text, mbox, reply):

From: "Michal Suchanek <hramrach@centrum.cz>" <michal.suchanek@ruk.cuni.cz>

To: Debian Bug Tracking System <481542@bugs.debian.org>

Subject: /usr/sbin/update-grub: kernel triggers

Date: Fri, 26 Jun 2009 14:08:59 +0200

Package: grub-efi
Version: 1.96+20080724-16
Followup-For: Bug #481542


I don't think considering the situation when you remove your running
kernel and install a new kernel in a single apt run should affect how
kernel packages are handled.

Kernel packages are not auto-removed by apt and if you remove your
running kernel manually you are just asking for trouble.

You may miss some important modules for your kernel later, generating
initrd for the new kernel might fail leaving you without one, and the
new kernel may just be plain broken.

Last but not least grub has a commandline so in most cases you should be
able to boot even with a broken grub.cfg. In cases when you cannot
access the console you should think twice about stuff you are doing and
not remove the old kernel in the first place for the reasons stated
above.

That said, re-generating grub.cfg is not that much of a problem, it only
causes noise during apt runs. The problem is constant re-generating of
initrds which takes qoute a bit of time. This is particualrly annoying
when kernels are removed because generating initrds is completely
pointless in such case.

Thanks

Michal

Message #65 received at 481542@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: Debian Bug Tracking System <481542@bugs.debian.org>

Subject: Re: please use triggers for update-grub

Date: Mon, 25 Aug 2014 07:07:35 -0700

Package: grub2-common
Version: 2.02~beta2-11
Followup-For: Bug #481542

In addition to re-running update-grub after installing or removing
kernels, update-grub should also trigger on /etc/default/grub.d/
and /etc/grub.d/ .  That would allow packages to install new grub
configuration snippets, and have update-grub automatically regenerate
the corresponding new configuration.

- Josh Triplett

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

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages grub2-common depends on:
ii  dpkg                1.17.13
ii  grub-common         2.02~beta2-11
ii  install-info        5.2.0.dfsg.1-4
ii  libc6               2.19-9
ii  libdevmapper1.02.1  2:1.02.88-1
ii  liblzma5            5.1.1alpha+20120614-2

grub2-common recommends no packages.

grub2-common suggests no packages.

-- no debconf information

Message #70 received at 481542-submitter@bugs.debian.org (full text, mbox, reply):

From: Julian Andres Klode <noreply@salsa.debian.org>

To: 481542-submitter@bugs.debian.org

Subject: Bug#481542 marked as pending in grub2

Date: Tue, 14 Nov 2023 19:03:14 +0000

Control: tag -1 pending

Hello,

Bug #481542 in grub2 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/grub-team/grub/-/commit/fbff3efb95eff8e4e25bc04af74817db4b94cde0

------------------------------------------------------------------------
update-grub: Use triggers

Closes: #481542
LP: #1250109
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/481542

Message #75 received at 481542-submitter@bugs.debian.org (full text, mbox, reply):

From: Julian Andres Klode <noreply@salsa.debian.org>

To: 481542-submitter@bugs.debian.org

Subject: Bug#481542 marked as pending in grub2

Date: Tue, 14 Nov 2023 19:22:06 +0000

Control: tag -1 pending

Hello,

Bug #481542 in grub2 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/grub-team/grub/-/commit/bdac298f949518e3020a530f6e1be292360702a9

------------------------------------------------------------------------
update-grub: Use triggers

Closes: #481542
LP: #1250109
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/481542

Send a report that this bug log contains spam.