From mboxrd@z Thu Jan 1 00:00:00 1970 From: "pelzflorian (Florian Pelz)" Subject: bug#40538: installer: Support uvesafb to install on machines without KMS. Date: Sun, 12 Apr 2020 20:11:01 +0200 Message-ID: <20200412181101.tfhtbyviwqbwsaqg@pelzflorian.localdomain> References: <20200410125447.smn6xhcixe7hpday@pelzflorian.localdomain> <87tv1rv21e.fsf@gnu.org> <20200411184346.c3cgop7egcjyqzwf@pelzflorian.localdomain> <874ktpspr5.fsf@gnu.org> <20200412090257.jxljqbkwfhn7afnr@pelzflorian.localdomain> <20200412112400.x4qufeztdnkmzqhx@pelzflorian.localdomain> <874ktooj3v.fsf@gmail.com> <20200412153052.ewxdd6m4f6yar2jw@pelzflorian.localdomain> <20200412174819.GA10140@LionPure> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:53053) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNh5P-00068l-B8 for bug-guix@gnu.org; Sun, 12 Apr 2020 14:12:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jNh5O-0007vO-FX for bug-guix@gnu.org; Sun, 12 Apr 2020 14:12:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:47281) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jNh5O-0007uy-3x for bug-guix@gnu.org; Sun, 12 Apr 2020 14:12:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jNh5N-0007Rd-UR for bug-guix@gnu.org; Sun, 12 Apr 2020 14:12:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <20200412174819.GA10140@LionPure> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane-mx.org@gnu.org Sender: "bug-Guix" To: Bengt Richter Cc: 40538@debbugs.gnu.org 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 and it should be impossible for v86d to be missing. On x86_64 and 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. Regards, Florian