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