Grub updated its configuration and now there are issues
During grub updates, depending on the operating system, grub will ask if it should update the grub configuration. The options are to install the maintainer's version, or keep the installed one.
A new version (/tmp/grub.QCD0kA1oxG) of configuration file /etc/default/grub is available, but the version installed currently has been locally modified. What do you want to do about modified configuration file grub? 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 start a new shell to examine the situation
The correct answer is the following:
keep the local version currently installed
But instead the following was chosen, and now there are issues:
install the package maintainer's version
If you already chose to install the maintainer's version, and are now experiencing issues, it can be reset back to Linode's provided.
Copy paste default
/etc/default/grub file from a working Linode of the same operating system.
Here is an example
/etc/default/grub file from Ubuntu 18.04. This will be the same for all Ubuntu 18.04 Linodes, and can be copy and pasted into
# If you change this file, run 'update-grub' afterwards to update # /boot/grub/grub.cfg. # For full documentation of the options in this file, see: # info -f grub -n 'Simple configuration' GRUB_DEFAULT=0 #GRUB_HIDDEN_TIMEOUT=0 #GRUB_HIDDEN_TIMEOUT_QUIET=true GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="" GRUB_CMDLINE_LINUX="console=ttyS0,19200n8 net.ifnames=0" # Uncomment to enable BadRAM filtering, modify to suit your needs # This works with Linux (no patch required) and with any kernel that obtains # the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...) #GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef" # Uncomment to disable graphical terminal (grub-pc only) #GRUB_TERMINAL=console # The resolution used on graphical terminal # note that you can use only modes which your graphic card supports via VBE # you can see them in real GRUB with the command `vbeinfo' #GRUB_GFXMODE=640x480 # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux GRUB_DISABLE_LINUX_UUID=true # Uncomment to disable generation of recovery mode menu entries #GRUB_DISABLE_RECOVERY="true" # Uncomment to get a beep at grub start #GRUB_INIT_TUNE="480 440 1" # Enable serial console for LISH GRUB_GFXPAYLOAD_LINUX=text GRUB_TERMINAL=serial GRUB_SERIAL_COMMAND="serial --speed=19200 --unit=0 --word=8 --parity=no --stop=1"
Once doing so, you can update the grub config and reboot. To do so, from the terminal run:
$ sudo update-grub
Updating a brand new ubuntu 18.04 system prompted me 4 times. How are you supposed to handle this when doing updates unattended?
Yeah, this is something I'm also not sure about, though in my case I wanted to set up a stackscript to for spinning up a server. According to someone on stackoverflow
apt -y upgrade doesn't help. Best solution I've come up with is .. well, not do an
apt upgrade in your setup script.
@povrazor I just wanted to pop in and mention that the correct syntax to use for an unattended upgrade is mentioned below:
sudo apt upgrade -y
That being said, I wouldn't recommend including that in your script if there are things that you would rather review before accepting. In this specific case, you can use @sjacobs instructions for editing
/etc/default/grub if the maintainer's version was selected during an unattended upgrade.
apt -y upgrade or
apt upgrade -y will work on GNU/Linux distributions like Debian and Ubuntu. This post from Stack Overflow has a nice explanation on different option/operand syntax treatment for POSIX vs. GNU/Linux systems.
The trick to pulling off unattended upgrades in StackScripts for Debian-based systems is to set this environment variable as follows before upgrading:
Unattended, initial updates/upgrades are very common in StackScripts, as the practice is commonly recommended as a first step when setting up a distribution for the first time (including in our own documentation) and is a prime example of how StackScripts can be leveraged to automate repetitive, time-consuming tasks.
Along these lines, you can see this implemented in our StackScript Bash Library's "system_update" function for distributions in the Debian family.