linux-image-extra-*-generic postrm script runs install actions

Forgot to mention: I noticed it in 14.04.3 trusty kernel version 3.13.0-63.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1501884

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Brad, what's to diagnose? I've done all the diagnosis for you already. Anyway, here's the relevant snippet from the dpkg log with the problematic line highlighted:

(Reading database ... 149768 files and directories currently installed.)
Removing linux-headers-3.13.0-63-generic (3.13.0-63.103) ...
Removing linux-headers-3.13.0-63 (3.13.0-63.103) ...
Removing linux-image-extra-3.13.0-63-generic (3.13.0-63.103) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.13.0-63-generic /boot/vmlinuz-3.13.0-63-generic
                                                                 ^^^^^
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.13.0-63-generic /boot/vmlinuz-3.13.0-63-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-63-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 3.13.0-63-generic /boot/vmlinuz-3.13.0-63-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.13.0-63-generic /boot/vmlinuz-3.13.0-63-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.13.0-65-generic
Found initrd image: /boot/initrd.img-3.13.0-65-generic
Found linux image: /boot/vmlinuz-3.13.0-63-generic
Found initrd image: /boot/initrd.img-3.13.0-63-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
done

Here is the content of /var/lib/dpkg/info/linux-image-extra-3.13.0-65-generic.postrm, again with highlight:
#!/bin/sh
set -e

case "$0::$1" in
*.postinst::configure|*.postrm::remove)
 depmod -a -F /boot/System.map-3.13.0-65-generic 3.13.0-65-generic || true
 for dir in "/etc/kernel/postinst.d" "/etc/kernel/postinst.d/3.13.0-65-generic"
                                                   ^^^^^^^ ^^^^^^
 do
  if [ -d "$dir" ]; then
   run-parts --verbose --exit-on-error --arg="3.13.0-65-generic" --arg="/boot/vmlinuz-3.13.0-65-generic" "$dir"
  fi
 done
 ;;
esac

All those postinst.d should be postrm.d

Sorry Brad. I didn't notice the 'Automatic Script' bit.

Changed the package name to linux-lts-trusty as that what I've seen used in other bug reports against the kernel for trusty even though the source package for e.g. linux-image-extra-3.13.0-65-generic is listed in apt-cache as linux. Feel free to change back if this is inappropriate.

I have attached an (untested) patch to fix this issue hoping that that will prod it along a bit. The patch is against the sources of `linux_3.13.0-67.110` as downloaded by an `apt-get source linux=3.13.0-67.110` on 14.04.3.

Cheers,
Seb

Is there anything else I can do to get this fixed?

We have now gone through a couple of kernel versions all of which have this bug. One of them had a problem which meant I couldn't use it and this bug meant I couldn't just reboot into the previous kernel (because it had been auto-removed).

I have already attached a patch, could one of the kernel maintainers have a look at it and either include it in the package or let me know why it can't be?

Cheers,
Seb

Still an issue in xenial! I've added package 'linux' since that's the source package that has the problem and I'm not sure how else to show that this is a problem in trusty AND xenial (and probably everything in-between).

This is still an issue in xenial. Triggered when running "sudo apt-get autoremove" to remove old linux-images. What is the correct package to report this bug against please?

As for the apt-auto-removal problem, it is fixed, right? Bug #1440608
Yet to be fixed at least:
Bug #1458204
Bug #1678187

linux-image-<VERSION>-generic is present when removing linux-image-extra-<VERSION>-generic. initramfs-tools needs to re-create initrd.img, at least if linux-image-<VERSION>-generic will not be removed. If that is the only reason, I think it would be better to do the re-creation in a postrm script than run all postinst scripts. /etc/kernel/postrm.d/initramfs-tools could detect it is removing a linux-image-extra package and then do the right thing.

Why doesn't linux-image-extra's postrm simply run update-initramfs. That seems the more sensible thing to do as it is the same as with any other package that wants to put things into the initrd.

The kernel linux-image-extras-* package intentionally calls postinst scripts even when it is rmeoved. This is required because after its removal you have still have the kernel installed though in a very slimmed down form; one which is valid for booting in a VM for instance. The postrm for the linux-image-* package will call the required postrm when and if the whole kernel is removed. We have to call all of the postinst (not just update-initramfs as we cannot know what else needs to care that the initramfs has changed; typically the bootloader which is informed of the kernel change via the /etc/kernel/* hooks. Without this the initramfs can get built without the contents of the -extras package, bootloaders can consume _that_ version and you have an unbootable system even though you subsequently installed linux-image-extra-*.

All of the scripts in the /etc/kernel/* hook directories need to be careful to view the world in the context of the installed system and idempotent against rerunning as they are part of postinst/postrm which has this requirement. If they are breaking in the face of this occuring the hooks are broken and we need to fix them.

It sounds like apt-auto-remove was incorrectly calculating the list of kernels in the past, but I understand that is fixed. Is there any other hook known to cause issues.

Thanks Andy, that makes sense. I'm not aware of any other hooks having problems. I have also neither checked apt-auto-remove nor noticed the issue recently. So I'll take you word for it that the hook itself has been fixed in which case we can close this one as Not-A-Bug or whatever seems appropriate.

Andy, in comment #10 I have mentioned a couple of other side effects of running post-installation scripts when removing a linux-image-extra package.

@Jarno the first of those seems unrelated to the underlying issue here. The second one of these is real. That would not be resolved by not running the postinst if postrm then did update-initramfs -u. That would be resolved by the long intended and never implemented switch to a fuller trigger implementation for initramfs-tools.

@Andy reboot request notification is triggered by some kernels post-installation scripts only, so it is related. And as for the second issue, I have presented different strategy or two in the description of that bug report.

@Andy, can you give more information about the trigger implementation you referred to?

I think the problems can be worked around by the attached code by adding it to post-installation scripts such as apt-auto-removal, unattended-upgrades, update-notifier, zz-update-grub, but not in initramfs-tools or dkms.

Still, it might make more sense to run the scripts in /etc/kernel/postrm.d and program the exceptions for linux-image-extra there. For example, check in /etc/kernel/postrm.d/zz-update-grub if we are removing a linux-image-extra package, and only update grub, if not, right? And in /etc/kernel/postrm.d/initramfs-tools create initrd.img instead of removing it, if removing a linux-image-extra package.

This is another version for the code. It does not use awk.

Oh, I seem to have forgotten to get the possible configurable path to dpkg in the version 2 of the code. That can be added to it, though I don't know how much that is required in Ubuntu.

A better (IMO) code to check this is:

case "$DPKG_MAINTSCRIPT_PACKAGE::$DPKG_MAINTSCRIPT_NAME" in
    linux-image-extra*::postrm)
        exit 0;;
esac

I uploaded update-notifier and unattended-upgrades with that for bug 1458204.

Cool, I was not aware of those variables.