On my 4K monitor with Intel graphics the GRUB menu is extremely slow, when the theme is used. With the new black and white theme though it's a bit better than with the old blue theme. Every second counting down needs additional time to calculate the graphics and switching from one boot option to the next one can cause a delay of several seconds per item. I've read that this can be caused by the use of scrollbars. See here page 73: https://drive.google.com/file/d/0B82343FTJphIbElHUGVac1hBZnc/view Maybe the progress bars are the problem here? It's at the moment still a legacy DOS system and I haven't changed anything about the GRUB files except for a briefer timeout. Reproducible: Always
If it was the progressbar I think we'd see more reports of this. I have however seen this temporarily at some point, since it went away on its own after some updates I am rather content in saying that this is either a bug in the grub config or grub itself. Please attach the following files to the bug report - /boot/grub/grub.cfg - /boot/grub/grubenv - /etc/default/grub Additionally zip up and attach all files in /etc/grub.d (alternatively attach the files individually but I expect there to be a bunch of them). Once you are sure you've attached all files please try the following. On a terminal run `sudo update-grub`, then reboot and see if that fixed the problem. If it did not fix the problem delete the following directories and files: - /boot/grub/themes/breeze/progress_bar/ - /boot/grub/themes/breeze/terminal/ - /boot/grub/themes/breeze/oxygenmono10.pf2 and again `sudo update-grub`, then reboot and see if that fixed the problem. If it did not fix the problem edit the file /boot/grub/themes/breeze/theme.txt and find the bit where it says > # Show the boot menu > + boot_menu { below that insert a new line with this content: > scrollbar = false save the file and again `sudo update-grub`, then reboot and see if that fixed the problem. If it did not fix the problem edit the same file again and remove the line again. Towards the end of the file you'll find two "progress_bar {}" blocks. Remove the bottom one, save the file and again `sudo update-grub`, then reboot and see if that fixed the problem. If it did not fix the problem edit the same file again and remove the other "progress_bar {}" block as well, save, `sudo update-grub`, reboot and see if that fixed the problem. If none of the above steps fixed the problem you can restore your theme to the defaults with the command `sudo apt install --reinstall grub-theme-breeze` and I'll have to take a closer look at your config. If one of the steps fixed the problem, please add a comment here. Additionally restore the default with the command `sudo apt install --reinstall grub-theme-breeze` followed by `sudo update-grub` and reboot to see if the problem remains fixed. Please add a comment about this as well.
Thanks for the comprehensive guide. Will do the steps it in a few days when I'm back on my 4K monitor.
Created attachment 101717 [details] requested boot and config files Tried out all your steps, problem wasn't solved. After looking at it a bit more, I also don't think anymore it's because of the progress bar. The boot screen is rendered letter by letter and it doesn't matter if the countdown is actually running or was canceled (by pressing arrow down). To me, it seems to be the fault of the GRUB theming engine itself. It's very inefficient and for example Fedora after they had tried it out, gave up on it directly as documented here: https://bugzilla.redhat.com/show_bug.cgi?id=822123 Maybe they reintroduced it later though with a trick? The alternative would be to only use a different background instead of a whole theme.
Status changed back to UNCONFIRMED, since infos have been given.
Well, if that is the case then I guess you should be filing a bug with GRUB, not the theme?
Of course somebody else has reported it already: http://savannah.gnu.org/bugs/?46133 There is no mention of a theme as the issue, but one of the links is to the redhat bug, I posted earlier. If this is a common problem, as a workaround until it is solved I would prefer to not use a theme at all per default. An unusable slow GRUB in case of high resolution displays is worse than having a not so nice looking GRUB. But I'm currently the only one complaining here, so as long as there are no other people I'm fine with waiting on a fix by GRUB (which, when I look at their bugtracker could be forever...). I can disable the theme on my PC in the meantime.
Sure if it is laggish then it shouldn't be themed. That too is something that ought to be addressed in GRUB though, as only GRUB knows if rendering is obscenely slow. Now this doesn't seem particularly common given you are the only person who complained. Best I can do is make distributions aware of this. If you think that we should not advise using the theme based on the rendering lag, that is something you want to take up with the VDG. Personally I advise whoever has the problem to simply disable the theme. It's basically having shit UX for everyone (no theme) or shit UX for a select few (laggish rendering).
I must say, Grub is also absurdly slow on my machine, especially with high resolution screens (4K) the menu takes multiple seconds(!) to draw and repaint. I never bothered to complain, though, as I hardly use or see the menu :)
If everyone used refind we'd all be happier for it ;)
I'm interested whether this effect is true when using other grub themes? Because if it is, it's something way bigger than KDE/Plasma and something that would make sense to ask around about since many distros and DE's also provide their own themed grub. If on the other hand it isn't then obviously something is terribly wrong in OUR grub theme that needs figuring out.