GNU bug report logs - #60010
[version 1.4.0] AMD screen stays black; modprobe fails

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 60010 in the body.
You can then email your comments to 60010 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: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Mon, 12 Dec 2022 17:27:00 +0100

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

Just now I tried the installer on an AMD desktop but the graphical
installer screen stays black.  Same on an AMD laptop.  After switching
to another TTY, dmesg tells me this:

> [   11.625264] shepherd[1]: Service host-name has been started.
> [   11.625839] shepherd[1]: Service user-homes has been started.
> [   11.629846] shepherd[1]: 
> [   11.630078] [
> [   11.630230] modprobe
> [   11.630382] ] 
> [   11.630592] modprobe: FATAL: Module uvesafb not found in directory /lib/modules/6.0.10-gnu
> 
> [   11.631734] shepherd[1]: Failed to start maybe-uvesafb in the background.
> [   15.185776] 0000:04:00.0: Missing Free firmware (non-Free firmware loading is disabled)

I tried manually running the modprobe command from
gnu/system/install.scm:

/gnu/store/vh4g56m35wwlfg300s4qafykxjy09511-kmod-29/bin/modprobe uvesafb v86d=/gnu/store/na24a7653hyf0pghhw9nhfr6mi15v6cz-v86d-0.1.10/sbin/v86d mode_option=1024x768

Works fine.  I can switch back by Ctrl-Alt-F1 and the graphical
installer works.

/run/current-system/kernel/lib/modules/6.0.10-gnu/kernel/drivers/video/fbdev/uvesafb.ko.gz
exists.

So I tried waiting until it exists before modprobe (in the attached
patch).  But modprobe still fails in the same way, according to dmesg,
even though the file evidently already existed.

Why doesn’t modprobe find it?  Where does it look?

I will try tomorrow to get an strace.  The installer worked fine in …
August I believe.

Regards,
Florian

[installer-Fix-uvesafb-not-loading.patch (text/x-patch, attachment)]

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

From: Josselin Poiret <dev <at> jpoiret.xyz>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>,
 60010 <at> debbugs.gnu.org
Subject: Re: bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Mon, 12 Dec 2022 21:11:55 +0100

Hi Florian,

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

> So I tried waiting until it exists before modprobe (in the attached
> patch).  But modprobe still fails in the same way, according to dmesg,
> even though the file evidently already existed.

I don't think there's a race issue with the files being available:
shepherd should start after system activation (so /run/current-system
exists), and after /gnu/store was mounted in the early userspace.

> I will try tomorrow to get an strace.  The installer worked fine in …
> August I believe.

You could also probably try logging the system* call in some temporary
log file, by using some bash redirection (or with-current-output-port
and friends).

By the way, why is the modprobe binary inside a #+?  The target will want
to be able to run the binary itself, right?  Shouldn't it be #$?

Best,
-- 
Josselin Poiret

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: 60010 <at> debbugs.gnu.org
Subject: Re: bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Tue, 13 Dec 2022 00:18:52 +0100

Hi Florian,

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

> Just now I tried the installer on an AMD desktop but the graphical
> installer screen stays black.  Same on an AMD laptop.  After switching
> to another TTY, dmesg tells me this:
>
>> [   11.625264] shepherd[1]: Service host-name has been started.
>> [   11.625839] shepherd[1]: Service user-homes has been started.
>> [   11.629846] shepherd[1]: 
>> [   11.630078] [
>> [   11.630230] modprobe
>> [   11.630382] ] 
>> [   11.630592] modprobe: FATAL: Module uvesafb not found in directory /lib/modules/6.0.10-gnu

[...]

> @@ -289,11 +289,18 @@ (define (uvesafb-shepherd-service _)
>           (provision '(maybe-uvesafb))
>           (requirement '(file-systems))
>           (start #~(lambda ()
> -                    (or (file-exists? "/dev/fb0")
> -                        (invoke #+(file-append kmod "/bin/modprobe")
> +		    (define (start-uvesafb)
> +		      ;; HOW TO DO THIS THE RIGHT WAY??
> +		      (if (file-exists? "/run/current-system/kernel/lib\
> +/modules/6.0.10-gnu/kernel/drivers/video/fbdev/uvesafb.ko.gz")
> +			  (invoke #+(file-append kmod "/bin/modprobe")
>                                  "uvesafb"
>                                  (string-append "v86d=" #$v86d "/sbin/v86d")
> -                                "mode_option=1024x768"))))
> +                                "mode_option=1024x768")

The ‘kmod’ package is patched to honor $LINUX_MODULE_DIRECTORY.
However, that variable is unset here:

--8<---------------cut here---------------start------------->8---
$ sudo cat /proc/1/environ |xargs -0
HOME=/ TERM=linux BOOT_IMAGE=/gnu/store/04ac4skvnrfdsdw7z3rl3ya8spcgsn6g-linux-libre-6.0.10/bzImage PATH=/gnu/store/zyk2b4zmy3vcaqs67s2czb6nsrbf3b68-e2fsck-static-1.46.4/sbin:/gnu/store/cchslqkqm3qix71bsjr72mw9fd85p8a5-loadkeys-static-2.5.1/bin GUIX_LOCPATH=/gnu/store/mw3py6smb1pk8yx298hd9ivz9lzbksqi-glibc-utf8-locales-2.33/lib/locale
--8<---------------cut here---------------end--------------->8---

So you may need to add:

  (setenv "LINUX_MODULE_DIRECTORY" "/run/booted-system/kernel/lib/modules")

Besides, but that’s more about aesthetics, it would make sense to use
(gnu build linux-modules) instead of calling out to ‘modprobe’, along
these lines:

  (load-linux-modules-from-directory '("uvesafb")
                                     "/run/booted-system/kernel/lib/modules")

HTH!

Ludo’.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: 60010 <at> debbugs.gnu.org
Subject: Re: bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Tue, 13 Dec 2022 11:00:34 +0100

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

Ludovic Courtès <ludo <at> gnu.org> skribis:

> So you may need to add:
>
>   (setenv "LINUX_MODULE_DIRECTORY" "/run/booted-system/kernel/lib/modules")

Specifically, here’s the minimal change we should test:

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

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index f6f1923121..a512ace29e 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -289,11 +289,16 @@ (define (uvesafb-shepherd-service _)
          (provision '(maybe-uvesafb))
          (requirement '(file-systems))
          (start #~(lambda ()
-                    (or (file-exists? "/dev/fb0")
-                        (invoke #+(file-append kmod "/bin/modprobe")
-                                "uvesafb"
-                                (string-append "v86d=" #$v86d "/sbin/v86d")
-                                "mode_option=1024x768"))))
+                    (unless (file-exists? "/dev/fb0")
+                      (setenv "LINUX_MODULE_DIRECTORY"
+                              "/run/booted-system/kernel/lib/modules")
+                      ;; TODO: Use 'load-linux-modules-from-directory' instead.
+                      (invoke #+(file-append kmod "/bin/modprobe")
+                              "uvesafb"
+                              (string-append "v86d=" #$v86d "/sbin/v86d")
+                              "mode_option=1024x768")
+                      (unsetenv "LINUX_MODULE_DIRECTORY")
+                      #t)))
          (respawn? #f)
          (one-shot? #t))))
 

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

Thanks,
Ludo’.

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Josselin Poiret <dev <at> jpoiret.xyz>
Cc: 60010 <at> debbugs.gnu.org
Subject: Re: bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Tue, 13 Dec 2022 13:29:05 +0100

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

Thank you Josselin.

Josselin Poiret <dev <at> jpoiret.xyz> writes:
> I don't think there's a race issue with the files being available:

Yes apparently, but it is some kind of race.

BTW it happens on master branch too despite its more recent linux.

> By the way, why is the modprobe binary inside a #+?  The target will want
> to be able to run the binary itself, right?  Shouldn't it be #$?

You are right, I guess.  But I will later try replacing it with Ludo’s
load-linux-modules-from-directory instead.  Perhaps that even gets the
install image small enough for a CDROM again? :)

>> I will try tomorrow to get an strace.  The installer worked fine in …
>> August I believe.
>
> You could also probably try logging the system* call in some temporary
> log file, by using some bash redirection (or with-current-output-port
> and friends).

I replaced the “(invoke #+(file-append kmod "/bin/modprobe") "uvesafb" …”
by a convoluted

(with-output-to-file "/tmp/strace"
  (lambda ()
    (with-error-to-port
     (current-output-port)
     (lambda ()
       (open-pipe* OPEN_READ
                   #+(file-append strace "/bin/strace")
                   "-f"
                   #+(file-append kmod "/bin/modprobe")
                   "uvesafb"

but now the strace is a workaround and the modprobe succeeds.  Either
way, /tmp/strace shows that modprobe first reads
/run/booted-system/kernel/lib/modules/6.0.10-gnu/modules.softdep and the
like.  The successful strace only eventually goes on to read
uvesafb.ko.gz.

For completeness, the strace ends with

[strace (text/plain, inline)]

openat(AT_FDCWD, "/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0203\0\0\0\0\0\0"..., 832) = 832
pread64(3, "\4\0\0\0 \0\0\0\5\0\0\0GNU\0\1\0\1\300\4\0\0\0\v\0\0\0\0\0\0\0"..., 48, 94696) = 48
newfstatat(3, "", {st_mode=S_IFREG|0444, st_size=100760, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc734a32000
mmap(NULL, 103496, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc734a18000
mmap(0x7fc734a1b000, 69632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fc734a1b000
mmap(0x7fc734a2c000, 16384, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x7fc734a2c000
mmap(0x7fc734a30000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7fc734a30000
close(3)                                = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc734a15000
arch_prctl(ARCH_SET_FS, 0x7fc734a15740) = 0
mprotect(0x7fc734be7000, 16384, PROT_READ) = 0
mprotect(0x7fc734a30000, 4096, PROT_READ) = 0
mprotect(0x7fc734c11000, 4096, PROT_READ) = 0
mprotect(0x7fc734c2d000, 4096, PROT_READ) = 0
mprotect(0x7fc734c5a000, 4096, PROT_READ) = 0
mprotect(0x7fc734d69000, 4096, PROT_READ) = 0
mprotect(0x425000, 4096, PROT_READ)     = 0
mprotect(0x7fc734d9c000, 8192, PROT_READ) = 0
munmap(0x7fc734d6b000, 6584)            = 0
set_tid_address(0x7fc734a15a10)         = 153
set_robust_list(0x7fc734a15a20, 24)     = 0
rt_sigaction(SIGRTMIN, {sa_handler=0x7fc734c196a0, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fc734c24d80}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {sa_handler=0x7fc734c19740, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7fc734c24d80}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
brk(NULL)                               = 0x1882000
brk(0x18a3000)                          = 0x18a3000
uname({sysname="Linux", nodename="gnu", ...}) = 0
newfstatat(AT_FDCWD, "/gnu/store/vh4g56m35wwlfg300s4qafykxjy09511-kmod-29/etc/modprobe.d", 0x7ffe93ffa1f0, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/run/modprobe.d", 0x7ffe93ffa1f0, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/usr/local/lib/modprobe.d", 0x7ffe93ffa1f0, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib/modprobe.d", 0x7ffe93ffa1f0, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/run/booted-system/kernel/lib/modules/6.0.10-gnu/modules.softdep", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_GETFL)                       = 0x8000 (flags O_RDONLY|O_LARGEFILE)
newfstatat(3, "", {st_mode=S_IFREG|0444, st_size=1424, ...}, AT_EMPTY_PATH) = 0
read(3, "# Soft dependencies extracted fr"..., 2048) = 1424
read(3, "", 2048)                       = 0
close(3)                                = 0
openat(AT_FDCWD, "/proc/cmdline", O_RDONLY|O_CLOEXEC) = 3
read(3, "BOOT_IMAGE=/gnu/store/3qdad0k7wv"..., 4095) = 300
read(3, "", 3795)                       = 0
close(3)                                = 0
openat(AT_FDCWD, "/run/booted-system/kernel/lib/modules/6.0.10-gnu/modules.dep.bin", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0444, st_size=1050966, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 1050966, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc734914000
close(3)                                = 0
openat(AT_FDCWD, "/run/booted-system/kernel/lib/modules/6.0.10-gnu/modules.alias.bin", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0444, st_size=1522188, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 1522188, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc7347a0000
close(3)                                = 0
openat(AT_FDCWD, "/run/booted-system/kernel/lib/modules/6.0.10-gnu/modules.symbols.bin", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0444, st_size=780289, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 780289, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc7346e1000
close(3)                                = 0
openat(AT_FDCWD, "/run/booted-system/kernel/lib/modules/6.0.10-gnu/modules.builtin.alias.bin", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0444, st_size=0, ...}, AT_EMPTY_PATH) = 0
close(3)                                = 0
openat(AT_FDCWD, "/run/booted-system/kernel/lib/modules/6.0.10-gnu/modules.builtin.bin", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0444, st_size=12061, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 12061, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc7346de000
close(3)                                = 0
openat(AT_FDCWD, "/sys/module/uvesafb/initstate", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/sys/module/uvesafb", 0x7ffe93ffa110, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/sys/module/uvesafb/initstate", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/sys/module/uvesafb", 0x7ffe93ffa110, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/run/booted-system/kernel/lib/modules/6.0.10-gnu/kernel/drivers/video/fbdev/uvesafb.ko.gz", O_RDONLY|O_CLOEXEC) = 3
read(3, "\37\213\10\0\0\0", 6)          = 6
lseek(3, 0, SEEK_SET)                   = 0
lseek(3, 0, SEEK_CUR)                   = 0
mmap(NULL, 4198400, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc7342dd000
read(3, "\37\213\10\0\0\0\0\0\0\3\354}\17x\24\325\271\367l\262\204\5\301\211\210\n^\257\214mPh"..., 8192) = 8192
read(3, "\235.\211\323\224\200\263\3015\2\347\1W\361\307\223\327j\364\256:\237\7g\237\4|#\274\36|\253"..., 8192) = 6966
read(3, "", 1226)                       = 0
init_module(0x7fc7342dd010, 54160, "v86d=/gnu/store/na24a7653hyf0pgh"...) = 0
munmap(0x7fc7342dd000, 4198400)         = 0
close(3)                                = 0
munmap(0x7fc734914000, 1050966)         = 0
munmap(0x7fc7347a0000, 1522188)         = 0
munmap(0x7fc7346e1000, 780289)          = 0
munmap(0x7fc7346de000, 12061)           = 0
exit_group(0)                           = ?
+++ exited with 0 +++

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

Regards,
Florian

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 60010 <at> debbugs.gnu.org
Subject: Re: bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Tue, 13 Dec 2022 13:50:57 +0100

Ludovic Courtès <ludo <at> gnu.org> writes:
> Specifically, here’s the minimal change we should test:[…]
> +                    (unless (file-exists? "/dev/fb0")
> +                      (setenv "LINUX_MODULE_DIRECTORY"
> +                              "/run/booted-system/kernel/lib/modules")

Thanks for the patch.

I found I can test in QEMU if I put nomodeset in the kernel arguments
in GRUB.

Without the patch, the screen stays black there too.
With the patch, it hrmm it also stays black.

I will next try using 'load-linux-modules-from-directory' and no
modprobe.

Regards,
Florian

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: 60010 <at> debbugs.gnu.org
Subject: Re: bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Tue, 13 Dec 2022 14:03:11 +0100

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

> Ludovic Courtès <ludo <at> gnu.org> writes:
>> Specifically, here’s the minimal change we should test:[…]
>> +                    (unless (file-exists? "/dev/fb0")
>> +                      (setenv "LINUX_MODULE_DIRECTORY"
>> +                              "/run/booted-system/kernel/lib/modules")
>
> Thanks for the patch.
>
> I found I can test in QEMU if I put nomodeset in the kernel arguments
> in GRUB.
>
> Without the patch, the screen stays black there too.
> With the patch, it hrmm it also stays black.

Do you see hints as to whether uvesafb gets loaded?

You can do that by adding “console=ttyS0” to the kernel arguments and by
passing ‘-serial stdio’ to QEMU.

Ludo’.

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 60010 <at> debbugs.gnu.org
Subject: Re: bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Tue, 13 Dec 2022 14:51:12 +0100

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

"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> writes:
> I will next try using 'load-linux-modules-from-directory' and no
> modprobe.

I tried the attached patch.  Doesn’t work, still black (in QEMU).

Says the dmesg:
> [   11.183789] shepherd[1]: Service user-homes has been started.
> [   11.184555] shepherd[1]: Service user-processes has been started.
> [   11.185587] shepherd[1]: Service host-name has been started.
> [   11.186350] shepherd[1]: Service user-homes has been started.
> [   11.187383] shepherd[1]: Failed to start maybe-uvesafb in the background.
> [   15.213524] 8021q: 802.1Q VLAN Support v1.8
> [   15.213541] 8021q: adding VLAN 0 to HW filter on device eth0

And nothing more.

Maybe there is a mistake in my patch.

Regards,
Florian

[load-linux-modules.patch (text/x-patch, attachment)]

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: 60010 <at> debbugs.gnu.org
Subject: Re: bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Tue, 13 Dec 2022 17:37:01 +0100

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

>           (provision '(maybe-uvesafb))
>           (requirement '(file-systems))
>           (start #~(lambda ()
> -                    (or (file-exists? "/dev/fb0")
> -                        (invoke #+(file-append kmod "/bin/modprobe")
> -                                "uvesafb"
> -                                (string-append "v86d=" #$v86d "/sbin/v86d")
> -                                "mode_option=1024x768"))))
> +                    (unless (file-exists? "/dev/fb0")
> +                      (load-linux-modules-from-directory '("uvesafb") "\
> +/run/booted-system/kernel/lib/modules"))))

To make it work, you’d need to add a ‘modules’ field so that (gnu build
linux-modules) is in scope, plus throw in ‘with-imported-modules’.

I’d say let’s stick to the minimal change where we still invoke
‘modprobe’.

Ludo’.

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 60010 <at> debbugs.gnu.org
Subject: Re: bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Wed, 14 Dec 2022 14:49:46 +0100

Ludovic Courtès <ludo <at> gnu.org> writes:
> Do you see hints as to whether uvesafb gets loaded?
>
> You can do that by adding “console=ttyS0” to the kernel arguments and by
> passing ‘-serial stdio’ to QEMU.

This serial output shows nothing about uvesafb, but dmesg contains about
uvesafb exactly the same modprobe failure as initially without
LINUX_MODULE_DIRECTORY.

I shall try Brice Waegeneire’s kernel-module-loader-service.  This
cannot be a solution because some computers do already have /dev/fb0 and
doing modprobe uvesafb regardless makes their screen go awry.  But it
will be interesting to know if it still works.

Also of course uvesafb still worked fine in November when we added
hardware support warnings to the installer, not long ago, not August.
Probably restoring the old linux kernel would be a workaround too.

Regards,
Florian

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: 60010 <at> debbugs.gnu.org
Subject: Re: bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Thu, 15 Dec 2022 00:29:32 +0100

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

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

> Ludovic Courtès <ludo <at> gnu.org> writes:
>> Do you see hints as to whether uvesafb gets loaded?
>>
>> You can do that by adding “console=ttyS0” to the kernel arguments and by
>> passing ‘-serial stdio’ to QEMU.
>
> This serial output shows nothing about uvesafb, but dmesg contains about
> uvesafb exactly the same modprobe failure as initially without
> LINUX_MODULE_DIRECTORY.

Oooh.  ‘invoke’ uses ‘system*’, and in shepherd 0.9.3, ‘system*’ is
implemented in terms of ‘fork+exec-command’, which only passes the
environment variables listed in ‘default-environment-variables’ by
default.  Thus, (setenv "LINUX_MODULE_DIRECTORY" …) had no effect on the
child process; it just wouldn’t see LINUX_MODULE_DIRECTORY.

I think the patch below will be good… or very close to it.

Lemme know!

Thanks,
Ludo’.

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

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index f6f1923121..e524729baf 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -289,11 +289,21 @@ (define (uvesafb-shepherd-service _)
          (provision '(maybe-uvesafb))
          (requirement '(file-systems))
          (start #~(lambda ()
-                    (or (file-exists? "/dev/fb0")
+                    (unless (file-exists? "/dev/fb0")
+                      ;; In shepherd 0.9.3, 'system*' is implemented in terms
+                      ;; of 'fork+exec-command'.  Thus, set
+                      ;; 'default-environment-variables' to pass an extra
+                      ;; variable to the child process.
+                      (parameterize ((default-environment-variables
+                                       `("LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules"
+                                         ,(environ))))
+                        ;; TODO: Use 'load-linux-modules-from-directory'
+                        ;; instead.
                         (invoke #+(file-append kmod "/bin/modprobe")
                                 "uvesafb"
                                 (string-append "v86d=" #$v86d "/sbin/v86d")
-                                "mode_option=1024x768"))))
+                                "mode_option=1024x768"))
+                      #t)))
          (respawn? #f)
          (one-shot? #t))))
 

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 60010 <at> debbugs.gnu.org
Subject: Re: bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Thu, 15 Dec 2022 18:42:59 +0100

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

Hello Ludo, sorry to say I attempted your modprobe patch that uses
(parameterize ((default-environment-variables …

No good.  Screen is black.  Same [ modprobe ] failure in dmesg on QEMU
and on real AMD hardware.

There are workarounds by surrounding modprobe within strace or
alternatively using kernel-module-loader-service (attached; but again,
without the file-exists? check, this would cause new issues on some
machines that dont need uvesafb).

A stupid

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index f6f1923121..a99cf09e31 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -289,6 +289,7 @@ (define (uvesafb-shepherd-service _)
          (provision '(maybe-uvesafb))
          (requirement '(file-systems))
          (start #~(lambda ()
+                   (sleep 1)
                     (or (file-exists? "/dev/fb0")
                         (invoke #+(file-append kmod "/bin/modprobe")
                                 "uvesafb"


fails though.

All bad…

Regards,
Florian

[use-kernel-module-loader.patch (text/x-patch, attachment)]

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: 60010 <at> debbugs.gnu.org
Subject: Re: bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Fri, 16 Dec 2022 00:37:45 +0100

Hi Florian,

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

> Hello Ludo, sorry to say I attempted your modprobe patch that uses
> (parameterize ((default-environment-variables …

Bah, turns out it’s trickier than this.  See
<https://issues.guix.gnu.org/60106>.

I figured I could test it in a VM.  I ended up with a minimal change,
pushed in commit b1aef25453067004279c4267cf25e8d6d365890d, that lets
modprobe load uvesafb for good (it was all about setting
‘LINUX_MODULE_DIRECTORY’).

Let me know if anything’s amiss!

Thanks,
Ludo’.

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

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 60010 <at> debbugs.gnu.org
Subject: Re: bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Date: Fri, 16 Dec 2022 12:48:46 +0100

Ludovic Courtès <ludo <at> gnu.org> writes:
> I ended up with a minimal change,
> pushed in commit b1aef25453067004279c4267cf25e8d6d365890d, that lets
> modprobe load uvesafb for good (it was all about setting
> ‘LINUX_MODULE_DIRECTORY’).

Thank you Ludo for your excellent work.  All is good now on AMD hardware
(my laptop and PC).  I’m still not sure why LINUX_MODULE_DIRECTORY is
needed here and is not needed for kernel module loader service, but
whatever.

Regards,
Florian

Previous Next

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