summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/105/semantic/1102027
blob: 030e7b2feb4ddec55ecbd7e7964b41df1257aa3a (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
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.]