add anaconda rescue test on encrypted disk
ClosedPublic

Authored by garretraziel on Sep 12 2016, 10:18 AM.

Details

Summary

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.

Test Plan

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
garretraziel retitled this revision from to add anaconda rescue test on encrypted disk.Sep 12 2016, 10:18 AM
garretraziel updated this object.
garretraziel edited the test plan for this revision. (Show Details)
garretraziel added reviewers: adamwill, jskladan.

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...

garretraziel added inline comments.Sep 14 2016, 11:05 AM
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:

https://openqa.stg.fedoraproject.org/tests/42796

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.

adamwill accepted this revision.Sep 16 2016, 2:13 AM

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).

This revision is now accepted and ready to land.Sep 16 2016, 2:13 AM
garretraziel closed this revision.Sep 16 2016, 1:45 PM