Comment 12 for bug 1309079

Revision history for this message
Nathan Stratton Treadway (nathanst) wrote :

I ran into a problem with grub-legacy-ec2 v1:1 in Bionic (on an EC2 instance built from a Canonical Bionic AMI)... but the problem I found relates to the switch from /var/run to /run, so it seems like it could be related the earlier reports as well.

Specifically, what I noticed was the "The first time ucf sees the file" check around line 1349 of update-grub-legacy-ec2, which is:

=====
# The first time ucf sees the file, we can only assume any difference
# between the magic comments and the kernel options is a result of local
# mods, so this will result in a ucf prompt for anyone whose first
# invocation of update-grub is as a result of updating the magic comments.
if ! ucfq grub | grep -q $ucf_menu_file; then
        otherbuffer=$(tempfile)
        cat $buffer > $otherbuffer

        sortedKernels=`sed -n -e "
        /$endopt/,/$end/ {
                s/^kernel[[:space:]]\+\([^[:space:]]\+\).*/\1/p
        }" < $menu | grep -vE "memtest86|$grub2name|xen" | uniq`
        xenKernels=`sed -n -e "
        /$endopt/,/$end/ {
                s/^module[[:space:]]\+\([^[:space:]]*vmlinuz[^[:space:]]\+\).*/\
1/p
        }" < $menu | uniq`

=====

When this is called, $ucf_menu_file contains "/var/run/grub/menu.lst"... but because of the /var/run -> /run switch, UCF doesn't actually have registered a file with that path:

=====
# ucfq grub
Configuration file Package Exists Changed
/run/grub/menu.lst grub Yes Yes
# if ! ucfq grub | grep -q /var/run/grub/menu.lst; then echo "yes"; fi
yes
=====

So the net effect is that the script assumes that the file has not been registered with UCF before and rebuilds it from the kernel list taken out of the existing /boot/grub/menu.lst... but since that list is stale, there is a ucf conflict and the new file is not installed -- and then later when the script tries to to update the file with the currently-installed kernel list, there is still a ucf conflict and the updated menu.lst file is not installed.

I was able to get past this by running the kernel-image install manually (using aptitude) and thus getting the ucf "A new version of /boot/grub/menu.lst is available, but the version installed currently has been locally modified" dialog box. When I chose the "install the package maintainer's version" version, the script was then able to proceed to install that (outdated) menu.lst file, and then went on to detect the current kernel list and update menu.lst reflect them...

(I have not yet tried a second kernel update to see if the problem reoccurs.)