Hey,
I don’t have an answer, but I did some digging. Here are my results; maybe they’ll be of help in investigating further.
The big difference in the output between your “not working” and “working” versions is this (paste is for the working version):
For the non-working version only the second line is output, not the first one.
The defective grub.cfg.new you’ve uploaded has an error in line 105 (you can get that information via grub-script-check grub.cfg.new):
if background_image /grub/uniboot.png; then
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
The problem is that the if part is empty, it doesn’t contain a single entry. Contrast this with a working grub.cfg where you might find:
if background_image /grub/uniboot.png; then
set color_normal=black/black
set color_highlight=white/green
set menu_color_normal=black/black
set menu_color_highlight=white/green
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
So how does that happen? Further digging yields /etc/grub.d/05_debian_theme. It contains the function set_background_image which is called from different places further down in the same file. The first parameter is the background image to use. All other optional parameters are the colors that should be set.
In the non-working version it seems that the function is called with a single parameter only, the background image, but no further parameters for the colors. This leads me to believe that the following code is the call that was made:
# Next search for pictures the user put into /boot/grub/ and use the first one.
for background in *.jpg *.JPG *.jpeg *.JPEG *.png *.PNG *.tga *.TGA; do
if set_background_image "${background}"; then
exit 0
fi
done
As we can see that place is only reached if the GRUB_BACKGROUND variable is unset; otherwise the following lines directly above would have been executed:
# First check whether the user has specified a background image explicitly.
# If so, try to use it. Don't try the other possibilities in that case
# (#608263).
if [ -n "${GRUB_BACKGROUND+x}" ]; then
set_background_image "${GRUB_BACKGROUND}" "${GRUB_COLOR_NORMAL}" "${GRUB_COLOR_HIGHLIGHT}" "${GRUB_MENU_COLOR_NORMAL}" "${GRUB_MENU_COLOR_HIGHLIGHT}"|| set_default_theme
exit 0
fi
GRUB_BACKGROUND is normally set in /etc/default/grub, and your running of update-grub shows that it is indeed set — but for some reason it doesn’t seem to be set when update-grub is called during package installation.
This is as far as I’ve come. Unfortunately you don’t seem to be able to reproduce the issue (and on my 4.2 servers I do have kernel revision 109 installed with working grub.cfg files, meaning it didn’t happen for me and I cannot reproduce it either). This makes further analysis a bit difficult. One could try to set up a virtual machine, update it to before 109, snapshot it, try the update to the 109 revision and see if that yields the same error.
On the other hand, maybe some other users will chime in here, too; further information would be great to have. For example, just a couple of hours ago another user complained that his server didn’t boot anymore after an update. Even though (s)he didn’t give enough information, maybe (s)he hit the same error.
Kind regards,
mosu