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

jnachtigall · November 7, 2018, 7:50pm

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

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

mk24 · November 7, 2018, 9:36pm

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

mj5030 · November 8, 2018, 1:11am

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.

mk24 · November 8, 2018, 5:53am

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.

jnachtigall · November 9, 2018, 7:32am

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 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?!)

lleachii · November 9, 2018, 11:18am

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

jnachtigall · November 9, 2018, 12:09pm

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>.

Borromini · November 9, 2018, 12:50pm

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?

mk24 · November 9, 2018, 2:13pm

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.

jnachtigall · November 9, 2018, 4:00pm

@mk24
Yeah 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).

Borromini · November 9, 2018, 4:06pm

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.

tmomas · November 19, 2018, 4:12pm

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