GNU bug report logs - #40538
installer: Support uvesafb to install on machines without KMS.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40538 in the body.
You can then email your comments to 40538 AT debbugs.gnu.org in the normal way.

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

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: bug-guix <at> gnu.org
Subject: installer: Support uvesafb to install on machines without KMS.
Date: Fri, 10 Apr 2020 14:54:47 +0200

[Message part 1 (text/plain, inline)]

uvesafb should be run in the Guix System installer image so the GUI
installer can be used on more systems, including AMD GPU systems.

uvesafb is needed to support systems that otherwise need nonfree
firmware or drivers (many current and older AMD GPUs as well as old
machines like Uniwill U50SI1 with Silicon Integrated Systems GPU). I
attach a patch I made previously at
<https://lists.gnu.org/archive/html/guix-patches/2020-04/msg00226.html>
(plus proper indentation and copyright statement).  I believe it could
be included in the installer even though it is a little hacky.

Note that the installed system will need uvesafb (or nonfree firmware)
too, so the patch alone won’t make these systems work out of the box.
But these things are easier to setup when the system can be installed
via the GUI installer.  I wrote the same about the issue previously at
<https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00350.html>.


On some machines uvesafb still requires to add a kernel parameter
nomodeset (or sometimes possibly vga=793 or something; nomodeset was
enough on tested machines, some machines don’t need nomodeset).

In my testing so far uvesafb did not cause any trouble on systems that
don’t need it.  I have not tested non-x86 systems and just hope the
code won’t break those.


When the dust has settled on the kernel-module-configuration-service
discussed by Brice Waegeneire and Danny Milosavljevic
<https://lists.gnu.org/archive/html/guix-patches/2020-04/msg00272.html>,
a proper uvesafb service can be added.  Then I can make and test one
and it could also be used in the installer.  That would be the clean
solution.  In particular, it could detect the resolution to use for
uvesafb automatically by running the attached code testvbe.scm as
root.  But how to run that code depends on the
kernel-module-configuration-service if/when it exists.  (I did not
know how to extend etc-service-type with a file created at runtime not
build time, but maybe kernel-module-configuration-service works
differently anyway.)

On Fri, Apr 10, 2020 at 12:38:05PM +0200, Ludovic Courtès wrote:
<https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00187.html>
> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> > On an Acer Aspire 5738PG with ATI Mobility Radeon HD 4570 the
> > installer remains black.  I pressed ctrl-alt-f3 and typed
> >
> > modprobe uvesafb v86d=$(guix build v86d | head -n1)/sbin/v86d mode_option=1024x768
> 
> Could we come up with a udev rule or a modprobe.d snippet so that this
> happens automatically?
> 
> I found things like:
> 
>   https://bbs.archlinux.org/viewtopic.php?id=165480
> 
> Or should we give up on v86d like Gentoo:
> 
>   https://wiki.gentoo.org/wiki/Uvesafb
> 
> ?
> 
> (Perhaps this is best discussed in a specific issue on bug-guix.)

I believe uvesafb can easily be supported on Guix System via
kernel-module-loader-service/configuration-service.

Regards,
Florian

[0001-installer-Load-uvesafb-kernel-module.patch (text/plain, attachment)]

[testvbe.scm (application/vnd.lotus-screencam, attachment)]

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: "pelzflorian \(Florian Pelz\)" <pelzflorian <at> pelzflorian.de>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Fri, 10 Apr 2020 16:38:37 +0200

Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:

> uvesafb should be run in the Guix System installer image so the GUI
> installer can be used on more systems, including AMD GPU systems.
>
> uvesafb is needed to support systems that otherwise need nonfree
> firmware or drivers (many current and older AMD GPUs as well as old
> machines like Uniwill U50SI1 with Silicon Integrated Systems GPU). I
> attach a patch I made previously at
> <https://lists.gnu.org/archive/html/guix-patches/2020-04/msg00226.html>
> (plus proper indentation and copyright statement).  I believe it could
> be included in the installer even though it is a little hacky.
>
> Note that the installed system will need uvesafb (or nonfree firmware)
> too, so the patch alone won’t make these systems work out of the box.
> But these things are easier to setup when the system can be installed
> via the GUI installer.  I wrote the same about the issue previously at
> <https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00350.html>.

Thanks for the explanations.

AIUI, uvesafb is needed for ksmcon (or presumably X11) to work, but it’s
not necessary to get the standard Linux framebuffer/console running
(indeed, you were able to ctrl-alt-f3 to get a terminal).  Is this
correct?

If that’s the case, then I think it’s acceptable for now to install a
system that lacks uvesafb.  Of course X11 won’t work (right?), which is
not great, but people can hopefully address it at the console until we
have a better fix, possibly using ‘kernel-module-configuration-service’
as you write.

WDYT?

> From de24448076379a1792a7e1031471d5ae33c8c440 Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> Date: Fri, 10 Apr 2020 14:35:38 +0200
> Subject: [PATCH] installer: Load uvesafb kernel module.
>
> This enables the installer to display when no Kernel Mode Setting is available
> (e.g. many AMD GPUs, old SIS GPUs).
>
> * gnu/system/install.scm (%installation-services): Add kernel-module-loader
> service for loading uvesafb.

[...]

> +     (if (member (%current-system) '("x86_64-linux" "i686-linux"))
> +         ;; Load uvesafb to show installer when no KMS is available.
> +         `(,(service kernel-module-loader-service-type '("uvesafb"))
> +           ,(let ((uvesafb-options
> +                   #~(with-output-to-file #$output
> +                       (lambda _
> +                         (format #t
> +                                 (string-join `("options" "uvesafb"
> +                                                ,(string-append "v86d=" #$v86d
> +                                                                "/sbin/v86d")
> +                                                "mode_option=1024x768")))))))
> +              (simple-service 'uvesafb-configuration etc-service-type
> +                              (list `("modprobe.d/uvesafb.conf"
> +                                      ,(computed-file "uvesafb-options"
> +                                                      uvesafb-options))))))

This is not quite correct because here ‘%current-system’ is evaluated at
the top level, when (gnu tests install) is loaded.  So on my laptop,
it’s always "x86_64-linux", regardless of any ‘-s’ flags.  Also, it
ignores ‘--target’.

Can we arrange to make it unconditional?

One way to do that (not great), would be to make it an activation
snippet: since activation snippets are written as monadic code, we can
reliably check ‘%current-system’ & ‘%current-target-system’ from there.
(For lack of a solution like <https://issues.guix.gnu.org/issue/29296>.)

Stylistic comments:

  1. IMO we should move the uvesafb service definition to the top-level
     for clarity.

  2. Does "modprobe.d/uvesafb.conf" work?  I thought there was nothing
     taking care of creating “modprobe.d” automatically.

  3. You can replace the whole ‘computed-file’ with:

       (mixed-text-file "uvesafb.conf"
                        "options uvesafb v86d=" v86d
                        "/sbin/v86d mode_option=1024x768\n")

  4. Please add a comment stating the hardware target, like in the
     commit log.

Thank you!

Ludo’.

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Fri, 10 Apr 2020 16:58:58 +0200

On Fri, Apr 10, 2020 at 04:38:37PM +0200, Ludovic Courtès wrote:
> AIUI, uvesafb is needed for ksmcon (or presumably X11) to work, but it’s
> not necessary to get the standard Linux framebuffer/console running
> (indeed, you were able to ctrl-alt-f3 to get a terminal).  Is this
> correct?

Yes, all correct.


> If that’s the case, then I think it’s acceptable for now to install a
> system that lacks uvesafb.  Of course X11 won’t work (right?),

Yes, right.

> which is
> not great, but people can hopefully address it at the console until we
> have a better fix, possibly using ‘kernel-module-configuration-service’
> as you write.
> 
> WDYT?

I agree.

I will try making a patch including your suggestions in a few hours.
> 

>   2. Does "modprobe.d/uvesafb.conf" work?  I thought there was nothing
>      taking care of creating “modprobe.d” automatically.

I think I tested this version of the patch and it worked.  One can
test on QEMU by passing nomodeset (without uvesafb the installer stays
black, I think).  It also matches the description of
kernel-module-loader-service-type that was recently added to the
manual.

Regards,
Florian

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sat, 11 Apr 2020 20:43:46 +0200

[Message part 1 (text/plain, inline)]

On Fri, Apr 10, 2020 at 04:38:37PM +0200, Ludovic Courtès wrote:
> > +     (if (member (%current-system) '("x86_64-linux" "i686-linux"))
> > +         ;; Load uvesafb to show installer when no KMS is available.
> > +         `(,(service kernel-module-loader-service-type '("uvesafb"))
> > +           [...]
> 
> This is not quite correct because here ‘%current-system’ is evaluated at
> the top level, when (gnu tests install) is loaded.  So on my laptop,
> it’s always "x86_64-linux", regardless of any ‘-s’ flags.  Also, it
> ignores ‘--target’.
> 
> Can we arrange to make it unconditional?
> 
> One way to do that (not great), would be to make it an activation
> snippet: since activation snippets are written as monadic code, we can
> reliably check ‘%current-system’ & ‘%current-target-system’ from there.
> (For lack of a solution like <https://issues.guix.gnu.org/issue/29296>.)

Please consider the attached patch.  I chose to go without
kernel-module-loader-service (only copying its requirements field)
because I do not know how to conditionally extend or start another
Shepherd service from an activation snippet.

I tested it on QEMU with and without nomodeset.  With a previous Guix
System install image, it stayed black when adding a nomodeset kernel
parameter.  I will test again on real hardware now, but previous
testing of uvesafb-enabled installer images proved successful unlike
non-uvesafb images.

Feel free to adapt the patch or not include it.  Or tell me to change
it if there is time.

Regards,
Florian

[0001-installer-Load-uvesafb-kernel-module.patch (text/plain, attachment)]

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sat, 11 Apr 2020 21:03:45 +0200

[Message part 1 (text/plain, inline)]

On Sat, Apr 11, 2020 at 08:43:46PM +0200, pelzflorian (Florian Pelz) wrote:
> Please consider the attached patch.

Actually I’m not sure about vga=793.  Better use this patch with vga=
removed.

[0001-installer-Load-uvesafb-kernel-module.patch (text/plain, attachment)]

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: "pelzflorian \(Florian Pelz\)" <pelzflorian <at> pelzflorian.de>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sat, 11 Apr 2020 22:59:10 +0200

[Message part 1 (text/plain, inline)]

Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:

> Please consider the attached patch.  I chose to go without
> kernel-module-loader-service (only copying its requirements field)
> because I do not know how to conditionally extend or start another
> Shepherd service from an activation snippet.
>
> I tested it on QEMU with and without nomodeset.  With a previous Guix
> System install image, it stayed black when adding a nomodeset kernel
> parameter.  I will test again on real hardware now, but previous
> testing of uvesafb-enabled installer images proved successful unlike
> non-uvesafb images.

Great.

> From 85a95ce758384979a0aae3bc9065197c74862b4b Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> Date: Sat, 11 Apr 2020 18:56:37 +0200
> Subject: [PATCH] installer: Load uvesafb kernel module.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Fixes <https://bugs.gnu.org/40538>.
>
> Machines without Kernel Mode Setting (those with many old and current AMD
> GPUs, SiS GPUs, …) need uvesafb to show the GUI installer.  Some may also need
> a kernel parameter like nomodeset or vga=793, but we leave that for the user
> to specify in GRUB.
>
> * gnu/system/install.scm (uvesafb-shepherd-service): New procedure.
> (uvesafb-service-type): New variable.
> (%uvesafb-service): New variable.
> (%installation-services): Add it.

I made the following adjustments.

I also confirmed that everything goes well in QEMU, but obviously we’ll
have to test on hardware.

Let’s publish an RC2 tomorrow so we can get feedback.

Thank you!

Ludo’.

[Message part 2 (text/x-patch, inline)]

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index 73a013bed0..203a085bcd 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -276,6 +276,7 @@ the user's target storage device rather than on the RAM disk."
 (define %configuration-template-service
   (service configuration-template-service-type #t))
 
+
 (define %nscd-minimal-caches
   ;; Minimal in-memory caching policy for nscd.
   (list (nscd-cache (database 'hosts)
@@ -295,21 +296,18 @@ the user's target storage device rather than on the RAM disk."
 ;; support Kernel Mode Setting.  Otherwise kmscon is missing /dev/fb0.
 (define (uvesafb-shepherd-service _)
   (list (shepherd-service
-         (documentation "Load uvesafb.")
+         (documentation "Load the uvesafb kernel module.")
          (provision '(uvesafb))
          (requirement '(file-systems))
-         (start (with-imported-modules (source-module-closure '((guix utils)))
-                  #~(begin
-                      (use-modules (guix utils))
-                      (lambda ()
-                        ;; uvesafb is only supported on x86 and x86_64.
-                        (if (member (%current-system)
-                                    '("x86_64-linux" "i686-linux"))
-                            (invoke #+(file-append kmod "/bin/modprobe")
-                                    "uvesafb"
-                                    (string-append "v86d=" #$v86d "/sbin/v86d")
-                                    "mode_option=1024x768")
-                            #t)))))
+         (start #~(lambda ()
+                    ;; uvesafb is only supported on x86 and x86_64.
+                    (or (not (and (string-suffix? "linux-gnu" %host-type)
+                                  (or (string-prefix? "x86_64" %host-type)
+                                      (string-prefix? "i686" %host-type))))
+                        (invoke #+(file-append kmod "/bin/modprobe")
+                                "uvesafb"
+                                (string-append "v86d=" #$v86d "/sbin/v86d")
+                                "mode_option=1024x768"))))
          (respawn? #f)
          (one-shot? #t))))
 
@@ -319,11 +317,10 @@ the user's target storage device rather than on the RAM disk."
    (extensions
     (list (service-extension shepherd-root-service-type
                              uvesafb-shepherd-service)))
+   (description
+    "Load the @code{uvesafb} kernel module with the right options.")
    (default-value #t)))
 
-(define %uvesafb-service
-  (service uvesafb-service-type))
-
 (define %installation-services
   ;; List of services of the installation system.
   (let ((motd (plain-file "motd" "
@@ -451,7 +448,7 @@ Access documentation at any time by pressing Alt-F2.\x1b[0m
           ;; current AMD GPUs, SiS GPUs, ...) need uvesafb to show the GUI
           ;; installer.  Some may also need a kernel parameter like nomodeset
           ;; or vga=793, but we leave that for the user to specify in GRUB.
-          %uvesafb-service)))
+          (service uvesafb-service-type))))
 
 (define %issue
   ;; Greeting.

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

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: "pelzflorian \(Florian Pelz\)" <pelzflorian <at> pelzflorian.de>,
 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 00:11:52 +0300

[Message part 1 (text/plain, inline)]

On Sat, Apr 11, 2020 at 10:59:10PM +0200, Ludovic Courtès wrote:
> Hi Florian,
> 
> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> 
> > Please consider the attached patch.  I chose to go without
> > kernel-module-loader-service (only copying its requirements field)
> > because I do not know how to conditionally extend or start another
> > Shepherd service from an activation snippet.
> >
> > I tested it on QEMU with and without nomodeset.  With a previous Guix
> > System install image, it stayed black when adding a nomodeset kernel
> > parameter.  I will test again on real hardware now, but previous
> > testing of uvesafb-enabled installer images proved successful unlike
> > non-uvesafb images.
> 
> Great.
> 
> > From 85a95ce758384979a0aae3bc9065197c74862b4b Mon Sep 17 00:00:00 2001
> > From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> > Date: Sat, 11 Apr 2020 18:56:37 +0200
> > Subject: [PATCH] installer: Load uvesafb kernel module.
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > Fixes <https://bugs.gnu.org/40538>.
> >
> > Machines without Kernel Mode Setting (those with many old and current AMD
> > GPUs, SiS GPUs, …) need uvesafb to show the GUI installer.  Some may also need
> > a kernel parameter like nomodeset or vga=793, but we leave that for the user
> > to specify in GRUB.
> >
> > * gnu/system/install.scm (uvesafb-shepherd-service): New procedure.
> > (uvesafb-service-type): New variable.
> > (%uvesafb-service): New variable.
> > (%installation-services): Add it.
> 
> I made the following adjustments.
> 
> I also confirmed that everything goes well in QEMU, but obviously we’ll
> have to test on hardware.
> 
> Let’s publish an RC2 tomorrow so we can get feedback.
> 
> Thank you!
> 
> Ludo’.
> 

> diff --git a/gnu/system/install.scm b/gnu/system/install.scm
> index 73a013bed0..203a085bcd 100644
> --- a/gnu/system/install.scm
> +++ b/gnu/system/install.scm
> @@ -276,6 +276,7 @@ the user's target storage device rather than on the RAM disk."
>  (define %configuration-template-service
>    (service configuration-template-service-type #t))
>  
> +
>  (define %nscd-minimal-caches
>    ;; Minimal in-memory caching policy for nscd.
>    (list (nscd-cache (database 'hosts)
> @@ -295,21 +296,18 @@ the user's target storage device rather than on the RAM disk."
>  ;; support Kernel Mode Setting.  Otherwise kmscon is missing /dev/fb0.
>  (define (uvesafb-shepherd-service _)
>    (list (shepherd-service
> -         (documentation "Load uvesafb.")
> +         (documentation "Load the uvesafb kernel module.")
>           (provision '(uvesafb))
>           (requirement '(file-systems))
> -         (start (with-imported-modules (source-module-closure '((guix utils)))
> -                  #~(begin
> -                      (use-modules (guix utils))
> -                      (lambda ()
> -                        ;; uvesafb is only supported on x86 and x86_64.
> -                        (if (member (%current-system)
> -                                    '("x86_64-linux" "i686-linux"))
> -                            (invoke #+(file-append kmod "/bin/modprobe")
> -                                    "uvesafb"
> -                                    (string-append "v86d=" #$v86d "/sbin/v86d")
> -                                    "mode_option=1024x768")
> -                            #t)))))
> +         (start #~(lambda ()
> +                    ;; uvesafb is only supported on x86 and x86_64.
> +                    (or (not (and (string-suffix? "linux-gnu" %host-type)
> +                                  (or (string-prefix? "x86_64" %host-type)
> +                                      (string-prefix? "i686" %host-type))))
> +                        (invoke #+(file-append kmod "/bin/modprobe")
> +                                "uvesafb"
> +                                (string-append "v86d=" #$v86d "/sbin/v86d")
> +                                "mode_option=1024x768"))))
>           (respawn? #f)
>           (one-shot? #t))))

You don't need both of these lines. If it's a one-shot service then it
shouldn't respawn when it finishes, just when something else needs it
again.

>  
> @@ -319,11 +317,10 @@ the user's target storage device rather than on the RAM disk."
>     (extensions
>      (list (service-extension shepherd-root-service-type
>                               uvesafb-shepherd-service)))
> +   (description
> +    "Load the @code{uvesafb} kernel module with the right options.")
>     (default-value #t)))
>  
> -(define %uvesafb-service
> -  (service uvesafb-service-type))
> -
>  (define %installation-services
>    ;; List of services of the installation system.
>    (let ((motd (plain-file "motd" "
> @@ -451,7 +448,7 @@ Access documentation at any time by pressing Alt-F2.\x1b[0m
>            ;; current AMD GPUs, SiS GPUs, ...) need uvesafb to show the GUI
>            ;; installer.  Some may also need a kernel parameter like nomodeset
>            ;; or vga=793, but we leave that for the user to specify in GRUB.
> -          %uvesafb-service)))
> +          (service uvesafb-service-type))))
>  
>  (define %issue
>    ;; Greeting.


-- 
Efraim Flashner   <efraim <at> flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[signature.asc (application/pgp-signature, inline)]

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

From: Bengt Richter <bokr <at> bokr.com>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 08:37:02 +0200

Hi Ludo, Florian,

On +2020-04-10 16:58:58 +0200, pelzflorian (Florian Pelz) wrote:
> On Fri, Apr 10, 2020 at 04:38:37PM +0200, Ludovic Courtès wrote:
> > AIUI, uvesafb is needed for ksmcon (or presumably X11) to work, but it’s
> > not necessary to get the standard Linux framebuffer/console running
> > (indeed, you were able to ctrl-alt-f3 to get a terminal).  Is this
> > correct?
> 
> Yes, all correct.

Did you mean s/ksmcon/kmscon/ ? If that is a descendant of David Herrmann's work,
I wonder if it wouldn't just look for /sys/class/drm/card0 and, if found,
ignore /dev/fb0 and the uvesafb (along with the latter's user stuff requirements).

> 
> 
> > If that’s the case, then I think it’s acceptable for now to install a
> > system that lacks uvesafb.  Of course X11 won’t work (right?),
> 
> Yes, right.
>

Is that as absolutely right as it sounds?
I had thought that some version of Wayland/weston had a back end that
could run on plain /dev/fb0, and if so could provide Xwayland for X11 clients.

Of course, if /sys/class/drm/card0 is available, Wayland will prefer that,
and you're home free for all kinds of GUIs.

> > which is
> > not great, but people can hopefully address it at the console until we
> > have a better fix, possibly using ‘kernel-module-configuration-service’
> > as you write.
> > 
> > WDYT?
> 
> I agree.
> 
> I will try making a patch including your suggestions in a few hours.
> > 
> 
> >   2. Does "modprobe.d/uvesafb.conf" work?  I thought there was nothing
> >      taking care of creating “modprobe.d” automatically.
> 
> I think I tested this version of the patch and it worked.  One can
> test on QEMU by passing nomodeset (without uvesafb the installer stays
> black, I think).  It also matches the description of
> kernel-module-loader-service-type that was recently added to the
> manual.
> 
> Regards,
> Florian
> 
> 
> 

-- 
Regards,
Bengt Richter

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

From: Bengt Richter <bokr <at> bokr.com>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 10:35:50 +0200

On +2020-04-12 08:37:02 +0200, Bengt Richter wrote:
> Hi Ludo, Florian,
> 
> On +2020-04-10 16:58:58 +0200, pelzflorian (Florian Pelz) wrote:
> > On Fri, Apr 10, 2020 at 04:38:37PM +0200, Ludovic Courtès wrote:
> > > AIUI, uvesafb is needed for ksmcon (or presumably X11) to work, but it’s
> > > not necessary to get the standard Linux framebuffer/console running
> > > (indeed, you were able to ctrl-alt-f3 to get a terminal).  Is this
> > > correct?
> > 
> > Yes, all correct.
> 
> Did you mean s/ksmcon/kmscon/ ? If that is a descendant of David Herrmann's work,
> I wonder if it wouldn't just look for /sys/class/drm/card0 and, if found,
> ignore /dev/fb0 and the uvesafb (along with the latter's user stuff requirements).
> 
> > 
> > 
> > > If that’s the case, then I think it’s acceptable for now to install a
> > > system that lacks uvesafb.  Of course X11 won’t work (right?),
> > 
> > Yes, right.
> >
> 
> Is that as absolutely right as it sounds?
> I had thought that some version of Wayland/weston had a back end that
> could run on plain /dev/fb0, and if so could provide Xwayland for X11 clients.
> 
> Of course, if /sys/class/drm/card0 is available, Wayland will prefer that,
> and you're home free for all kinds of GUIs.
>

Sorry, forgot to add this in context:

This "hello world" might suggest what you could do at a direct-to-wayland level,
without involving major GUI libs at run time:

    https://gitlab.com/hdante/hello_wayland

(it compiled and ran fine on my PureOS debian-based system, sharing display
with gnome as just another wayland client, since all the GUI runs on wayland)

I'm sure someone with more guile-fu than me could provide a guile wrapper
to vary text and cursor etc. faster than I can.
I've been meaning to do it, but time flies :)

It looks to me like a way to produce a fancy UI for a small runtime by using guix to
define build-time use of major graphics and font resources etc. for the run-time
wayland client.

> > > which is
> > > not great, but people can hopefully address it at the console until we
> > > have a better fix, possibly using ‘kernel-module-configuration-service’
> > > as you write.
> > > 
> > > WDYT?
> > 
> > I agree.
> > 
> > I will try making a patch including your suggestions in a few hours.
> > > 
> > 
> > >   2. Does "modprobe.d/uvesafb.conf" work?  I thought there was nothing
> > >      taking care of creating “modprobe.d” automatically.
> > 
> > I think I tested this version of the patch and it worked.  One can
> > test on QEMU by passing nomodeset (without uvesafb the installer stays
> > black, I think).  It also matches the description of
> > kernel-module-loader-service-type that was recently added to the
> > manual.
> > 
> > Regards,
> > Florian
> > 
> > 
> > 
> 
-- 
Regards,
Bengt Richter

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Bengt Richter <bokr <at> bokr.com>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 10:56:21 +0200

On Sun, Apr 12, 2020 at 08:37:02AM +0200, Bengt Richter wrote:
> Did you mean s/ksmcon/kmscon/ ?

Yes.


> If that is a descendant of David Herrmann's work,
> I wonder if it wouldn't just look for /sys/class/drm/card0 and, if found,
> ignore /dev/fb0 and the uvesafb (along with the latter's user stuff requirements).
> […]
> I had thought that some version of Wayland/weston had a back end that
> could run on plain /dev/fb0, and if so could provide Xwayland for X11 clients.
> 
> Of course, if /sys/class/drm/card0 is available, Wayland will prefer that,
> and you're home free for all kinds of GUIs.

Well only with uvesafb I get a /dev/fb0 device and with /dev/fb0 I can
use xf86-video-fbdev or kmscon.  It seems kmscon has multiple
backends, I do not know if it can work in other ways, but by default
it does not work without uvesafb.

Regards,
Florian

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 11:02:57 +0200

On Sat, Apr 11, 2020 at 10:59:10PM +0200, Ludovic Courtès wrote:
> I made the following adjustments.

Thank you.  I am impressed by the speed at which you fix things.


> I also confirmed that everything goes well in QEMU, but obviously we’ll
> have to test on hardware.
> 
> Let’s publish an RC2 tomorrow so we can get feedback.

I believe I was mistaken to write about vga=793; it seems it has the
opposite effect and breaks uvesafb.  Anyway that’s only comments in
the patch and commit message, and it is not on master yet.

Regards,
Florian

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 11:23:30 +0200

[Message part 1 (text/plain, inline)]

On Sun, Apr 12, 2020 at 12:11:52AM +0300, Efraim Flashner wrote:
> >           (respawn? #f)
> >           (one-shot? #t))))
> 
> You don't need both of these lines. If it's a one-shot service then it
> shouldn't respawn when it finishes, just when something else needs it
> again.

Thank you.  Maybe I should push the attached patch?

Regards,
Florian

[0001-services-kernel-module-loader-Clean-up.patch (text/plain, attachment)]

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 13:24:00 +0200

On Sun, Apr 12, 2020 at 11:02:57AM +0200, pelzflorian (Florian Pelz) wrote:
> I believe I was mistaken to write about vga=793; it seems it has the
> opposite effect and breaks uvesafb.  Anyway that’s only comments in
> the patch and commit message, and it is not on master yet.

All is fine vga=793 does not break uvesafb on my Acer Aspire but does
not help either.  Only on QEMU vga=793 broke everything.  Maybe leave
the patch as is.

Also with uvesafb my Acer Aspire with ATI Radeon boots fine without
kernel parameters.  Without uvesafb the screen remains black until I
switch to a console.  I believe this issue can be closed?

Regards,
Florian

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 14:33:35 +0200

On Sun, Apr 12, 2020 at 01:24:00PM +0200, pelzflorian (Florian Pelz) wrote:
> Also with uvesafb my Acer Aspire with ATI Radeon boots fine without
> kernel parameters.

So does my Uniwill U50SI1 which previously did not work.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: "pelzflorian \(Florian Pelz\)" <pelzflorian <at> pelzflorian.de>
Cc: Efraim Flashner <efraim <at> flashner.co.il>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 16:28:20 +0200

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:

> On Sun, Apr 12, 2020 at 12:11:52AM +0300, Efraim Flashner wrote:
>> >           (respawn? #f)
>> >           (one-shot? #t))))
>> 
>> You don't need both of these lines. If it's a one-shot service then it
>> shouldn't respawn when it finishes, just when something else needs it
>> again.
>
> Thank you.  Maybe I should push the attached patch?
>
> Regards,
> Florian
>
> From e16a277d1ec1afa14dede7bac0307b12603ebebd Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> Date: Sun, 12 Apr 2020 11:08:28 +0200
> Subject: [PATCH] services: kernel-module-loader: Clean up.
>
> Suggested by Efraim Flashner <efraim <at> flashner.co.il>.
> See <https://lists.gnu.org/archive/html/bug-guix/2020-04/msg00237.html>.
>
> * gnu/services/linux.scm (kernel-module-loader-shepherd-service):
> Remove unneeded 'respawn?' field.

Yes, you can push it to ‘version-1.1.0’, which we’ll eventually merge to
‘master’.

Also feel free to adjust the comment about vga= there.

Thanks for testing on your machines!

Ludo’.

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

From: Mathieu Othacehe <m.othacehe <at> gmail.com>
To: "pelzflorian \(Florian Pelz\)" <pelzflorian <at> pelzflorian.de>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 16:48:36 +0200

Hey!

> All is fine vga=793 does not break uvesafb on my Acer Aspire but does
> not help either.  Only on QEMU vga=793 broke everything.  Maybe leave
> the patch as is.

Thanks for your patch. I tried briefly 1.1.0-rc2 on some hardware of
mine. On three somehow recent laptops, everything still works fine but
v86d segfaults without giving much information.

The 'dmesg' output looks like:

--8<---------------cut here---------------start------------->8---
v86d[371]: segfault at xxxxx.
uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
uvesafb: vbe_init() failed with -22
uvesafb: probe of uvesafb.0 failed with error -22
--8<---------------cut here---------------end--------------->8---

On a really old Intel machine, I have a complete black screen on all TTY
but that was maybe the case on older Guix System revisions and I would
need to do more investigations.

Mathieu

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Mathieu Othacehe <m.othacehe <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 17:30:52 +0200

On Sun, Apr 12, 2020 at 04:48:36PM +0200, Mathieu Othacehe wrote:
> Thanks for your patch. I tried briefly 1.1.0-rc2 on some hardware of
> mine. On three somehow recent laptops, everything still works fine but
> v86d segfaults without giving much information.
> 
> The 'dmesg' output looks like:
> 
> --8<---------------cut here---------------start------------->8---
> v86d[371]: segfault at xxxxx.
> uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
> uvesafb: vbe_init() failed with -22
> uvesafb: probe of uvesafb.0 failed with error -22
> --8<---------------cut here---------------end--------------->8---
>

Even though I do not remember a segfault, I believe these errors come
when another driver has already reserved the memory that uvesafb
wants.  If the other driver already works fine and that is the only
error, maybe we can just ignore the uvesafb error.



> On a really old Intel machine, I have a complete black screen on all TTY
> but that was maybe the case on older Guix System revisions and I would
> need to do more investigations.
> 
> Mathieu

Please try adding nomodeset to the kernel parameters.  I hope this
makes the Intel machine work fine.

Thank you for your feedback and all your work!

Regards,
Florian

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

From: Bengt Richter <bokr <at> bokr.com>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 19:48:19 +0200

Hi Florian,

On +2020-04-12 17:30:52 +0200, pelzflorian (Florian Pelz) wrote:
> On Sun, Apr 12, 2020 at 04:48:36PM +0200, Mathieu Othacehe wrote:
> > Thanks for your patch. I tried briefly 1.1.0-rc2 on some hardware of
> > mine. On three somehow recent laptops, everything still works fine but
> > v86d segfaults without giving much information.
> > 
> > The 'dmesg' output looks like:
> > 
> > --8<---------------cut here---------------start------------->8---
> > v86d[371]: segfault at xxxxx.
> > uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
> > uvesafb: vbe_init() failed with -22
> > uvesafb: probe of uvesafb.0 failed with error -22
> > --8<---------------cut here---------------end--------------->8---
> >
> 
> Even though I do not remember a segfault, I believe these errors come
> when another driver has already reserved the memory that uvesafb
> wants.  If the other driver already works fine and that is the only
> error, maybe we can just ignore the uvesafb error.
> 
>

Could it be segfaulting trying to access a missing v86d ?
(if so maybe you could detect its absence before it segfaults and issue a hint?)

Looking at
    https://www.kernel.org/doc/html/latest/fb/uvesafb.html
I see (hand-wrapped, and boxing what I thought might be extra interesting):
--8<---------------cut here---------------start------------->8---
Unlike other drivers, uvesafb makes use of a userspace helper called v86d.
v86d is used to run the x86 Video BIOS code in a simulated and controlled environment.
This allows uvesafb to function on arches other than x86.
Check the v86d documentation for a list of currently supported arches.

v86d source code can be downloaded from the following website:

    https://github.com/mjanusz/v86d

Please refer to the v86d documentation for detailed configuration and installation instructions.

┌───────────────────────────────────────────────────────────────┐
│ Note that the v86d userspace helper has to be available       │
│ at all times in order for uvesafb to work properly.           │
│ If you want to use uvesafb during early boot,                 │
│ you will have to include v86d into an initramfs image,        │
│ and either compile it into the kernel or use it as an initrd. │
└───────────────────────────────────────────────────────────────┘
--8<---------------cut here---------------end--------------->8---
Also there are various options for compiling in vs modprobe vs kernel params etc
mentioned in https://www.kernel.org/doc/html/latest/fb/uvesafb.html so I imagine
v86d could be missing for various reasons in a particular run-time context?

> 
> > On a really old Intel machine, I have a complete black screen on all TTY
> > but that was maybe the case on older Guix System revisions and I would
> > need to do more investigations.
> > 
> > Mathieu
> 
> Please try adding nomodeset to the kernel parameters.  I hope this
> makes the Intel machine work fine.
> 
> Thank you for your feedback and all your work!
> 
> Regards,
> Florian
> 
-- 
Regards,
Bengt Richter

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Bengt Richter <bokr <at> bokr.com>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 20:11:01 +0200

On Sun, Apr 12, 2020 at 07:48:19PM +0200, Bengt Richter wrote:
> Could it be segfaulting trying to access a missing v86d ?

The code for loading the uvesafb module looks like this:

(invoke #+(file-append kmod "/bin/modprobe")
        "uvesafb"
        (string-append "v86d=" #$v86d "/sbin/v86d")
        "mode_option=1024x768"))))

So it should call

modprobe uvesafb v86d=/gnu/store/…-v86d-…/sbin/v86d mode_option=1024x768

and it should be impossible for v86d to be missing.  On x86_64 and
i686 at least, and on other architectures uvesafb will not be loaded.

Then again, if the GUI works because of other drivers already, we need
not fix it, I think.  Also I still believe the error comes because
other drivers already reserve needed memory -- passing nomodeset
should make sure they don’t.  Except if vesafb or xf86-video-vesa is
loaded, which is not the case in the installer.

Regards,
Florian

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Efraim Flashner <efraim <at> flashner.co.il>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 20:33:56 +0200

On Sun, Apr 12, 2020 at 04:28:20PM +0200, Ludovic Courtès wrote:
> Yes, you can push it to ‘version-1.1.0’, which we’ll eventually merge to
> ‘master’.
> 

Done.

> Also feel free to adjust the comment about vga= there.
> 
> Thanks for testing on your machines!

I will leave the comment as is.  Sorry for the noise.  (The mechanics
behind vga= appear complicated, I’ve read of rumors it may help some
people and passing it is only sometimes harmful.)

Thank you for your amazing work!

Regards,
Florian

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

From: Bengt Richter <bokr <at> bokr.com>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Mon, 13 Apr 2020 07:00:26 +0200

Hi Florian,

On +2020-04-12 20:11:01 +0200, pelzflorian (Florian Pelz) wrote:
> On Sun, Apr 12, 2020 at 07:48:19PM +0200, Bengt Richter wrote:
> > Could it be segfaulting trying to access a missing v86d ?
> 
> The code for loading the uvesafb module looks like this:
> 
> (invoke #+(file-append kmod "/bin/modprobe")
>         "uvesafb"
>         (string-append "v86d=" #$v86d "/sbin/v86d")
>         "mode_option=1024x768"))))
> 
> So it should call
> 
> modprobe uvesafb v86d=/gnu/store/…-v86d-…/sbin/v86d mode_option=1024x768
>
Thanks for explaining. I hope others benefit too :)

> and it should be impossible for v86d to be missing.  On x86_64 and

Hm, could it be there in /gnu/store and have been built so it's a wrong
version somehow for the running kernel? That's the only bug possibility
I can think of now ;-)

> i686 at least, and on other architectures uvesafb will not be loaded.
> 
> Then again, if the GUI works because of other drivers already, we need
> not fix it, I think.  Also I still believe the error comes because
> other drivers already reserve needed memory -- passing nomodeset
> should make sure they don’t.  Except if vesafb or xf86-video-vesa is
> loaded, which is not the case in the installer.

sudo dmesg|grep -i fb in that context doesn't show anything weird?

Oh, well. Sorry I don't seem to be able to accept a mystery sigsev ;-)
Could it be wrapped and caught in a catch?

> 
> Regards,
> Florian

-- 
Regards,
Bengt Richter

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Bengt Richter <bokr <at> bokr.com>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Mon, 13 Apr 2020 07:37:25 +0200

On Mon, Apr 13, 2020 at 07:00:26AM +0200, Bengt Richter wrote:
> Sorry I don't seem to be able to accept a mystery sigsev ;-)

Thank you for your debugging help.  Of course you are right that
sigsegv is not good error handling.  I can look later what might be
the error in /sbin/v86d.  But now I am busy with other bugs.


> Hm, could it be there in /gnu/store and have been built so it's a wrong
> version somehow for the running kernel? That's the only bug possibility
> I can think of now ;-)

The latest commits to https://github.com/mjanusz/v86d are from 2014.
However we patch v86d to use a more recent x86emu.  Maybe there is
some incompatibility.

> sudo dmesg|grep -i fb in that context doesn't show anything weird?
> 
> Oh, well. 
> Could it be wrapped and caught in a catch?

Probably yes.  I will get back to this bug later, feel free to change
and catch things in the meantime.

Maybe the sigsegv even shows up in QEMU?

Regards,
Florian

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

From: Mathieu Othacehe <m.othacehe <at> gmail.com>
To: "pelzflorian \(Florian Pelz\)" <pelzflorian <at> pelzflorian.de>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Tue, 14 Apr 2020 09:24:52 +0200

Hello Florian,

> Please try adding nomodeset to the kernel parameters.  I hope this
> makes the Intel machine work fine.

Yes it works fine with nomodeset! Do you think we can do something about
it, besides adding a few lines in the documentation to warn that old
hardware may require this option?

Thanks,

Mathieu

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Mathieu Othacehe <m.othacehe <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Tue, 14 Apr 2020 10:16:52 +0200

On Tue, Apr 14, 2020 at 09:24:52AM +0200, Mathieu Othacehe wrote:
> 
> Hello Florian,
> 
> > Please try adding nomodeset to the kernel parameters.  I hope this
> > makes the Intel machine work fine.
> 
> Yes it works fine with nomodeset! Do you think we can do something about
> it, besides adding a few lines in the documentation to warn that old
> hardware may require this option?
> 
> Thanks,
> 
> Mathieu

That is good to hear!  The options I know of are:

1) Make the loading of the uvesafb kernel module by the installer
conditional.  For your GPU, don’t load uvesafb, if before it worked
without.

2) Add modprobe.blacklist=i915 to the default kernel parameters (or
whatever the kernel module for this GPU is), so this kind of GPU
always only uses uvesafb.

3) Add nomodeset to the default kernel parameters for the installer,
so all GPUs always use uvesafb.

I do not know if uvesafb works on all display technologies though.

uvesafb certainly is not supported on ARM (though maybe it works; the
README of uvesafb’s helper program v86d just says it is not supported).

Regards,
Florian

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Mathieu Othacehe <m.othacehe <at> gmail.com>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Tue, 14 Apr 2020 10:34:34 +0200

On Tue, Apr 14, 2020 at 10:16:52AM +0200, pelzflorian (Florian Pelz) wrote:
> 1) Make the loading of the uvesafb kernel module by the installer
> conditional.  For your GPU, don’t load uvesafb, if before it worked
> without.

P.S. I would suppose that a lot of cases and lspci parsing might be
needed to do that for various AMD GPUs and Intel GPUs.  Also the
Nvidia GPU in my Macbook requires nomodeset only if booted from
DVD. :/  But I think my Macbook GPU is semi-broken anyway; because
I see errors from nouveau, I generally use fbdev.  I also need an
older kernel for GDM to log in, even though GDM itself runs fine.

Regards,
Florian

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Bengt Richter <bokr <at> bokr.com>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Tue, 14 Apr 2020 10:57:27 +0200

On Mon, Apr 13, 2020 at 07:37:25AM +0200, pelzflorian (Florian Pelz) wrote:
> Maybe the sigsegv even shows up in QEMU?

Sadly QEMU shows no sigsegv.  Neither does a real-hardware AMD GPU PC.
I have no machine with old Intel GPU.  None of my machines has
SIGSEGV in v86d.

Regards,
Florian

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: "pelzflorian \(Florian Pelz\)" <pelzflorian <at> pelzflorian.de>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Tue, 14 Apr 2020 12:09:12 +0200

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:

> That is good to hear!  The options I know of are:
>
> 1) Make the loading of the uvesafb kernel module by the installer
> conditional.  For your GPU, don’t load uvesafb, if before it worked
> without.
>
> 2) Add modprobe.blacklist=i915 to the default kernel parameters (or
> whatever the kernel module for this GPU is), so this kind of GPU
> always only uses uvesafb.
>
> 3) Add nomodeset to the default kernel parameters for the installer,
> so all GPUs always use uvesafb.
>
> I do not know if uvesafb works on all display technologies though.

Would there be a way to load uvesabf only on hardware where it’s known
to fix things?

Or better yet, is there a way to check whether KMS is already using
another driver, and to not load uvesafb in that case?  Probably there’s
some info in /sys.

> uvesafb certainly is not supported on ARM (though maybe it works; the
> README of uvesafb’s helper program v86d just says it is not supported).

Let’s forget about ARM, we don’t ship Guix System installation images
for ARM.

Ludo’.

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Tue, 14 Apr 2020 12:28:38 +0200

On Tue, Apr 14, 2020 at 12:09:12PM +0200, Ludovic Courtès wrote:
> Or better yet, is there a way to check whether KMS is already using
> another driver, and to not load uvesafb in that case?  Probably there’s
> some info in /sys.

Hmm I will try if checking for the presence of /dev/fb0 helps.

Regards,
Florian

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Tue, 14 Apr 2020 15:14:04 +0200

On Tue, Apr 14, 2020 at 12:28:38PM +0200, pelzflorian (Florian Pelz) wrote:
> On Tue, Apr 14, 2020 at 12:09:12PM +0200, Ludovic Courtès wrote:
> > Or better yet, is there a way to check whether KMS is already using
> > another driver, and to not load uvesafb in that case?  Probably there’s
> > some info in /sys.
> 
> Hmm I will try if checking for the presence of /dev/fb0 helps.

I have tested and pushed a check for /dev/fb0 as
0ad60b2a89d6d387236466e0bcdd61ac489fca37 to the version-1.1.0 branch.

All my machines that need uvesafb use it while those that don’t need
it do not modprobe the kernel module anymore.  Possibly there remain
problems should the normal Kernel Mode Setting be very slow to create
/dev/fb0, but otherwise the logs should no longer show uvesafb errors.

They do show that the uvesafb shepherd service was started, even when
it did not load uvesafb.  Maybe the shepherd service should be
renamed.

Regards,
Florian

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: "pelzflorian \(Florian Pelz\)" <pelzflorian <at> pelzflorian.de>
Cc: 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Tue, 14 Apr 2020 16:12:28 +0200

Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:

> On Tue, Apr 14, 2020 at 12:28:38PM +0200, pelzflorian (Florian Pelz) wrote:
>> On Tue, Apr 14, 2020 at 12:09:12PM +0200, Ludovic Courtès wrote:
>> > Or better yet, is there a way to check whether KMS is already using
>> > another driver, and to not load uvesafb in that case?  Probably there’s
>> > some info in /sys.
>> 
>> Hmm I will try if checking for the presence of /dev/fb0 helps.
>
> I have tested and pushed a check for /dev/fb0 as
> 0ad60b2a89d6d387236466e0bcdd61ac489fca37 to the version-1.1.0 branch.
>
> All my machines that need uvesafb use it while those that don’t need
> it do not modprobe the kernel module anymore.  Possibly there remain
> problems should the normal Kernel Mode Setting be very slow to create
> /dev/fb0, but otherwise the logs should no longer show uvesafb errors.
>
> They do show that the uvesafb shepherd service was started, even when
> it did not load uvesafb.

Well done!

I’ll send an image to Niels in case they can double-check that the
/dev/fb0 check works for them.

> Maybe the shepherd service should be renamed.

To ‘maybe-uvesafb’?  Doesn’t matter much to me.  :-)

Thank you!

Ludo’.

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

From: Mathieu Othacehe <m.othacehe <at> gmail.com>
To: "pelzflorian \(Florian Pelz\)" <pelzflorian <at> pelzflorian.de>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Tue, 14 Apr 2020 19:09:23 +0200

Hey Florian,

> They do show that the uvesafb shepherd service was started, even when
> it did not load uvesafb.  Maybe the shepherd service should be
> renamed.

I did check on my recent hardware, the module is not loaded anymore and
everything works fine. On my old Intel machine, I guess uvesafb was
messing with i915, and as you pointed out, "nomodeset" was required.

With your recent patch, uvesafb is not loaded and it works fine out of
the box.

Thanks a lot for all the effort your are investing into this :)

Mathieu

Message #100 received at 40538-done <at> debbugs.gnu.org (full text, mbox):

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Mathieu Othacehe <m.othacehe <at> gmail.com>
Cc: 40538-done <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Tue, 14 Apr 2020 23:31:37 +0200

On Tue, Apr 14, 2020 at 07:09:23PM +0200, Mathieu Othacehe wrote:
> 
> Hey Florian,
> 
> > They do show that the uvesafb shepherd service was started, even when
> > it did not load uvesafb.  Maybe the shepherd service should be
> > renamed.
> 
> I did check on my recent hardware, the module is not loaded anymore and
> everything works fine. On my old Intel machine, I guess uvesafb was
> messing with i915, and as you pointed out, "nomodeset" was required.
> 
> With your recent patch, uvesafb is not loaded and it works fine out of
> the box.
> 
> Thanks a lot for all the effort your are investing into this :)
> 
> Mathieu

I’m glad.  Thank you for testing.  Closing. :)

Regards,
Florian

Previous Next

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