bug#54945: installer should have a no-graphics boot option

[raingloom]

On Fri, 15 Apr 2022 22:44:58 +0200
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

> On Fri, Apr 15, 2022 at 01:36:36PM +0200, raingloom wrote:
> > On Fri, 15 Apr 2022 08:55:43 +0200
> > "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:  
> > > I’ve previously had such issues with AMD Radeon GPUs, so we added
> > > it to the blacklist in gnu/system/install.scm:  
> > AFAIK it's a Radeon machine, so that may be the problem.  
> 
> Could you check if editing the boot options in GRUB to
> modprobe.blacklist=amdgpu makes nomodeset unnecessary?  Then
> modprobe.blacklist=radeon,amdgpu could be added to
> gnu/system/install.scm.
> 
> Other than that, I believe the installer would eventually have shown
> up with nomodeset and 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.
> 
> 
> > I have no idea how long the GUI is expected to take to show up,
> > maybe it would have appeared if I just waited even more, but there
> > was no indication of anything happening.  
> 
> It takes some time on my old laptop, but it is an old laptop.
> 
> All that aside, I believe uvesafb-service-type or
> kernel-module-loader-service-type can be added to any config.scm to
> show i3 or any desktop environment using software rendering.  It just
> consumes much CPU.  The installer could add it to the config.scm
> automatically, however it may not be what the user wants and it seems
> there is no way to auto-detect the appropriate resolution (v86d has a
> resolution checker, but it maybe cannot be run early in the boot).
> 
> Regards,
> Florian

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.