QA » openQA Project

Thanks to @cdywan's work on #107002 we now have a video. It shows that poweroff is typed before the prompt "within" sudo is ready and one can also shortly see some boot messages after reaching the prompt. The typing poweroff actually nevertheless appears within the prompt but I suppose the return key didn't make it and thus nothing happens.

I've been attaching the most important frames of the video (they're ordered despite some numbers being omitted).

So we see:

1. Boot logging
2. Prompt with keys for sudo and poweroff already being typed
3. Prompt is gone again, further boot messages appear (and not it doesn't look like shutdown messages)
4. Prompt is shown again but it is messed up by further boot messages
5. Screen is cleared, just a single "_" appears
6. We're back at a clean prompt
7. The keystrokes for sudo and poweroff are "re-typed" or "replied"
8. That's it, apparently the poweroff command is there but never submitted or has no effect

I'd say there are no typing issues on our side. It is also clear why waiting for the prompt doesn't do the trick. The prompt is already shown while the system is booting. Maybe we need to assert that the boot prompt is shown for at least e.g. 5 seconds to be sure the system is really ready. That would be really annoying. I'm afraid we cannot assert for the last boot message because we might not catch it at all. I'm also wondering why 7. happens.

@cdywan please only "Blocked" with assignee so that we know who tracks the blocker. I set you as assignee now. (EDIT: took assignee myself now because I think it's not blocked anymore)

mkittler wrote:

Thanks to @cdywan's work on #107002 we now have a video. It shows that poweroff is typed before the prompt "within" sudo is ready and one can also shortly see some boot messages after reaching the prompt. The typing poweroff actually nevertheless appears within the prompt but I suppose the return key didn't make it and thus nothing happens.
[…]
I'd say there are no typing issues on our side. It is also clear why waiting for the prompt doesn't do the trick. The prompt is already shown while the system is booting. Maybe we need to assert that the boot prompt is shown for at least e.g. 5 seconds to be sure the system is really ready. That would be really annoying. I'm afraid we cannot assert for the last boot message because we might not catch it at all.

Couple of different ideas to try

• Use "power" function from test API, see https://github.com/os-autoinst/os-autoinst/blob/master/testapi.pm#L1902
• In https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/79/files#diff-1e64619f043972b0dff7b9d7ecde066f55e04b2fcb307beb4ead0e03dc69b6a6R8 we do a different approach by using a "root" console, not switching just in before with "su"
• Instead of ending up with typing "sudo su" and then typing (too soon) "poweroff" we should just type "sudo poweroff"

Trying that now myself: https://github.com/os-autoinst/os-autoinst/pull/1963

I'm also wondering why 7. happens.

I think this is normal behaviour. If you type while the next prompt isn't ready characters are echoed onto the (raw) console. But as soon as the prompt appears (and your PS command and stuff is finished processing) then the previously typed text is repeated from the buffer into the prompt line. I would not worry about that.

https://github.com/os-autoinst/openQA/runs/5324376037?check_suite_focus=true#step:7:117 failed after 5 successful runs with

Rerun 5 of 15 …
Calling retry hook ./tools/delete-coverdb-folder
Deleting cover_db_fullstack/
DBIx::Class::Storage::DBI::_exec_txn_commit(): DBI Exception: DBD::Pg::db commit failed: PANIC:  could not write to file "pg_wal/xlogtemp.2980": No space left on device
server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request. at inline delegation in DBIx::Class::DeploymentHandler for deploy_method->txn_do (attribute declared in /usr/lib/perl5/vendor_perl/5.26.1/DBIx/Class/DeploymentHandler/WithApplicatorDumple.pm at line 51) line 18
[20:18:19] t/full-stack.t .. 
No subtests run 
[20:18:19]

maybe saving all artifacts won't scale that good :) But the original problem did not appear here.

The very same consistently was reproduced in https://github.com/os-autoinst/os-autoinst/runs/5324381907?check_suite_focus=true#step:8:93 . I don't feel like triggering the above two 10 times more. But locally I have finished 90 runs successfully without any error so I declare this good enough :)https://github.com/os-autoinst/openQA/runs/5324376037?check_suite_focus=true#step:7:117 failed after 5 successful runs with

Rerun 5 of 15 …
Calling retry hook ./tools/delete-coverdb-folder
Deleting cover_db_fullstack/
DBIx::Class::Storage::DBI::_exec_txn_commit(): DBI Exception: DBD::Pg::db commit failed: PANIC:  could not write to file "pg_wal/xlogtemp.2980": No space left on device
server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request. at inline delegation in DBIx::Class::DeploymentHandler for deploy_method->txn_do (attribute declared in /usr/lib/perl5/vendor_perl/5.26.1/DBIx/Class/DeploymentHandler/WithApplicatorDumple.pm at line 51) line 18
[20:18:19] t/full-stack.t .. 
No subtests run 
[20:18:19]

maybe saving all artifacts won't scale that good :) But the original problem did not appear here.

The very same consistently was reproduced in https://github.com/os-autoinst/os-autoinst/runs/5324381907?check_suite_focus=true#step:8:93 . I don't feel like triggering the above two 10 times more. But locally I have finished 130 runs successfully without any error so I declare this good enough :)