From mboxrd@z Thu Jan 1 00:00:00 1970 From: "pelzflorian (Florian Pelz)" Subject: bug#40599: 1.1.0rc2 i686 gui install unreadable Date: Tue, 14 Apr 2020 15:22:00 +0200 Message-ID: <20200414132200.ikfbj2famdaamfbd@pelzflorian.localdomain> References: <871rorxzpw.fsf@ficus.lan> <87pncb3yyk.fsf@gnu.org> <871roqusha.fsf@ficus.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:41971) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jOLWp-0002xy-EV for bug-guix@gnu.org; Tue, 14 Apr 2020 09:23:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jOLWo-0004wH-Ij for bug-guix@gnu.org; Tue, 14 Apr 2020 09:23:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:50106) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jOLWo-0004wB-FR for bug-guix@gnu.org; Tue, 14 Apr 2020 09:23:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jOLWo-0000fT-AT for bug-guix@gnu.org; Tue, 14 Apr 2020 09:23:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <871roqusha.fsf@ficus.lan> 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: Niels Felsted Cc: 40599@debbugs.gnu.org On Tue, Apr 14, 2020 at 03:06:25PM +0200, Niels Felsted wrote: > And testing Florians suggestions: > > setting 'nomodeset' kernel parameter -> screen displays fine > > setting 'modprobe.blacklist=i915' kernel parameter -> screen displays fine > > As mentioned before, I did manage to install guix via tty3 (without > setting any kernel parameters), and it boots up fine with > gdm3/xfce4. So it is only the initial boot from the install iso that's > distorted. Thank you for the testing! Xorg working confirms that uvesafb really is the source of the problem. This is good to know. I have hope that this issue is fixed by commit 0ad60b2a89d6d387236466e0bcdd61ac489fca37 that loads uvesafb only if it cannot already detect a frame buffer device. I do not have a downloadable image for confirming the fix though. Sorry I did not think of checking the presence of /dev/fb0 earlier. Regards, Florian