Thank you Josselin.

Josselin Poiret <dev@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