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.
Sounds ok, but I don't have time to look into this at the moment. A patch would be welcome.
Robert Millan 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. (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.
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 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.
Felix Zielcke wrote: 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.
Am Donnerstag, den 31.07.2008, 16:46 -0400 schrieb Joey Hess: 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.
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. 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.
Am Donnerstag, den 31.07.2008, 16:46 -0400 schrieb Joey Hess: 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.
Felix Zielcke wrote: #473461 You can't count on triggers doing this, ever.
Am Freitag, den 01.08.2008, 12:44 -0400 schrieb Joey Hess: 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.
tag 481542 wontfix thanks Am Freitag, den 01.08.2008, 19:03 +0200 schrieb Felix Zielcke: 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.
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
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