Migrating Windows 10 Anniversary Edition to USB-C External SSD Drive from USB-C MacBook Boot Camp Partition
Migrating a Boot Camp partition to an external drive can be challenging, but Windows 10 Anniversary (build 1607) gives some additional pain due to issues with the USB-C drivers.
The USB-C Macs have changed the physical block size of the internal drive and most external drives (including the Samsung T3 USB-C external drive I used) have the smaller block size (512).
One of the key features of Winclone 6 is the ability to migrate the Boot Camp partition between Macs with different block sizes. This makes Winclone 6 the idea tool for this task. However, it doesn’t solve the issue to USB-C drivers in Windows 10 after the Boot Camp partition has been migrated. For that, we will use the built-in tool, sysprep, to prepare the Boot Camp partition prior to migrating.
Here is how I did it:
First, I installed Windows 10 (build 1607) on a USB-C MacBook using boot camp assistant.
i let it boot up, went through the setup assistant, boot camp driver setup, and then created a user account. I then prepared the Windows installation for migration using Sysprep (C:\Windows\System32\Sysprep\sysprep.exe). I selected the OOB option and shutdown when completed. After sysprep completed, the Mac shutdown.
I then started up in macOS, and created a Winclone image of it using Winclone 6.
I then took my Samsung T3 USB-C SSD, which I formatted as an EFI partition scheme with 2 partitions (HFS+ and FAT32).
I then restored the Syspreped, Winclone image to the FAT32 partition on the external drive. Winclone 6 formatted the partition as NTFS and restored Windows.
When I rebooted into Windows on the external drive, it booted up and it discovered drivers. I then created a different user account, it logged into the desktop. I logged out and then logged into the original user I set up. The Boot Camp partition was now migrated. I booted back into macOS and removed the internal Boot Camp partition.
Finally, I booted back into Windows on the external drive and it booted without issue.
Winclone 6 adds some great new features to deploying a Boot Camp partition to a bunch of Macs and wanted to talk a bit about what has changed and some best practices.
First, Winclone 6 has moved from a block-based image based on NTFSProgs to one that is file-based based on WIMLib. Winclone 6 still supports block-based images for both cloning and restoring since it can be faster, but there are some disadvantages to block based imaging. The biggest reason is that the new MacBook and MacBook Pros have a 4096 physical block size on the SSD drives that ship with those Macs, and we expect that all new Macs will have this larger block size. While block based cloning works to restore correctly, Windows expects the MFT (basically the catalog) to have a larger entry size, and that prevents it from booting or mounting. The other big reason is that file-based works better is that you don’t need to shrink or expand the filesystem, which means less preparation and more flexibility when restoring the image.
In order to support file-based imaging, Winclone 6 uses the WIM format (through the WIMlib project). WIMlib uses NTFSProgs to make sure all the file attributes are cloned correctly. It also creates a wim file, which should be very familiar to folks that deploy on Windows. If you control-click on a Winclone image created by Winclone 6, you’ll see a Windows.wim file, which is compatible with Windows tools that know how to read WIM files. We are excited for the possibilities that using a standard format for Windows tools, and have some great ideas on how this can help admins in the future.
Another interesting new feature is the ability to read the Windows registry directly. In prior versions of Windows, we scanned the license text file in Windows to deduce the edition and version. Some organizations change that file as do some editions of Windows, so we had to prompt the user or make some assumptions. In Winclone 6, we use hivex to read the Windows version directly from the Windows registry, so we know exactly what version you are restoring (which is important to decide how to make it boot). Reading and writing to the registry opens up some interesting ideas for the future as well, as we can potentially insert drivers and configuration scripts to make first boot more reliable and customizable.
So what does that mean for you? If you are already using Winclone Pro to create packages to deploy Boot Camp partitions, the process is essentially the same. You no longer shrink the Boot Camp partition prior to cloning it if you use the new WIM file-format (which Winclone 6 now uses by default). It also means that the same image can be restored on both old and new Macs (assuming, of course, that the version of Windows you are restoring is supported on that Mac). Operations such as self-extract and package based restores should work as they always have, as well as creating Boot Camp partitions on restore from a package.
It also means that we should have some great new features coming in updates that will make it much easier to set up and customize the images when deploying.
If you don’t already have Winclone Pro, give it a try! It makes Windows deployment on a Mac easy!
We have been working on Winclone 6 for a while now, and have packed it with some great features that make it really easy to backup, clone, migrate and restore your Boot Camp partition. I wanted to do a blog post and highlight some of the features that I think are really interesting.
Top Feature #1: Compatibility. Winclone needs to be able to clone Windows to the widest arrange of Macs possible. Setting up your Boot Camp partition takes time and having to re-do that work when you get a new Mac can be time consuming. Apple did some changes to how the new MacBook and MacBook Pros that required some changes in Winclone. Winclone 6 now fully supports migrating from older Macs to the new Macs. You can ready all about the changes here if you are interested, but the key point is that you don’t have to think about it. Just create an image and restore, and Windows boots.
Top Feature #2: In-App Features. You can now see send a support request, see a tutorial video, or upgrade between Basic, Standard or Pro right in the app. This means that you get the information you need to get done right away.
Top Feature #3: Read/Write Mounting of NTFS Volumes. Sometimes you need to copy a file to the Windows volume before you boot into Windows. You can now select a volume, select Mount Read/Write from the tools menu, and start copy files.
Top Feature #4: Restore to Disk Image. One common requests we get is how do you know that the Boot Camp partition was cloned successfully? You never really know unless you restore, and that what makes Disk Image restore so great. You can restore directly to a disk image and verify that all your files were cloned correctly. You can’t boot from the Disk Image, but you’ll know that the restore process works and you can see all your files. It is also great for grabbing a few files from an image.
If you haven’t already check out Winclone 6, do so now! You can download, install and buy it right from in the app.
One of the surprisingly challenging tasks when working with Bootcamp partition is finding a consistent way to find the version of Windows that has been installed. Applications running in Windows can look up this value in the registry, but apps running in macOS don’t have that ability. However, I recently have been using the hivex open source project to read registry files from macOS. I created a simple command line tool that you pass the file path to the Windows registry file on the Bootcamp partition and the path to a key and the value you want. For example, here is how I grab the version of Windows from the Software node:
Counterfeit SD Cards are a widespread issue (see this article from EE Times,) and can be very hard to detect right away. The counterfeiters depend on it taking a while for you to figure out the cards have issues, and by that time, they have closed up shop and moved on. The only comprehensive way to detect if a card is misrepresenting how much space is available on an SD card is write data to the entire card and then read it back. SD Clone 3 for MacOS does exactly that. It generates random bytes and writes the data to the SD Card, then re-generates the same random bytes again to verify the card. If all the data is correct, then the SD Card passes; otherwise it fails. Each time the test is run, a new set of random bytes is used so it is a very effective technique to detect bad or counterfeit cards.
Verifying an SD Card is easy with SD Clone 3.
Step 1: Launch SD Clone
Launch SD Clone 3 and insert an SD Card into your Mac.
Step 2: Click Verify SD Card and Confirm:
Since random data will be written to the SD Card, it will complete erase all existing data on the SD card during verification. If you are sure, click Erase and Verify.
Step 3: Wait
Depending on the size and type of SD Card, it can take a long time to verify the entire card. You patience will be rewarded, however, with the knowledge of the validity of your SD Card!
Restore an SD Card image to an MacOS disk image with SD Clone 3
If you created an image of an SD Card with SD Clone 3, or downloaded an image from the internet (like the Raspbian OS), and want to see the contents of it, you can easily do this with the Restore to Disk Image feature in SD Clone 3. Here’s how:
Step 1:Select source and destination
Launch SD Clone 3 and drag the image into the sources column. Select the image and select Restore to Disk Image.
Step 2: Restore
Click the Restore to Disk Image button, and a spare bundle image will be created and restore to the disk image, all in one step.
Step 3: View Disk Image
Once the restore is complete, any mountable partitions will be mounted. The disk image itself will be available in Sources where you can do Shrink and Expand the Linux (Ext) partitions on it.
Clone SD Card from a larger size SD Card to a smaller size SD Card
If you do any work with the Raspberry Pi or other Linux based system that uses SD Cards as the primary storage device, you’ll run across a issue that can be time consuming and troublesome. When you purchase SD Cards, they are advertised as X number of GB’s. However, two cards that have the exact same number of GB’s (for instance 8 GB) advertised might not have the exact number of available space. For instance, I have a SanDisk SD Card that is advertised as 8 GB, but it has 7.95 GB of actual space. I also have a Kingston SD Card that is advertised as 8 GB, but it has 7.97 GB of available space. Normally, this isn’t an issue, but in some circumstances it can be problematic.
When it is a problem
If you install an operating system on an SD Card and want to make a copy of it, the simplest way is to get another SD card and do a byte-by-byte copy of the card. However, if the new card is slightly smaller, the operation will fail since the last partition on the original SD card cannot be completely copied. This can lead to corruption and problems with the new SD Card. Copying an SD card from a smaller card to a larger card doesn’t have this issue, but it you lose the additional space (not a big deal if it is only 0.02 GB, but is a bigger deal if you are going from a 8 GB card to a 16 GB card).
The Solution
The solution is to shrink the last partition so that it is only as large as the actual space being used. The card can then be copied and the last partition on the new SD Card can be expanded to take up all the remaining space.
SD Clone makes this operation easy, and has 2 different ways to accomplish it. The first involves shrinking the filesystem on the original card, making an image of it, then restoring that image to a new card. The second way is to make a copy of the original SD Card to a disk image so that you are not making any changes to the source SD Card. You then do the shrink operation on the disk image, make a clone of the disk image, and then restore that image to the new SD Card. Both ways work equally well, but the second way is slower but safer (since it doesn’t change the source SD Card).
Technique 1: Shrink Original SD Card
To shrink the original SD Card, launch SD Clone 3 and insert the original SD Card. Select the SD Card in Sources, and click the Shrink button in the toolbar. This will shrink the last Linux (EXT) partition on the SD Card, and then resize the partition to the size of the filesystem. When it is done, create a clone of the SD Card by selecting the SD Card in Sources, select Save Image in Destinations, and click Save Image...
Once the image has been created, you can expand the filesystem on the original SD Card by selecting the SD Card and click Expand in the toolbar. You can then eject the original SD Card, insert a new SD Card, and restore the image to the new SD Card. The size shown next to the image in sources is the minimum size SD Card you will need to restore the image.
Technique 2: Create Image, Restore to Disk Image, Shrink, Clone and Restore
The second way to do this involves a few more steps, but is safer since you do not change the source. As with the first technique, insert the original SD Card. Select it in Sources, and create an image of it by selecting Save Image and clicking the Save Image button. Give the image a name and click Save, and a image of the entire SD Card will be saved. Once this is completed, you can eject the original SD Card and put it away for safe keeping.
Back in SD Clone, select the image you just created, and restore to a disk image by selecting Restore to Disk Image in Destinations. Click Restore to Volume..., give it a name, and click Save. This will restore the image to an MacOS disk image.
Once the disk image have been saved, it will show in the sources, and you can shrink, clone, and restore it just like an SD card using technique 1.
I create a video of how to do this as well showing both technique 1 and technique 2:
SD Clone 3 has some awesome new features and I wanted give an overview of what it can do and some background on how those features came to be.
New Feature 1: Image Central
One of the common issues when someone gets a new Raspberry Pi is “What do I do with it now?” Image Central is a great place to grab an image of a great existing project, put it on an SD Card, boot up the Pi, and start experimenting. I plan on discussing these projects in a series of upcoming post and will be adding more to the list in the future. Image Central has images for a couple of media players, the base Raspbian OS, a music player, and more.
New Feature 2: Verify SD Card
A year ago, I ordered a dozen or so 8 GB Micro SD Cards from Amazon. I wanted to make sure that I got quality SD cards, so I ordered cards that were from Kingston, and the seller was Kingston and not a 3rd party. Once I got the cards, I found that after imaging them, they refused to mount. I thought there was an issue with my process, but it turns out that the cards were counterfeit. after some research, it became clear that testing SD cards is a important feature for anyone that does deployments with SD Card based iOT device. So the Verify SD Card feature was added to SD Clone. It generates random series of bytes that get written to the SD card to fill it up, and once it is full, it regenerates that same series of random numbers and verifies that the data was written correctly.
New Feature 3: Toolbar
Not a new function, but the toolbar gives you access to all the interesting features that you might not have been aware of before. Right from the toolbar, you can eject a SD Card, shrink a Linux (ext 2/3/4 filesystem), get access to tutorial videos and more!
New Feature 4: Purchase in the App
With SD Clone 2, we featured a “pay what you want” model, and found that most people were paying about $40 for SD Clone. We decided to build that price in and give an option for a Pro feature as well (with Unlimited Concurrent Restores). When you download the app as a Trial, you get access to all the features, and when the trial runs out, it reverts to a Free version which has a limited feature set (restoring images, Image Central). You can upgrade to the paid version right in the app, using the awesome system from Paddle. And if you decide you want to upgrade from Standard to Pro after your purchase, you can do that right in the app as well. Pretty slick.
There are a bunch of other features (like .gz image support, better file naming inside the zip file, etc) so I think you’ll really like SD Clone 3. Head over to twocanoes.com and download a trial and let me know what you think.
I also created a video of the new features, so check that out as well:
Last month I wrote about issues with block sizes and migrating Boot Camp partitions and said this:
There is currently no way to update the MFT record size without reformatting, but I will continue to investigate and will update as I know more. In the meantime, you can always boot Windows in Boot Camp with an external drive, or reinstall/migrate Windows.
Things have changed a lot in the last month! We have been hard at work on Winclone 6, which makes it easy to migrate from a non USB-C mac to the new USB-C macs. It also means that if you do package deployments with Winclone, you’ll be able to have one image to deploy on any boot camp partition. How is all this magic possible? We are introducing a new file format for Winclone based on the WIM file format. It will give lots of flexibility to include drivers, scripts, and other files on during restore (and package deployment).
Want to give it a try? The beta version is available to all current Winclone 5 customers. Sign up here!
USB-C MacBook / MacBook Pro Physical Block Size Change
The new MacBooks and MacBook Pros have garnered a bunch of discussions online, mainly around the new Touch Bar and the USB-C only inputs. There was an additional change as well: The hardware block size is now 4096 bytes versus 512 bytes. While this is pretty esoteric, it does represent a pretty big switch for a computing platform. But first some background.
What is physical block size?
Physical Block size is the smallest amount of data that can be written at one time to a disk. Physical Block Size can also be referred to as sectors, but sectors is a term that has its roots in spinning platter disks. I suspect Apple uses the term Physical Block Size since it is more universal across SSD’s and spinning platter disks.
You can see the physical block size of compared to the filesystem block size on a prior generation of MacBook Pro:
For this MacBook Pro, the smallest amount of data that the filesystem can write at one time is 4096 bytes, and the smallest amount of data that the device (in this case, my internal SSD) is 512.
Advanced Format Drives
It is important to understand that the Device Block Size is set by the physical device (like a SSD or spinning platter disk) and is not adjustable by the filesystem. However, having the filesystem block size be a multiple of the physical block size is important for speed, so they two are related. Also, there are some speed advantages for having the physical block size and filesystem block size be the same. To address this, Advanced Format Drives were created. Advanced Format Drives support 4096 Device Block Size and have many advantages (see here). However, there is one major disadvantage: software legacy assumptions. Disk Utilities and Operating Systems (such as Windows) assumed that a physical block size of 512 bytes. To address this, a compatibility layer was introduced called 512e. The disk used 4096 Physical Block Size, but tells the attached computer that the physical block size is actually 512 bytes. This provided compatibility but did not expose all the advantages of the native 4096 byte Physical Block Size.
USB-C MacBooks
So with the USB-C MacBook and the new MacBook Pros, the Physical Block Size changed to 4096. You can see this change by running the same command as above on one of these new Macs:
Device Block Size: 4096 Bytes
Implications For Boot Camp Booting Windows
We discovered an issue with Advanced Format Drives in MacBooks when the USB-C MacBooks came out. Modern versions of Windows fully support Advanced Format Drives, both native 4096 blocks size and 512e emulation. However, issues come about when transferring a filesystem from a 512 physical blocks size to a 4096 physical block size. The Master File Table (MFT) is what keeps track of all the files on the NTFS filesystem, and it normally has a 1024 bytes entry per file on 512 physical block device. However, if you install Windows on a 4k physical block disk, the MFT has an entry size is 4096 bytes. When you transfer NTFS from a device that has a physical block size of 512 to one that has a physical block size of 4096, the MFT entry size is still 1024 bytes. This is what causes Windows issues with booting. Windows assumes that if the physical block size is 4096 or greater, then the MFT entry size will be the same size (4096 or greater). From the MSFT note on 4k file systems here:
2. File records will assume the size of the logical block size of 4KB, rather than the previous size of 1KB. This actually improves scalability to some degree, but the down-side is that each NTFS file record will require 4KB or more in the MFT.
In fact, if you go and update the NTFS BPB Bytes per Sector, sectors per cluster, and Total Sectors to make it match the 4096 physical block size of a device, and then try and mount it, MacOS will give you:
Mft record size (1024) is smaller than the sector size (4096). This is not supported. Sorry.
When you try to boot Windows on the USB-C MacBook after these modifications, Windows will error with an “Unaccessible_Boot_Device” error. I highly suspect that the reason that the boot partition cannot be mounted is due to the MFT record size.
There is currently no way to update the MFT record size without reformatting, but I will continue to investigate and will update as I know more. In the meantime, you can always boot Windows in Boot Camp with an external drive, or reinstall/migrate Windows.
I was creating a Raspberry Pi project and needed to make a bunch of SD cards to install in over 30 Raspberry Pi's. I had been using the command line tool "dd" to make an image of our SD card, and would then restore it to a new SD card. That worked fine, except that it was very slow. So I create SD Clone.
I was using 8 GB SD Cards, and it was taking about 22 minutes per cards to restore. We were doing a deployment of 30 Raspberry Pi 2 B+'s, so I started looking around for ways to create copies of SD cards, but all the dedicated hardware options were expensive ($1000+). At the same time, we were having issues with an image restoring to an SD card that was slightly smaller than image created with dd. Since dd makes a block-by-block copy of the SD card, the new card needs to be the same size or larger, and that was causing errors.
So I created an MacOS app that lets to create an image of an SD card and then easily restores that image to multiple cards at once. I can now crank out 8 SD cards in about 15 minutes. I also added in a feature that shrinks the last Linux EXT2/3/4 partition, so the image only has the used space. When the image is restored, it is much faster since much less data is copied. I also added a feature that automatically expands the last Linux EXT2/3/4 partition when a restore is done, so if you restore on to a larger SD card, all the available space is used. You can also use it to restore images you get from raspberrypi.org or elsewhere.
Step 1: Download SD Clone
Head over and download SD Clone from Twocanoes Software. There is a full functional trial and I made it a "pay what you want" app.
Install SD Clone on your Mac.
Step 2: Shrink Last Linux Partition
Insert your SD card into the SD card reader on your Mac, and it should show up in the sources in SD Clone. Select the SD card in the Sources, and In the gear menu, select Shrink Last Linux Partition in the gear menu.
Step 3: Create Image
Now you can create the image. Select the SD Card as the source, and select Save Image from the Destination. Enter in a filename, and click Save. The image will now be created and added to the Sources column.
Step 4: Restore 8 SD Cards at once
I needed to find a way to hook up lots of SD cards at once, and while I could have used a USB hub and lots of readers, I found a 4 SD card reader on amazon:
Insert all the SD cards at once, and connect the reader to your Mac. You should see all of them show up in the Destination. Select the source, and then select all the destinations (or press command-a to select them all). You'll see a checkbox on each of the destinations. Click Restore, and the image will be cloned to all 8 SD cards at once. Once the image is restored, the last Linux partition will be expanded to take up all used space on the cards so when you boot to it in the Raspberry Pi, you'll have all the available space.
USB Speed Considerations
I did a bunch of tests and found that more than 4 SD cards on a single USB bus did not help, since the USB bus became the speed bottleneck. My Mac has 2 USB buses (one for each USB port) so I stuck to create 8 images at a time. I also played around with USB 3, but since the 4 USB card reader was USB 2 only, using USB 3 ports didn't make a difference. I could use a bunch of USB 3 readers and a USB 3 hub, but that was prohibitively expensive.
I made a video of the restores that you can see here:
How El Capitan Boot Camp is Affected by Apple’s New System Integrity Protection (SIP)
With Apple’s new System Integrity Protection (SIP) in OS X 10.11, the Mac is now ever more secure. But with SIP comes some additional restrictions that affect how System Administrators can make Windows bootable during deployments.
SIP prevents any user (including the all powerful root user) from writing to specific locations in OS X (mainly in the System Folder). Rich Trouton has some great info on SIP at his Der Flounder blog here that cover the folders that are protected and some great information on NetBoot and SIP.
One of the protections that SIP puts into place is a restriction from modifying the startup disk programatically:
Configuring System Integrity Protection (developer.apple.com)
Note: To safeguard against disabling System Integrity Protection by modifying security configuration from another OS, the startup disk can no longer be set programmatically, such as by invoking the bless(8) command.
You can still set the Startup Disk using the Option key at startup, or by using the Startup Disk System Preference Pane. However, you can no longer change NVRAM or the boot sector on the disk. NVRAM holds the currently selected disk for next reboot.
In prior versions of OS X, you would use the “bless” command to change the bootable disk. This now fails, as “bless” writes to NVRAM, which is protected by SIP (even for the root user). Bless is still on the system for a couple of reasons. First, if SIP is disabled, the prior functionality returns. Second, Apple utilities (such as the Startup Disk preference pane) use bless to set the selected startup disk. But how is Apple able to use “bless” and restrict its use for anyone else? OS X uses digital signatures to determine if bless can be run. Only Apple apps signed with a identity from Apple and a correct entitlement are allowed to run the bless command.
This all relates to Boot Camp and booting Windows through the boot sector. The boot sector is the first sector on a hard disk, and is usually used when legacy booting Windows. SIP restricts access to the device that OS X is booted from (usually /dev/disk0), even for the root user.
This is where the situation gets interesting. Modern Macs always boot via EFI, but Windows hardware has only recently started natively booting EFI. While there was some support for EFI booting Windows 7, Apple didn’t support EFI booting Windows until Windows 8. With the newest Apple hardware, Windows 8 or later is required, and EFI booting is the only way that Windows will boot on the Mac.
Usually you don’t have to worry about any of this, since Boot Camp Assistant and the Windows installer will set everything up correctly. But what happens if you are mass deploying Boot Camp and having issues?
If you use Disk Utility to create a Boot Camp partition on El Capitan (10.11) or earlier, OS X will create what is called a “hybrid master boot record (MBR)”. This lets Windows boot via “legacy” mode, which (as mentioned before) is not supported on the newest Macs. You can see it in OS X using the fdisk command:
SIP does not prevent you from reading information (such as the Master Boot Record), but does prevent any writing to the MBR.
If you use Boot Camp Assistant to create the Boot Camp partition, you’ll get a standard EFI “guard” MBR:
The hybrid MBR has an entry for each of the first 4 partitions. The guard MBR has only a single entry that covers the entire disk (used to protect legacy tools from doing bad things).
The difference is important, since it affects how Windows will boot. If Windows 7 or earlier is running on older Macs, it needs to have a hybrid MBR. If Windows 8 or later is running new Macs, a standard “guard” MBR is required. If the wrong type is used, Windows will refuse to boot (usually with a black or blue screen). The common way to resolve this issue was to write a new MBR, but since SIP restricts access to the master boot record, it seems impossible unless you disable SIP.
However, there are a couple of workarounds. Since Apple tools can write a MBR, you can use this to get the MBR in the correct mode. Here are the tools and what they do:
Disk Utility (or diskutility command line):
If a FAT or XFAT partition is created in partition 4, a hybrid MBR is created.
If a HFS+ partition is created in partition 4, a guard MBR is created.
If partition 4 is erased (rather than deleted and then created), the MBR will not change.
If a partition is deleted and partition 4 becomes a Windows partition, a hybrid MBR is written.
Boot Camp Assistant
New Macs (support only Windows 8 and later): A guard MBR is written.
Older Macs (supporting Windows 7): A hybrid MBR is written.
Using these tools, you can create the MBR in the state that you want. If you are on a newer Mac, and want a guard MBR, you have 2 options:
1. Use Disk Utility, and create a small (10 MB or so ) HFS+ partition at partition 4 and the Windows partition at partition 5. You can also use the disk utility command line:
This takes a standard OS X partitioned disk and shrinks the OS X partition to 400 GB, create a 10 MB HFS+ partition, and fills in the rest of the space with a MS-DOS partition.
This results in a guard master boot record. You can’t delete the HFS+ partition after Windows is installed since that results in a hybrid MBR being written.
2. Use Boot Camp Assistant. Boot Camp assistant will create a disk layout that looks like this:
You can see from the above screen shot that the BOOTCAMP partition is created on slice 5, right after the OSXRESERVED partition used to install Windows. After the next reboot into OS X, OS X will automatically delete the OSXRESERVED partition and put the space back into Core Storage. When this partition is deleted, the MBR is not converted from guard to hybrid. The MBR will remain a guard MBR, which is exactly what you want for EFT-booting Windows such as Windows 8 or later.
Apple is making great strides in securing OS X, and SIP goes a long way to protect the system. With some knowledge and understanding, you can still get the same or similar behaviors from prior versions of OS X, and with the extra protections of SIP.
Do you have Windows running on your Mac in a Boot Camp partition? Check out Winclone and Boot Runner to backup, migrate, and manage your Boot Camp partition.
Find this article interesting? Let me know what you think by tweeting at me on Twitter: @tperfitt
Apple Boot Camp No Longer Requires USB Flash Drive to Install Windows in El Capitan
Some very interesting changes in how Windows is installed in Boot Camp on OS X 10.11 “El Capitan”. When you open Boot Camp Assistant on a new Mac that supports Windows 8 or later, you’ll get the new Boot Camp interface.
Notice the ISO image and partitioning are all on a single screen. Prior to El Capitan, you had to insert a USB Flash Drive and Boot Camp Assistant copied the Windows installer from an ISO disk image to the flash drive, and then downloaded and set up the Windows drivers to the correct location in the installer for the Mac hardware. El Capitan makes this a lot simpler. Just select the ISO and how much space you want from Boot Camp, and then you click Install.
After Boot Camp Assistantd completes, OS X restarts to the Windows installer, and you follow the normal Windows installation.
Behind the Scenes
So how is this possible? Where is the Windows installer if there is no installation media? Boot Camp Assistant doesn’t just create a Boot Camp partition, but also creates an additional partition called “OSXRESERVED” that is FAT32 formatted. It places this partition right after the recovery partition, and before the Boot Camp partition, as shown below.
The command line make this really clear. Partition 1 is the standard EFI partition, partition 2 is the Mac partition, partition 3 is the Recovery partition. All standard stuff. Partition 4 is now the OSXRESERVED partition, and partition 5 is the BOOTCAMP partition. You’ll also notice that disk2 is the Windows install ISO disk image that the Windows install files are copied from.
The OSXRESERVED partition has all the installer files, the Boot Camp drivers for Windows, and the EFI files for booting.
If you are familiar with EFI booting on OS X, you’ll see a familiar setup. The EFI folder on the OSXRESERVED partition is the same one you would normally find on the EFI partition (normally disk0s1). It appears that newer Macs have the ability to detect this partition and present it to Windows as if it were EFI installation media (such as a DVD or USB Flash drive).
So what happens to this partition after you are done installing? During the next boot into OS X, the OSXRESERVED partition is removed and put back into the Core Storage container of the OS X partition:
Note that the Device is disk0s5 since the other partition existed on startup, but then it was deleted. On next reboot, this device will change back to disk0s4, which is the standard device location for a Boot Camp partition.
This setup is not supported on all Macs that run El Capitan. Only hardware that has newer firmware supports this. We did a survey of all the shipping Macs, and here are the ones that support this new slicker setup:
Supported:
Mac Pro
MacBook Air 13‑inch
MacBook Air 11‑inch
MacBook Pro 13‑inch
MacBook Pro 15‑inch
Older USB Installation
iMac 21.5″
iMac 27″
MacBook Pro 13‑inch
USB-C MacBook (surprising)
El Capitan’s Boot Camp-related updates are not just limited to Boot Camp Assistant. There are also changes in how Boot Camp is affected by the new System Integrity Protection (SIP). Tune in tomorrow for the next segment.
Do you have Windows running on your Mac in a Boot Camp partition? Check out Winclone and Boot Runner to backup, migrate, and manage your Boot Camp partition.
Find this article interesting? Let me know what you think by tweeting at me on Twitter: @tperfitt
We had a great time attending this year’s Penn State MacAdmins conference in College Park, Pennsylvania. Our team had the opportunity to talk about our Winclone and Boot Runner software for managing dual-boot labs, as well as iBeacon technology.
Fun at the Booth
We had the opportunity to meet new people have a lot of great dialogue about iBeacons, Winclone, and Boot Runner. We met customers from all over the World and offered on-site demos.
Click here to learn more about our products
Managing Windows in a Mac World
Our product manager Russell Scheil had the opportunity to talk about managing dual-boot labs in education and iBeacons in classroom settings.
Click here to learn more about our solutions for dual-boot labs in Education
Proximityd Starter Pack
We introduced our Proximityd Starter Pack which allows admins to easily use configuration profiles and iBeacons in Mac OS X. Two lucky winners won a 3-pack in our Sponsor Raffle!
Click here to learn more about Proximityd
Tussey Mountain
We joined in on the festivities at Wednesday night’s event at Tussey Mountain ski park and saw some great views coming down the Mountain.
#TeamTwocanoes
We met some new fans who wanted to join our Twocanoes Team
Birds of a Feather
We had a great time hosting a table discussion on iBeacon technology. Applications in retail and education are endless.
Click here to learn how beacons work
Proud Sponsors
We were happy to be a sponsor for this year’s event. Our service Bleu Meetings was used for easy attendee check in. And a special thanks to the great folks at Penn State, Justin Elliott, Gretchen Kuwahara, Dave Test and Rusty Myers!
Manage your Macs using iBeacons! Run a command, install a package, enforce a policy just by having the Mac in range of a beacon. Just install the package and you can change any setting, install any package, apply any policy based on proximity to any iBeacon.
Proximityd is a daemon that runs on OS X. Once installed, it that listens for beacons and automatically runs scripts in the background based on rules you set up. All configuration is done via Configuration Profiles, so setup is a breeze.
Getting Started
First, purchase iBeacons at store.twocanoes.com. Our beacons (and this project) will support Trusted Beacons, which means that you can know that your iBeacon is not being spoofed. You can use the beacons in standard mode as well and proximityd will work fine with it.
In the downloads section, grab the latest DMG. Open the disk image and double click on the installer, and following items will be installed:
/Applications/Utilities/Proximity Service Setup.app: Configuration app for generating a configuration profile for use with the daemon.
/Library/PrivilegedHelperTools/proximityd: This is the daemon that gets launched.
/Library/LaunchDaemons/com.twocanoes.proximityd.plist: The configuration file to start up the agent.
The installer will start up the daemon so no restart is required.
Configuration
All the configuration is done via configuration profiles, either locally or via a MDM server. A sample profile, called “3PackConfig.mobileconfig” is included as an example. When you install this configuration profile, it will do 3 things when leaving/entering 3 beacon ranges:
INSTALL PRINTER:
UUID: E2C56DB5-DFFB-48D2-B060-D0F5A71096E0
MajorNumber: 1 MinorNumber: 3
Enter Command:
lpadmin -p DemoInkJetFaxPrinter -v socket://19.86.82.172 -P '/Library/Printers/PPDs/Contents/Resources/hp color LaserJet 2500.gz'
Exit Command:
open /System//Library/Frameworks/ScreenSaver.framework/Versions/A/Resources/ScreenSaverEngine.app
Creating your own profiles
To create your own configuration profiles, open the configuration app in Utilities called Proximity Service Setup:
When done, click Save Config Profile, and then install that config profile on any Mac that has proximityd installed and the settings will immediately take affect.
Twocanoes was lucky enough to obtain a ticket for WWDC 2015. Here are some observations we came away with, and how it will affect out products here at Twocanoes Labs.
It’s a Whole New Crowd
Once upon a time, Apple platforms enjoyed a small but dedicated group of developers. WWDC was generally populated by the same crowd year after year. It was a great chance to catch up with old friends. These days thing are much different. I saw exactly two people I knew at the conference, in addition to a couple I ran into outside the conference.
While I agree with’s Apple’s strategy of keeping the conference size small, it means that even if you are lucky enough to get in, you probably don’t know many other people with the same luck. Plan your social and networking opportunities accordingly.
It’s All About the Labs
The sessions are most useful to the extent that they prepare you for the labs afterwards. If you attend WWDC and do nothing but sessions, you’re squandering the best opportunities available.
We spent some time in the Accessories Lab to talk to Bluetooth engineers about some ways we can improve the interaction between Blue Setup and Bleu Stations.
We also spent time in the Swift lab and Testing lab. The testing suite for the Bleu SDK relies heavily on mocked versions of Core Bluetooth objects. While it works, there are a couple problems with mocks. One is that they are difficult to use in a strongly-typed Swift environment. Another is that they tend to be fragile, even when properly built out in Objective C. Protocol-oriented development provides a path to testing that can avoid mocks and still test the code that interacts with system objects we can’t create.
The Pendulum is Swinging Towards Swift
I’ve always liked Swift, but there hasn’t been a huge reason to migrate away from Objective-C. Swift has nice features, an I’m generally a fan of strong typing. Even so, writing new Swift seemed like a wash in the overall tradeoff.
With features like Protocol Extensions and Availability checking, Swift is gaining tangible benefits over Objective-C. Also, Xcode and the debugger are getting more robust support for Swift. Overall, I’d say the advantage has tipped towards towards Swift, especially for new development.
Our Blue Station SDK will be Objective-C for the immediate future, but we do plan to implement the new Objective-C nullability annotations to make it easier for developers to call our SDK from Swift.
The new MacBooks have been getting some attention, in large part due to the single USB 3 Type C connector that further simplifies Apple's hardware connectivity options. Our mission was to install Windows 10 for testing Winclone and Boot Runner and the process had some interesting twists.
The one-port challenge
First of all, due to the limited connection options on the 2015 MacBooks, installing Boot Camp requires using a separate USB-to-USB Type-C dongle to connect the USB flash drive that contains the Windows installer and device driver files created by Boot Camp Assistant. We had heard about some issues booting from the USB flash drive during the Boot Camp installation, but previous tests installing Windows 8.1 64-bit had been trouble-free.
We used the latest Windows 10 Insider Preview 64-bit Build 10074 ISO image and Boot Camp Assistant to build the USB flash drive installer, all of which worked as expected.
However, booting from the installer flash drive left the MacBook without control of the internal keyboard and trackpad. Since the flash drive boots in legacy BIOS mode, the required 64-bit internal keyboard and trackpad drivers are not loaded, leaving us temporarily stranded. The installer screen was sitting there showing the dropdown menus for language, time and keyboard region and the "Next" button waiting for input.
Saved by the hub
After a bit of headscratching, we pulled the flash drive with the system still running and inserted a bus-powered 4-port USB hub, attached the flash drive and external class-compliant USB mouse and keyboard. The external keboard and mouse worked and the installation proceeded without issues, despite having the boot media removed and re-attached to a USB hub.
Following installation we removed the hub, mouse and keyboard, restored the AC power cable to the USB-C port and rebooted. Windows 10 proceeded through the account setup wizard. The internal keyboard was working and the trackpad was limited but functional.
Despite the fact that the Boot Camp drivers had not yet been installed, the display came up in incredibly high resolution. Historically Windows running on default display drivers runs in very low resolution. In this case the resolution was so high, my 50-year-old eyeballs could not read the text without putting my nose up to the screen. It was encouraging to see Windows default drivers loaded optimized for the MacBook's retina display.
A dazzling display
We connected the USB flash drive again, navigated to the Boot Camp folder and launched Setup and installed the Boot Camp drivers. On completing the install, a check in Device Manager confirmed that all hardware device drivers had been installed. All good! The display resolution was driving me bananas, but setting the Display zoom to 150 percent made everything look perfect. Windows 10 displayed on the 2015 MacBook retina screen looks pretty danged spectacular.
It will be nice to have the keyboard and trackpad issue fixed in Boot Camp Assistant by the time Windows 10 officially drops, because it looks and performs wonderfully on the 2015 MacBook.
Twocanoes Blog @twocanoessoftware - Tumblr Blog | Tumgag
