Since a longer time grub already supports efi-based systems. In regards to supported resolutions, the comment for GRUB_GFXMODE does only mention `vbeinfo` for grub-pc. We should mention `videoinfo` for grub-efi as well. Reproducible: Always Steps to Reproduce: grep -m 1 -B 3 GRUB_GFXMODE /etc/default/grub Actual Results: # The resolution used on graphical terminal. # Note that you can use only modes which your graphic card supports via VBE. # You can see them in real GRUB with the command `vbeinfo'. #GRUB_GFXMODE=640x480 Expected Results: # The resolution used on graphical terminal. # Note that you can use only modes which your graphic card supports via VBE. # You can see them in real GRUB with the command `vbeinfo' for grub-pc, or `videoinfo` for grub-efi respectively. #GRUB_GFXMODE=640x480
Created attachment 898275 [details, diff] Update grub default comment on GRUB_GFXMODE to contain videoinfo for grub-efi N/A
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=81e838bcee091ab342610d59feac08954a7667e1 commit 81e838bcee091ab342610d59feac08954a7667e1 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2024-08-04 15:06:03 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-08-04 15:06:03 +0000 sys-boot/grub: update GRUB_GFXMODE description Closes: https://bugs.gentoo.org/936596 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-boot/grub/files/grub.default-4 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
I had a modified /etc/default/grub file since years, and I didn't realize that the above commit since it modified whatever the default contents for that file were, the newly modified one has now overwrote /etc/default/grub entirely with its default contents. It's in /etc/ shouldn't this be protected by default? Perhaps something else happened since I got this message after update: * IMPORTANT: 3 config files in '/etc' need updating. * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS * sections of the emerge man page to learn how to update config files. * After world updates, it is important to remove obsolete packages with * emerge --depclean. Refer to `man emerge` for more information. however running `dispatch-conf` manually after update just exited with no prompts or anything, as if there were in fact no files to update. As if, something already updated them and chose the `use new` somehow. This would explain why the overwrite happened, hmmm...
(In reply to Emanuel Czirai from comment #3) Yes, if you had previously modified the file it should have been preserved by FEATURES="config-protect-if-modified". I didn't do anything special here. If the file got overwritten, it is either a bug in Portage or user error.
tracked down my issue to: * dispatch-conf ignores the exit code of 'diff', so if it's exit code 2 aka trouble, it doesn't care, as long as the output is of length non 0 it thinks the files are modified. `Exit status is 0 if inputs are the same, 1 if different, 2 if trouble.` * somehow same_cvs in /usr/lib/python-exec/python3.12/dispatch-conf became true, and the /etc/dispatch-conf.conf setting replace-cvs=yes was at its =yes default, thus it silently replaced the new files. This is at least 50% my fault for using a script wrapper for `diff` which happens to output some stuff to stderr(and apparently stdout too) even when exit code is 2, else dispatch-conf wouldn't have thought the len of the output is non zero (it mixes both stdout and stderr when counting it). It's not 100% clear but apparently /etc/dispatch-conf.conf setting 'diff=' is ignored as it won't use a 'diff' command that I specify there. But maybe I'm missing something. Please don't ask me to make a new bug report:) I'll work around this locally.
