ucf and update-grub semantics are incompatible
Binary package hint: grub
Ubuntu hardy (amd64)
The Ubuntu-specific modification to use ucf for managing menu.lst breaks the traditional update-grub semantics in fundamental ways. If I understand the architecture correctly, I'm not sure how using ucf could ever support the normal workflow that's possible using the Debian update-grub.
ucf's goal is to preserve local changes to a configuration file, but its notion of local changes is contrary to how update-grub is supposed to work. Suppose that you're a large organization with a lot of systems with a variety of kernel revisions, for one reason or another, but with a desire to have uniform kernel parameters like console speed and timeouts. With update-grub, you can just copy your menu.lst template to all of your systems and run update-grub afterwards, and update-grub will apply your new defaults and generate a new kernel list using them. However, with Ubuntu's update-grub, it generates the initial menu.lst and kernel list, and then when you replace that with a fresh template, ucf sees that you've removed the kernel list. It thinks that's a local modification, and when update-grub generates a new kernel list, it "preserves" your modification and leaves the kernel list out of the new menu.lst. Tada, instant unbootable system.
Even worse, this bug is sticky: you can re-run update-grub all you want, it succeeds without errors, and it keeps generating an empty menu.lst. This is a completely mystifying error until you dig into the details of what's going on. To recover, you have to run ucf --purge /var/run/
The specific problem I had was that we were copying our template over and re-running update-grub in an FAI post-install script, resulting in a system that always had an empty kernel menu and wouldn't boot. Once I finally figured out what's going on, I worked around it by being very careful to put our template in place before the initial system bootstrap and then never changing menu.lst afterwards, but this is a bad limitation for a large site that scales system administrators by automating configuration file updates.
It's possible that the right solution here is to change to a completely different configuration that uses a separate file for the template and explicitly supports custom kernel menu entries rather than reverting to the Debian behavior, but the current solution in Ubuntu breaks capabilities of update-grub that we expected to be able to use. Reverting to the Debian behavior, which we've never had any trouble with, would be an improvement over the current Ubuntu version for us.