error trying to restore gpt table

[Sebastian Roth]

@Matthieu-Jacquart With the latest FOS inits you use with dev-branch there should be no need to remove the 5th partition because they handle moving of partitions after the resize.

The issue here to me seems to be that partition 4 is not being shrunk. Looks like FOS detects it as fixed and won’t shrink it.

Probably best if you schedule another capture of the image but tick the checkbox for debug this time. Step through the capture process and pay attention to where it says something about partition number 4. Take pictures and post here.

[Matthieu Jacquart]

@sebastian-roth Hi, OK thanks I’ll try it tomorrow. I found another image with these 5 partitions but this time d1.fixed_size_partitions

1:2:3:5

so Windows partition is shrunk for this one, any way to force it for the bad one ?

Matthieu

[Sebastian Roth]

@matthieu-jacquart said in error trying to restore gpt table:

any way to force it for the bad one ?

We better find out why FOS thinks it cannot shrink this partition. There is usually a reason for it.

[Matthieu Jacquart]

@sebastian-roth Hi, That’s a bad photomontage of debug capture task, I think “Not shrinking (/dev/nvme0n1p4) trying fixed size” is interesting :

[Sebastian Roth]

@Matthieu-Jacquart Ok, see the message Not shrinking (/dev/nvme0n1p4) trying fixed size. At this stage FOS tried to find out how much it can shrink this partition but failed to get the information.

Please schedule another debug capture on that machine and when you get to the command shell just run ntfsresize -fivP /dev/nvme0n1p4, take a picture of the screen and post that here.

[Matthieu Jacquart]

@sebastian-roth Hi, result for first trial :

And after chkdsk /F

[Matthieu Jacquart]

OMG shame on me, it was just a chkdsk problem, never thought to that…
sorry for this, I’ll tried to keep in mind for next time !

[Sebastian Roth]

@Matthieu-Jacquart No problem. Good we figured that out so quickly. We might think about adding some debug output in FOS in case the ntfsresize check fails. Though I have very little time at the moment. Not sure if and when I will get to this. Anyone else keen to look into this? @Wayne-Workman ?

[Matthieu Jacquart]

@sebastian-roth Is there a link with this feature in general settings ?

For the second option (change hostname early), can i activate it ? because after deployment the temporary name of the workstation appears in WSUS instead of the real name and I have to delete it.
Matthieu

[Sebastian Roth]

@Matthieu-Jacquart I didn’t even know about that FOG setting. Something that was part of FOG long before I joined the dev team and I never stumbled upon this myself by the looks.

The help text is as follows: “This is an experimental feature that will can be used to not set the dirty flag on a NTFS partition after resizing it. It is recommended to you run chkdsk.”

From what I see in the code this setting is piped through to FOS (the FOG Linux OS doing the imaging work) but not use by it. To make a long story short, I have no idea.

For the second option (change hostname early), can i activate it ? because after deployment the temporary name of the workstation appears in WSUS instead of the real name and I have to delete it.

Yes, enable it and give it a try. FOS will try to mount the Windows partition and manipulate registry entries at the end of a deployment to change the hostname before the first Windows boot. Works like a charm from what I have tested not too long ago.

[Wayne Workman]

There’s also this article:
https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit