This DR adds rescue mode test. It uses disk from
simple_encrypted test, so it tests that it can mount LUKS on LVM.
It tries to access home folder, write file to that disk and read
it back. If you think that something else should be also tested,
speak now or forever hold your peace.
Details
run install_rescue_encrypted from universal tests
Diff Detail
- Repository
- rOPENQATESTS os-autoinst-distri-fedora
- Branch
- feature/rescue (branched from develop)
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 833 Build 833: arc lint + arc unit
Looks fine. I'm gonna apply this to staging so we can see if it works there before acking it.
| tests/rescue_mode_encrypted.pm | ||
|---|---|---|
| 1 | have you checked whether anacondatest's post_fail_hook is appropriate for this test's environment? I don't know, offhand... | |
| tests/rescue_mode_encrypted.pm | ||
|---|---|---|
| 1 | I don't know about error screens (I hope that in case of error, anaconda_text_error would be shown), but log location is the same as in Anaconda. | |
well, the test failed on staging, but I think it may actually have found a bug rather than this being a problem in the test:
From this https://openqa.stg.fedoraproject.org/tests/42796#step/rescue_mode_encrypted/4 it looks like it couldn't find any Linux partitions for some reason. Test should use disk from install_simple_encrypted which passed. Can you please check whether disk_64bit_encrypted.qcow2 contains correct LVM partitions? Otherwise yes, it looks like it found a bug in rescue mode.
it's obviously *seeing* the encrypted device, otherwise it wouldn't ask you to type the passphrase. I can reproduce the bug manually, so it looks like a real bug; I'll file it, and ack the PR (from the failed test we can see that the log uploading seems more or less right as well).
have you checked whether anacondatest's post_fail_hook is appropriate for this test's environment? I don't know, offhand...