fatal: can't handle xcode314_2809_developerdvd.dmg about dmg2img

[Lekensteyn]

Should be fixed by fc9b304, can you verify this?

[lemzwerg]

Not in the near future, sorry.

[xiangzhai]

NOT fixed by fc9b304
but it might be the HFS partition is wrapped in a CoreStorage volume issue!

$ dmg2img -p 4 -i Install\ macOS\ Sierra\ 10.12\(16A323\)-B.dmg -o macOS-Sierra-10.12-B.img

$ file macOS-Sierra-10.12-B.img 
macOS-Sierra-10.12-B.img: Macintosh HFS Extended version 4 data last mounted by: '10.0', created: Wed Sep 14 01:26:44 2016, last modified: Tue Sep 20 19:54:26 2016, last checked: Wed Sep 14 00:26:44 2016, block size: 4096, number of blocks: 1519152, free blocks: 14770

# mount -t hfsplus -o loop macOS-Sierra-10.12-B.img /mnt

$ dmesg | tail

[93052.533475] hfsplus: invalid secondary volume header
[93052.533478] hfsplus: unable to find HFS+ superblock

[Lekensteyn]

@xiangzhai Can you post debug.log that is created by the -d option (upload as attachment to the issue by dropping the file)? Or else provide with a link to the image file where you found the issue. Thanks!

[xiangzhai]

post debug.log

dmg2img.log.zip

provide with a link to the image file where you found the issue

https://pan.baidu.com/s/1qYU4Zfe

$ dmg2img -v -V -d -p 4 -i Install\ macOS\ Sierra\ 10.12\(16A323\)-B.dmg -o macOS-Sierra-10.12-B.img

.
.
.
offset = 236240  block_type = 0x00000001
copy data  (in_addr=5269294712 in_size=1048576 out_size=1048576)
[5907]  99.80%
offset = 236280  block_type = 0x00000001
copy data  (in_addr=5270343288 in_size=1048576 out_size=1048576)
[5908]  99.81%
offset = 236320  block_type = 0x00000001
copy data  (in_addr=5271391864 in_size=1048576 out_size=1048576)
[5909]  99.83%
offset = 236360  block_type = 0x00000001
copy data  (in_addr=5272440440 in_size=1048576 out_size=1048576)
[5910]  99.85%
offset = 236400  block_type = 0x00000001
copy data  (in_addr=5273489016 in_size=1048576 out_size=1048576)
[5911]  99.86%
offset = 236440  block_type = 0x00000001
copy data  (in_addr=5274537592 in_size=1048576 out_size=1048576)
[5912]  99.88%
offset = 236480  block_type = 0x00000001
copy data  (in_addr=5275586168 in_size=1048576 out_size=1048576)
[5913]  99.90%
offset = 236520  block_type = 0x00000001
copy data  (in_addr=5276634744 in_size=1048576 out_size=1048576)
[5914]  99.92%
offset = 236560  block_type = 0x00000001
copy data  (in_addr=5277683320 in_size=245760 out_size=245760)
[5915]  99.93%
offset = 236600  block_type = 0x00000002
null bytes (out_size=5632)
[5916]  99.95%
offset = 236640  block_type = 0x80000005
zlib inflate (in_addr=5277929080 in_size=162 out_addr=6222448128 out_size=512)
[5917]  99.97%
offset = 236680  block_type = 0x00000002
null bytes (out_size=512)
[5918]  99.98%
offset = 236720  block_type = 0xffffffff
terminator
[5919] 100.00%
  ok

Warning: wrote 6222449152 bytes, expected 6442450944
Wrote 220001792 padding bytes

Archive successfully decompressed as macOS-Sierra-10.12-B.img

You should be able to mount the image [as root] by:

modprobe hfsplus
mount -t hfsplus -o loop macOS-Sierra-10.12-B.img /mnt

[Lekensteyn]

@xiangzhai Are you sure that this is a problem of dmg2img? The output could be a disk volume, not a single partition. Try gdisk -l your.img. That will show several partitions with a start offset (in blocks). Then if the start offset is 40, you can try mount -o loop,offset=$((40*512)) your.img /mnt.

The logs look fine.

[xiangzhai]

Hi @Lekensteyn

Sorry for my late reply due to Chinese Spring Festival long vocation ;-)

The output could be a disk volume, not a single partition

$ dmg2img -v -V -d -p 4

so I use wrong parameters?

with a start offset

like but it might be the HFS partition is wrapped in a CoreStorage volume issue?

And my old 10.5 iMac is able to mount such dmg, I uploaded the screenshot to weibo http://wx4.sinaimg.cn/mw690/658b3ba1gy1fckgahu9ksj20jb0dg0ur.jpg

But it was still segfault when making LiveUSB http://wx3.sinaimg.cn/mw690/658b3ba1gy1fckgbh6grbj20rd0h0wie.jpg

Regards,
Leslie Zhai

[Lekensteyn]

@xiangzhai Np, I hope you enjoyed the holidays 😄

The parameters should be good. What is the output of dmg2img -l -v your.dmg? If you run file your.img (after converting the input file), what does it say? If it is a disk (instead of partition) image, what is the output of gdisk -l your.img or fdisk -l your.img?

[xiangzhai]

Hi @Lekensteyn

Sorry that I have deleted the *.dmg, *.img and related files, because they are too big, I need more pace to debug llvm... and I found that you are also the contributor!

Regards,
Leslie Zhai https://reviews.llvm.org/p/xiangzhai/

[Lekensteyn]

@timofonic not in 1.6.7, see #6 for the list of missing changes.

[Lekensteyn]

@timofonic That openssl 1.1 compat patch is only needed if you build everything (including vfdecrypt), you don't need it for just dmg2img. Are you creating a new dmg2img-git package?

[Lekensteyn]

I don't think the old releases are that interesting, especially if they are just code dumps

[Lekensteyn]

Asking for providing more "code dumps" will likely not be fruitful, I doubt that vu1tur has maintained a VCS repo.

Where did you find these tarballs? They were not listed on vu1tur.eu.org. More history is maybe nice for archeology, but I don't know if it is more useful than what we have now.

[Lekensteyn]

@timofonic I have no dmg file to test with, do you have one that fails?