summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/118/none/1102027
blob: 1818fad7b175ab56fbdb8ff44783810f14869979 (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
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
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.]