blob: 46ae8018250f2871e9babb71e8d43ef108682d64 (
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
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
|
register: 0.963
permissions: 0.959
semantic: 0.957
graphic: 0.953
device: 0.953
assembly: 0.950
performance: 0.950
architecture: 0.950
peripherals: 0.944
virtual: 0.942
debug: 0.942
mistranslation: 0.941
files: 0.941
risc-v: 0.936
VMM: 0.932
boot: 0.931
user-level: 0.929
PID: 0.928
arm: 0.927
KVM: 0.927
TCG: 0.925
socket: 0.922
vnc: 0.921
kernel: 0.915
network: 0.913
ppc: 0.905
hypervisor: 0.899
x86: 0.899
i386: 0.837
qemu-img convert qcow2 to raw fails on OS X
I try to convert a image from qcow2 to raw and the result is a not bootable image.
I dont know if it is a bug in qemu-img convert or with the image it self.
See this error report for better readability:
https://github.com/coreos/bugs/issues/1121#issuecomment-351968518
As a reply here they use 2.9.0 version of
$ qemu-img -V
qemu-img version 2.11.0
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
$ uname -v
Darwin Kernel Version 17.2.0
$ mount ./
/dev/disk1s1 on / (apfs, local, journaled)
$ wget https://beta.release.core-os.net/amd64-usr/current/coreos_production_openstack_image.img.bz2
$ date
Fri Dec 14 17:15:57 CET 2017
$ bunzip2 coreos_production_openstack_image.img.bz2
$ cp -a coreos_production_openstack_image.img.org coreos_production_openstack_image.img
$ shasum coreos_production_openstack_image.img.org
ae2119c6f0390dc36f247f7016923ea85de5d8e6 coreos_production_openstack_image.img.org
$ qemu-img convert -f qcow2 -O raw coreos_production_openstack_image.img.org coreos_production_openstack_image.bin
$ qemu-system-x86_64 -m 256 -nographic -hda coreos_production_openstack_image.img -boot c
SeaBIOS (version rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org)
iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+0FF915A0+0FEF15A0 C980
Booting from Hard Disk...
GRUB loading....
Welcome to GRUB!
....
$ qemu-system-x86_64 -m 256 -nographic -hda coreos_production_openstack_image.bin -boot c
SeaBIOS (version rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org)
iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+0FF915A0+0FEF15A0 C980
Booting from Hard Disk...
Boot failed: not a bootable disk
....
$ head -c 8192 coreos_production_openstack_image.bin | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00002000
$ qemu-img info coreos_production_openstack_image.bin
image: coreos_production_openstack_image.bin
file format: raw
virtual size: 8.5G (9116319744 bytes)
disk size: 217M
$ qemu-img info coreos_production_openstack_image.img
image: coreos_production_openstack_image.img
file format: qcow2
virtual size: 8.5G (9116319744 bytes)
disk size: 785M
cluster_size: 65536
Format specific information:
compat: 0.10
refcount bits: 16
The same version works on Ubuntu so it looks like its only the Mac version or the new APFS filesystem.
We've had APFS bugs before, if memory serves... perhaps something to do with sparse gap handling?
Do you have the ability to take a "good" conversion of the qcow2 file (made on a non-APFS partition) and compare it against the "bad" conversion?
Highlighting the differences might inspire some ideas as to where this has gone wrong, but at present I don't have an OSX computer to test this with, personally.
I gave it a try here:
http://termbin.com/ufv4
Its only the first 4096 bytes.
I tried to make a quick grep of the start of the disk in the "bad" raw image and it does not exist anywhere so there is more ot it then just a offset issue.
rg -M 20 -a --encoding=ascii '\xeb\x63\x90\x00\x00\x00\x00\x00\x00\x00\x00\x00' coreos_production_openstack_image.bin.apfs
or
rg -M 20 -a --encoding=ascii 'GRUB \x00Geom\x00Hard Disk\x00Read\x00 Error' coreos_production_openstack_image.bin.apfs
The actual data seams to start here:
$ hexdump -C coreos_production_openstack_image.bin.apfs | head
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0cc4f000 48 8b 4c 24 58 48 89 4c 24 08 48 89 44 24 10 e8 |H.L$XH.L$.H.D$..|
0cc4f010 3c a5 c5 ff 48 8b 44 24 18 48 8b 4c 24 20 48 8d |<...H.D$.H.L$ H.|
0cc4f020 15 9b e9 3f 00 48 39 c2 75 22 48 8b 44 24 48 48 |...?.H9.u"H.D$HH|
0cc4f030 8b 00 48 89 44 24 10 48 89 0c 24 66 c7 44 24 08 |..H.D$.H..$f.D$.|
0cc4f040 00 00 e8 c9 00 00 00 e9 70 ff ff ff 48 89 04 24 |........p...H..$|
0cc4f050 48 89 54 24 08 48 8d 05 e4 cf 3e 00 48 89 44 24 |H.T$.H....>.H.D$|
0cc4f060 10 e8 1a f1 bb ff 0f 0b e8 a3 5a c0 ff e9 7e fe |..........Z...~.|
0cc4f070 ff ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc |................|
and ends here:
261bf040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
21f600000
There are som small small zones of zeroes here and there also but not much.
And the file size seams small and wrong.
$ ls -lah coreos_production_openstack_image.bin.apfs
$ du -hs coreos_production_openstack_image.bin.apfs
16M coreos_production_openstack_image.bin.apfs
Adding "-S 0" on the APFS convert only makes the file 8.5Gb but its still "bad".
The image apfs2 here is created with "-S 0"and the .bin is a working one generated on a ubuntu machine.
Strange thing is that this say they are identical:
$ time qemu-img compare -f qcow2 -F raw coreos_production_openstack_image.img.org coreos_production_openstack_image.bin.apfs
Images are identical.
real 0m0.078s
user 0m0.016s
sys 0m0.054s
But these are not:
$ time qemu-img compare -f qcow2 -F raw coreos_production_openstack_image.img.org coreos_production_openstack_image.bin.apfs2
Content mismatch at offset 0!
real 0m0.026s
user 0m0.009s
sys 0m0.010s
But hese are identical :)
$ diff coreos_production_openstack_image.bin.apfs coreos_production_openstack_image.bin.apfs2
$ echo $?
0
And of cause these are not identical:
$ diff coreos_production_openstack_image.bin coreos_production_openstack_image.bin.apfs2
Binary files coreos_production_openstack_image.bin and coreos_production_openstack_image.bin.apfs2 differ
$ diff coreos_production_openstack_image.bin coreos_production_openstack_image.bin.apfs
Binary files coreos_production_openstack_image.bin and coreos_production_openstack_image.bin.apfs differ
In the termbin:
So the "good" one is on the left, and the "bad" one is on the right. The bad one is ... completely blank for the first 200+ MB? That's not great.
so:
.bin.apfs: broken raw file, made on apfs, no arguments(?)
.bin.apfs2: broken raw file, made on apfs, `-S 0` ?
.img.org: qcow2 file (original/working?)
.bin: working raw file, made on Ubuntu?
Do I have that right?
|