This requires us to handle decryption each time we reboot in
the upgrade process, so factor that little block out into the
base class so we don't have to keep pasting it. It's also a
bit tricky to integrate into the 'catch a boot loop' code we
have to deal with #1349721, but I think this should work. There
is a matching openqa_fedora_tools diff to generate the disk
image.
Details
Run the tests, check that they work, run the other
upgrade and encrypted install tests and check they still work
properly too.
Diff Detail
- Repository
- rOPENQATESTS os-autoinst-distri-fedora
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
tests/disk_guided_encrypted_postinstall.pm | ||
---|---|---|
10 | Long waiting on two different places isn't nice, but I guess that there's no way around. |
How do you mean you 'naturally' cannot upgrade f24 disks? Building f23 and f24 is correct, that's what it's intended to do ATM, because current tests are for post-f24 Rawhide. The prod tests at the moment test upgrading from f23->rawhide and f24->rawhide, and I don't see why you can't test that too?
tests/disk_guided_encrypted_postinstall.pm | ||
---|---|---|
10 | it doesn't actually do a long wait in both places. note that I also changed _graphical_wait_login (it's just above, in Phab) so the wait_time there will only be 300 for encrypted upgrades; I tweaked it so it only gets extended to 6000 if UPGRADE is set *and `ENCRYPT_PASSWORD is not*. |
Long waiting on two different places isn't nice, but I guess that there's no way around.