Created attachment 1397818 [details]
tar of openqa logs

I'm not sure but this looks to me like broken VM or broken graphics driver for VM (I guess Spice).

Is it still happening for every new installation? Wasn't that just some glitch in taking the screenshot by OpenQA?

Using openqa is happening every time. I tested also manually on an other KVM machine and I reached this panel correctly but it becames fuzzy when I click continue, So it's not linked to the screenshot capture of openqa. Note that even if I got two different behaviours (openqa and manual test), these behaviours always stay the same on each environment.
Note that problem does not exist on ppc64. 
I do agree that problem could come from graphics driver but why it's this panel only during the installation process...

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

problem still present on last Rawhide compose 20180220 as per openQA tests results: 

https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora&version=Rawhide&build=Fedora-Rawhide-20180220.n.0&groupid=3
https://openqa.stg.fedoraproject.org/tests/240356#step/_boot_to_anaconda/5

Created attachment 1400827 [details]
other fuzzy panel

In fact it happens more or less on all panells displayed by VNC

Created attachment 1400828 [details]
other fuzzy panel

Can anyone have a look ? not sure what component to assign it, feel free to reassign.

Created attachment 1408687 [details]
packages_list.tgz

I do not know if that could help for investigation but I have two rawhide isos (there was no compose between 20180204 and 20180217)
* 20180204  => no failure
* 20180220  => has reported fuzzy problem.

I retrieved from them the sorted list of packages in Packages dir, but there are many differences between them.
Is there a better way to compare the two isos to isolate potential source of this problem ?

The 20180220 compose contains the mass rebuild results merged back to F-28, so the compose will have a mix of rebuilt and rebased packages :-(

So few more observations - I did a VNC installation using Fedora-28-20180319.n.0 compose (booted from netboot iso and added "vnc" to kernel command line). When I connected with an external VNC viewer (from my workstation) I saw correct "language selection" page, with just a subtle vertical glitch in the "Fedora Server" logo on the left. Because the first screen was in Czech I selected English/English in the lists. All was still good. Then right after pressing the Continue button I saw the "fuzzy" screen for a moment before anaconda got to the main page, which was displayed correctly again. My hypervisor/host is F-27 libvirt/KVM.

Also it's not only the graphics what's wrong, but also the mouse, clicks are way off from the pointer ...

let's go to the Xorg team for an opinion

Created attachment 1420284 [details]
screenshot

I went thru the whole installation (Fedora-Everything-28-ppc64le-20180410.n.1), it was quite challenging because the misplaced mouse pointer. The result is that all anaconda screens are affected in some way, also the installed desktop environment (XFCE) is affected. The terminal window looks good, but the notification in top right corner and the bottom panel are bad. Again the mouse pointer was misplaced.

* There was the same problem with Rawhide until 20180418 compose (1) that seems to disappear with compose 20180419 (2).
* The F28 20180420 still has the problem (3)

So need to identify what package changes in Rawhide may explain the correction, and if able to backport the same change in F28.

(1) https://openqa.stg.fedoraproject.org/tests/286076#step/_boot_to_anaconda/5
(2) https://openqa.stg.fedoraproject.org/tests/288824#step/_boot_to_anaconda/4
(3) https://openqa.stg.fedoraproject.org/tests/288479#step/_boot_to_anaconda/4

The diff between 0418 and 0419 composes is in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OC7WW4XBW54V3MMTY5IZTWEF3ZWHLZ7V/

If I should pick one change, then I would go with mesa. I'm going to create a new installed based on 20180418 + mesa-18.0.1-1.fc29

so it's not mesa alone, the output is the same when mesa-18.0.1-1.fc29 is included

So my tests show it's libglvnd-1.0.1-0.5.20180327git5baa1e5.fc29 added to 20180418 compose what unbreaks it. Don't ask me why :-)

Dan I checked the last f28 compose 20180423 iso and it already has the same rpm version, BUT  still has the fuzzy screen in our local openQA server.

(In reply to Michel Normand from comment #19)
> Dan I checked the last f28 compose 20180423 iso and it already has the same
> rpm version, BUT  still has the fuzzy screen in our local openQA server.

my comment was about libglvnd, while the mesa differ for f28:
===
$mount -o loop,ro ~michel/iso/Fedora-Server-dvd-ppc64le-28-20180423.n.0.iso /tmp/tmp2
[root@abanc:~]
$find /tmp/tmp2 -name libglvnd\*
/tmp/tmp2/Packages/l/libglvnd-1.0.1-0.5.20180327git5baa1e5.fc28.ppc64le.rpm
/tmp/tmp2/Packages/l/libglvnd-egl-1.0.1-0.5.20180327git5baa1e5.fc28.ppc64le.rpm
/tmp/tmp2/Packages/l/libglvnd-gles-1.0.1-0.5.20180327git5baa1e5.fc28.ppc64le.rpm
/tmp/tmp2/Packages/l/libglvnd-glx-1.0.1-0.5.20180327git5baa1e5.fc28.ppc64le.rpm
$find /tmp/tmp2 -name mesa\*
/tmp/tmp2/Packages/m/mesa-dri-drivers-18.0.0-4.fc28.ppc64le.rpm
/tmp/tmp2/Packages/m/mesa-filesystem-18.0.0-4.fc28.ppc64le.rpm
/tmp/tmp2/Packages/m/mesa-libEGL-18.0.0-4.fc28.ppc64le.rpm
/tmp/tmp2/Packages/m/mesa-libGL-18.0.0-4.fc28.ppc64le.rpm
/tmp/tmp2/Packages/m/mesa-libgbm-18.0.0-4.fc28.ppc64le.rpm
/tmp/tmp2/Packages/m/mesa-libglapi-18.0.0-4.fc28.ppc64le.rpm
===

Pretty sure this is pixman being miscompiled by newer gcc. Notice the difference in testsuite output between:

https://kojipkgs.fedoraproject.org//packages/pixman/0.34.0/4.fc27/data/logs/ppc64/build.log

https://kojipkgs.fedoraproject.org//packages/pixman/0.34.0/6.fc28/data/logs/ppc64le/build.log

(In reply to Adam Jackson from comment #21)
> Pretty sure this is pixman being miscompiled by newer gcc. Notice the
> difference in testsuite output between:
> 
> https://kojipkgs.fedoraproject.org//packages/pixman/0.34.0/4.fc27/data/logs/
> ppc64/build.log

This should have said ppc64le, though both pass the tests in F27.

Also, a scratch build against F28 with --disable-vmx fixes it. So this is either a gcc8 bug or the vmx code in pixman is broken.

pixman-0.34.0-7.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fc3904edc1

I've created an updates.img with the new pixman and indeed it fixes the problem. You can use inst.updates=http://fedora.danny.cz/ppc/updates-1546693.img as a workaround.

I've reported a new bug #1572540 against gcc.

pixman-0.34.0-7.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-fc3904edc1

pixman-0.34.0-7.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Dan, I am not familiar with the Atomic compose process, But we still have pixman-0.34.0.6 in last Atomic compose 20180515 (1);
What need to be done to have atomic iso with above pixman-0.34.0-7.fc28 correction ?

(1) https://kojipkgs.fedoraproject.org/compose/twoweek/latest-Fedora-Atomic-28/logs/ppc64le/AtomicHost/ostree_installer-2/dnf.log

To clarify, this is about the build for the installer ISO for Atomic Host *just* on ppc64?

Anyways, it'd need to be explicitly tagged into the build for the installer; AFAIK the default is to use the "gold" packages for the ISO builds.  I'd file a fedora releng ticket: https://pagure.io/releng/issues

After a chat with Dusty I've opened https://pagure.io/releng/issue/7500 for updating pixman in the runtime repo.