On Sat, Apr 16, 2022 at 07:48:52PM +0200, raingloom wrote: > On Sat, 16 Apr 2022 19:31:15 +0200 > "pelzflorian (Florian Pelz)" <[email protected]> wrote: > > > On Sat, Apr 16, 2022 at 05:32:38PM +0200, raingloom wrote: > > > On Fri, 15 Apr 2022 22:44:58 +0200 > > > "pelzflorian (Florian Pelz)" <[email protected]> wrote: > > > >[…] > > > > I believe uvesafb makes the graphics work on any > > > > x86_64 or x86 machine, so no save-graphics GRUB entry is needed. > > > > But maybe I’m wrong and uvesafb isn’t a panacea. > > > >[…] > > > Hmm, it did end up working, even without the amdgpu trick. Finally > > > had an excuse to try the TUI installer. > > > I guess we can close this for now, but I still think that a safe > > > graphics mode could be a good idea. > > > > Is there reason to believe installer’s graphics don’t work on some PC? > > I have laptops with fried GPUs that still somewhat work with nomodeset. > For rescue images, a no-graphics or nomodeset graphics mode is > definitely useful, because graphics is often the reason booting is > broken.
I presume this would need changes to the API described at `info "(guix)Bootloader Configuration"` to generate each boot.cfg menu-entry repeatedly with different boot options, or it would need a custom copy of grub-bootloader with said changes to boot.cfg generation, or a new feature to, as you wrote, include multiple operating system fields in the same image. Anyway, I wouldn’t be implementing it. I will close this bug report in a few days. Regards, Florian
