Created attachment 1012620 [details] anaconda logs .tgz +++ This bug was initially created as a clone of Bug #1194991 +++ Description of problem: installation cannot proceed past Welcome/language selection screen Version-Release number of selected component (if applicable): anaconda-22.20.8-1 How reproducible: start installation on 32 bit Socket A Sempron with NForce2 chipset & rv200 radeon (host m7ncd) Steps to Reproduce: 1.start HTTP installation via boot.iso or Grub 2.click "Continue" on Welcome to screen Actual results: Installation summary wheel screen paints, then an empty popup appears, and nothing is possible on the screen except for moving the mouse pointer Expected results: Installation can proceed Additional info: 1-I've been trying to get Xorg/KF5 to work on this host, in both F22 and Rawhide, off and on for several months without success, to follow-up in Rawhide to bug 1096487 , getting black screen from what should be sddm or kdm greeter, and plasma-workspace segfault from trying startx, with no clues given by Xorg.0.log. With same host, Cauldron and Tumbleweed, XOrg and K* are working as expected except for bug 1096487.
Two things stand out in the logs: 1) there are an absurd number of partitions, and checking them is taking a while. There is nothing that can be done about this. The partition checks run in a separate thread, so if this is making the rest of the GUI unresponsive it's because your system does not have the capacity to run fsck and also run a GUI 2) chronyd is flooding the log with " ERR chronyd: Could not open IPv6 NTP socket : Address family not supported by protocol". Reassigning to chrony for that part of it.
Fixed in upstream git: http://git.tuxfamily.org/chrony/chrony.git/commit/?id=fdf9640349f1432ed2c2a0d343bca06fe9771e0d
(In reply to David Shea from comment #1) > 1) there are an absurd number of partitions, and checking them is taking a > while. There is nothing that can be done about this. The partition checks > run in a separate thread, so if this is making the rest of the GUI But for bug 1202024 there shouldn't have been any significant time spent checking. > unresponsive it's because your system does not have the capacity to run fsck > and also run a GUI Retrying with today's failed to reproduce the GUI hang. OTOH, I waited 20 minutes on tty2 watching top tell me e2fsck was busy and 100% of swap was available before proceeding with installation.