Any idea why disk0s2 always formats to 14.1GB?

  • No matter what i do messing with the profiles, i can't get this image to deploy to the 11" Macbook Air drive. In the log i noticed that no matter what it always tries to format /dev/disk0s2 as 14.1GB which then errors out when imaging saying the drive isn't big enough. Is there something i need to do different with these 11" Macbook Air's using these NVME drives in order for them to use the whole drive? See attached clientlog.


  • I'm guessing you took the image from a 512b hd and are restoring to a 4k drive? In the linux environment it will just stop with an error because you can't do it, or at least I haven't been able to get it to work. With the OS X I had no 4k native drives to test with, so I did not implement an error situation, i was hoping it might just work. But even at that the partition scheme is not accounting for the 4k for some reason. Can you attach the schema for the image?

  • Yup you got it, that's exactly the case. Here it the attached schema. So here is my question i guess: would it be possible down the road to, say, have a checkbox that said something like "4K drive" and if checked would overwrite the schema file do use the correct LBS/PBS? or possibly allow for different profiles to use a different schema? That way we don't have to mess with the original schema, but it might make a duplicate one with the LBS/PBS changes?

  • You shouldn't have to, when deploying I check the lbs on the client and the lbs on the original uploaded image, if they don't match I make the correct adjustments. At least that was the plan, obviously that isn't happening. It's probably something stupid I missed. Even if when I get the partition issue fixed there is no guarantee it will image successfully. Like I said these are block based clones, I have never been able to restore 4k native to 512 and vice versa using partclone with the Linux imaging environment. I guess we'll see what that mac environment does.

  • So I believe this is actually something strange on Apples part. According to your logs my calculations were done correctly. See this line that create the partitions.
    [code]diskutil partitionDisk /dev/disk0 3 "Journaled HFS+" "Macintosh HD" 29116157s "Journaled HFS+" "Recovery HD" 158692s "Free Space" "" R[/code]

    Whe can see that it should create the partition with the size being 29116157 sectors. When multiplied by 4096 gives you around 119GB, but when multiplied by 512 gives you 14.9GB. So it appears that apple's disk utility is always treating a sector as 512b even though that is incorrect. I think we just need to remove the code that converts the sizes when using the macos environment.

  • Found the answer in the diskutil man page.
    [quote]S | UAM ("sectors") is 512-byte units (device-independent) where the multiplier is always

           •   DBS ("device block size") is the device-dependent native block size of the encompassing whole
               disk, if applicable, where the multiplier is often 512, but not always; indeed it might not
               be a power of two.[/quote]

    looks like I just need to change the s to dbs

  • Oh interesting, is this something i can manually change to test out or something i would need a patch for?

  • Try this, overwrite existing at web directory\App_Code\BLL\Workflows\

  • Yup, that did the job! Thanks man!