summary refs log tree commit diff stats
path: root/results/classifier/105/semantic/1102027
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/105/semantic/1102027')
-rw-r--r--results/classifier/105/semantic/1102027125
1 files changed, 125 insertions, 0 deletions
diff --git a/results/classifier/105/semantic/1102027 b/results/classifier/105/semantic/1102027
new file mode 100644
index 00000000..030e7b2f
--- /dev/null
+++ b/results/classifier/105/semantic/1102027
@@ -0,0 +1,125 @@
+semantic: 0.697
+device: 0.668
+assembly: 0.664
+graphic: 0.659
+other: 0.655
+instruction: 0.646
+network: 0.638
+socket: 0.626
+vnc: 0.607
+KVM: 0.603
+boot: 0.595
+mistranslation: 0.576
+
+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.]
+