nvme0n1p2 fatclone c: is not in a valid state

[Psycholiquid]

@Sebastian-Roth Yes that is the error I am seeing in partclone.

[Psycholiquid]

@Sebastian-Roth I can tell you that is the EFI partition of windows that is used to boot it, but I have made sure I am shutting it down cleanly. I have even set the sysprep to shutdown rather than reboot.

[Sebastian Roth]

@Psycholiquid Are you able to mount the partition in debug mode?

mkdir -p /mnt
mount -t vfat /dev/nvme0n1p2 /mnt
ls -al /mnt
umount /mnt

[Psycholiquid]

@Sebastian-Roth yes it does mount and I can see the file structure

[Tom Elliott]

@Psycholiquid What if you add 1 to the d1.fixed_size_partitions file? Will it work then? It looks like it’s growing the EE partition when it really shouldn’t be.

[Sebastian Roth]

@Psycholiquid Looking through the partclone code I found out that there is a thing called “clean shutdown bit/flag” within the FAT (file allocation table). This sounds like it could be related to the NTFS dirty bit but is definitely a whole lot different - after all it’s FAT not NTFS. When searching the web for FAT and dirty bit a lot of people point you to the 0x41 byte (0x25 fog FAT16) of the partition which seams to be some kind of mount/fs-check/dirty marker as well but it’s definitely not the one partclone is complaining about! The one I found is relevant sits in the second reserved FAT entry. This is the best/simplest description I could find - and here another one. With that information I was able to replicate the error message you are seeing. The problem is I used a hex editor and dd to modify this on disk - so I don’t have an easy solution yet. Interestingly enough - even if partclone complains about it I could still mount the filesystem (just as you could). So I have no idea why partclone is checking this flag (where mount is not!) and who/what set this on your system?!?

I haven’t found any tool that would set/unset this “clean shutdown flag” for you. Linux fsck only un/sets the dirty bit AFAIK. Some say you can use windows chkdsk tool but I am not able to confirm this. In your case nvme0n1p2 is the EFI boot partition and I am not sure if you are able to run chkdsk on this partition from within a running windows system?!

I guess we could come up with some C-code to do this for you. Here is a nice example on how to read that flag.

I wonder if anyone else has looked into this yet? Is anyone aware of the difference between dirty bit and clean shutdown bit here in the forums??

[george1421]

@Sebastian-Roth While I don’t have an answer for you on the shutdown part, I wonder if the developers of partclone would have checked this flag on a fat partition, just because of the nature of the fat I would suspect its not necessary. They must do this for a reason. Maybe they can provide a switch to ignore or even reset this bit in the disk structure if possible. Windows 10 is here to stay so they will run across this issue more often than not.

I wonder if the state of this flag could be dependent on the issue I posted before (from memory). I wonder if when the system is sysprepp’d instead of shutdown you pick reboot and then power off the device when it is working through post before it boots. (it may be impossible to catch because of the speed of the system).

[Psycholiquid]

@Sebastian-Roth I was trying the chkdsk this morning within windows I had to add a drive letter to the partition. Not sure if it will work yet, taking a raw image of the machine (of course that works but not efficient) to make the powers that be happy.

chkdsk is what I usually did to any drive that gave this problem. Let me roll it back to the current bad state and try that and I will let you know the results.

[Psycholiquid]

@george1421 I tried both reboot and shutdown, I am not sure catching it while it is EFI booting would have an effect, since it is already flagged as soon as it goes down. I think it is getting flagged during the sysprep due to I have rebooted it multiple times. Or maybe even being flagged during the switch to Audit mode. I am attempting the clear from within windows this morning to see if it helps.

[Psycholiquid]

@Tom-Elliott said:

@Psycholiquid What if you add 1 to the d1.fixed_size_partitions file? Will it work then? It looks like it’s growing the EE partition when it really shouldn’t be.

Not real sure what your talking about here.

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