infinite loop in /etc/grub.d/10_linux while reading image list - "Found linux image: /boot/vmlinuz-2.6.32-16-generic"

Thanks for your report.

The relevant error is
---
Preparing to replace memtest86+ 2.11-3ubuntu5 (using .../memtest86+_4.00-2ubuntu2_i386.deb) ...
Unpacking replacement memtest86+ ...
Generating grub.cfg ...
untu1_i386.deb) ...
Found linux image: /boot/vmlinuz-2.6.32-16-generic
) ...
tu3_i386.deb) ...
 ...
-2ubuntu2_i386.deb) ...
Found linux image: /boot/vmlinuz-2.6.32-16-generic
Found linux image: /boot/vmlinuz-2.6.32-16-generic
Found linux image: /boot/vmlinuz-2.6.32-16-generic
[...]
Found linux image: /boot/vmlinuz-2.6.32-16-generic
Found linux image: /boot/vmlinuz-2.6.32-16-generic
Found linux image: /boot/vmlinuz-2.6.32-16-generic
^Cdpkg: warning: old post-removal script killed by signal (Interrupt)
dpkg - trying script from the new package instead ...
Generating grub.cfg ...
al (Interrupt)
^Cdpkg: warning: old post-removal script killed by signal (Interrupt)
dpkg - trying script from the new package instead ...
Generating grub.cfg ...
^Cdpkg: warning: old post-removal script killed by sign

^Cdpkg: warning: old post-removal script killed by signal (Interrupt)
dpkg - trying script from the new package instead ...
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.32-16-generic
Found linux image: /boot/vmlinuz-2.6.32-16-generic
[...]
ric
^Cdpkg: error while cleaning up:
 subprocess new post-removal script killed by signal (Interrupt)

It shows some kind of loop.

I've read through the code very carefully, but at the moment I can't see why this would be happening. There are some changes I could make that would probably make it go away, but I'd like to understand the problem before randomly prodding at possible solutions.

Could somebody affected by this bug please do the following:

  * Edit /etc/grub.d/10_linux (as root) and put 'set -x' (without the quotes) on the second line, that is on the line immediately after '#! /bin/sh -e'.
  * Run 'sudo update-grub >update-grub.out 2>&1' (without the quotes; make sure you type this exactly).
  * Assuming that you hit the same problem, this should run indefinitely. Give it (say) a minute to make sure that it has definitely entered the infinite loop we're seeing here, and then press Control+c.
  * Attach the file update-grub.out to this bug.
  * Undo the change you made to /etc/grub.d/10_linux in the first step.

Thanks in advance!

From the duplicates it seems that it only happens when dist-upgrading a wubi system from Karmic to Lucid.

Fair enough, though I still don't see how the loop could fail to
terminate and would like the set -x trace to help me determine that.

Thanks for being interested in this bug.
Jean-Baptiste Lallement seems to be right, it did happen when upgrading wubi system from Karmic to Lucid. I don't see why it would make bug irrelevant though.

Now, reproducing bug will require some amount of time (I'll have to redownload Karmic, reinstall wubi, make proper backups for further testing, downloading all lucid upgrades to make sure it shows up, then going back to backup and running case), but I'll sacrifice some time and will try to get you results as soon as possible (evening or tomorrow).

On updating my wubi installation a second time from 9.10 to 10.04 I got the same infinite error. It continued after I killed that part but a gui came up asking what partition i would like to install grub to, there was no option for anything wubi so selected nothing and pressed continue.
Afterwards I put the set -x and ran update-grub and i am attaching the output from that.

Alex, unfortunately your log does not show an infinite loop. It seems to complete normally.

However, this gave me a hint - I've been looking in the wrong place. The buggy script is actually /etc/grub.d/10_lupin, not /etc/grub.d/10_linux at all, and on looking at it I see the problem.

This bug was fixed in the package lupin - 0.29

---------------
lupin (0.29) lucid; urgency=low

  * Fix infinite loop if there's no initrd (LP: #540579).
 -- Colin Watson <email address hidden> Tue, 23 Mar 2010 09:16:15 +0000

There's a remaining piece of this, namely that upgrades won't necessarily install the fixed lupin-support in time for it to be used. I've sent mail to a few people asking for advice on this.

Hmm, is this fixed? I just hit the memtest infinite loop bug today while trying to upgrade a wubi install of Karmic to Lucid Lynx, using "udpate-manager -d" ...

Just tried this the second time again and have the same loop.
attempting to upgrade wubi install 9.10 to 10.04

Accepted update-manager into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

An inquiry, please: is available the package to update into lucid from karmic wubi installed? Thank you very much.

Testcase verified: OK
No regression, no prompt.

This bug was fixed in the package update-manager - 1:0.134.8

---------------
update-manager (1:0.134.8) lucid-proposed; urgency=low

  * DistUpgrade/DistUpgradeCache.py:
    - show pulse while calculating the changes (LP: #548398)
  * DistUpgrade/DistUpgradeQuirks.py:
    - add workaround for 10_lupin infinite loop (LP: #540579)
      Thanks to Juergen Klar for providing the test-case
  * DistUpgrade/10_lupin:
    - include (fixed) lucid version of 10_lupin that fixes a possible
      infinite loop on upgrade
 -- Michael Vogt <email address hidden> Fri, 30 Apr 2010 17:08:46 +0200

Copied update-manager lucid-proposed to maverick.

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".