Hi,
intrigeri wrote (11 Nov 2011 11:03:38 GMT) :
>> Running the test in a VM, and inspecting the VM memory from the
>> host system, should also work.
> Going to try this.
My virtualization setup currently does not support (our way of using?)
kexec, so I won't be able to do any such tests. Therefore I'll try
going the "obsolete amd64 Lenny Live system" way instead, on a box
with 8GB RAM.
But why bother? We already know it's half-broken, at least for the
area from 3 to 4 GB, as we've not fixed it since Tails 0.9
was released.
Well, maybe it's not: after reviewing our testing procedures, I was
fed up with that bug and decided I did not want to see it sadden our
release process when we're testing the 0.10 ISO. Hence, I could not
refrain myself and implemented todo/move_from_sdmem_to_memtest.
At first glance it seems to work nicely (at least on bare metal).
See bugfix/from_sdmem_to_memtest branch in Git.
So what to do? Do we consider the move implemented by this branch as
a fix for a serious bug, that would be worth a freeze exception?
The diffstat is pretty small (a few file renames make it appear bigger
than it really is), the changes are self-contained, and I would be
delighted to see us use the memtest kernel feature ASAP after having
had it enabled in Debian (yeah, this last one does not count), so my
answer would be a clear "yes" iff. the following happens quickly:
experimental results show the branch actually fix the bug
AND
at least two people other than me try it (preferably on bare
metal) and confirm it seems to be working as well as for them the
sdmem-based solution we shipped in Tails 0.9.
What do you think?
Cheers,
--
intrigeri <intrigeri@???>
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Did you exchange a walk on part in the war
| for a lead role in the cage?
