diff options
Diffstat (limited to 'results/classifier/105/semantic/1102027')
| -rw-r--r-- | results/classifier/105/semantic/1102027 | 125 |
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.] + |