Comment 18 for bug 222421

Yes, the sequence here that results in this kind of breakage must be:

- kernel is unpacked
- update-grub is called
- initramfs is generated (in kernel package postinst)
- update-grub is *not* called
- kernel package postinst ends successfully, leaving the kernel configured
  but menu.lst broken

There are any number of ways this could come to pass, but I haven't found
any way this would happen as a result of bugs in the kernel package
maintainer scripts shipped in any of the relevant kernel versions, nor in
initramfs-tools. It's also possible this could happen as a result of a
misconfigured /etc/kernel-img.conf (postinst_hook unset, postrm_hook left in
place), or it's possible to get in this state because the kernel package
postinst did *not* complete successfully - but in that case the user should
get a very visible error from the package manager.

I would note that it's not a bug for update-grub to be called by something
else after the new kernel is unpacked and before it's configured. There are
perfectly legitimate reasons this would be the case, either due to direct
user action, as part of the postrm of another kernel that's being
uninstalled or upgraded at the same time, or as part of the maintainer
script of another package (e.g., grub itself - though this would not be the
case for hardy->intrepid upgrades - or memtest86+). The bug is in
update-grub *not* being called at the end of the kernel postinst, and I
don't see why that's happening in any of these cases.