Garbled QXL display after kexec breaks the "Memory erasure" scenario on Stretch
I see that both on Jenkins (Jessie host) and locally (sid host).
What I’ve tried on a sid host:
--reset-vgafrom the kexec call: no visible impact
- giving the QXL video adapter more memory (
ram='524288' vram='262144' vgamem='262144'): improves a little bit (I see the stars-based progress bar) but not enough for the “Happy dumping!” message to be correctly displayed
- replacing the QXL video adapter with a virtio one: even the kexec message is not displayed
- replacing the QXL video adapter with a virtio one + dropping
--reset-vgafrom the kexec call: even the kexec message is not displayed
I don’t know what else to try. A (temporary?) workaround could be to have the
I shutdown and wait for Tails to finish wiping the memory step (that’s only used in this scenario) not fail when it can’t find MemoryWipeCompleted.png on the screen, but instead print some warning like “Cannot tell if memory wipe completed, but the timeout was reached, so let’s see how well it has worked so far”. At least this would allow us to check whether memory wiping works on Stretch, which is top-priority to me wrt. releasing 3.0~beta1.
#4 Updated by anonym 2016-12-27 19:52:40
- Assignee changed from anonym to intrigeri
I think your fix is buggy: see https://jenkins.tails.boum.org/job/test_Tails_ISO_feature-stretch/78/artifact/build-artifacts/00:21:48_Memory_erasure.mkv
and the place it is reported in:
At around 14:45 the VM is killed (and
virt-manager displays “Waiting for guest domain to re-start”) so I guess the 10 minute sleep of
debug=memwipe is triggered before the attempt we attempt the 240 second timeout. I pushed these two untested commits which I hope will implement what you wanted robustly:
925ea0d924 Add sanity check. 2f0609e410 Make the memory wipe wait reliable again.
What do you think?
Oh, and yes, I do agree that this is an acceptable change. Let’s just be careful to take this into account next time the amount of unwiped memory increases (the warning will help us!).
#6 Updated by anonym 2016-12-28 12:01:50
> Thanks! But for some reason this doesn’t work either
Because of a syntax error, fixed in commit:a5028f0f8219dde923b191c0219a58569425db1e.
try_for take into account how much the looped over code takes to run?)
It does [when the syntax is correct! :)]
> so I’ve added commit:07dfb622f1119698612d17d89bd823c4c083090f on top.
This still makes sense, IMHO, although it invalidates the sanity check I added, so I have reverted it.