Odd intermittent issues with imaging El Capitan

  • Image profiles are not designed to use different schemas based on different sized hard drives. You should never need to create the image specifically for different sized hard drives, that was one of my main goals in designing CloneDeploy. I believe what you are seeing is just by chance that it seemed to repair the computer, and has nothing to do with the schema matching the hard drive size.

    The upload schema only option was never meant to add on to an existing image. It is there to give you control of how you want to upload the image, for example if you only wanted to upload only one partition, you would upload only the schema first, select that partition, remove the upload schema only and finally do a normal upload. When uploading the schema only everything is deleted because you should be eventually uploading a new image.

    Based on the log, only two things actually happened.
    1st. All of the information before the start of the first partition was erased. In this case the first 40 sectors were erased. This is normal, and typically gets restored from the file called table, but you no longer had a file to restore, so that information remained blanked out until the partition table was recreated. Is it possible something there was causing the fsck to fail, seems unlikely but who knows.

    2nd. The fsck simply ran again. It's possible for some reason that just running the fsck again from within the CloneDeploy boot image magically works the second time, or maybe only after booting in OS X one time and then back to the CloneDeploy boot image.

    I would test the second theory. Boot one of the broken Macs to the CloneDeploy Client Console. And try running the fsck on the last two partitions.
    [code]fsck.hfsplus -f /dev/sda2
    fsck.hfsplus -f /dev/sda3[/code]

    If that still doesn't work, I'll show you how we can test the first theory.

  • I sent you an email with some files to look at that may help better show what i'm seeing. I tried fsck.hfsplus -f /dev/sda2
    fsck.hfsplus -f /dev/sda3

    But as you will see in the pic it still errored out. I did another test with a 1TB imac making an "image" that only had an uploaded schema, deployed it back down to the same machine and it fixed the drive.

  • At this point I'm convinced that it's either the table file not being restored or the repartitioning that is fixing this. With your good image the one that actually has files. Rename the table file to table.bak then try to deploy it to one of the broken macs. This will replicate the idea of not restoring the table file

  • I tried your idea of adding .bak to the file name but had the same result, invalid node tree 3,0. As a test i then imaged the machine just using the blank "1TB imac" image with just the schema in the image folder and again it didn't image the machine but did run the FSCK and once again fixed the drive. Did you get the video and screen shots i emailed you as reference by chance?

  • yea I got them, they show exactly what you describe. I still don't think this is a schema issue. I suspect that even if you just took the schema file from the original 300gb image or whatever it was, made a new image and just copied the schema file over and deployed with that it would also fix it. Can you try?

  • Ok so file this under Bizarre...I decided to delete the schema file within the image folder containing the good image. I then copied the "1TB" schema file that was repairing the drive and pasted it into the known good image folder and low and behold....all my clients are imaging properly now and have no node tree errors. I have a couple of thousand Macbooks we will be imaging over the next few weeks so i'll see if this fix holds true for all of them. Thanks for your help man. Still all very odd why I needed to do this though? Thanks!

  • I would double check to make sure you can image drives smaller than 1TB with that schema

  • Yep, that is what I tested. So far a 350gb and a 500gb have imaged great with no issues.

  • Ok, i'm officially lost, I have no idea whats happening. As long as it's working I guess. If you get a few mins can you attach both schemas? I'm still interested in why this works.

  • Sure thing here you go. I had to add .log to the extension for it to let me upload. The working one i added working to the name so you can tell them apart at first glance.