Question

[Ubuntu] New /boot/grub/menu.lst after `apt-get upgrade`?

Posted June 8, 2018 37.2k views
Linux BasicsDigitalOceanDockerUbuntu 16.04

Hi there!

Just started a new droplet with Docker.

I wanted to make sure I have the newest version, so I ran apt-get update and apt-get upgrade after which I got the following in Terminal:

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’ve never edited the menu.lst file, I imagine this is something done by DO.

What exactly is happening here, and what option should I select?

Thanks!

Dillon

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
Submit an Answer
16 answers

I used the option to see differences…

“There are no non-whitespace differences in the files.”

OK then, new version it is!

Update: after finding this discussion, I chose to keep the current version (prompted twice). After that, I rebooted my server and crossed fingers and it looks like it survived the reboot.

So I suppose the “keep current version” is not an entirely bad option.

Hey @DigitalOcean, can we have an official answer on this? I’m getting the same warning and the changes between the two versions of /run/grub/menu.lst show that the new version is for Ubuntu 16.04.5.

Line by line differences between versions                                 

--- /run/grub/menu.lst root.root 0644 2018-08-05 09:53:42     
+++ /tmp/filenNNsEF root.root 0600 2018-08-05 09:53:42
@@ -1,11 +1,31 @@                    
 ## ## End Default Options ##
-title Ubuntu 16.04.4 LTS, kernel 4.4.0-127-generic
+title Ubuntu 16.04.5 LTS, kernel 4.4.0-131-generic
+root (hd0)                       
+kernel /boot/vmlinuz-4.4.0-131-generic root=LABEL=cloudimg-rootfs ro console=hvc0                             
+initrd /boot/initrd.img-4.4.0-131-generic
+
+title Ubuntu 16.04.5 LTS, kernel 4.4.0-131-generic (recovery mode)
+root (hd0)
+kernel /boot/vmlinuz-4.4.0-131-generic root=LABEL=cloudimg-rootfs ro single
+initrd /boot/initrd.img-4.4.0-131-generic
+                                
+title Ubuntu 16.04.5 LTS, kernel 4.4.0-130-generic
+root (hd0)                       
+kernel /boot/vmlinuz-4.4.0-130-generic root=LABEL=cloudimg-rootfs ro console=hvc0
+initrd /boot/initrd.img-4.4.0-130-generic
+
+title Ubuntu 16.04.5 LTS, kernel 4.4.0-130-generic (recovery mode)
+root (hd0)
+kernel /boot/vmlinuz-4.4.0-130-generic root=LABEL=cloudimg-rootfs ro single     
+initrd /boot/initrd.img-4.4.0-130-generic    
+                                
+title Ubuntu 16.04.5 LTS, kernel 4.4.0-127-generic root (hd0) kernel /boot/vmlinuz-4.4.0-127-generic root=LABEL=cloudimg-rootfs ro console=hvc0
initrd /boot/initrd.img-4.4.0-127-generic
-title Ubuntu 16.04.4 LTS, kernel 4.4.0-127-generic (recovery mode)
+title Ubuntu 16.04.5 LTS, kernel 4.4.0-127-generic (recovery mode)
 root (hd0)       
 kernel /boot/vmlinuz-4.4.0-127-generic root=LABEL=cloudimg-rootfs ro single initrd /boot/initrd.img-4.4.0-127-generic
  • Hello there,

    I used the first option just to try and it seems like everything is ok. I mean, I restarted the server and I was able to continue working on it. Honestly I’m not sure about the implications but there was no error for me.

This is what worked for me to eliminate the GRUB conflict message during the initial “apt upgrade” after spinning a new Ubuntu server.

$ sudo apt update
$ sudo rm /boot/grub/menu.lst
$ sudo update-grub-legacy-ec2 -y
$ sudo apt -y upgrade
$ sudo reboot

Also hitting the same situation and would love some clarification.

The third option doesn’t show any non-whitespace differences between the two files, and as far as I can see, neither does the fourth one.

The fifth option, however, shows a change in root device from root=/dev/hda1 to root=LABEL=cloudimg-rootfs.

Which would be the right option to choose?

Doing sudo rm /boot/grub/menu.lst before apt-get upgrade -y fixed the issue for me.

  • Thank you. I did the same, no issues.

  • The outcome of this is the same as choosing “Install package maintainer’s version”.

    Side note: Removing /boot/grub/menu.lst is probably a bad choice, since if the file is not recreated (and valid), then you’re screwed on reboot — unless DigitalOcean, in their infinite wisdom, hooks into the VM and puts a default version of the file there if it’s missing, or even always puts their version there on boot. In fact, if they do indeed do it always, then the subject of this thread is moot, since it literally doesn’t matter which option you choose.

I encountered the same with Ubuntu 18.04.1 and chose to use the package manager’s instead of keeping the modified one.
All seems well, but I have no idea what the changes are or mean.

Any official response or clarification on this @DigitalOcean?

Previous 1 2 Next