nvme0n1p2 fatclone c: is not in a valid state

[Tom Elliott]

@Psycholiquid I kept thinking it was download for some reason.

[Psycholiquid]

@Tom-Elliott Ahh ok.

[george1421]

@Psycholiquid Can we isolate this issue to this specific hardware? Its unclear to me (at this distance) if your issue is with the M.2 disk, the device, or something crazy that win10 is doing.

Thinking about it, I’m not sure trying to duplicate this on different hardware is the answer either. Unless you could build a reference image on different hardware and then deploy to this troubled system.

Is it safe to assume you are not using mdt to create your reference image.?

[Psycholiquid]

@george1421 Correct I am not using MDT to create them. I am however seeing this same result off of the Surfaces. So I will break down what I am using and that way we can all see what is happening:

System 1) HP Z240 using NVME drive.

I am creating the image by starting machine up and going through the normal windows start motions for a new machine (basically it is OOBE when I get it) I then upgrade the machine to Enterprise by switching the key. I then install all software I need and make changes. I then switch it into Audit mode (running sysprep). From there I place my Unattend.xml and launch it using elevated command prompt.

System 2) MS Surface 4 Pro using NVME drive.

I am creating the image by starting machine up and going through the normal windows start motions for a new machine (basically it is OOBE when I get it) I then upgrade the machine to Enterprise by switching the key. I then install all software I need and make changes. I then switch it into Audit mode (running sysprep). From there I place my Unattend.xml and launch it using elevated command prompt.

So basically they are both using similar hardware in regards to the drives (Not sure on the MB part though)

[Psycholiquid]

And it just keeps getting better and better.

So i took a RAW image of the PC and when I try to put that image back onto the device I get the following:

Now I am thinking it isn’t the OS but the hardware. The reason behind this is when the machine is done imaging it comes up and does its sysprep motions just fine. and all my testing in the VMs were good also. But this doesn’t answer why the partition went bad either, I am thinking it is the Audit mode that causes that and I am building a new OS on the machine now to test the theory and find out.

[george1421]

@Psycholiquid said:

@george1421 Correct I am not using MDT to create them. I am however seeing this same result off of the Surfaces. So I will break down what I am using and that way we can all see what is happening:

Any thought about creating a standard image on MDT and then deploying to the surfaces since you are upgrading to enterprise anyway. This would give you a consistent image across your fleet of computers from tablets to workstations. The only issue I can see is ensuring you have the proper driver files available for the surface.

The idea would be to build your reference image as a vm. If you use the lite touch method (with a little work) you can install windows, update it to the latest patches, install all software, do a last windows update then capture with fog for deployment. This is how we manage our images. Then next quarter rebuild the reference image again with the latest updates and software and recapture with FOG.

I know this is off topic a little, but maybe its not the computer but the process that has issues (no offense intended). Its just something to consider.

Ref: https://technet.microsoft.com/en-us/windows/dn913725.aspx

[Psycholiquid]

@george1421 No I am totally open to ideas. Just because I have been doing it one way doesn’t mean it is the right way.

[Psycholiquid]

@george1421 The problem with the surfaces is that it has to be done a certain way since MS’s key validation isn’t working at the moment. Also using Enterprise you don’t get the pen and apps like you would on a surface, so I am left with upgrading the OS, which in that case I have to reg hack the Surface in order to sysprep it.

I haven’t even used MDT but I will read up on it today and see what I can come up with, you may be right though it may be the way I am doing it that is causing the issue.

[george1421]

I really wouldn’t rule out FOG either, since you are swimming in new waters here with Win10, Surface Pro 4, partclone, and FOG. Any weak link could cause everything to fall down.

[Psycholiquid]

@george1421 Well I think I should start over using best practices. I will start with building a basic image with no extras in it with MDT and try uploading that to FOG and then downloading it to a PC. That will give me a good starting point. Like I just told my boss, I was pushed into this to fast and have been taking shortcuts to try and get PCs on the floor. When I first started this I was able to take my time with no interruptions. This is not the case this time. People are all up in arms wanting their Surfaces because they are the new cool thing.

[Tom Elliott]

@Psycholiquid This new photo appears like it’s not getting the actual disk number :(.

It appears to be cutting the disk number off. (/dev/nvme0n, where your disk is /dev/nvme0n1)

[Psycholiquid]

@Tom-Elliott Agreed

[Sebastian Roth]

@Psycholiquid Would you mind running this small tool called chkfatflags? Probably easiest if you start the client in debug (capture or deploy does not matter) mode and run and take a picture of what you see:

wget --no-check-certificate -O chkfatflags https://forums.fogproject.org/uploads/files/1458048073579-chkfatflags
chmod 755 chkfatflags
./chkfatflags /dev/nvme0n1p2

[Psycholiquid]

OK huge update.

I worked today to learn MDT (Not that bad at all) and got it all setup and the image done. With @george1421 and @Wayne-Workman I got the dual EFI and BIOS booting going, I was able to capture and deploy windows 10 Enterprise. This is setup correctly for EFI and boots no problems. I am going to build off of this now and see where I can get it. Hopefully I can document, I always say I am going to but never do because work gets the better of me.

So this is exactly what I did:

Setup VM with EFI firmware
Loaded windows and it picked up on the EFI drive and partitioned it as a GTP drive with the EFI partition.
Started the MDT sysprep and shut it down.
Changed the firmware over to BIOS on teh VM.
Captured the image
Set PC to deploy and ran it (The screen was stuck on init.xz but it was imaging)
IT rebooted after imaging and I have a Windows 10 Screen and it is Enterprise.

[Psycholiquid]

So this makes me wonder if it is AUDIT mode that causes it more and more, I will have to play with that later to see if it is and why it causes it.

[george1421]

@Psycholiquid Totally ignoring the fact that this is probably a win 10/hardware issue.

If you are going to be deploying more that two or three of these tablets, it will be well worth your while to go the MDT route and build a standard platform image for your deployments. That way you can include your standard software and configuration settings. The idea in any mass setup is to ensure that each device is exactly the same that way if (when) you run into an issue, you fix it for one you fix it for all, because they are exactly alike with the same exact software and version.

[Sebastian Roth]

@Psycholiquid Is this solved from your point of view? I still wonder if you think that more people will run into this and if we better should provide a tool to reset the FS shutdown flag?!

[Psycholiquid]

I am still not sure to tell teh truth. I am doing it a different way and right now got pushed back onto another project so I haven’t gotten back to it yet. But that being said using MDT seems to make life better.