Description of problem: The installer is hanging on launch. Version-Release number of selected component (if applicable): Fedora-Workstation-Live-x86_64-28-20180320.n.0.iso anaconda-28.22.2-4.fc28.x86_64 How reproducible: Most of the time, not always. Steps to Reproduce: 1. F27 host, F28 guest using above live ISO as source 2. Boot and then launch the installer 3. Actual results: Hang Expected results: Installer should work Additional info: Attached journal is captured using 'virsh console' and 'journalctl -o short-monotonic' output to a file.
Created attachment 1411491 [details] journal log
Created attachment 1411492 [details] program.log
Created attachment 1411493 [details] anaconda.log
Created attachment 1411494 [details] storage log
Created attachment 1411509 [details] fedorabios.xml virsh dumpxml for the VM being used
Same results. Fedora-Workstation-Live-x86_64-28-20180321.n.0.iso anaconda-28.22.2-5.fc28.x86_64
Created attachment 1411618 [details] strace anaconda strace of the runaway and hanging anaconda process
Proposed as a Blocker for 28-beta by Fedora user chrismurphy using the blocker tracking app because: Well there isn't any one particular criterion busted but all the installer criteria can't be met because it doesn't launch.
Happens even with RAM set to 3072M
Hmm, I just booted that same Live image in KVM multiple times on both F27 and F28 VM hosts. I can't reproduce this issue. Could it be hardware-specific? As of right now, I'm -1 blocker based on my own testing.
I'm not seeing any weird errors in either the host or the guest, outside of anaconda itself. Fedora 27 ISO boots and installs fine in this same VM.
Can't reproduce in openQA, on my test system, or on any of my laptops. -1.
Discussed during blocker review [1]: RejectedBlocker (Final) - no-one else is able to reproduce this in testing on various systems, so it does not appear to be a blocker [1] https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-03-22/
Discussed during blocker review [1]: RejectedBlocker (Beta) - no-one else is able to reproduce this in testing on various systems, so it does not appear to be a blocker [1] https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-03-22/
I've reproduced this on an Intel NUC running Fedora 27 Server. However, I'm using virt-manager on the originally reported computer (laptop). So while the VM itself is on the remote NUC, I'm looking at it with the laptop and for all I know the actual problem is with the local virt-manager somehow confusing the installer. The repeating message in the journal is still: Mar 23 01:04:53 localhost-live fedora-welcome.desktop[2067]: refresh]: Please make a selection from the above ['c' to continue, 'q' to quit, 'r' to Mar 23 01:04:53 localhost-live anaconda[2749]: simpleline: New signal InputReadySignal enqueued with source InOutManager Mar 23 01:04:53 localhost-live anaconda[2749]: simpleline: Processing signal InputReadySignal Mar 23 01:04:53 localhost-live anaconda[2749]: simpleline: No callback registered for user input Mar 23 01:04:53 localhost-live anaconda[2749]: simpleline: Input was not successful, ask for new input. Mar 23 01:04:53 localhost-live fedora-welcome.desktop[2067]: refresh]: Please make a selection from the above ['c' to continue, 'q' to quit, 'r' to Mar 23 01:04:53 localhost-live anaconda[2749]: simpleline: New signal InputReadySignal enqueued with source InOutManager Mar 23 01:04:53 localhost-live anaconda[2749]: simpleline: Processing signal InputReadySignal Mar 23 01:04:53 localhost-live anaconda[2749]: simpleline: No callback registered for user input Mar 23 01:04:53 localhost-live anaconda[2749]: simpleline: Input was not successful, ask for new input. Mar 23 01:04:53 localhost-live fedora-welcome.desktop[2067]: refresh]: Please make a selection from the above ['c' to continue, 'q' to quit, 'r' to I've tried separately making the guest then the host then the host and guest use X instead of Wayland. No change. Maybe there's some kind of input device confusion happening? I don't understand what these messages refer to or how to get more information or what to even try changing.
simpleline is the library the installer text mode uses.
OK I've found the instigator: Use boot param: console=ttyS0,38400 It is not necessary to connect with 'sudo virsh console vm' but obviously if you want to connect to the VM with the virtual serial console you have to boot with console=ttyS0,38400 [1] Problem happens on Fedora 27 ISO as well, I just wasn't trying to troubleshoot early crashing problems with F27 with serial console so I hadn't noticed it until trying it. [1] https://freedesktop.org/wiki/Software/systemd/Debugging/ (problem happens if console=tty1 is also included)
I'm gonna guess the installer is getting confused, when there's a serial console it assumes text install?
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I don't think the installer is 'confused', I think this is intentional behaviour. Is there still a bug here?
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.