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

From: Bengt Richter <[email-masked]>
Date: Mon, 13 Apr 2020 07:00:26 +0200

Hi Florian,

On +2020-04-12 20:11:01 +0200, pelzflorian (Florian Pelz) wrote:
> On Sun, Apr 12, 2020 at 07:48:19PM +0200, Bengt Richter wrote:
> > Could it be segfaulting trying to access a missing v86d ?
> 
> The code for loading the uvesafb module looks like this:
> 
> (invoke #+(file-append kmod "/bin/modprobe")
>         "uvesafb"
>         (string-append "v86d=" #$v86d "/sbin/v86d")
>         "mode_option=1024x768"))))
> 
> So it should call
> 
> modprobe uvesafb v86d=/gnu/store/…-v86d-…/sbin/v86d mode_option=1024x768
>
Thanks for explaining. I hope others benefit too :)

> and it should be impossible for v86d to be missing.  On x86_64 and

Hm, could it be there in /gnu/store and have been built so it's a wrong
version somehow for the running kernel? That's the only bug possibility
I can think of now ;-)

> i686 at least, and on other architectures uvesafb will not be loaded.
> 
> Then again, if the GUI works because of other drivers already, we need
> not fix it, I think.  Also I still believe the error comes because
> other drivers already reserve needed memory -- passing nomodeset
> should make sure they don’t.  Except if vesafb or xf86-video-vesa is
> loaded, which is not the case in the installer.

sudo dmesg|grep -i fb in that context doesn't show anything weird?

Oh, well. Sorry I don't seem to be able to accept a mystery sigsev ;-)
Could it be wrapped and caught in a catch?

> Regards,
> Florian

-- 
Regards,
Bengt Richter