1.1.0rc2 i686 gui install unreadable

  • Done
  • quality assurance status badge
Details
3 participants
  • Ludovic Courtès
  • Niels Felsted
  • pelzflorian (Florian Pelz)
Owner
unassigned
Submitted by
Niels Felsted
Severity
important
N
N
Niels Felsted wrote on 13 Apr 2020 16:02
(address . bug-guix@gnu.org)
871rorxzpw.fsf@ficus.lan
Hello

I have have installed guix on a old laptop from. I dd'ed the iso file:

guix-system-install-1.1.0rc2.i686-linux.iso

on a usb stick, and booted from it.

It boots directly into a ncurses gui, but the screen is distorted and
it is not possible to read anything. I have attached an image showing
the issue.

I finished the install using the terminal on tty3.

I have tested the current 1.0.1 iso also, and the ncurses gui looks
fine there (though the actual install fails compiling some amdgpu
package).

The laptop is a Acer aspire 3680, with Intel Celeron cpu, 1.5gb ram
and the following graphics card:

~$ lspci | grep -e "VGA"
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

br
Niels Felsted
Attachment: gui-unreadable.jpg
L
L
Ludovic Courtès wrote on 13 Apr 2020 22:36
(name . Niels Felsted)(address . niels@pdlkrft.eu)
87pncb3yyk.fsf@gnu.org
Hi Niels,

Niels Felsted <niels@pdlkrft.eu> skribis:

Toggle quote (10 lines)
> I have have installed guix on a old laptop from. I dd'ed the iso file:
>
> guix-system-install-1.1.0rc2.i686-linux.iso
>
> on a usb stick, and booted from it.
>
> It boots directly into a ncurses gui, but the screen is distorted and
> it is not possible to read anything. I have attached an image showing
> the issue.

Ouch, indeed.

Toggle quote (2 lines)
> I finished the install using the terminal on tty3.

And tty3 displays fine, right?

Toggle quote (4 lines)
> I have tested the current 1.0.1 iso also, and the ncurses gui looks
> fine there (though the actual install fails compiling some amdgpu
> package).

OK.

Toggle quote (6 lines)
> The laptop is a Acer aspire 3680, with Intel Celeron cpu, 1.5gb ram
> and the following graphics card:
>
> ~$ lspci | grep -e "VGA"
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

I see. Could you boot the 1.1.0rc2 again and send us the
/var/log/messages file? (You can either do “herd start ssh-daemon” in
the image or run scp right from there, once networking is up, which
means you have to go to the networking dialog of the installer.)

Florian, could it be uvesafb messing with the graphics card?

Thanks a lot for testing and reporting back!

Ludo’.
P
P
pelzflorian (Florian Pelz) wrote on 13 Apr 2020 22:51
(name . Ludovic Courtès)(address . ludo@gnu.org)
20200413205125.texkpflm2t2csny2@pelzflorian.localdomain
On Mon, Apr 13, 2020 at 10:36:19PM +0200, Ludovic Courtès wrote:
Toggle quote (2 lines)
> Florian, could it be uvesafb messing with the graphics card?

Yes, maybe, if amdgpu and uvesafb both try to modeset. Apparently
yes, if it did not happen for rc1.

Please try adding a kernel parameter modprobe.blacklist=amdgpu so only
uvesafb is active. (To do that, press the E key in GRUB and move the
cursor to the end of the line starting with linux. Then type
modprobe.blacklist=amdgpu at the line’s end.)

I wonder whether it’s better to

1) revert uvesafb and break other systems again, including other AMD
ones,

2) add modprobe.blacklist=amdgpu to the default kernel parameters,
although I’m not sure if uvesafb can replace amdgpu for every screen.

Regards,
Florian
L
L
Ludovic Courtès wrote on 13 Apr 2020 22:56
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
875ze33y0m.fsf@gnu.org
Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (8 lines)
> I wonder whether it’s better to
>
> 1) revert uvesafb and break other systems again, including other AMD
> ones,
>
> 2) add modprobe.blacklist=amdgpu to the default kernel parameters,
> although I’m not sure if uvesafb can replace amdgpu for every screen.

It’s a tough choice. We know what we’d lose with option #1, but we
don’t really know what we’d lose with option #2, right?

Maybe wait and see if passing “modprobe.blacklist=amdgpu” works on
Neils’ machine?

Ludo’.
P
P
pelzflorian (Florian Pelz) wrote on 13 Apr 2020 23:06
(name . Niels Felsted)(address . niels@pdlkrft.eu)(address . 40599@debbugs.gnu.org)
20200413210650.uwuswmbv2tqpqp56@pelzflorian.localdomain
On Mon, Apr 13, 2020 at 04:02:00PM +0200, Niels Felsted wrote:
Toggle quote (3 lines)
> The laptop is a Acer aspire 3680, with Intel Celeron cpu, 1.5gb ram
> and the following graphics card:

Wait it’s Intel?? Sorry I misread. I thought I had read AMD.

It is an older machine, right? I do not know what kernel module is
responsible for Intel.

Please try adding “nomodeset” as a kernel parameter instead of
modprobe.blackliist=amdgpu.

Regards,
Florian
P
P
pelzflorian (Florian Pelz) wrote on 13 Apr 2020 23:48
(name . Niels Felsted)(address . niels@pdlkrft.eu)(address . 40599@debbugs.gnu.org)
20200413214824.4xcb5e7yvzdymru2@pelzflorian.localdomain
On Mon, Apr 13, 2020 at 11:06:50PM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (6 lines)
> On Mon, Apr 13, 2020 at 04:02:00PM +0200, Niels Felsted wrote:
> > The laptop is a Acer aspire 3680, with Intel Celeron cpu, 1.5gb ram
> > and the following graphics card:
>
> Wait it’s Intel?? Sorry I misread. I thought I had read AMD.

It’s funny how my Acer Aspire 5738PG has an old AMD/ATI Radeon and
only works with uvesafb, while uvesafb causes problems with your Acer
Aspire 3680’S old Intel GPU.

I believe “nomodeset” will help you with rc2, although it is a
regression. If you run lsmod after pressing Ctrl+Alt+F3, is there a
module called “i915”? You could try adding a kernel parameter
“modprobe.blacklist=i915” and maybe it won’t break the graphics.


Have you previously used a GNU/Linux distribution with Xorg on the
Acer Aspire (probably yes)? However could you try if after installing
you even have Xorg graphics support? If and only if you don’t have
Xorg after installation, maybe you might actually need to add uvesafb
to your config.scm to have graphics support later on.

That is in your /etc/config.scm in the services field add:

(services <here are your other services…>
(set-xorg-configuration
(xorg-configuration
(modules
(list ;it is important xf86-video-vesa is not listed
xf86-video-fbdev
xf86-input-libinput
;; you probably don’t need these:
xf86-input-evdev
xf86-input-keyboard
xf86-input-mouse
xf86-input-synaptics))
(keyboard-layout keyboard-layout)))
(service kernel-module-loader-service-type '("uvesafb"))
(simple-service 'uvesafb-configuration etc-service-type
(list `("modprobe.d/uvesafb.conf"
,(mixed-text-file
"uvesafb.conf"
"options uvesafb v86d=" v86d
"/sbin/v86d mode_option=1024x768\n")))))

and before (services …) a field (kernel-arguments '("nomodeset"))

Regards,
Florian
P
P
pelzflorian (Florian Pelz) wrote on 14 Apr 2020 02:48
(name . Ludovic Courtès)(address . ludo@gnu.org)
20200414004845.gspjxetkqdvvlfo6@pelzflorian.localdomain
On Mon, Apr 13, 2020 at 10:56:41PM +0200, Ludovic Courtès wrote:
Toggle quote (3 lines)
> It’s a tough choice. We know what we’d lose with option #1, but we
> don’t really know what we’d lose with option #2, right?

From my limited experience with my old machines and a friend’s recent
machine, uvesafb was often helpful. If nomodeset calms Niels’
Intel GMA, I would prefer keeping uvesafb.

Regards,
Florian
P
P
pelzflorian (Florian Pelz) wrote on 14 Apr 2020 15:22
(name . Niels Felsted)(address . niels@pdlkrft.eu)
20200414132200.ikfbj2famdaamfbd@pelzflorian.localdomain
On Tue, Apr 14, 2020 at 03:06:25PM +0200, Niels Felsted wrote:
Toggle quote (11 lines)
> 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
N
N
Niels Felsted wrote on 14 Apr 2020 15:06
(name . Ludovic Courtès)(address . ludo@gnu.org)
871roqusha.fsf@ficus.lan
Hi Ludovic and Florian

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (20 lines)
> Hi Niels,
>
> Niels Felsted <niels@pdlkrft.eu> skribis:
>
>> I have have installed guix on a old laptop from. I dd'ed the iso file:
>>
>> guix-system-install-1.1.0rc2.i686-linux.iso
>>
>> on a usb stick, and booted from it.
>>
>> It boots directly into a ncurses gui, but the screen is distorted and
>> it is not possible to read anything. I have attached an image showing
>> the issue.
>
> Ouch, indeed.
>
>> I finished the install using the terminal on tty3.
>
> And tty3 displays fine, right?

Yes tty3 displays fine

Toggle quote (18 lines)
>
>> I have tested the current 1.0.1 iso also, and the ncurses gui looks
>> fine there (though the actual install fails compiling some amdgpu
>> package).
>
> OK.
>
>> The laptop is a Acer aspire 3680, with Intel Celeron cpu, 1.5gb ram
>> and the following graphics card:
>>
>> ~$ lspci | grep -e "VGA"
>> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
>
> I see. Could you boot the 1.1.0rc2 again and send us the
> /var/log/messages file? (You can either do “herd start ssh-daemon” in
> the image or run scp right from there, once networking is up, which
> means you have to go to the networking dialog of the installer.)

I have attached /var/log/messages

Toggle quote (2 lines)
> Florian, could it be uvesafb messing with the graphics card?

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.

br
Niels Felsted
Attachment: messages.txt
L
L
Ludovic Courtès wrote on 14 Apr 2020 17:12
control message for bug #40599
(address . control@debbugs.gnu.org)
87ftd6w17a.fsf@gnu.org
severity 40599 important
quit
L
L
Ludovic Courtès wrote on 14 Apr 2020 17:42
Re: bug#40599: 1.1.0rc2 i686 gui install unreadable
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87a73evzu3.fsf@gnu.org
Hi Niels & Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (19 lines)
> 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.

Niels, here’s a new ISO image built from commit
bd4c345ef7ddf3542662fe0872b06393b414a3fc, which includes Florian’s fix.


Could you simply boot that image, without any additional kernel
arguments, and confirm that the installer now displays correctly? (You
don’t need to run the actual install.)

Thanks in advance,
Ludo’.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEPORkVYqE/cadtAz7CQsRmT2a67UFAl6V2dQACgkQCQsRmT2a
67Wt1BAAlkHODRL8crqiHBf8kClirrCr2MhWSl2gh6KV2r2W8pArJYCFD3fT4D5q
XfIbe/sXoh8hdtq4ma7LoDFYZqntOHgPdafjYJJjwtRe7tlZHWkDNlwfUwb14FoD
NT290PBd7y03MUkW5uKgnfPu/Z5tbjPDvpTqYYGT9UxgIyh3QIrE2W80NX5xZJTa
aEqcjwY/cFxKplQf61CFRnXCM+iqGRNJZk7BCCJ5/sPx1PUDacyIasxxfvJHI4XS
RTum9iAN/tqnhqIKAV73AWu6Vbi9mG8UrSTyr+iIT2qlT5T77hbWvhtVZmkTAb2t
ltbZHwg6HyMh9MmVHSwVKGopskMFwd+JnZl4HLsv62zRgR6xm7wjmz4L3TlfJch1
bxXQT9phgfwQLJf2bmsAMSemGs1MFC7NPNxN/Ct8ts6ZeUHM0pAG1gESyBM5COi8
ROwk8mRPuju/WitDcIYsgPrNvCiK+mvaqYu0P21d+eDB6jo431l0XnZfltY0LnRJ
LOWkmLLu5PPqXFS+81iMJapXSFLehjowKiOCVxHwjhckYHCx7Vcw9F07jwT5zE5h
uNqpXUDrHzkI+aGLi/4NMxqd/pUea1XGSIgEJZCqhF1TLLU3q6SPNj4LmFgNnxFd
KDEATV2YJ61l83b5q9oIxDbxnTXNhnmCDZLdhQ8v9CGQ9851ff8=
=PsSO
-----END PGP SIGNATURE-----

N
N
Niels Felsted wrote on 14 Apr 2020 20:20
(name . Ludovic Courtès)(address . ludo@gnu.org)
87d08aszdy.fsf@ficus.lan
Hi Ludovic

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (32 lines)
> Hi Niels & Florian,
>
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
>
>> 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.
>
> Niels, here’s a new ISO image built from commit
> bd4c345ef7ddf3542662fe0872b06393b414a3fc, which includes Florian’s fix.
>
> https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc2.5/
>
> Could you simply boot that image, without any additional kernel
> arguments, and confirm that the installer now displays correctly? (You
> don’t need to run the actual install.)

1.1.0rc2.5 works fine here!

br
Niels
P
P
pelzflorian (Florian Pelz) wrote on 14 Apr 2020 20:48
(name . Niels Felsted)(address . niels@pdlkrft.eu)
20200414184834.nwjmi5sribw4b7tr@pelzflorian.localdomain
On Tue, Apr 14, 2020 at 08:20:09PM +0200, Niels Felsted wrote:
Toggle quote (2 lines)
> 1.1.0rc2.5 works fine here!

Thank you greatly for showing me uvesafb is not always harmless. :)

Closing.

Regards,
Florian
Closed
L
L
Ludovic Courtès wrote on 14 Apr 2020 22:01
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87o8rtvntk.fsf@gnu.org
Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (5 lines)
> On Tue, Apr 14, 2020 at 08:20:09PM +0200, Niels Felsted wrote:
>> 1.1.0rc2.5 works fine here!
>
> Thank you greatly for showing me uvesafb is not always harmless. :)

Awesome, thank you for re-testing, Niels!

Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 40599@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 40599
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch