add 18th iteration of classifier

1 files changed, 142 insertions, 0 deletions

diff --git a/results/classifier/118/none/1102027 b/results/classifier/118/none/1102027
new file mode 100644
index 000000000..1818fad7b
--- /dev/null
+++ b/results/classifier/118/none/1102027
@@ -0,0 +1,142 @@
+hypervisor: 0.744
+peripherals: 0.708
+permissions: 0.701
+semantic: 0.697
+architecture: 0.679
+register: 0.676
+device: 0.668
+assembly: 0.664
+user-level: 0.660
+graphic: 0.659
+i386: 0.657
+PID: 0.651
+performance: 0.642
+network: 0.638
+socket: 0.626
+kernel: 0.626
+debug: 0.613
+files: 0.612
+virtual: 0.611
+vnc: 0.607
+VMM: 0.605
+x86: 0.604
+KVM: 0.603
+ppc: 0.602
+boot: 0.595
+risc-v: 0.583
+mistranslation: 0.576
+arm: 0.572
+TCG: 0.565
+
+QED Time travel
+
+This night after a reboot of a VM, it was back to 8 Oct. 2012, i've lost all data between 8 Oct 2012 and now. I've check the QED file and mount on another VM, all seems OK.
+
+This QED has a raw backfile with the base OS (debian) shared with many others QED. It has NO snapshot.
+
+QEMU emulator version 1.1.2
+
+Does anyone have a hint ?
+
+On Sun, Jan 20, 2013 at 11:54:33AM -0000, Mekza wrote:
+> Public bug reported:
+> 
+> This night after a reboot of a VM, it was back to 8 Oct. 2012, i've lost
+> all data between 8 Oct 2012 and now. I've check the QED file and mount
+> on another VM, all seems OK.
+
+Hi Mekza,
+Are you able to reproduce this issue or did this happen once only?
+
+Does "all seems OK" mean that you still only saw the files from 8 Oct
+2012 when you attached the image to another VM?
+
+> Does anyone have a hint ?
+
+There's not a lot of information here to go by.  If the issue is
+reproducible it should be possible to collect more information, starting
+with the steps to reproduce the issue.
+
+Stefan
+
+
+On Tue, Jan 29, 2013 at 1:46 PM, Stefan Hajnoczi <<email address hidden>
+> wrote:
+
+> On Sun, Jan 20, 2013 at 11:54:33AM -0000, Mekza wrote:
+> > Public bug reported:
+> >
+> > This night after a reboot of a VM, it was back to 8 Oct. 2012, i've lost
+> > all data between 8 Oct 2012 and now. I've check the QED file and mount
+> > on another VM, all seems OK.
+>
+> Hi Mekza,
+> Are you able to reproduce this issue or did this happen once only?
+>
+
+Hi Stefan,
+
+I already had this bug once and after a unmeasurable period (days or even
+weeks) and a reboot of the VM, the FS was back.
+
+
+>
+> Does "all seems OK" mean that you still only saw the files from 8 Oct
+> 2012 when you attached the image to another VM?
+>
+
+"all seems OK" means the QED file is not corrupted and consistent. I still
+have files from 8 Oct 2012.
+
+
+>
+> > Does anyone have a hint ?
+>
+> There's not a lot of information here to go by.  If the issue is
+> reproducible it should be possible to collect more information, starting
+> with the steps to reproduce the issue.
+>
+
+I know, i'm gonna copy the QED and then convert to RAW and attach it to a
+new VM. I'll keep you in touch.
+
+>
+> Stefan
+>
+> --
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1102027
+>
+> Title:
+>   QED Time travel
+>
+> Status in QEMU:
+>   New
+>
+> Bug description:
+>   This night after a reboot of a VM, it was back to 8 Oct. 2012, i've
+>   lost all data between 8 Oct 2012 and now. I've check the QED file and
+>   mount on another VM, all seems OK.
+>
+>   This QED has a raw backfile with the base OS (debian) shared with many
+>   others QED. It has NO snapshot.
+>
+>   QEMU emulator version 1.1.2
+>
+>   Does anyone have a hint ?
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1102027/+subscriptions
+>
+
+
+
+-- 
+Martin-Zack Mekkaoui
+
+
+Have you ever been able to reproduce this issue?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+