FS#37904 - [grub] 10_linux generates submenu without closing bracket with grub-mkconfig

Attached to Project: Arch Linux
Opened by Felix Yan (felixonmars) - Monday, 25 November 2013, 10:24 GMT
Last edited by Tobias Powalowski (tpowa) - Saturday, 21 December 2013, 20:50 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 48
Private No

Details

Description:
I'm getting error trying to run grub-mkconfig, with latest grub in [testing]. A quick and dirty workaround works for me, though I don't know how to fix it properly.

Details:

In file /etc/grub.d/10_linux, I didn't really get it here:

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

So it adds "}" only when /etc/arch-release doesn't exist? But that file was included in [core]/filesystem 2013.05-2

I just removed those ifs and tried grub-mkconfig again, it now works flawlessly.

Additional info:
* package version(s)
testing/grub 1:2.00.1282.g5ae5c54-1

* config and/or log files etc.
Submenu that misses "}":

submenu 'Advanced options for Arch Linux' $menuentry_id_option 'gnulinux-advanced-...' {

Error:

error: out of memory.
error: syntax error.
error: Incorrect command.
error: syntax error.
Syntax error at line 393
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.done

(line 393 was actually end of the file, which indicates the missing bracket '}')
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Saturday, 21 December 2013, 20:50 GMT
Reason for closing:  Fixed
Additional comments about closing:  2.02-beta1
Comment by Keshav Amburay (the.ridikulus.rat) - Monday, 25 November 2013, 15:17 GMT
This issue seems to be occurring when submenu is NOT disabled in /etc/default/grub. For now disable submenu by adding "GRUB_DISABLE_SUBMENU=y" to /etc/default/grub and regenerate grub.cfg .
'
Making sure the fallback initramfs entry is also created by /etc/grub.d/10_linux file requires some non-upstream hackery which is done by https://projects.archlinux.org/svntogit/packages.git/tree/trunk/archlinux_grub_mkconfig_fixes.patch?h=packages/grub . This patch will work for submenu disabled scenario but MAY NOT work for submenu enabled scenario.

Unfortunately the fallback initramfs usage is something unique to Arch (and its derivatives) that is used by majority of linux distros out there and unlikely to be supported by default by upstream GRUB in grub-mkconfig and/or 10_linux .

EDIT: If any one has a better patch please submit it, or even better try to get it incorporated upstream. Upstream does not like distro specific hacks in its source, so any to-be-submitted patch should not be specific/limited to Arch (and/or its derivatives).
Comment by felix (fstirlitz) - Monday, 25 November 2013, 21:02 GMT
Here it is… The syntax seems to be correct for both settings. The patch also makes "core" kernels appear before "lts" ones.
   grub-git-archlinux.patch (4.8 KiB)
Comment by Jesse (techno-geek) - Friday, 06 December 2013, 23:14 GMT
Keshav's comment resolves it for me.
Comment by Dan Ziemba (zman0900) - Saturday, 07 December 2013, 04:10 GMT
Confirming that felix's patch works for me.

Edit: Actually there is one minor problem that may be related to the patch. Versions in the menuentry show up missing a dash.

Example for linux /boot/vmlinuz-linux-3.12.3-1
Actual: menuentry 'Arch Linux, with Linux 3.12.31 kernel'
Expected: menuentry 'Arch Linux, with Linux 3.12.3-1 kernel'
Comment by tolya (tchgefest) - Saturday, 07 December 2013, 13:18 GMT
What's?
sudo grub-mkconfig -o /boot/grub/grub.cfg
.

Comment by André Fettouhi (A.Fettouhi) - Sunday, 08 December 2013, 16:03 GMT
In my case Keshav's comment fixes

grub-mkconfig -o /boot/grub/grub.cfg

but when I run

grub-install --directory=/usr/lib/grub/i386-pc --target=i386-pc --boot-directory=/boot --recheck --debug /dev/sda
grub-install --directory=/usr/lib/grub/i386-pc --target=i386-pc --boot-directory=/boot --recheck --debug /dev/sdb

they both fail with gpt.mod missing.
Comment by Keshav Amburay (the.ridikulus.rat) - Monday, 09 December 2013, 19:19 GMT
@felix: I rebased my patch (currently used in the core/grub pkg) based on your patch, and I have submitted it to grub-devel http://lists.gnu.org/archive/html/grub-devel/2013-12/msg00143.html for inclusion in upstream grub so that it is easier for pkg maintainer.
Comment by WD (warden989) - Tuesday, 10 December 2013, 11:09 GMT
I continue to have the same problem with the core/grub x86_64 pkg

I think that the guards of these ifs (the last two in /etc/grub.d/10_linux) contradicts the comments above them.

Changing the lines with
if ! test -e "/etc/arch-release"; then
to
if test -e "/etc/arch-release"; then

just let grub-mkconfig work fine.
Comment by Daniel Kao (dkao) - Friday, 13 December 2013, 05:08 GMT
That if guard is fine, the patch is just setting an outdated variable when creating the arch-specific linux_entry.
   archlinux_grub_mkconfig_fixes... (0.4 KiB)
Comment by Keshav Amburay (the.ridikulus.rat) - Friday, 13 December 2013, 20:24 GMT
@ALL: I got tired of https://projects.archlinux.org/svntogit/packages.git/tree/trunk/archlinux_grub_mkconfig_fixes.patch?h=packages/grub issues with grub-mkconfig changes by upstream, so I put together a different script that should be copied to /etc/grub.d/10_archlinux and then grub-mkconfig should be run. This script generates Arch Linux kernel part of grub.cfg similar to Archboot ISO Setup script's do_grub_config() function. This script can also be copied to /etc/grub.d of other distros (in case of dual-boot) and that distro's grub-mkconfig will detect Arch kernels (provided /boot is common).

You can also run the script standalone and copy its output to /etc/grub.d/40_custom or /boot/grub/custom.cfg (GRUB 2.00+). This script does not rely on /etc/grub.d/10_linux (shipped by GRUB upstream), which is the actual script generating the linux boot entries part of grub.cfg .

Please test 10_archlinux script and give feedback. If it works properly, then we can ditch the whole patch except the GRUB_COLOR part (of the current patch), which can be split easily.
   10_archlinux (4.7 KiB)
Comment by Benjamin B. (sywesk) - Sunday, 15 December 2013, 18:52 GMT
@Keshav Your 10_archlinux did it for me.
Comment by Pawel (ISeeYou) - Tuesday, 17 December 2013, 11:44 GMT
I can confirm that the "GRUB_DISABLE_SUBMENU=y" option fixed the problem but @Keshav's 10_archlinux script did not work for me and grub-mkconfig has shown the same errors like the /etc/grub.d/10_archlinux was completely ignored.
Comment by Chris Down (chrisdown) - Friday, 20 December 2013, 04:27 GMT
Shouldn't this be at a higher priority/severity, considering it breaks all new GRUB installations, which is likely to affect most people going through the installation guide?
Comment by Tom Yan (tom.ty89) - Friday, 20 December 2013, 10:48 GMT
I think it should be rolled back to older version if there isn't a very assuring solution.
Btw, why is Arch using a snapshot version of grub? I know it's supposed to be bleeding-edge but even ffmpeg is a "stable" version. Not to mentioned that it's using a LEGACY VERSION OF APACHE.
The policy of Arch is getting so inconsistent!

Loading...