Description of problem: There are cases, when an anaconda detected error ends up in a long timeout in beaker. It would be much better if anaconda reported the problems to the test harness if running under beaker. Probably anaconda needs a boot option to turn on this behavior. (Maybe the anaconda bugzilla would be better for this RFE, but anyway requires activity from beaker side.) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
The anaconda BZ for this issue is 893084. Please keep in touch with its assignee to work out a solution.
I do not expect the Anaconda folks will want to add Beaker-specific code, which is fair. But maybe we could work with them to figure out a more generally useful way of reporting errors which Beaker can plug in to. The other thing to bear in mind is that although there are many kinds of errors that can make the installation hang, Anaconda often shows a prompt to allow the problem to be fixed with manual intervention. For example, when the kickstart can't be fetched you will be prompted to enter a different URL. And this is useful even in Beaker, because it gives us a chance to get onto the serial console and investigate the problem. If the system were returned immediately we would not have a chance to do that. A better approach might be to have a shorter initial watchdog time (I think we allow 3 hours for installation right now) and add something to the anamon script to periodically extend the watchdog by 10 minutes as long as Anaconda is making progress. The hard part might be figuring out whether Anaconda is actually making progress, but a rudimentary way might be just to check for new log entries in any of the monitored Anaconda logs.
My last comment on anaconda pair of this bug, ATM unanswered, The most important point is to make the job submitter aware, when anaconda is asking questions on console. Generally, this is an issue in case of unattended installation, thus a more generic solution is desirable. That solution then can be implemented in beaker. Probably a minimalist solution to give an rsyslog server on the boot command line, but this not is necessarily the beaker way. The second point is to agree on unique patterns signalizing fatal conditions. (Maybe the rsyslog solution is unavoidable while we have test systems lacking the serial console.) The third point, to make an opaque string to be able to identify the actual installation, - in beaker case is the taskid - to include in each log line. I hope this is not too much to implement as rsyslog support is already present. (For the beaker side this means a mandatory, open for the whole lab rsyslog port on the lab controller and monitored its content for relevant events.) Are my wishes realistic? Cheers Endre.
We've just tried to fix Bug 1413827 and while doing the QA part found Bug 1552401. This feels like we're fighting a loosing battle. The idea behind this RFE I think is sound and should use this bug to investigate anaconda, as well as come up with an idea of perhaps not rely on pattern matching against the log.
Beah is no longer supported by Beaker development team. Instead of that, we are working on Restraint test harness. You can find all the features of Restraint here. https://restraint.readthedocs.io/en/latest/ If you think your RFE should be still implemented as part of Restraint feel free to create a new BZ ticket. https://bugzilla.redhat.com/enter_bug.cgi?product=Restraint In case you have any question feel free to reach out to me Thank you, Martin Styk <martin.styk>