Comment 1 for bug 239674

I just want to add a me too for this bug. I'm not using any custom kernels, but I just have a noninteractive script that does my software updates, so I set UCF_FORCE_CONFFOLD=YES in the script and this causes nothing but problems for grub menu.lst configuration.

Thanks to this bug report, it does seem that I can do this to workaround the problem in my script:
   unset UCF_FORCE_CONFFOLD
   export UCF_FORCE_CONFFNEW=YES
   ucf --purge /var/run/grub/menu.lst
   update-grub

I have spent hours trying to figure out why update-grub would say it found new kernels, yet, never update the menu.lst. There should at least be an error message of some sort if the menu.lst didn't actually get updated with the kernels it said it found. For example, without purging /var/run/grub/menu.lst here is the output of update-grub with no UCF environment variables set:

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-2.6.24-21-generic
Found kernel: /boot/vmlinuz-2.6.24-19-generic
Found kernel: /boot/memtest86+.bin
Updating /boot/grub/menu.lst ... done

At this point menu.lst does not have the 2.6.24-21-generic kernel. This kernel was installed with my noninteractive script, so UCF_FORCE_CONFFOLD=YES would have been set when it was initially installed.