I finally had a bootable usb key working with a windows 7 install ready to go, when I realized that once the Language selection came up, my Macbook Pro's keyboard and trackpad no longer functioned and I had no way to actually proceed with the install.

I decided to setup a VirtualBox Windows 7 x64, install the keyboard and trackpad drivers from Bootcamp Support Software package, and shutdown the VM.

I used VBoxManage internalcommands converttoraw ... to turn the virtual disk into an .img . For those unfamiliar with virtualbox, it creates a full image of the virtual harddrive as if it were a physical harddrive, and works just the same.

I used fdisk to view the image:

sh-3.2# fdisk WINDOWS7.img 
Disk: WINDOWS7.img  geometry: 2610/255/63 [41943040 sectors]
Signature: 0xAA55
     Starting       Ending
#: id  cyl  hd sec -  cyl  hd sec [     start -       size]
*1: 07    0  32  33 -   12 223  19 [      2048 -     204800] HPFS/QNX/AUX
2: 07   12 223  20 - 1023 254  63 [    206848 -   41734144] HPFS/QNX/AUX
3: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
4: 00    0   0   0 -    0   0   0 [         0 -          0] unused

I then used the following in an attempt to skip the System Reserved partition and just copy the windows data partition to the designated slice of my Macintosh HD:

sh-3.2# dd if=WINDOWS7.img of=/dev/disk0s4 skip=206848 bs=65535

Leaving me with the following:

sh-3.2# fdisk /dev/disk0
Disk: /dev/disk0    geometry: 60821/255/63 [977105060 sectors]
Signature: 0xAA55
         Starting       Ending
#: id  cyl  hd sec -  cyl  hd sec [     start -       size]
1: EE 1023 254  63 - 1023 254  63 [         1 -     409639] <Unknown ID>
2: AC 1023 254  63 - 1023 254  63 [    409640 -  684395032] <Unknown ID>
3: AB 1023 254  63 - 1023 254  63 [ 684804672 -    1269536] Darwin Boot 
4: 0B 1023 254  63 - 1023 254  63 [ 686074208 -  290768672] Win95 FAT-32

Which seems correct, but leaves me with an Uninitialize-able disk that I can't mount or access with disk utility, when I click mount, nothing happens, even if I try mount -t ntfs /dev/disk0s4 /Volumes/Temp-Dir-Made-With-mkdir

disk utility

What could be the problem? Am I doing something wrong? Is this impossible?

Does slice 4 of disk0 not inherit the filesystem of the partition I wrote to it?

Thanks in advance for any insight!

Edit 1:

@David It's a MacbookPro11,3 which should tell you everything you need to know about it. As far as bootcamp I downloaded it directly to windows from the following Apple Support Document kbDL1720

@klanomath (Comment 1)True, but it's good information to know! Out of curiosity, why is 65535 a bad block size? I thought the block size specification only had to do with the number of blocks that were processed and dumped to the drive/image at a time, basically allowing you to DD faster with more RAM (with the law of diminishing returns coming into effect at some point of course.) Am I just completely wrong in my understanding of the bs= parameter?

@user3439894 I thought about that, shouldn't need the MBR if I'm using a different bootloader, but I did neglect the System Reserved partition. The problem here is that I already have 4 partitions on the hard drive... I forget what partition 0 is (not in front of my mac), partition 1 is Mac, partition 2 is mac recovery partition, and partition 3 is the one I made for windows. Maybe I'm going about this all wrong... Boot camp has turned into quite the nightmare, would have been nice if it just took my image and did the job for me, but I digress.

  • 1
    The bs is completely wrong. It should be 512. Using 65535 skips the first 206848x65535 Bytes of the image! Use a count of (41734144 -206848) -> dd if=WINDOWS7.img of=/dev/disk0s4 skip=206848 bs=512 count=41527296 Also create a properly sized (41527296x512 Bytes) & correct marked partition disk0s4 with gpt first. And make a backup first! – klanomath Jun 27 '16 at 10:47
  • 1
    What is the model/year of you Mac? Did the "Boot Camp Support Software" get correctly copied to the USB key? As for your above procedure, you are hopelessly lost. Virtually, every step you have given has a flaw. In addition, you have left out more steps than you have included in your posted question. – David Anderson Jun 27 '16 at 10:49
  • Additionally: though my comment may answer your question correctly, I can't guarantee that you get the desired result: a bootable "Windows 7 ready to go" partition! – klanomath Jun 27 '16 at 10:55
  • @DeeJayh, Even with klanomath's corrected dd command Windows 7 will not be functional as it will be missing the information required to boot in the partition you're skipping in the WINDOWS7.img file. I'd suggest fixing the original issue that sent you on this convoluted path to begin with! – user3439894 Jun 27 '16 at 13:08
  • @ALL Question updated with an edit – DeeJayh Jun 27 '16 at 15:44

The proper command to dd a part of a raw file to a partition in your case is:

dd if=WINDOWS7.img of=/dev/disk0s4 skip=206848 bs=512 count=41527296

The bs in the dd command can be interpreted as an artificial block size of the input and the output "file". For historical and technical reasons the default block size of dd is 512 Byte.

The reason to use 512 (or an appropriate integer^2 multiple/divider) as bs is the block size of your image and the partition disk0s4 – which is either 512 or 4096.

The (logical) block size of disk0 can be calculated (even without knowing if fdisk works with 512 or 4096 Byte internally): 977105060 * 512 = 500 GB or 977105060 * 4096 = 4 TB. A 4 TB SSD still doesn't exist for MacBook Pro's therefore the block size has to be 512 byte. The same is valid for your img file.

Now you may take speed reasons into account: the bigger the bs is, the faster the image will be copied.

So one valid dd command in your case may be:

dd if=WINDOWS7.img of=/dev/disk0s4 skip=X bs=2 count=Y

Since bs is 2 Byte only, you have to modify skip (skips X blocks à bs of if) and count (Y blocks à bs are "written"). Since skip is 206848*512, X is 206848*512/2 and count is 41527296*512, Y is 41527296*512/2 and the above command is:

dd if=WINDOWS7.img of=/dev/disk0s4 skip=52953088 bs=2 count=10630987776

A quick test reveals:

dd if=/dev/zero of=~/Desktop/output.file bs=1 count=1048576
1048576 bytes transferred in 1.593527 secs (658022 bytes/sec)
dd if=/dev/zero of=~/Desktop/output.file bs=2 count=524288
1048576 bytes transferred in 0.800444 secs (1309993 bytes/sec)
dd if=/dev/zero of=~/Desktop/output.file bs=4 count=262144
1048576 bytes transferred in 0.384188 secs (2729331 bytes/sec)
dd if=/dev/zero of=~/Desktop/output.file bs=1024 count=1024
1048576 bytes transferred in 0.001932 secs (542700705 bytes/sec)

The larger bs is, the faster the dd command is executed.

BTW: The largest bs working for you is 1048576 (the greatest common divisor) because 105906176(=skip-size in Byte)/1048576=101 (and 21261975552(=count-size in Byte)/1048576=20277). 101 is prime!

So far all bs values are multiples of 2. If bs is uneven this may collide with the (block-)sizes of if/of. At least in your case if and of have even Byte sizes because they are multiples of 512.

Now it should be obvious why using bs=65535 fails: skip and count block numbers are determined by bs and not by the natural block size of your image or partition. A proper command may be

dd if=WINDOWS7.img of=/dev/disk0s4 skip=1616.024... bs=65535 count=324436.950...

At least for me this fails because 1616.024... is an illegal numeric value. So one may assume that all numbers have to be integer values!

A bs of 65535 only works if the total size of if/of and any skip or seek "boundaries" are multiples of 65535 Byte.

If your dd command doesn't contain any skip/seek/count part you may use arbitrary bs sizes though.

Though the dd command at the beginning of answer will work, you probably won't be able to boot to the Windows To Go (or Windows Installer Ready-To-Go?) partition. The MBR of disk0 won't contain the necessary boot entry.

  • Amazing, this isn't the solution to my issue, but it IS the answer to question I technically asked. This will likely be my choice for best answer. Thank you so much for clarifying! I truly have a better understanding now, and I foresee that helping me in the future! – DeeJayh Jun 27 '16 at 19:06
  • I already selected it as best answer, could you clarify the last paragraph with a solution? You say "The MBR of disk0 won't contain the necessary boot entry." but couldn't I simply install something like GRUB2 at that point and be up and running? Thanks again for the awesome answer! – DeeJayh Jun 27 '16 at 19:11
  • @DeeJayh David Anderson provides a lot of excellent answers to the topic. In my setup (at home) I can't install Windows 7 (and Bootcamp doesn't allow an installation of Windows in a Parallels OS X VM because it crashes) so I can't really answer the question properly. You may be fine by installing rEFInd. – klanomath Jun 27 '16 at 19:18
  • When @DeeJayh installed Windows in VirtualBox, he choose the default partitioning. By default, Windows creates two partitions. (The Boot Camp Assistant creates a single partition which works, but is not the default configuration.) The first partition is the smaller "System Reserved" NTFS volume. This is the active partition containing all the code needed to boot Windows. This includes the Volume Boot Record (VBR) and the hidden system boot files including the BCD file. The dd command is skipping all of this required software. Installing rEFInd will not remedy this situation. – David Anderson Jun 27 '16 at 20:14
  • @DeeJayh Probably the best is to ask a second question to address your real problem. – klanomath Jun 27 '16 at 20:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .