bug#40538: installer: Support uvesafb to install on machines without KMS.

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)" <address@hidden> 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 <address@hidden>
> 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’.