Scenario / Questions

I just tried to do a sudo do_release_upgrade on an AWS EC2 Ubuntu 13.10 server to upgrade to 14.04. All was going well until I got the following message:

A new version of /boot/grub/menu.lst is available, but the version installed 
currently has been locally modified.

  What would you like to do about menu.lst?       

   * install the package maintainer's version
   * keep the local version currently installed
   * show the differences between the versions
   * show a side-by-side difference between the versions
   * show a 3-way difference between available versions
   * do a 3-way merge between available versions (experimental)
   * start a new shell to examine the situation

  <Ok>

I certainly haven’t modified menu.lst, so I assume the local modifications are Amazon’s doing. I’m going to hit the “keep the local version currently installed” option and hope for the best.

But why am I getting this message, and is this the correct way to handle it?

Find below all possible solutions or suggestions for the above questions..

Suggestion: 1

This issue can be caused by a range of different problems so there isn’t a single solution. These steps should work on EC2.

Source:

The issue is caused by a local and remote change conflict in Grub legacy configuration. Grub legacy and Grub2 use different config locations:

  • Grub legacy: /boot/grub/menu.lst
  • Grub2: /boot/grub/grub.cfg

Causes:

You’re probably using an Amazon EBS-Backed AMI. Instances construct their root file system from a pre-built base image (snapshot). The grub configuration is written in the snapshot, but the UCF registry isn’t purged correctly. This means that you have a snapshot that thinks the menu.lst config was locally modified.
More information can be found here: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1485685

Why ubuntu uses UCF for grub is explained here: https://askubuntu.com/a/147079

Solution(s):

One general solution that works is removing menu.list and reconfiguring it. This ensures that ucf registry entry and configuration file resolve to the same hash.

#Remove the menu.lst config.

sudo rm /boot/grub/menu.lst
# Generate a new configuration file. 
sudo update-grub-legacy-ec2 -y

#Upgrade the configuration
sudo apt-get dist-upgrade -qq --force-yes

A second solution is modifying the UCF config to auto accept the maintainer changes

unset UCF_FORCE_CONFFOLD
export UCF_FORCE_CONFFNEW=YES
ucf --purge /var/run/grub/menu.lst
sudo apt-get dist-upgrade -qq --force-yes

Disclaimer:

This issue is very broad and use cases will impact the required solution. If possible its highly recommended to upgrade to grub2. Grub2 can be configured without modifying system files.

There are also a ton of different solutions offered and issue reports opened in the ubuntu tracker. I’d love to link to all of them but don’t have the rep.

Good luck 🙂

Suggestion: 2

My version of this question goes: “I have automatic kernel upates on ec2, and recently did apt-get autoremove -y. Even after sudo update-grub I only see 3.13.0-48 listed in /boot/grub/menu.lst but not among the installed kernels. How screwed am I?”

My answer: “Probably not screwed. On other Ubuntu systems. menu.lst does not even exist, and update-grub appears to be putting configuration in /boot/grub/grub.cfg instead. My guess is that menu.lst is some weird artifact from EC2’s Ubuntu AMI, or some interacting with packaging or local config management.”

Suggestion: 3

Personally, in your place I would “show the difference between versions”, take careful note of what the changes are, then experiment with the new differences in a “development” AWS instance. If I were being extra cautious, I would simply read the man page for the changes in question (they might not be for menu.lst, but some other software like the kernel, or heck, anything really) to find out exactly what is changing.

Alternatively, you can clone this virtual machine, do the upgrade, see what happens, and if that fails, you nuke the new VM and start the process again with a different choice. Virtual machines are great for this reason alone.

Suggestion: 4

I just ran into the same “problem” with an VPS from OVH.
In my case (and many others I found while Googling) the only changes were whitespaces.
Where they come from I don’t know, but if you select show the differences between the versions and the answer is No non whitespace changes detected just take the maintainers version.

Suggestion: 5

Your choice

  • show the differences between the versions

then

  • install the package maintainer’s version

or

  • keep the local version currently installed

Anyway, now you can run

ls -hl /boot/grub/menu.lst*
diff --suppress-common-lines /boot/grub/menu.lst*