installer: Support uvesafb to install on machines without KMS.

  • Done
  • quality assurance status badge
Details
5 participants
  • Bengt Richter
  • Efraim Flashner
  • Ludovic Courtès
  • Mathieu Othacehe
  • pelzflorian (Florian Pelz)
Owner
unassigned
Submitted by
pelzflorian (Florian Pelz)
Severity
normal
P
P
pelzflorian (Florian Pelz) wrote on 10 Apr 2020 14:54
(address . bug-guix@gnu.org)
20200410125447.smn6xhcixe7hpday@pelzflorian.localdomain
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
(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


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
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:
Toggle quote (21 lines)
> "pelzflorian (Florian Pelz)" <pelzflorian@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
Attachment: 0001-installer-Load-uvesafb-kernel-module.patch
Attachment: testvbe.scm
L
L
Ludovic Courtès wrote on 10 Apr 2020 16:38
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 40538@debbugs.gnu.org)
87tv1rv21e.fsf@gnu.org
Hi Florian,

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

Toggle quote (17 lines)
> 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?

Toggle quote (11 lines)
> From de24448076379a1792a7e1031471d5ae33c8c440 Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian@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.

[...]

Toggle quote (16 lines)
> + (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’.
P
P
pelzflorian (Florian Pelz) wrote on 10 Apr 2020 16:58
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40538@debbugs.gnu.org)
20200410145858.cekc55kjog3eblbu@pelzflorian.localdomain
On Fri, Apr 10, 2020 at 04:38:37PM +0200, Ludovic Courtès wrote:
Toggle quote (5 lines)
> 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.


Toggle quote (3 lines)
> 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.

Toggle quote (7 lines)
> 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.
Toggle quote (5 lines)
>

> 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
P
P
pelzflorian (Florian Pelz) wrote on 11 Apr 2020 20:43
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40538@debbugs.gnu.org)
20200411184346.c3cgop7egcjyqzwf@pelzflorian.localdomain
On Fri, Apr 10, 2020 at 04:38:37PM +0200, Ludovic Courtès wrote:
Toggle quote (17 lines)
> > + (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
From 85a95ce758384979a0aae3bc9065197c74862b4b Mon Sep 17 00:00:00 2001
From: Florian Pelz <pelzflorian@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


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.
---
gnu/system/install.scm | 47 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 45 insertions(+), 2 deletions(-)

Toggle diff (95 lines)
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index c15c2c7814..73a013bed0 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -4,6 +4,7 @@
;;; Copyright © 2016 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2017 Marius Bakke <mbakke@fastmail.com>
;;; Copyright © 2017, 2019 Tobias Geerinckx-Rice <me@tobias.gr>
+;;; Copyright © 2020 Florian Pelz <pelzflorian@pelzflorian.de>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -27,6 +28,7 @@
#:use-module (guix gexp)
#:use-module (guix store)
#:use-module (guix monads)
+ #:use-module (guix modules)
#:use-module ((guix packages) #:select (package-version))
#:use-module ((guix store) #:select (%store-prefix))
#:use-module (gnu installer)
@@ -50,6 +52,7 @@
#:use-module (gnu packages texinfo)
#:use-module (gnu packages compression)
#:use-module (gnu packages nvi)
+ #:use-module (gnu packages xorg)
#:use-module (ice-9 match)
#:use-module (srfi srfi-26)
#:export (installation-os
@@ -273,7 +276,6 @@ 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)
@@ -287,6 +289,41 @@ the user's target storage device rather than on the RAM disk."
(persistent? #f)
(max-database-size (* 5 (expt 2 20)))))) ;5 MiB
+
+;; These define a service to load the uvesafb kernel module with the
+;; appropriate options. The GUI installer needs it when the machine does not
+;; support Kernel Mode Setting. Otherwise kmscon is missing /dev/fb0.
+(define (uvesafb-shepherd-service _)
+ (list (shepherd-service
+ (documentation "Load uvesafb.")
+ (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)))))
+ (respawn? #f)
+ (one-shot? #t))))
+
+(define uvesafb-service-type
+ (service-type
+ (name 'uvesafb)
+ (extensions
+ (list (service-extension shepherd-root-service-type
+ uvesafb-shepherd-service)))
+ (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" "
@@ -408,7 +445,13 @@ Access documentation at any time by pressing Alt-F2.\x1b[0m
(list bare-bones-os
glibc-utf8-locales
texinfo
- (canonical-package guile-2.2))))))
+ (canonical-package guile-2.2)))
+
+ ;; 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.
+ %uvesafb-service)))
(define %issue
;; Greeting.
--
2.26.0
P
P
pelzflorian (Florian Pelz) wrote on 11 Apr 2020 21:03
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40538@debbugs.gnu.org)
20200411190344.pwadvpv3jzne42gx@pelzflorian.localdomain
On Sat, Apr 11, 2020 at 08:43:46PM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (2 lines)
> Please consider the attached patch.

Actually I’m not sure about vga=793. Better use this patch with vga=
removed.
From 4b5a1b522dfd76d5c6c6a4cb093dba45cf636a58 Mon Sep 17 00:00:00 2001
From: Florian Pelz <pelzflorian@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


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, 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.
---
gnu/system/install.scm | 47 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 45 insertions(+), 2 deletions(-)

Toggle diff (95 lines)
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index c15c2c7814..cfe2b9540a 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -4,6 +4,7 @@
;;; Copyright © 2016 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2017 Marius Bakke <mbakke@fastmail.com>
;;; Copyright © 2017, 2019 Tobias Geerinckx-Rice <me@tobias.gr>
+;;; Copyright © 2020 Florian Pelz <pelzflorian@pelzflorian.de>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -27,6 +28,7 @@
#:use-module (guix gexp)
#:use-module (guix store)
#:use-module (guix monads)
+ #:use-module (guix modules)
#:use-module ((guix packages) #:select (package-version))
#:use-module ((guix store) #:select (%store-prefix))
#:use-module (gnu installer)
@@ -50,6 +52,7 @@
#:use-module (gnu packages texinfo)
#:use-module (gnu packages compression)
#:use-module (gnu packages nvi)
+ #:use-module (gnu packages xorg)
#:use-module (ice-9 match)
#:use-module (srfi srfi-26)
#:export (installation-os
@@ -273,7 +276,6 @@ 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)
@@ -287,6 +289,41 @@ the user's target storage device rather than on the RAM disk."
(persistent? #f)
(max-database-size (* 5 (expt 2 20)))))) ;5 MiB
+
+;; These define a service to load the uvesafb kernel module with the
+;; appropriate options. The GUI installer needs it when the machine does not
+;; support Kernel Mode Setting. Otherwise kmscon is missing /dev/fb0.
+(define (uvesafb-shepherd-service _)
+ (list (shepherd-service
+ (documentation "Load uvesafb.")
+ (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)))))
+ (respawn? #f)
+ (one-shot? #t))))
+
+(define uvesafb-service-type
+ (service-type
+ (name 'uvesafb)
+ (extensions
+ (list (service-extension shepherd-root-service-type
+ uvesafb-shepherd-service)))
+ (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" "
@@ -408,7 +445,13 @@ Access documentation at any time by pressing Alt-F2.\x1b[0m
(list bare-bones-os
glibc-utf8-locales
texinfo
- (canonical-package guile-2.2))))))
+ (canonical-package guile-2.2)))
+
+ ;; 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,
+ ;; but we leave that for the user to specify in GRUB.
+ %uvesafb-service)))
(define %issue
;; Greeting.
--
2.26.0
L
L
Ludovic Courtès wrote on 11 Apr 2020 22:59
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 40538@debbugs.gnu.org)
874ktpspr5.fsf@gnu.org
Hi Florian,

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

Toggle quote (11 lines)
> 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.

Toggle quote (20 lines)
> From 85a95ce758384979a0aae3bc9065197c74862b4b Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian@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’.
Toggle diff (67 lines)
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.
E
E
Efraim Flashner wrote on 11 Apr 2020 23:11
(name . Ludovic Courtès)(address . ludo@gnu.org)
20200411211152.GA31526@E5400
Attachment: file
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAl6SMpgACgkQQarn3Mo9
g1FBaA//cBfFlKIjiznklc9G865KilI1MPPh0zM0TuPi8n+uX7SKWPT4IoShLs9e
QKM/G5Z9K7eTP14/DMSHBKZ3GsOLTzu2/B6O6D+jBF6OgDSOa40tG/yNiHiyOyyw
jerfgThf0HmL1dz9XjyCrlzdT47UuArkJYVOpXbIVLmpHb3390ZS2jgddzF2u8So
5gXTQSiIAta+KGvTjgjSWrnhUnJzKneOpfUSkGLbcJaxmsxJFs8BRYSIXhB/0NGV
ol1cRr00+20v1pQCuVT4wwaH2b2Y5EqLa8Hhvt/Hk920I0stEITA87cg7NcQKvBb
TLu3G6KnjNK6QRKyEwOKCtv4Vm5nKeXl69gwD5xZePFTZMzu68pTuvfYd3DnGByp
XwUY8nm76+5gTW1w/GidwFe2Mt+WfErURyMg4CMbBLyRSI9GquNCPhhB1O2VEy6Q
a9o/UUg0XLRlfSW3KVOrQ7kjSq4kjUr4VOo9Rg3E6FeLTOt0I3fRNndG5q7y/8Ic
SIPlZg4e4c94b0MSylQZmGMqSGWUMg7IeYPS92bNXfAWOBxi3faGTnk/QArARgtP
5yy0xk/dYd3N8SaYmZpmr8mC8GD+OC0EXL0ZEay/lGznIS6N4S/9z9fDPFT18nkP
G9NFTuu1R1k27uDcvFt5YGj+muUhMHmKsJGVnsAe+SpSmBi3f+g=
=fCAL
-----END PGP SIGNATURE-----


B
B
Bengt Richter wrote on 12 Apr 2020 08:37
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
20200412063702.GA4097@LionPure
Hi Ludo, Florian,

On +2020-04-10 16:58:58 +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (8 lines)
> 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).

Toggle quote (8 lines)
>
>
> > 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.

Toggle quote (27 lines)
> > 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
B
B
Bengt Richter wrote on 12 Apr 2020 10:35
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 40538@debbugs.gnu.org)
20200412083550.GA5546@LionPure
On +2020-04-12 08:37:02 +0200, Bengt Richter wrote:
Toggle quote (31 lines)
> 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:


(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.

Toggle quote (27 lines)
> > > 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
P
P
pelzflorian (Florian Pelz) wrote on 12 Apr 2020 10:56
(name . Bengt Richter)(address . bokr@bokr.com)(address . 40538@debbugs.gnu.org)
20200412085621.5pzvrgs3rg3mvrsy@pelzflorian.localdomain
On Sun, Apr 12, 2020 at 08:37:02AM +0200, Bengt Richter wrote:
Toggle quote (2 lines)
> Did you mean s/ksmcon/kmscon/ ?

Yes.


Toggle quote (10 lines)
> 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
P
P
pelzflorian (Florian Pelz) wrote on 12 Apr 2020 11:02
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40538@debbugs.gnu.org)
20200412090257.jxljqbkwfhn7afnr@pelzflorian.localdomain
On Sat, Apr 11, 2020 at 10:59:10PM +0200, Ludovic Courtès wrote:
Toggle quote (2 lines)
> I made the following adjustments.

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


Toggle quote (5 lines)
> 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
P
P
pelzflorian (Florian Pelz) wrote on 12 Apr 2020 11:23
(name . Efraim Flashner)(address . efraim@flashner.co.il)
20200412092330.4tgmyv24wbeaopnc@pelzflorian.localdomain
On Sun, Apr 12, 2020 at 12:11:52AM +0300, Efraim Flashner wrote:
Toggle quote (7 lines)
> > (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@pelzflorian.de>
Date: Sun, 12 Apr 2020 11:08:28 +0200
Subject: [PATCH] services: kernel-module-loader: Clean up.

Suggested by Efraim Flashner <efraim@flashner.co.il>.

* gnu/services/linux.scm (kernel-module-loader-shepherd-service):
Remove unneeded 'respawn?' field.
---
gnu/services/linux.scm | 1 -
1 file changed, 1 deletion(-)

Toggle diff (14 lines)
diff --git a/gnu/services/linux.scm b/gnu/services/linux.scm
index 781a61973c..12934c2084 100644
--- a/gnu/services/linux.scm
+++ b/gnu/services/linux.scm
@@ -142,7 +142,6 @@ representation."
(documentation "Load kernel modules.")
(provision '(kernel-module-loader))
(requirement '(file-systems))
- (respawn? #f)
(one-shot? #t)
(modules `((srfi srfi-1)
(srfi srfi-34)
--
2.26.0
P
P
pelzflorian (Florian Pelz) wrote on 12 Apr 2020 13:24
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40538@debbugs.gnu.org)
20200412112400.x4qufeztdnkmzqhx@pelzflorian.localdomain
On Sun, Apr 12, 2020 at 11:02:57AM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (4 lines)
> 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
P
P
pelzflorian (Florian Pelz) wrote on 12 Apr 2020 14:33
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40538@debbugs.gnu.org)
20200412123335.s3bm4s4fktran6n5@pelzflorian.localdomain
On Sun, Apr 12, 2020 at 01:24:00PM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (3 lines)
> Also with uvesafb my Acer Aspire with ATI Radeon boots fine without
> kernel parameters.

So does my Uniwill U50SI1 which previously did not work.
L
L
Ludovic Courtès wrote on 12 Apr 2020 16:28
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87pnccok1n.fsf@gnu.org
Hi,

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

Toggle quote (24 lines)
> 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@pelzflorian.de>
> Date: Sun, 12 Apr 2020 11:08:28 +0200
> Subject: [PATCH] services: kernel-module-loader: Clean up.
>
> Suggested by Efraim Flashner <efraim@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’.
M
M
Mathieu Othacehe wrote on 12 Apr 2020 16:48
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
874ktooj3v.fsf@gmail.com
Hey!

Toggle quote (4 lines)
> 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:

Toggle snippet (6 lines)
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

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
P
P
pelzflorian (Florian Pelz) wrote on 12 Apr 2020 17:30
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)
20200412153052.ewxdd6m4f6yar2jw@pelzflorian.localdomain
On Sun, Apr 12, 2020 at 04:48:36PM +0200, Mathieu Othacehe wrote:
Toggle quote (14 lines)
> 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.



Toggle quote (6 lines)
> 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
B
B
Bengt Richter wrote on 12 Apr 2020 19:48
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
20200412174819.GA10140@LionPure
Hi Florian,

On +2020-04-12 17:30:52 +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (22 lines)
> 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
I see (hand-wrapped, and boxing what I thought might be extra interesting):
Toggle snippet (19 lines)
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. ?
?????????????????????????????????????????????????????????????????
Also there are various options for compiling in vs modprobe vs kernel params etc
v86d could be missing for various reasons in a particular run-time context?

Toggle quote (15 lines)
>
> > 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
P
P
pelzflorian (Florian Pelz) wrote on 12 Apr 2020 20:11
(name . Bengt Richter)(address . bokr@bokr.com)
20200412181101.tfhtbyviwqbwsaqg@pelzflorian.localdomain
On Sun, Apr 12, 2020 at 07:48:19PM +0200, Bengt Richter wrote:
Toggle quote (2 lines)
> 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
P
P
pelzflorian (Florian Pelz) wrote on 12 Apr 2020 20:33
(name . Ludovic Courtès)(address . ludo@gnu.org)
20200412183356.atvlducto244zoh2@pelzflorian.localdomain
On Sun, Apr 12, 2020 at 04:28:20PM +0200, Ludovic Courtès wrote:
Toggle quote (4 lines)
> Yes, you can push it to ‘version-1.1.0’, which we’ll eventually merge to
> ‘master’.
>

Done.

Toggle quote (4 lines)
> 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
B
B
Bengt Richter wrote on 13 Apr 2020 07:00
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
20200413050026.GA17633@LionPure
Hi Florian,

On +2020-04-12 20:11:01 +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (14 lines)
> 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 :)

Toggle quote (2 lines)
> 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 ;-)

Toggle quote (8 lines)
> 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?

Toggle quote (4 lines)
>
> Regards,
> Florian

--
Regards,
Bengt Richter
P
P
pelzflorian (Florian Pelz) wrote on 13 Apr 2020 07:37
(name . Bengt Richter)(address . bokr@bokr.com)
20200413053725.5fwe57hyz7vkhlbq@pelzflorian.localdomain
On Mon, Apr 13, 2020 at 07:00:26AM +0200, Bengt Richter wrote:
Toggle quote (2 lines)
> 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.


Toggle quote (4 lines)
> 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/v86dare from 2014.
However we patch v86d to use a more recent x86emu. Maybe there is
some incompatibility.

Toggle quote (5 lines)
> 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
M
M
Mathieu Othacehe wrote on 14 Apr 2020 09:24
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
871roqlebf.fsf@gmail.com
Hello Florian,

Toggle quote (3 lines)
> 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
P
P
pelzflorian (Florian Pelz) wrote on 14 Apr 2020 10:16
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)
20200414081652.vjdu7d6w2u5piud4@pelzflorian.localdomain
On Tue, Apr 14, 2020 at 09:24:52AM +0200, Mathieu Othacehe wrote:
Toggle quote (14 lines)
>
> 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
P
P
pelzflorian (Florian Pelz) wrote on 14 Apr 2020 10:34
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)(address . 40538@debbugs.gnu.org)
20200414083434.jwx4p5psgvqtxhzp@pelzflorian.localdomain
On Tue, Apr 14, 2020 at 10:16:52AM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (4 lines)
> 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
P
P
pelzflorian (Florian Pelz) wrote on 14 Apr 2020 10:57
(name . Bengt Richter)(address . bokr@bokr.com)(address . 40538@debbugs.gnu.org)
20200414085727.jykhlpmt46tf6udt@pelzflorian.localdomain
On Mon, Apr 13, 2020 at 07:37:25AM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (2 lines)
> 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
L
L
Ludovic Courtès wrote on 14 Apr 2020 12:09
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87h7xmz8dz.fsf@gnu.org
Hi,

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

Toggle quote (15 lines)
> 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.

Toggle quote (3 lines)
> 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’.
P
P
pelzflorian (Florian Pelz) wrote on 14 Apr 2020 12:28
(name . Ludovic Courtès)(address . ludo@gnu.org)
20200414102838.n776paycpuy6kykx@pelzflorian.localdomain
On Tue, Apr 14, 2020 at 12:09:12PM +0200, Ludovic Courtès wrote:
Toggle quote (4 lines)
> 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
P
P
pelzflorian (Florian Pelz) wrote on 14 Apr 2020 15:14
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40538@debbugs.gnu.org)
20200414131404.gzashg4iyuyfdoua@pelzflorian.localdomain
On Tue, Apr 14, 2020 at 12:28:38PM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (7 lines)
> 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
L
L
Ludovic Courtès wrote on 14 Apr 2020 16:12
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 40538@debbugs.gnu.org)
873696xik3.fsf@gnu.org
Hi Florian,

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

Toggle quote (19 lines)
> 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.

Toggle quote (2 lines)
> Maybe the shepherd service should be renamed.

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

Thank you!

Ludo’.
M
M
Mathieu Othacehe wrote on 14 Apr 2020 19:09
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87pnca9epo.fsf@gmail.com
Hey Florian,

Toggle quote (4 lines)
> 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
P
P
pelzflorian (Florian Pelz) wrote on 14 Apr 2020 23:31
(name . Mathieu Othacehe)(address . m.othacehe@gmail.com)
20200414213137.zerxceuddei4vga6@pelzflorian.localdomain
On Tue, Apr 14, 2020 at 07:09:23PM +0200, Mathieu Othacehe wrote:
Toggle quote (18 lines)
>
> 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
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 40538@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 40538
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch