Let’s say you own a mac and you installed Windows into a second partition of your hard drive via Boot Camp, and let’s say you need to access your alternate OS from its partition often but you won’t reboot everytime.
Several softwares enable you to do that using OSX as your main OS: Parallels, VMware Fusion, and VirtualBox are just the most known guys out there and all of them have options to boot a vm from a physical installation of Windows.
But what if you are in the opposite situation and you’re using Windows as the main OS and want to boot a vm from the OSX installed in the main partition of your hard drive?
Here’s how I made it possible with VMware Fusion 6 and VMware Player 6 for Windows.
NOTE: First of all I’ve to say this is a hack, not something I’d recommend for daily work, moreover remember that there’s your physical installation of OSX inside that vm so don’t mess anything up otherwise you’ll have to fix them the next time you’re booting to OSX.
These are the steps to follow to create a VM booting from your physical OSX installation:
- Boot your OSX and install VMware Fusion 6 (you don’t need the pro version for this) on OSX
- Create an empty OSX VM. Don’t use “Install OSX from recovery partition”, you don’t need a new installation, you’re going to make the VM boot your physical installation, so just create a custom VM. In my case I created it for Mavericks (10.9) and I really don’t know if it works with other versions of OSX.
- Open Terminal and type “diskutil list” in order to get the list of your partitions, you should get something like this.
in the picture you can see that OSX is installed in partition 2 of disk0 (it should be the same for you, if it’s not just take a note of your partition number and use that instead)
- Reboot to your Boot Camp Windows installation and install VMware Player 6 (again, you don’t need any pro version, moreover the player is free for non commercial usage)
- Open the blank OSX VM settings with VMware Player (Fusion should have created a .vmwarevm file that Windows sees as a folder, inside that folder there’s the actual VM file which has a .vmx extension)
- Remove the current Hard Disk from the settings (the blank VM should have a SATA virtual disk sized 40gb) and replace it with a physical disk, here’s the steps to follow:
- Click the “Add” button at the bottom of the hardware tab in Virtual Machine Settings dialog and click next
- Select Hard Disk from the hardware types list and click next
- Select IDE from the virtual disk type options and click next
- Select Use a physical disk (yes, for advanced users) and click next
- Select Use individual partitions and click next
- Now, remember the partition you listed on the terminal when you booted on Mac? Select the partition where your OSX is installed, the partition file system should be Apple HFS… and click next
- Choose a name to save that virtual disk configuration and click finish!
- You should now have a configuration similar to this
Now your VM is ready to boot your OSX partition! Just tweak your VM RAM and CPUs to make it usable.
- VMware tools won’t install, at least it won’t for me, so the drag n drop file feature won’t work
- Bootcamp drive will not be accessible from OSX VM because in use by the running Windows instance, same will happen for every volume you mounted in Windows, such as CD-rom and USB keys
- I don’t know if it matters in any way but I’ve installed a driver to enable writing HFS+ filesystem from Windows (otherwise it was read only). The driver I use is Paragon HFS for Windows.
Once more, this is a hack and I don’t suggest you to use this approach for daily or frequent usage.
I don’t assure you it works in every machine nor I tried in other machines, it works on mine which is a MBP 6,1 (mid 2010).
I’m running Mavericks (10.9) on a mbp version 6,1 and Bootcamp assistant doesn’t let me create install windows from an USB drive.
Here’s how to fix it:
- Locate Boot Camp Assistant.app in /Applications/Utilities folder and backup it somewhere
- Right click the copy in Utilities folder and click on Show package contents.
- Locate Info.plist file and open it with a text editor
- Locate the tag “PreUSBBootSupportedModels” and change its name in “USBBootSupportedModels” (just remove “Pre”)
- Save that plist, it will require you to authenticate as administrator
- Now you should be fine if you’re running a system older than Mavericks.
If you’re running Mavericks you need to replace existing app signature as an extra step, otherwise Bootcamp assistant will close unexpectedly:
- Open the terminal and type “sudo codesign -fs – /Applications/Utilities/Boot\ Camp\ Assistant.app”
- The command will print out “Boot Camp Assistant.app: replacing existing signature” then quit.
- Now your assistant should display a new “Create a Windows 7 install disk” option
DiskUtility doesn’t let you restore a volume using an ISO image, only DMGs are accepted, otherwise it prompts you an error.
Here’s a workaround using osx hdiutil and unix dd command :
- open your terminal and cd to the directory where your .iso file is
- convert your iso to a dmg by typing “hdiutil convert -format UDRW -o myoutput.img mysource.iso”, depending on how large is your file it may take different amounts of time and print out the path to the created dmg (in this case “/path/to/myoutput.img.dmg”)
- once done you’ve to list your mounted disks with “diskutil list” and unmount the usb volume (not the device!!!) with “diskutil unmountDisk /dev/disk1″
NOTE: change disk1 with whatever disk number your destination drive is
- now restore the dmg image to your usb drive with the dd command by typing “sudo dd if=myoutput.img.dmg of=/dev/rdisk1 bs=8m”
NOTE: change rdisk1 with whatever disk number your destination drive is, if it was disk2 use rdisk2 and so on…
NOTE2: 8m means “8Megabites per second”, feel free to edit this param according to your needs
- when the command ends it prints out a stats report including total bytes transferred and time elapsed.
Hope this helps
Recently I had to deal with symbols conflict between C\C++ libraries and found this solution on stackoverflow:
In order to solve the issue on a mac it’s a bit you’ll need to run objcopy… but there’s no objcopy available on osx!!!
I worked around it and installed homebrew, a package manager for osx that reminds me ubuntu’s apt.
Homebrew is VERY easy to install, just copy\paste the ruby script on your terminal and it’ll download and install everything you need. Moreover it’s the cleanest solution I found so far on a mac because it’s installing ONLY on its directory (and you can choose the directory where you want it set up).
Actually there is no brewed formula to install objcopy and objdump (“brew search objcopy” returns nothing) but there’s a formula named “crosstool-ng” which is installing “gobjcopy” and “gobjdump” which are actually the same programs!
So just type
brew install crosstool-ng
on your shell and, when you’re done, edit your ~/.profile adding the following
to create aliases to those programs.
Now you’ve objcopy and objdump on your mac
I got into this error while setting up Jenkins to deploy a built artifact to a maven repository ( sonatype nexus ) on my Windows 7 system.
ERROR: Failed to deploy artifacts: Could not transfer artifact it.pigiuz.test.AutoDeploy:TestLibOne:swc:1 from/to pippo (http://localhost:8081/nexus/content/repositories/pippo/): Failed to transfer file: http://localhost:8081/nexus/content/repositories/pippo/it/pigiuz/test/AutoDeploy/TestLibOne/1/TestLibOne-1.swc. Return code is: 401, ReasonPhrase: Unauthorized.
org.apache.maven.artifact.deployer.ArtifactDeploymentException: Failed to deploy artifacts: Could not transfer artifact it.pigiuz.test.AutoDeploy:TestLibOne:swc:1 from/to pippo (http://localhost:8081/nexus/content/repositories/pippo/): Failed to transfer file: http://localhost:8081/nexus/content/repositories/pippo/it/pigiuz/test/AutoDeploy/TestLibOne/1/TestLibOne-1.swc. Return code is: 401, ReasonPhrase: Unauthorized.
It turned out that the default installation of Jenkins runs as SYSTEM not as <USER>, this means that the M2_HOME is not resolved in the current user .m2 folder and settings.xml is picked up from the maven installation folder.
To solve this issue Jenkins provides you an option under the “advanced options” menu at the “build” label to specify where the settings.xml is located.
here’s a screenshot of my configuration:
The specified settings.xml has to contain the credentials to deploy the built artifact to the wanted server. If you didn’t change the default nexus deployment user password the configuration looks similar to this:
You can find maven settings.xml file reference here http://maven.apache.org/settings.html