On Fri, 15 Apr 2022 22:44:58 +0200 "pelzflorian (Florian Pelz)" <[email protected]> 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)" <[email protected]> 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.
