Syntax error in grub config when installing linux-image-4.9.0-ucs109-amd64

UCS - Univention Corporate Server
,
#1

Hi everyone,

installing some errata updates for a ucs 4.2 server, the machine ended up unwilling to boot. It was still possible to boot the system, by manually choosing an older kernel image from grub’s boot menu. Digging the logs I’ve found some lines, complaining a syntax error in /boot/grub/grub.cfg:

inux-image-4.9.0-ucs109-amd64 (4.9.30-2A~4.2.0.201803221415) wird eingerichtet ...
/etc/kernel-img.conf:12: W: ignoring unknown parameter do_bootfloppy
/etc/kernel-img.conf:13: W: ignoring unknown parameter silent_loader
/etc/kernel-img.conf:15: W: ignoring unknown parameter postinst_hook
I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.9.0-ucs105-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-4.9.0-ucs105-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-4.9.0-ucs109-amd64
I: /initrd.img is now a symlink to boot/initrd.img-4.9.0-ucs109-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-ucs109-amd64
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
W: mdadm: no arrays defined in configuration file.
W: Possible missing firmware /lib/firmware/ast_dp501_fw.bin for module ast
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found background image: uniboot.png
Linux-Abbild gefunden: /boot/vmlinuz-4.9.0-ucs109-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.9.0-ucs109-amd64
Linux-Abbild gefunden: /boot/vmlinuz-4.9.0-ucs105-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.9.0-ucs105-amd64
Linux-Abbild gefunden: /boot/vmlinuz-4.9.0-ucs104-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.9.0-ucs104-amd64
Linux-Abbild gefunden: /boot/vmlinuz-4.1.0-ucs207-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.1.0-ucs207-amd64
Found memtest86+ image: /memtest86+.bin
Adding boot menu entry for EFI firmware configuration
Fehler: syntax error.
Fehler: Incorrect command.
Fehler: syntax error.
Syntaxfehler in Zeile 105
In der erzeugten GRUB-Konfigurationsdatei wurden
Syntaxfehler entdeckt. Stellen Sie sicher, das die Dateien
/etc/default/grub und /etc/grub.d/* fehlerfrei sind oder
erstellen Sie einen Fehlerbericht mit /boot/grub/grub.cfg.new als Anhang.
erledigt
Generating legacy menu.lst from current kernels
linux-image-4.9.0-ucs109-amd64-signed (3.0.2-22A~4.2.0.201803231159) wird eingerichtet ...
python-univention-config-registry (12.0.1-8A~4.2.0.201802061802) wird eingerichtet ...
univention-config (12.0.1-8A~4.2.0.201802061802) wird eingerichtet ...
univention-kernel-image (10.0.0-12A~4.2.0.201802151039) wird eingerichtet ...

I attached the file right here:
grub.cfg.new.txt (12,3 KB)

I’ve seen an older bug https://forge.univention.org/bugzilla/show_bug.cgi?id=39009 although I cannot estimate, if that is the same issue here.

Purging a linux-image*.deb leftover, didn’t solve the issue.

Does that mean anything to anyone?

Cheers
Sebastian

#2

Whoosh! ucr commit /etc/default/grub gave me this:

ucr commit /etc/default/grub
File: /etc/default/grub
Generating grub configuration file ...
Found background: /boot/grub/uniboot.png
Found background image: /boot/grub/uniboot.png
Found linux image: /boot/vmlinuz-4.9.0-ucs109-amd64
Found initrd image: /boot/initrd.img-4.9.0-ucs109-amd64
Found linux image: /boot/vmlinuz-4.9.0-ucs105-amd64
Found initrd image: /boot/initrd.img-4.9.0-ucs105-amd64
Found linux image: /boot/vmlinuz-4.9.0-ucs104-amd64
Found initrd image: /boot/initrd.img-4.9.0-ucs104-amd64
Found linux image: /boot/vmlinuz-4.1.0-ucs207-amd64
Found initrd image: /boot/initrd.img-4.1.0-ucs207-amd64
Found memtest86+ image: /memtest86+.bin
File descriptor 6 (/dev/urandom) leaked on lvs invocation. Parent PID 8506: /bin/sh
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 8775: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 8775: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 8861: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 8861: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 8947: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 8947: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9032: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9032: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9118: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9118: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9246: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9246: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9333: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9333: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9418: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9418: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9503: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9503: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9589: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9589: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9687: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9687: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9774: grub-probe
File descriptor 6 (/dev/urandom) leaked on vgs invocation. Parent PID 9774: grub-probe
Adding boot menu entry for EFI firmware configuration
done
Generating legacy menu.lst from current kernels

I tried once more

update-grub2
Generating grub configuration file ...
Found background: /boot/grub/uniboot.png
Found background image: /boot/grub/uniboot.png
Found linux image: /boot/vmlinuz-4.9.0-ucs109-amd64
Found initrd image: /boot/initrd.img-4.9.0-ucs109-amd64
Found linux image: /boot/vmlinuz-4.9.0-ucs105-amd64
Found initrd image: /boot/initrd.img-4.9.0-ucs105-amd64
Found linux image: /boot/vmlinuz-4.9.0-ucs104-amd64
Found initrd image: /boot/initrd.img-4.9.0-ucs104-amd64
Found linux image: /boot/vmlinuz-4.1.0-ucs207-amd64
Found initrd image: /boot/initrd.img-4.1.0-ucs207-amd64
Found memtest86+ image: /memtest86+.bin
Adding boot menu entry for EFI firmware configuration
done
Generating legacy menu.lst from current kernels

Doesn’t look too bad for the grub part, right. Even though I don’t know what to do with these leaks concerning vgs.

Cheers
Sebastian

#3

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

#4

Addendum: the issue you’ve encountered has nothing to do with bug 39009. There the UCR variable grub/default was set wrong (it contained whitespaces), but that’s not the case for you; your variable is set to its safe default 0.

#5

Hi Moritz,

during upgrade to UCS 4.2-4 it happened again on a different server:

/etc/kernel-img.conf:12: W: ignoring unknown parameter do_bootfloppy
/etc/kernel-img.conf:13: W: ignoring unknown parameter silent_loader
/etc/kernel-img.conf:15: W: ignoring unknown parameter postinst_hook
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-4.9.0-ucs104-amd64
/etc/kernel/postrm.d/zz-update-grub:
Generating grub configuration file ...
Found background image: uniboot.png
Linux-Abbild gefunden: /boot/vmlinuz-4.9.0-ucs109-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.9.0-ucs109-amd64
Linux-Abbild gefunden: /boot/vmlinuz-4.9.0-ucs108-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.9.0-ucs108-amd64
Linux-Abbild gefunden: /boot/vmlinuz-4.9.0-ucs105-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.9.0-ucs105-amd64
Found memtest86+ image: /memtest86+.bin
Fehler: syntax error.
Fehler: Incorrect command.
Fehler: syntax error.
Syntaxfehler in Zeile 106
In der erzeugten GRUB-Konfigurationsdatei wurden
Syntaxfehler entdeckt. Stellen Sie sicher, das die Dateien
/etc/default/grub und /etc/grub.d/* fehlerfrei sind oder
erstellen Sie einen Fehlerbericht mit /boot/grub/grub.cfg.new als Anhang.
erledigt
Generating legacy menu.lst from current kernels
Log ended: 2018-07-03  10:17:48

Anyway,

ucr commit /etc/default/grub
update-grub2

solved it for me.
Cheers
Sebastian

Mastodon