[Solved] Boot "hangs" on 'LEDE' item in grub menu on x86 (no grub 'timeout')

I've been using LEDE Reboot 17.01.4 on x86_64 hardware (a Intel Celeron J1900 4x1GbE device). It worked without a problem for a year. Now after power on/off it did not boot anymore.

Couldn't ping the device or anything, so eventually I attached a monitor to the VGA port. It turned out that it "hangs" indefinitely at the grub menu prompt listing:

[*] LEDE
[ ] LEDE failsafe

After attaching a keyboard and pressing <ENTER> (so it boots the default LEDE item) the system boots again and works flawlessly. Now I am not sure why this happened because it booted without interaction (which is what I want) for the last year...

Now I search the docs and forum and come across the post [solved] X86 and x86_64 generic doesn't start headless which suggests that there should be a /boot/grub/grub.cfg file on the device to which a timeout should be added. However there's no such /boot/ directory on the system:

# ls -l /
drwxr-xr-x    2 root     root          4096 Jun  4 17:11 bin
drwxr-xr-x    6 root     root          2680 Nov  7 19:59 dev
drwxr-xr-x   19 root     root          4096 Oct 18  2017 etc
drwxr-xr-x   10 root     root          4096 Oct 18  2017 lib
lrwxrwxrwx    1 root     root             3 Oct 17  2017 lib64 -> lib
drwx------    2 root     root          4096 Jan  1  1970 lost+found
drwxr-xr-x    2 root     root          4096 Oct 17  2017 mnt
drwxr-xr-x    2 root     root          4096 Oct 17  2017 overlay
dr-xr-xr-x   83 root     root             0 Nov  7 19:59 proc
drwxr-xr-x    2 root     root          4096 Oct 17  2017 rom
drwxr-xr-x    5 root     root          4096 Aug  8 10:34 root
drwxr-xr-x    2 root     root          4096 Oct 17  2017 sbin
dr-xr-xr-x   13 root     root             0 Nov  7 19:59 sys
drwxrwxrwt   16 root     root           440 Nov  7 20:20 tmp
drwxr-xr-x    8 root     root          4096 Jul 21 01:11 usr
lrwxrwxrwx    1 root     root             4 Oct 17  2017 var -> /tmp
drwxr-xr-x    4 root     root          4096 Oct 17  2017 www

Also I cannot find any grub related config in the luci web interface or inside /etc/ or /etc/config.

I am not sure how to proceed here, I defintely want an automatic (re)boot without having to press <ENTER> everytime :wink:

FWIW, here's my mount and df output (I have not fiddled with this, it's a pretty much default, vanilla system):

# mount
/dev/root on / type ext4 (rw,noatime,block_validity,delalloc,barrier,user_xattr)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)

# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root               258016     51504    201272  20% /
tmpfs                  1962576       536   1962040   0% /tmp
tmpfs                      512         0       512   0% /dev

Pretty sure there is a small boot partition which is mounted by GRUB, then unmounted (or rather, not re-mounted) once the kernel loads.

The file /boot/grub/grub.cfg should be generated by "grub-mkconfig" or "grub2-mkconfig". Is there a /etc/default/grub file, that you can add "GRUB_TIMEOUT=t" where t is the integer timeout in seconds? Then from there regenerate the grub.cfg using 'grub-mkconfig -o /boot/grub/grub.cfg'.

https://www.gnu.org/software/grub/manual/grub/grub.html#Configuration

The only problem is figuring out where the boot partition is and mounting it to write the grub.cfg, since it's not currently mounted in /boot.

It should be /dev/sda1. /dev/sda2 is the main root partition.

mount /dev/sda1 /mnt
ls /mnt

After making changes, umount the boot partition then you can reboot.
This is assuming you're using an ext4 type image. I'm not sure how the others work.

Thank a lot for the responses so far!

Is there a /etc/default/grub file

@mj5030 No.

mount /dev/sda1 /mnt

@mk24

This way I found the /boot/ directory now :slight_smile: But when looking at the current grub config this does have a timeout="5" parameter already (line 5):

# cat /mnt/boot/grub/grub.cfg 
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 --rtscts=off
terminal_input console serial; terminal_output console serial

set default="0"
set timeout="5"
set root='(hd0,msdos1)'

menuentry "LEDE" {
	linux /boot/vmlinuz root=PARTUUID=b3ade79d-02 rootfstype=ext4 rootwait console=tty0 console=ttyS0,115200n8 noinitrd
}
menuentry "LEDE (failsafe)" {
	linux /boot/vmlinuz failsafe=true root=PARTUUID=b3ade79d-02 rootfstype=ext4 rootwait console=tty0 console=ttyS0,115200n8 noinitrd
}

So I do not think that regenerating would help. Could there be any other reason why LEDE stops/waits at the grub menu?

As said it used to be working for year or so and I have not done anything software like on the device (there only used to be an update on the Fritzbox sitting between the LEDE router and the Internet, but I do not think this should have any influence on booting of LEDE, right?!)

By any chance, do you have any input device (e.g. a keyboard) or serial adapters connected to the router?

do you have any input device (e.g. a keyboard) or serial adapters connected to the router?

No, I never have or had. Even now I always unplug the keyboard from USB board after having pressed <ENTER>.

When I test-drive my x86/64 builds, there seems to be such a timeout in GRUB by default (it seems like you had that as well, before).

Have you tested 18.06 or master builds to see is the issue persists with those?

As I remember it from last year, that guy's problem was it was hanging trying to start up a serial interface on a machine with no serial hardware.

If your x86 box doesn't have serial hardware, remove the two lines at the top that set up a serial console.

1 Like

@mk24
Yeah :slight_smile: Uncommenting those first two lines fixes the problem:

#serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 --rtscts=off
#terminal_input console serial; terminal_output console serial

Device is booting automatically now again. Strange that this surfaced now, that is, one year after running withou any problem (including several reboots).

Should I file a bug somewhere about this? or would this be a waste of time as I'm running 17.04.01 (don't wanna upgrade just for testing).

If you can reproduce with 17.01.6 maybe it will be looked at, but reporting bugs on deprecated releases won't get any attention.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.