[gentoo-user] Irritating ~5s pause whilst booting with grub

[gentoo-user] Irritating ~5s pause whilst booting with grub

[Alan Mackenzie]

Hello, Gentoo,

This isn't a critical problem, but it's a little irritating.

When my machine boots, it first displays the BIOS invitation to type F2,
then starts grub.  Grub spends about 5 seconds with a blank screen, and
an underline cursor dotting about randomly in the top left hand area of
the screen, possibly some 25 x 80 area (whatever that might mean).  Only
then does it display its boot menu.

My machine is a standard up to date (18 months old) AMD-64 Ryzen machine
booting from EFI.

Looking into my /boot/grub/grub.conf, I've got:

    # Menu timeout
    timeout=10

: the irritating delay is ~5 seconds, so this can't be due to anything
dependant on that timeout setting; and

    # If we have a font available, start graphical output.
    if loadfont unifont; then
            echo "Loading unifont"
            # Output resolution for GRUB (eg. 1024x768 or 'auto').
            gfxmode=auto

            # Output resolution for Linux (VESAFB only).
            # 'keep' means use the same resolution as GRUB.
            # For other framebuffer drivers, pass a resolution using the
            # video= kernel param.
            gfxpayload=keep

            # Load all video drivers.
            insmod all_video

            # Switch to graphical output.
            terminal_output gfxterm
    fi

.  I'm wondering if my problem has something to do with the 'insmod
all_video', and then the system is trying out lots of different video
modes, each with a long timeout, before finally finding the correct one.
Would, perhaps, a more specific value of gfxmode help?

Also, as an aside, grub has 878 .c files and a user's info guide
weighing in at 300 kbytes.  It's great that the documentation exists,
but 300k?  This is all just for a boot system.  There are 255 loadable
modules.  (For comparison, the Emacs core has just 132 .c files.)  I
can't help feeling that this has got horribly out of hand.

I just need a program to boot the machine, that's all - I don't really
care what colours it uses, what fonts it uses, it only needs to read a
GPT partition table, and boot on utterly standard hardware.  I
appreciate having a menu of different boot options (in my case, this
just means different kernel versions), but everything else is just
aesthetic sugar.  Too much sugar isn't good for one.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Irritating ~5s pause whilst booting with grub

[Mick]

[-- Attachment #1: Type: text/plain, Size: 3582 bytes --]

On Monday, 22 October 2018 21:03:54 BST Alan Mackenzie wrote:
> Hello, Gentoo,
> 
> This isn't a critical problem, but it's a little irritating.
> 
> When my machine boots, it first displays the BIOS invitation to type F2,
> then starts grub.  Grub spends about 5 seconds with a blank screen, and
> an underline cursor dotting about randomly in the top left hand area of
> the screen, possibly some 25 x 80 area (whatever that might mean).  Only
> then does it display its boot menu.
> 
> My machine is a standard up to date (18 months old) AMD-64 Ryzen machine
> booting from EFI.
> 
> Looking into my /boot/grub/grub.conf, I've got:
> 
>     # Menu timeout
>     timeout=10
> 
> : the irritating delay is ~5 seconds, so this can't be due to anything
> dependant on that timeout setting; and

Yes, this is the time GRUB will wait for keyboard input before booting the 
default menu entry.


>     # If we have a font available, start graphical output.
>     if loadfont unifont; then
>             echo "Loading unifont"
>             # Output resolution for GRUB (eg. 1024x768 or 'auto').
>             gfxmode=auto

GRUB will select some resolution your hardware can accommodate.  I guess this 
means probing for suitable resolutions and this is likely to take the ~5 
seconds you have noticed.

You could specify something suitable and to check what GRUB can use, run the 
command 'videoinfo' in GRUB.


>             # Output resolution for Linux (VESAFB only).
>             # 'keep' means use the same resolution as GRUB.
>             # For other framebuffer drivers, pass a resolution using the
>             # video= kernel param.
>             gfxpayload=keep
> 
>             # Load all video drivers.
>             insmod all_video
> 
>             # Switch to graphical output.
>             terminal_output gfxterm
>     fi
> 
> .  I'm wondering if my problem has something to do with the 'insmod
> all_video', and then the system is trying out lots of different video
> modes, each with a long timeout, before finally finding the correct one.
> Would, perhaps, a more specific value of gfxmode help?

The all_video refers to the GRUB drivers available for video.  Have a look in 
/boot/grub/video.lst to see what GRUB has in there, or in /usr/lib64/grub/
x86_64-efi/video.lst and try the one you prefer GRUB to load.

 
> Also, as an aside, grub has 878 .c files and a user's info guide
> weighing in at 300 kbytes.  It's great that the documentation exists,
> but 300k?  This is all just for a boot system.  There are 255 loadable
> modules.  (For comparison, the Emacs core has just 132 .c files.)  I
> can't help feeling that this has got horribly out of hand.

I share your feelings here.  I don't use GRUB unless I *have* to multiboot, 
which these days is a rarity.


> I just need a program to boot the machine, that's all - I don't really
> care what colours it uses, what fonts it uses, it only needs to read a
> GPT partition table, and boot on utterly standard hardware.  I
> appreciate having a menu of different boot options (in my case, this
> just means different kernel versions), but everything else is just
> aesthetic sugar.  Too much sugar isn't good for one.

You could use the the kernel EFI stub to boot directly from the EFI partition, 
without the intermediation of a boot manager.[1]  The only problem with this 
approach is you will need to enter your UEFI boot menu to select another 
kernel image to boot with, if the default kernel selection is not your 
requirement.

[1] https://wiki.gentoo.org/wiki/EFI_stub_kernel

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Irritating ~5s pause whilst booting with grub

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

On Mon, 22 Oct 2018 20:03:54 +0000, Alan Mackenzie wrote:

> I just need a program to boot the machine, that's all - I don't really
> care what colours it uses, what fonts it uses, it only needs to read a
> GPT partition table, and boot on utterly standard hardware.  I
> appreciate having a menu of different boot options (in my case, this
> just means different kernel versions), but everything else is just
> aesthetic sugar.  Too much sugar isn't good for one.

Use a UEFI boot manager, which is much simpler than GRUB. If you use
systemd you already have one if you installed it with USE="gnuefi".
Otherwise use the standalone version, systemd-boot. Or you can use
refind, but that is a bit more sugary.


-- 
Neil Bothwick

I'm not anti-social, I'm just not user friendly

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Irritating ~5s pause whilst booting with grub

[Peter Humphrey]

On Tuesday, 23 October 2018 22:08:43 BST Neil Bothwick wrote:

> Use a UEFI boot manager, which is much simpler than GRUB. If you use
> systemd you already have one if you installed it with USE="gnuefi".
> Otherwise use the standalone version, systemd-boot. Or you can use
> refind, but that is a bit more sugary.

Agreed. I was forced into it when I couldn't get grub to boot on this machine, 
then new. I've never been so relieved to see the back of any program as grub.

-- 
Regards,
Peter.

Re: [gentoo-user] Irritating ~5s pause whilst booting with grub

[Alan Mackenzie]

Hello, Mick.

On Tue, Oct 23, 2018 at 18:21:08 +0100, Mick wrote:
> On Monday, 22 October 2018 21:03:54 BST Alan Mackenzie wrote:
> > Hello, Gentoo,

> > This isn't a critical problem, but it's a little irritating.

> > When my machine boots, it first displays the BIOS invitation to type F2,
> > then starts grub.  Grub spends about 5 seconds with a blank screen, and
> > an underline cursor dotting about randomly in the top left hand area of
> > the screen, possibly some 25 x 80 area (whatever that might mean).  Only
> > then does it display its boot menu.

> > My machine is a standard up to date (18 months old) AMD-64 Ryzen machine
> > booting from EFI.

> > Looking into my /boot/grub/grub.conf, I've got:

> >     # Menu timeout
> >     timeout=10

> > : the irritating delay is ~5 seconds, so this can't be due to anything
> > dependant on that timeout setting; and

> Yes, this is the time GRUB will wait for keyboard input before booting the 
> default menu entry.


> >     # If we have a font available, start graphical output.
> >     if loadfont unifont; then
> >             echo "Loading unifont"
> >             # Output resolution for GRUB (eg. 1024x768 or 'auto').
> >             gfxmode=auto

> GRUB will select some resolution your hardware can accommodate.  I guess this 
> means probing for suitable resolutions and this is likely to take the ~5 
> seconds you have noticed.

> You could specify something suitable and to check what GRUB can use, run the 
> command 'videoinfo' in GRUB.

Thanks, I've done that.  It showed that Grub was running at 1024x768 on
driver Efi Gop.  So I plugged those values into my grub.cfg and cut down
video.lst to include only that one driver.

This didn't help - I still got the ~5s delay.

> >             # Output resolution for Linux (VESAFB only).
> >             # 'keep' means use the same resolution as GRUB.
> >             # For other framebuffer drivers, pass a resolution using the
> >             # video= kernel param.
> >             gfxpayload=keep

> >             # Load all video drivers.
> >             insmod all_video

> >             # Switch to graphical output.
> >             terminal_output gfxterm
> >     fi

> > .  I'm wondering if my problem has something to do with the 'insmod
> > all_video', and then the system is trying out lots of different video
> > modes, each with a long timeout, before finally finding the correct one.
> > Would, perhaps, a more specific value of gfxmode help?

> The all_video refers to the GRUB drivers available for video.  Have a look in 
> /boot/grub/video.lst to see what GRUB has in there, or in /usr/lib64/grub/
> x86_64-efi/video.lst and try the one you prefer GRUB to load.

Tried that.  Then I tried

                gfxmode=text,1024x768

, in the off chance it might use the 80x25 character terminal which is
baked into the video HW.  This didn't work, either.

Why does Grub need to initialise a graphical bit map terminal when the
80x25 simply exists?
 
> > Also, as an aside, grub has 878 .c files and a user's info guide
> > weighing in at 300 kbytes.  It's great that the documentation exists,
> > but 300k?  This is all just for a boot system.  There are 255 loadable
> > modules.  (For comparison, the Emacs core has just 132 .c files.)  I
> > can't help feeling that this has got horribly out of hand.

> I share your feelings here.  I don't use GRUB unless I *have* to multiboot, 
> which these days is a rarity.


> > I just need a program to boot the machine, that's all - I don't really
> > care what colours it uses, what fonts it uses, it only needs to read a
> > GPT partition table, and boot on utterly standard hardware.  I
> > appreciate having a menu of different boot options (in my case, this
> > just means different kernel versions), but everything else is just
> > aesthetic sugar.  Too much sugar isn't good for one.

> You could use the the kernel EFI stub to boot directly from the EFI partition, 
> without the intermediation of a boot manager.[1]  The only problem with this 
> approach is you will need to enter your UEFI boot menu to select another 
> kernel image to boot with, if the default kernel selection is not your 
> requirement.

Thanks.  But it took me several evenings of sweating and cursing to get
Grub working ~18 months ago, and I'm loathe to go through the same again
to get a different booter working.  I think, sooner or later, I'm going
to have to reacquaint myself with my installation CD, and do this, though.

> [1] https://wiki.gentoo.org/wiki/EFI_stub_kernel

> -- 
> Regards,
> Mick

-- 
Alan Mackenzie (Nuremberg, Germany).