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

June 8, 2018 16.8k views
DigitalOcean Docker Linux Basics Ubuntu 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

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

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?

I will open a support ticket to find out the answer to this since no one officially is commenting and report back here when I hear from them.

Got this reply back from Keith A. in support:
“I don’t have an exact answer but have received the same error in upgrading and have never had any issues as a result. I’ll continue to research, but I believe it has something to do with US installing new droplets from images. In any case, it really is up to you to decide, if you don’t see major differences then feel free to use the maintainers version.”

I would appreciate a more definitive answer but it seems like there isn’t one unfortunately.

is there any update on the matter? im standing here staring at the computer wondering what to do ? :)

To those still asking what to do in this situation:

I’ve always just gone with “Keep local version currently installed”, and not faced any issues as a result. More recently, you can see that “Show the differences between the versions” results in:

Line by line differences between versions
There are no non-white space differences in the files.

So it literally does not matter whether you choose “Install the package maintainer’s version” or “Keep the local version currently installed”.

As I mentioned in reply to @mahnuh, since the file in question is used during the boot process, DigitalOcean might just hook into the VM and put a default version of the file there if it’s missing, or even always put their own version there on boot/reboot. 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; they will always automatically replace the existing file with the “right one”.

Have another answer? Share your knowledge.