nvme0n1p2 fatclone c: is not in a valid state

[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.