GNU bug report logs - #54945
installer should have a no-graphics boot option

Previous Next

To reply to this bug, email your comments to 54945 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: raingloom <raingloom <at> riseup.net>
To: Guix Bugs <bug-guix <at> gnu.org>
Subject: installer should have a no-graphics boot option
Date: Fri, 15 Apr 2022 02:17:49 +0200

Disclaimer: the last time I used an ISO for installing Guix was before
there was a graphical installer, so I'm not sure what it's expected to
look like now.

Anyways, I tried booting the latest release on a netbook, it failed
around/after KMS. Kernel seemed to lock up. No panic, no usable visible
log, not responding to Ctrl-Alt-Del, had to reboot with Sysrq-Alt-b.
I added nomodeset to the kernel command line in GRUB and managed to
boot it that way, although that still didn't immediately result in a
usable terminal, vtty1 only had a non-blinking cursor if I recall
correctly. Had to switch to vtty2 or above to do anything useful.

So, most users can't be expected to know about nomodeset, so there
should be a clearly labeled "safe graphics" mode, just like how some
other distros do it.

There have been other issues and discussions about generating multiple
configs from a single reconfigure, this would be an important and
practical use case for that.

IMHO the simplest thing is to just let config files return a list of
operating-system records and make that into a menu in GRUB. This would
also cover the use case of wanting a boot time choice in kernels.

Message #8 received at 54945 <at> debbugs.gnu.org (full text, mbox):

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: raingloom <raingloom <at> riseup.net>
Cc: 54945 <at> debbugs.gnu.org
Subject: Re: bug#54945: installer should have a no-graphics boot option
Date: Fri, 15 Apr 2022 08:55:43 +0200

On Fri, Apr 15, 2022 at 02:17:49AM +0200, raingloom wrote:
> Disclaimer: the last time I used an ISO for installing Guix was before
> there was a graphical installer, so I'm not sure what it's expected to
> look like now.
> 
> Anyways, I tried booting the latest release on a netbook, it failed
> around/after KMS. Kernel seemed to lock up. No panic, no usable visible
> log, not responding to Ctrl-Alt-Del, had to reboot with Sysrq-Alt-b.
> I added nomodeset to the kernel command line in GRUB and managed to
> boot it that way, although that still didn't immediately result in a
> usable terminal, vtty1 only had a non-blinking cursor if I recall
> correctly. Had to switch to vtty2 or above to do anything useful.
> 
> So, most users can't be expected to know about nomodeset, so there
> should be a clearly labeled "safe graphics" mode, just like how some
> other distros do it.


I assume that the driver will also cause troubles post-install?  Users
will not be happy users anyway with such a machine.

If you boot with nomodeset, graphics should come up with
uvesafb-shepherd-service from gnu/system/install.scm.  (They did for
my old laptop with latest guix three months ago.)  You imply that
graphics never appear and the screen stays black?  Or does it just
take a long time?

I’ve previously had such issues with AMD Radeon GPUs, so we added it
to the blacklist in gnu/system/install.scm:

    ;; XXX: The AMD Radeon driver is reportedly broken, which makes kmscon
    ;; non-functional:
    ;; <https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00441.html>.
    ;; Thus, blacklist it.
    (kernel-arguments '("quiet" "modprobe.blacklist=radeon"))

Regards,
Florian

Message #11 received at 54945 <at> debbugs.gnu.org (full text, mbox):

From: raingloom <raingloom <at> riseup.net>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: 54945 <at> debbugs.gnu.org
Subject: Re: bug#54945: installer should have a no-graphics boot option
Date: Fri, 15 Apr 2022 13:36:36 +0200

On Fri, 15 Apr 2022 08:55:43 +0200
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> wrote:

> On Fri, Apr 15, 2022 at 02:17:49AM +0200, raingloom wrote:
> > Disclaimer: the last time I used an ISO for installing Guix was
> > before there was a graphical installer, so I'm not sure what it's
> > expected to look like now.
> > 
> > Anyways, I tried booting the latest release on a netbook, it failed
> > around/after KMS. Kernel seemed to lock up. No panic, no usable
> > visible log, not responding to Ctrl-Alt-Del, had to reboot with
> > Sysrq-Alt-b. I added nomodeset to the kernel command line in GRUB
> > and managed to boot it that way, although that still didn't
> > immediately result in a usable terminal, vtty1 only had a
> > non-blinking cursor if I recall correctly. Had to switch to vtty2
> > or above to do anything useful.
> > 
> > So, most users can't be expected to know about nomodeset, so there
> > should be a clearly labeled "safe graphics" mode, just like how some
> > other distros do it.  
> 
> 
> I assume that the driver will also cause troubles post-install?  Users
> will not be happy users anyway with such a machine.
> 
> If you boot with nomodeset, graphics should come up with
> uvesafb-shepherd-service from gnu/system/install.scm.  (They did for
> my old laptop with latest guix three months ago.)  You imply that
> graphics never appear and the screen stays black?  Or does it just
> take a long time?
> 
> I’ve previously had such issues with AMD Radeon GPUs, so we added it
> to the blacklist in gnu/system/install.scm:
> 
>     ;; XXX: The AMD Radeon driver is reportedly broken, which makes
> kmscon ;; non-functional:
>     ;;
> <https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00441.html>.
> ;; Thus, blacklist it. (kernel-arguments '("quiet"
> "modprobe.blacklist=radeon"))
> 
> Regards,
> Florian

AFAIK it's a Radeon machine, so that may be the problem.
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.

I'll see if something lightweight like i3wm can start up.

Users will also certainly not be happy if they can't use their Guix
live ISO to rescue their system.

Message #14 received at 54945 <at> debbugs.gnu.org (full text, mbox):

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: raingloom <raingloom <at> riseup.net>
Cc: 54945 <at> debbugs.gnu.org
Subject: Re: bug#54945: installer should have a no-graphics boot option
Date: Fri, 15 Apr 2022 22:44:58 +0200

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 <at> 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

Message #17 received at 54945 <at> debbugs.gnu.org (full text, mbox):

From: raingloom <raingloom <at> riseup.net>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: 54945 <at> debbugs.gnu.org
Subject: Re: bug#54945: installer should have a no-graphics boot option
Date: Sat, 16 Apr 2022 17:32:38 +0200

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

Message #20 received at 54945 <at> debbugs.gnu.org (full text, mbox):

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: raingloom <raingloom <at> riseup.net>
Cc: 54945 <at> debbugs.gnu.org
Subject: Re: bug#54945: installer should have a no-graphics boot option
Date: Sat, 16 Apr 2022 19:31:15 +0200

On Sat, Apr 16, 2022 at 05:32:38PM +0200, raingloom wrote:
> On Fri, 15 Apr 2022 22:44:58 +0200
> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> 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?

Regards,
Florian

Message #23 received at 54945 <at> debbugs.gnu.org (full text, mbox):

From: raingloom <raingloom <at> riseup.net>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: 54945 <at> debbugs.gnu.org
Subject: Re: bug#54945: installer should have a no-graphics boot option
Date: Sat, 16 Apr 2022 19:48:52 +0200

On Sat, 16 Apr 2022 19:31:15 +0200
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> 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)" <pelzflorian <at> pelzflorian.de> 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?
> 
> Regards,
> Florian

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.

Message #26 received at 54945 <at> debbugs.gnu.org (full text, mbox):

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: raingloom <raingloom <at> riseup.net>
Cc: 54945 <at> debbugs.gnu.org
Subject: Re: bug#54945: installer should have a no-graphics boot option
Date: Mon, 18 Apr 2022 16:50:02 +0200

On Sat, Apr 16, 2022 at 07:48:52PM +0200, raingloom wrote:
> On Sat, 16 Apr 2022 19:31:15 +0200
> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> 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)" <pelzflorian <at> pelzflorian.de> 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

Message #29 received at 54945 <at> debbugs.gnu.org (full text, mbox):

From: raingloom <raingloom <at> riseup.net>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: 54945 <at> debbugs.gnu.org
Subject: Re: bug#54945: installer should have a no-graphics^W nomodeset boot
 option
Date: Tue, 19 Apr 2022 01:53:23 +0200

On Mon, 18 Apr 2022 16:50:02 +0200
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> wrote:

> On Sat, Apr 16, 2022 at 07:48:52PM +0200, raingloom wrote:
> > On Sat, 16 Apr 2022 19:31:15 +0200
> > "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> 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)" <pelzflorian <at> pelzflorian.de>
> > > > 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

Okay so I'm doing some more experimentation and a lot of times the
installer really does not show up. It certainly shows up more often
when I add nomodeset and if I remember correctly I may have been using
nomodeset during the previous succesful installs too.

So IMHO this should be kept open.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.