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..
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:
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
unset UCF_FORCE_CONFFOLD export UCF_FORCE_CONFFNEW=YES 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.
- 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*
Kubernetes Free Online Tutorial, Kubernetes Beginner Tutorial
DevOps Free Online Tutorial, DevOps Beginner Tutorial
Ansible Free Online Tutorial, Ansible Beginner Tutorial
Docker Free Online Tutorial, Docker Beginner Tutorial
Openstack Free Online Tutorial, Openstack Beginner Tutorial
Disclaimer: This has been sourced from a third party syndicated feed through internet. We are not responsibility or liability for its dependability, trustworthiness, reliability and data of the text. We reserves the sole right to alter, delete or remove (without notice) the content in its absolute discretion for any reason whatsoever.