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
