anaconda is set up such that, even if the system has a single empty disk attached, the user must at least visit the INSTALLATION DESTINATION spoke and click Done before the install can proceed. When you first see the hub, the spoke has the message "Automatic partitioning selected" in red, and the orange 'warning triangle' emblem is shown on the spoke icon to indicate you have to visit it. Usually, when you visit it and then click 'Done', the main hub appears again, the INSTALLATION DESTINATION spoke shows a message "Saving storage configuration..." for a bit, then flips to 'Automatic partitioning selected' in *black* (not red) and the orange warning triangle emblem disappears. However, in the last few weeks in both Fedora 26 and Rawhide, openQA seems to occasionally run into a bug with this. Many of our tests start with a single empty disk, and only need openQA to go to INSTALLATION DESTINATION and immediately click 'Done' to fulfill that part of the installation process. But it seems like, sometimes, after the test goes to the spoke and clicks Done, the normal process doesn't happen. The "Saving storage configuration..." message never appears. The spoke just shows exactly as it did before being visited - 'Automatic partitioning selected' in red, and the orange warning triangle emblem shown on the icon, and the install cannot be started. Here's one case of this happening: https://openqa.stg.fedoraproject.org/tests/99451 Here's a video: https://openqa.stg.fedoraproject.org/tests/99451/file/video.ogv Logs are here: https://openqa.stg.fedoraproject.org/tests/99451#downloads You can see from the video that the test does visit the spoke and click Done, but after it does so, the spoke still shows as needing action on the main hub. This causes the test to fail every time it happens, so it's rather a problem.
Created attachment 1273090 [details] anaconda.log from an occurrence of the bug
Created attachment 1273091 [details] storage.log from an occurrence of the bug
Looking at an anaconda.log from a working case, the messages after the final run of the storage check differ. Failure case: 12:09:15,829 DEBUG anaconda: Storage check finished with success. 12:09:15,829 DEBUG anaconda: spoke is ready: StorageSpoke 12:09:15,830 INFO anaconda: Thread Done: AnaCheckStorageThread (140711799531264) Working case: 18:28:52,191 DEBUG anaconda: Storage check finished with success. 18:28:52,192 INFO anaconda: Thread Done: AnaCheckStorageThread (140584501044992) 18:28:53,757 INFO anaconda: fs space: 14.45 GiB needed: 4.41 GiB 18:28:53,758 DEBUG anaconda: spoke is ready: StorageSpoke 18:28:55,068 INFO anaconda: fs space: 14.45 GiB needed: 4.41 GiB 18:28:55,068 DEBUG anaconda: spoke is not ready: StorageSpoke 18:28:55,068 DEBUG anaconda: setting StorageSpoke status to: Checking storage configuration... 18:28:56,422 INFO anaconda: fs space: 14.45 GiB needed: 4.41 GiB 18:28:56,423 DEBUG anaconda: spoke is ready: StorageSpoke I think there may be some sort of thread race going on here, there seem to be different threads doing stuff and perhaps things go wrong if they finish in a particular order or something?
Note, openQA probably enters the spoke and clicks Done faster than a human possibly could. It happens as fast as openQA can spot the 'Done' button and send a mouse click event, which is very fast indeed.
This is still happening in current tests, most recent example is https://openqa.fedoraproject.org/tests/113914 .
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. 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 '26'. 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 26 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.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 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.