Grub throwing a "error: no symbol table"

English Install/Boot/Login
#1

Several weeks ago I noticed on my laptop that right when grub attempts to boot the kernel, it pauses and throws up the messages “error: no symbol table” along with “press any key to continue” Pressing any key doesn’t seem to do anything different then if you don’t press any key – i.e. after a few seconds, booting of the kernel commences.

So, its only a momentary pause from usual and expected action, but its not something that has been corrected (“automagically”) as I was hoping upon installation of more recent kernels (dot or minor revisions). A quick search through the forum only finds this old thread with the same error: https://forums.opensuse.org/showthread.php/483637-Error-on-grub2-boot-boots-fine-however

Will turn to google shortly. Anyone else seeing this or seen it before?

#2

Well, it got mentioned here recently:
https://forums.opensuse.org/showthread.php/520401-logon-loop-after-software-updates-to-4-7-5

No idea what it causes it yet though…

#3

Ahh, thanks. Skimmed through it. No VM involved in my case. I’ll rebuild the grub menu in a bit to see if there is any effect.

#4

When watching more closely, last night, I noticed that the message is actually generated right after Grub starts. It flashes by so quickly, its hard to spot, but what is seen is:


Grub loading
Welcome to Grub
error: no symbol table

One usually can see the first two lines, but the third error line is literally visible only for a fraciton of a second before the screen is replaced by the Grub menu, with all your kernel and OS choices to boot etc.
If you manually make a selection in the menu or allow the grub time out to proceed on its own to end up booting the default selection, then the terminal like window opens up and it reports

error: no symbol table.
loading linux blah blah blah ...
loading initial ramdisk ...

Press any key to continue

And, as I mentioned yesterday, it doesn’t seem to matter if you press any key or just wait, as resumption of the boot occurs after a several second (maybe 4 or 5s ?) pause.

#5

I have been having this exact error. Isn’t it the case the a “no symbol table” message occurs when debug C++ code is used and no symbol table is present for the debugger?

So, could it be the case that some debug code accidentally found its way into grub?

#6

No.
You’d rather get something like “no debug symbols found” if you run it in gdb.

So, could it be the case that some debug code accidentally found its way into grub?

No.
At least it wouldn’t cause this error message.

#7

Btw, I found this patch which looks like it would fix it:
https://lists.gnu.org/archive/html/grub-devel/2016-02/msg00011.html

#8

This patch is included in 2.02beta3 which is included in TW.

#9

Ok, thanks.

And FTR, this doesn’t happen here in an uptodate Tumbleweed VirtualBox VM, I just checked.

Maybe they are not using openSUSE’s grub2 at all?
AFAIK, that “Press any key to continue” message is even removed in openSUSE, isn’t it?

There may be some non-openSUSE boot code installed I suppose, in the MBR e.g.
I would suggest to reinstall the boot loader, just opening YaST->System->Boot Loader and clicking OK should do that.
Most google results I found also suggested this.

#10

No; this message is printed by grub2 when e.g. command in menu entry returns failure, before it attempts to boot. But the only two places I see ‘no symbol table’ in current grub2 is in efiemu and BSD loader. efiemu is used only with OS X loader (so we boot in CSM, then load EFI emulation to boot OS X loader). So I am rather confused as well. I would be interested in seeing grub.cfg with indication which menu entry shows this error.

#11

Yeah, while I didn’t dig through the code, I did come across reference to both of those through googling. Neither struck me as being likely.

I would be interested in seeing grub.cfg with indication which menu entry shows this error.
I’ll post it tomorrow (before I carry out the restoration process discussed below)

Ahh, that’s a possibility. I do recall restoring grub a while back, but I believe it was to my desktop workstation. Though, maybe I’m misremembering and it was for the laptop. In any regard, I have no recollection of what source I used to do that, but its quite possible I had used a third party ISO like systemrescue etc.

I would suggest to reinstall the boot loader, just opening YaST->System->Boot Loader and clicking OK should do that.
Most google results I found also suggested this.
Yeah, google seem to suggest that the quick an easy solution was to just reinstall/restore grub, so I was planning to do that this weekend.

#12

[quote=“Tyler_K,post:11,topic:121445”]

I’ll post it tomorrow [/QUOTE]
The entire file contents can be found at this susepaste link: http://paste.opensuse.org/21013904

As you can see, its a simple config, with only openSUSE installed on the machine. All boot entries produce the error.

(before I carry out the restoration process discussed below)
I’ll hold off on this for the moment to see if anything further can be gleaned

#13

Do you also see this error before menu is displayed (although it may disappear too fast to be noticed)? You can also add “sleep 5” after “load_video” to have time to read it if this is the same error that was mentioned earlier.

Also please edit one menu entry and add “echo name-of-command” before each line and “sleep 5” after each line so you see which line is executed and have time to read any error that it displays. Thank you.

#14

Yep; see first half of this post: https://forums.opensuse.org/newreply.php?do=newreply&p=2797211
Adding the sleep is a good suggestion – will see if there might be anything else that can be spotted.

Also please edit one menu entry and add “echo name-of-command” before each line and “sleep 5” after each line so you see which line is executed and have time to read any error that it displays. Thank you.
okay, will do, but has to wait until tomorrow. will let ya know what transpires.

#15

The “error: no symbol table” gets thrown right after it echoes load video

menuentry 'openSUSE Tumbleweed'  --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-db2c5f25-8673-4c85-8916-8bd88d488c57' {
    echo load video
    load_video
    sleep 5
    echo set gfxpayload
    set gfxpayload=keep
    sleep 5
    echo insmod gzio
    insmod gzio
    sleep 5
    echo insmod part_msdos
    insmod part_msdos
    sleep 5
    echo insmod ext2
    insmod ext2
    sleep 5
    echo root=
    set root='hd0,msdos2'
    sleep 5
    echo if then else
    if  x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 --hint='hd0,msdos2'  db2c5f25-8673-4c85-8916-8bd88d488c57
    else
      search --no-floppy --fs-uuid --set=root db2c5f25-8673-4c85-8916-8bd88d488c57
    fi
    sleep 5
    echo    'Loading Linux 4.8.3-1-default ...'
    linux    /boot/vmlinuz-4.8.3-1-default root=UUID=db2c5f25-8673-4c85-8916-8bd88d488c57
    sleep 5
    echo    'Loading initial ramdisk ...'
    initrd    /boot/initrd-4.8.3-1-default
    sleep 5
}
#16

OK, so this is the same problem that was mentioned already. I do not see it in current TW (even after removing grub.cfg and loading all_video manually). The problem was caused by compiling grub2 with newer versions of binutils. What version grub2 prints when you enter CLI (`c’ when in grub2 menu)?

Hmm … actually the problem would be caused by having new version of all_video.mod in /boot/grub2 but old version of core.img as stage1.5 (because code that emits this warning belongs to grub2 kernel). Not sure how can we check for it. Yes, it will obviously be fixed by reinstalling GRUB2, but it also means for some reasons this does not happen during grub2 update and that is the real bug.

Could you please run https://github.com/arvidjaar/bootinfoscript and make result available? Thank you.

#17

Okay, thanks

What version grub2 prints when you enter CLI (`c’ when in grub2 menu)?
2.02~beta3

Hmm … actually the problem would be caused by having new version of all_video.mod in /boot/grub2 but old version of core.img as stage1.5 (because code that emits this warning belongs to grub2 kernel). Not sure how can we check for it. Yes, it will obviously be fixed by reinstalling GRUB2, but it also means for some reasons this does not happen during grub2 update and that is the real bug.

Could you please run https://github.com/arvidjaar/bootinfoscript and make result available? Thank you.
Follow the rabbit: https://paste.opensuse.org/17192002

#18

OK, so you have grub2 installed both in MBR and sda2. What is content of /etc/default/grub_installdevice?

#19

The following:

/dev/disk/by-id/wwn-0x5000000000001681-part2
activate
generic_mbr
#20

As expected. Here is what happened. Your system is configured to install grub2 in partition and use generic code in MBR. So when grub2 is updated, system script will update core.img (stage1.5) code only in partition, because that is what your configuration says. At the same time you also have grub2 installed in MBR, and it took over booting. core.img in MBR still points to the same /boot/grub2, which gets updated when grub2 package is updated.

At some point you got new grub2 package where all_video.mod was lacking symbol table (because it was rebuilt using new version of binutils). During package update new all_video.mod was installed in /boot/grub2, and new version of core.img was generated and installed in /dev/sda2 - but core.img in MBR remained untouched.

How grub2 was installed in MBR we do not know. I supposed at some point you run “grub2-install /dev/sda” directly.

That is exact reason why I always recommend to use “update-bootloader --reinit” to recover grub2 installation - because update-bootloader is aware of system configuration and will use the same bootloader locations that are configured in YaST. Unfortunately far too often you see advice to run grub-install directly - and this without person who advises having checked where bootloader was (expected to be) located.

You are lucky that it ended up in harmless message. This could well be the reason of multiple mysterious “my system stopped booting after update” threads.