Hi Florian, "pelzflorian (Florian Pelz)" <[email protected]> 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 <[email protected]> > 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’.
