3

When I run update-grub or I try to reinstall it, I get a "syntax error".

The output is somewhat like this:

error: syntax error.
error: Incorrect command.
error: syntax error.
error: line no: 262
Syntax errors are detected in generated GRUB config file.
Ensure that there are no errors in /etc/default/grub
and /etc/grub.d/* files or please file a bug report with
/boot/grub/grub.cfg.new file attached.

Why is this happening? What can I do?

Background

After a Manjaro update, my system did no longer boot. It said "file /boot/vmlinuz-316-x86_64 not found". And then "you need to load the kernel first".

I then booted from a usb stick (the manjaro live/installer disk), and followed the instructions from https://wiki.manjaro.org/index.php/Restore_the_GRUB_Bootloader (UEFI systems) with chroot and update-grub. In fact I first noticed the "syntax error" trouble in the step where I tried to reinstall grub, after I got "EFI variables are not supported on this system."

I imagine (but don't know for sure) that this might have been going on for a while unnoticed. Any update to grub.cfg failed, but the old grub.cfg was still "good enough". But with the update, the vmlinuz file was renamed, and the grub.cfg referred to an old, no longer existing, vmlinuz file. This is why the boot failed.


(I already know the answer while I am writing this. It may not be a complete explanation, but it was enough for me to fix it. I just want to share the result, to save others the trouble)

9

For me it was a very specific answer, but I want to explain in a more general way how to troubleshoot this.

Actually a lot of the information is already in the error message, but to me it was not obvious at first.

In short:

  • Follow the line number, in /boot/grub/grub.cfg.new. Try to understand why what you find there is a syntax error.
  • Follow the comment in this file, that points to either /etc/default/grub, or a specific file in /etc/grub/*.
  • In case of a proxy script, follow the hint to a file in /etc/grub.d/proxifiedScripts/.

Troubleshooting steps, in detail

The /boot/grub/grub.cfg is automatically created on "update-grub", based on a number of files: /etc/default/grub, and any files in /etc/grub.d/*.

/boot/grub/grub.cfg.new
However, in case of a syntax error (or any error, I suppose), the original /boot/grub/grub.cfg is NOT overwritten, but instead the new file is created in /boot/grub/grub.cfg.new.

The error message contains a line number, in my case 262, that refers to this /boot/grub/grub.cfg.new file. In my case, this was 262. Looking at the file, I found this:

### BEGIN /etc/grub.d/60_memtest86+_proxy ###
if [ "${grub_platform}" == "pc" ]; then
fi
### END /etc/grub.d/60_memtest86+_proxy ###

I learned that en empty if/then/fi block in shell script is not allowed, so this was the syntax error. Quite stupid language design imo, but this is how it is.

I also found a fix, which is to add a meaningless statement in the block. A colon was suggested, but there might be other solutions.

### BEGIN /etc/grub.d/60_memtest86+_proxy ###
if [ "${grub_platform}" == "pc" ]; then
    :
fi
### END /etc/grub.d/60_memtest86+_proxy ###

Even better would be to remove this meaningless block completely.

Now we don't really want to edit this file manually, because the changes would be wiped on the next update-grub (if successful, which is the goal).

/etc/grub.d/*
The snippet contains a hint where to look next: /etc/grub.d/60_memtest86+_proxy. This file says:

#!/bin/sh
#THIS IS A GRUB PROXY SCRIPT
'/etc/grub.d/proxifiedScripts/memtest86+' | /etc/grub.d/bin/grubcfg_proxy "+*
+#text
-'Memory Tester (memtest86+)'~30b99791e52c3f0cb32601c5b8f57cc7~
"

/etc/grub.d/proxifiedScripts/*
The relevant part of /etc/grub.d/proxifiedScripts/memtest86+ is this:

    [..]
    cat << EOF
if [ "\${grub_platform}" == "pc" ]; then
    menuentry "Memory Tester (memtest86+)" ${CLASS} {
        search --fs-uuid --no-floppy --set=root ${_GRUB_MEMTEST_HINTS_STRING} ${_GRUB_MEMTEST_FS_UUID}
        linux16 ${_GRUB_MEMTEST_REL_PATH} ${GRUB_CMDLINE_MEMTEST86}
    }
fi
EOF
[..]

The file itself is a shell script, but then it has those "cat" statements. These print the shell script snippets that should finally go into /boot/grub/grub.cfg. With some modifications, maybe.

In the /boot/grub/grub.cfg.new, we observe that the "menuentry ..." stuff is actually missing, and instead we get an empty then..fi block. Why the "menuentry ..." disappears, I don't know. Maybe grub thinks that it is not needed. Unfortunately, the removal breaks the script.

Workaround

The trick / workaround was to add a colon in this file, like this:

if [ "\${grub_platform}" == "pc" ]; then
    :
    menuentry "Memory Tester (memtest86+)" ${CLASS} {
        search --fs-uuid --no-floppy --set=root ${_GRUB_MEMTEST_HINTS_STRING} ${_GRUB_MEMTEST_FS_UUID}
        linux16 ${_GRUB_MEMTEST_REL_PATH} ${GRUB_CMDLINE_MEMTEST86}
    }

When running update-grub, this generates a grub.cfg with the workaround described above.

Background / More investigation

The /etc/grub.d/ folder on my system actually contained two files for memtest86+_proxy: 60_memtest86+_proxy and 62_memtest86+_proxy. I assume that one of them is a leftover of some sort. But both of them have the same updated timestamp, so I really don't know which of them would be safe to delete. A diff shows this:

--- /etc/grub.d/60_memtest86+_proxy 2015-01-08 15:54:02.228927526 +0100
+++ /etc/grub.d/62_memtest86+_proxy 2015-01-08 15:54:02.228927526 +0100
@@ -1,6 +1,6 @@
 #!/bin/sh
 #THIS IS A GRUB PROXY SCRIPT
-'/etc/grub.d/proxifiedScripts/memtest86+' | /etc/grub.d/bin/grubcfg_proxy "+*
-+#text
--'Memory Tester (memtest86+)'~30b99791e52c3f0cb32601c5b8f57cc7~
+'/etc/grub.d/proxifiedScripts/memtest86+' | /etc/grub.d/bin/grubcfg_proxy "+'Memory Tester (memtest86+)'~30b99791e52c3f0cb32601c5b8f57cc7~
+-*
+-#text
 "
\ No newline at end of file

So, both of the files refer to the same proxified script, but the result is piped through the grubcfg_proxy binary, with different parameters. These different parameters could be responsible for removing the "menuentry ..." stuff in case of the 60_memtest86+_proxy.

Conclusion

Others may have completely different problems. But the troubleshooting, at least the first steps, should be quite similar.

1
  • 1
    Best answering technique I have ever seen... Mar 23 '20 at 9:05
2

Great troubleshooting steps from @donquixote (+1 upvote).

For my situation, the error was because I had not set the dev / partition for Ubuntu to boot from, when I re-ordered my menu options for a Windows / Ubuntu dual boot setup.

What helped me was to move a menu option up and down through the list in the grub-customizer menu and observe id the line number of the syntax error changed, that way, one would know that the option needed further attention.

2

Thanks it realy helped me.

In my case it was that file /etc/grub.d/proxifiedScripts/custom

I tried to create custom script using grub-customizer to boot Prime OS from directory in the root path.

I removed the file then the command update-grub done without errors then I regenerated the custom script using grub-customizer and it is working well.

2

As per @donquixote's answer - I also had the exact same 60_memtest86+_proxy and 62_memtest86+_proxy files in /etc/grub.d/. Running update-grub resulted with syntax errors in my /boot/grub/grub.cfg that read:

### BEGIN /etc/grub.d/~60_memtest86+_proxy ###

if [ "${grub_platform}" == "pc" ]; then

fi
### END /etc/grub.d/~60_memtest86+_proxy ###

### BEGIN /etc/grub.d/62_memtest86+_proxy ###
menuentry "Memory Tester (memtest86+)" --class memtest86 --class gnu --class tool {
        search --fs-uuid --no-floppy --set=root --hint-ieee1275='ieee1275//disk@0,gpt5' --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  afa594f4-80a8-4a18-8df5-53d58be8651a
        linux16 /boot/memtest86+/memtest.bin 
}
### END /etc/grub.d/62_memtest86+_proxy ###

To solve I just removed the 60_memtest86+_proxy that was creating the empty if statement. This made update-grub finally work.

1

user, I am a normal newbie at linux but getting stronger a it day by day. Still learning some new commands but i will master linux soon.

According to ur question and the answers provided, u must have solved the issue but still i will give my views on it.

According to some sources on the internet,i tried them all because i also had encountered that issue when i was removing (purging) my old kali kernel, none of them proved in solving my problem.

them i resorted to use my own linux knowledge and lo! i found the solution. every time i did "update-grub" it would result the following, https://im.ge/i/9MH08 then i checked my /boot/grub/grub.cfg.new the error line was 260, so firstly i did in a terminal;

nano /boot/grub/grub.cfg.new then i pressed Ctrl</kbd+Shift</kbd+_ and typed the error line number (mine was 260)

i saw there was a menuentry giving the error but i couldn't clear it out what the problem was. i deleted whole menuentry and run "update-grub" but the grub configuration file was read-only so no effect of my changes.

again a source said me that during "update-grub" the original grub.cfg stays same but a new grub.cfg.new is created so then i saw the grub.cfg(which was too read only.) which had the original thing without any errors or menentry so simply for every line or any error this solution 100% will work.

just start a terminal Non-root user : first do sudo su, then goto solution Root user : direct goto solution Solution:

  1. I removed (not completely, just backed up) the file grub.cfg.new by:

    mv /boot/grub/grub.cfg.new /home/grub.cfg.new.bak

  2. Then i replaced the original grub.cfg as grub.cfg.new by:

    mv /boot/grub/grub.cfg /boot/grub/grub.cfg.new

this will replace the original with the new one because the new is already backed up to directory "/home" and removed from "/boot/grub/" directory.

  1. Then i run "update-grub" in the terminal and got : https://im.ge/i/9QnRx

everybody can try this simple solution

0

I had the same problem with Xubuntu 18.04 but I couldn't find anything wrong in /etc/default/grub or the /etc/grub.d files

Since I was able to access the system despite the error, I didn't have to chroot into it which will be necessary if you cannot boot into the system. What I did was purge and reinstall grub which did the trick.

The steps I used are as follows:

  1. I confirmed that I had an internet connection with sudo apt-get update # ***
  2. I purged grub-pc and grub-common with sudo apt-get purge grub-pc grub-common
  3. I read the warning about removing the bootloader, hit TAB to highlight "" and pressed ENTER.
  4. I issued the command apt-get install grub-common grub-pc and when prompted I hit TAB to highlight "" and pressed ENTER
  5. When presented with the device option, I used the UP/DN keys to select the correct drive (sdX) NOT a partition.

    I made sure the installation drive [] /dev/sdX had an asterisk next to it ( in my case: [] /dev/sda ). If it doesn't, highlight it and press the SPACE bar to select it. Then I hit TAB to highlight "" and pressed ENTER

    I tested that the installation was complete and working by issuing the command sudo update-grub and everything worked error free as expected.

Sources: https://ubuntuforums.org/showthread.php?t=1581099

0

In Manjaro Linux, I faced the same problem. I got a hint to my fix by reading the most popular answer by @donquixote.

Edit the file /etc/grub.d/proxifiedScripts/memtest86+ and add a : between the last if block

...
if [ "\${grub_platform}" == "pc" ]; then
    :
    menuentry "Memory Tester (memtest86+)" ${CLASS} {
        search --fs-uuid --no-floppy --set=root ${_GRUB_MEMTEST_HINTS_STRING} ${_GRUB_MEMTEST_FS_UUID}
    linux16 ${_GRUB_MEMTEST_REL_PATH} ${GRUB_CMDLINE_MEMTEST86}
    }
fi
...

Then run sudo update-grub and it should complete successfully.

0

Same error different cause and solution (more of a fix, than a definitive explanation). MSI GS65 dual boot (2 drives with separate EFI partitions on each drive) Bodhi Linux 5.1.0 (Ubuntu 18.04.4 derivative)

on update-grub I got:

error: syntax error.
error: Incorrect command.
error: syntax error.
error: line no: 257.

The error had created a new file in the boot/grub directory called: /boot/grub/grub.cfg.new looked at line 257 in this file. This line had only one character causing the problem a: }

Further research found that this error related to an open } that did not have an earlier { the file from line 250 look like this:

     fi
     echo  'Loading Linux 4.15.0-99-generic ...'
     linux  /boot/vmlinuz-4.15.0-99-generic root=UUID=f75e24e4-223e-4594-9392-db651308fc71
     echo  "Loading initial ramdisk ...'
     initrd /boot/initrd.img-4.15.0.99-generic
  }
}

### END /etc/grub.d/10_linux ###

This was being generated by the script in the file: /etc/grub.d/10_linux

at the end of this file there was the lines:

# If at least one kernel was found, then we need to 
# add a closing '}' for the submenu command.
if [ x"$is_top_level" !=xtrue ]; then
echo '}'
fi

so the obvious thing to do was to comment out (using #) the part of the script that was causing this problem, as so:

#if [ x"$is_top_level" !=xtrue ]; then
#echo '}'
#fi

save the modifications to the file, then:

sudo update-grub

And no errors! Why the problem happened I can not say. Getting a sustainable dual boot working on this MSI machine has been a nightmare. Currently using rEFInd, and having two Windows OS's on separate SSD's does not help matters.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.