Open lemzwerg opened 8 years ago
Should be fixed by fc9b304, can you verify this?
Not in the near future, sorry.
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
@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!
post debug.log
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
@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.
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
@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
?
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/
@timofonic not in 1.6.7, see #6 for the list of missing changes.
@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?
I don't think the old releases are that interesting, especially if they are just code dumps
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.
@timofonic I have no dmg file to test with, do you have one that fails?
[937606a0249e38db873cf0cb1bb968d4f837db76] [gcc 4.8.5, x86_64 openSuSE Leap 42.1]
I tried to unpack the xcode 3.1.4 dmg file as can be downloaded from
https://developer.apple.com/downloads/?name=Xcode%203.1.4
Doing
I get
in the log file, and I can't mount it afterwards since
fails with
Looking into the
dmesg
output, I seeVersion 1.6.3 (also self-compiled) handles the file just fine.