bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Ludovic Courtès 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

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Hi Florian, "pelzflorian (Florian Pelz)" 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 . I figured I could test it in a VM. I

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

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

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

"pelzflorian (Florian Pelz)" skribis: > Ludovic Courtès 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

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Ludovic Courtès 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

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

"pelzflorian (Florian Pelz)" skribis: > (provision '(maybe-uvesafb)) > (requirement '(file-systems)) > (start #~(lambda () > -(or (file-exists? "/dev/fb0") > -(invoke #+(file-append kmod "/bin/modprobe") > -

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

"pelzflorian (Florian Pelz)" 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]:

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

"pelzflorian (Florian Pelz)" skribis: > Ludovic Courtès writes: >> Specifically, here’s the minimal change we should test:[…] >> +(unless (file-exists? "/dev/fb0") >> + (setenv "LINUX_MODULE_DIRECTORY" >> +

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Ludovic Courtès 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.

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Thank you Josselin. Josselin Poiret 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

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Ludovic Courtès 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: diff --git a/gnu/system/install.scm b/gnu/system/install.scm index f6f1923121..a512ace29e 100644 ---

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Hi Florian, "pelzflorian (Florian Pelz)" 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

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Hi Florian, "pelzflorian (Florian Pelz)" 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

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

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