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
signature.asc
Description: This is a digitally signed message part.
