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


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?


6 Answers 6


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


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


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


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

ucf --purge /var/run/grub/menu.lst
sudo apt-get dist-upgrade -qq --force-yes


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 :)


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."


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.


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.


The error is still happening on my Ubuntu 18.04 EC2 instances and it seems to be related when the kernel upgrades from 4.x to 5.x.

Steps which worked for me, which are similar to @menzo:

  1. When prompted during $sudo apt update; sudo apt upgrade to resolve, I kept the original version.
  2. Backup: sudo mv -v /boot/grub/menu.lst.bkp
  3. Recreate and press y: sudo update-grub-legacy-ec2

Searching for GRUB installation directory ... found: /boot/grub Searching for default file ... found: /boot/grub/default Testing for an existing GRUB menu.lst file ...

Could not find /boot/grub/menu.lst file. Would you like /boot/grub/menu.lst generated for you? (y/N) y Searching for splash image ... none found, skipping ... Found kernel: /boot/vmlinuz-5.4.0-1054-aws Found kernel: /boot/vmlinuz-5.3.0-1032-aws Found kernel: /boot/vmlinuz-4.15.0-1065-aws Updating /boot/grub/menu.lst ... done

  1. Check: sudo cat /boot/grub/menu.lst
  2. sudo reboot

Initially, in AWS EC2 console

0/2 Checks passed

which however resolved after 5-10min.

Good luck! It is so annoying as the upgrade is not automatic and I have a lot of old instances...


Your choice

  • show the differences between the versions


  • install the package maintainer's version


  • 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*
  • 1
    -1; this doesn't answer the question at all (indeed, it mostly just repeats bits of the message I already quoted), nor does it explain why I'd want to run the provided code or what it will do.
    – Mark Amery
    Jul 21, 2017 at 14:26
  • Files hash mismatch cause message with options, you must find differences between them to choose right option. "whatis ls diff" prints description of commands.
    – Imya
    Jul 21, 2017 at 14:44
  • "Files hash mismatch cause message with options" - Yes, I can read. My question is why these differences exist on EC2 instances and what the consequences of keeping or discarding them will be. Your answer doesn't address this at all, it just repeats what's printed in the message. Your answer doesn't even mention Amazon or EC2; it's not relevant to the question that was asked.
    – Mark Amery
    Jul 21, 2017 at 14:46
  • Oh, boi, even doesn't provided content of files and waits others will find out, what is going on on his system.
    – Imya
    Jul 21, 2017 at 14:57
  • 2
    It's not "my system". I'm asking about standard EC2 installation behaviour on a question about EC2 and tagged with the EC2 tag. Sure, I decided not to dump the complete content of the file into the question, because it's not necessary for the question to be understood and answerable; anyone who uses Ubuntu on EC2 is capable of checking its contents if they want to investigate the issue. I don't see why I'd be expected to provide the source of the file here any more than I'd dump the source code of a popular library into a Stack Overflow question before asking about it.
    – Mark Amery
    Jul 21, 2017 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.