Ok, I did this on a T460 and here is what I got:
Let me know if I did this command correct?
One thing I have been noticing is it set the hard drive size to the image size on FOG. So when I image with my Enterprise image on a machine that has the issue the disk size is always 38gb which the size of the image is 37.84. Like I said before this issue is very hit or miss, does not happen to any specific model or harddrive model.
@Sebastian-Roth said in Full C:\ After Imaging Inconsistent:
grep " part_number " /usr/share/fog/lib/procsfdisk.awk
Ok, I’m not sure exactly what I am looking for to put this command in at the correct time? Is it before the Partclone starts or after? This is something I am not familiar with doing, I want to make sure I do this the right way so I get you the right info.
I also noticed that we have been getting this error on machines, no consistent model and not always happening when a machine gets the full C:, maybe they are related…
https://drive.google.com/file/d/1w4ToCKSSng0gvdNpFWlZD-9J7yZqeUaG/view?usp=sharing
Also as a side note when we updated te init files a month ago we changed the KERNEL RAMDISK SIZE from 127000 to 275000. Would it be worth changing it back to 127000?
I put that command in on the computer when the debug screen came up, I took pictures as it went along. I put all the pictures for the first computer I did on Google Drive:
https://drive.google.com/drive/folders/1EyxMz7RF7LzVEDYPygshJKT_qRxN-jge?usp=sharing
Here was the initial output right after I put the command in on the machine in debug mode:
This is the first time I did a debug on an image, so not sure if I’m doing this the correct way.
I ran one debug task so far on a Lenovo T440p with a Samsung SSD and it imaged fine did not have the disk space problem. But I got a bunch of pictures during the whole image debug task. I am going to be imaging more machines today, so I will keep running debug tasks and hopefully I will get one that results in the drive size issue. This issue seems to be really hit or miss, sometimes you get one and sometimes you don’t. Out of 45 machines we did the one day (T460’s and T440’s), only 4 out of the 45 had the issue.
I put the pictures I took on a Shared Google Drive Folder: https://drive.google.com/drive/folders/1EyxMz7RF7LzVEDYPygshJKT_qRxN-jge?usp=sharing
Also I ran an apache tail while this was going on and here is the results:
[Thu Jul 11 07:35:06.234826 2019] [mpm_prefork:notice] [pid 1624] AH00163: Apache/2.4.33 (Ubuntu) OpenSSL/1.1.0h configured -- resuming normal operations
[Thu Jul 11 07:35:06.234842 2019] [core:notice] [pid 1624] AH00094: Command line: '/usr/sbin/apache2'
[Thu Jul 11 09:00:18.200339 2019] [proxy_fcgi:error] [pid 10448] [client 172.16.9.35:52466] AH01071: Got error 'PHP message: PHP Warning: Illegal offset type in /var/www/fog/lib/fog/fogmanagercontroller.class.php on line 296\n', referer: http://foggy.adelphoi.org/fog/management/index.php?node=host&sub=edit&id=24
[Thu Jul 11 09:01:08.039396 2019] [proxy_fcgi:error] [pid 10448] [client 172.16.9.35:52511] AH01071: Got error 'PHP message: PHP Warning: Illegal offset type in /var/www/fog/lib/fog/fogmanagercontroller.class.php on line 296\n', referer: http://foggy.adelphoi.org/fog/management/index.php?node=host&sub=edit&id=31
[Thu Jul 11 09:01:23.484370 2019] [proxy_fcgi:error] [pid 10452] [client 172.16.9.35:52520] AH01071: Got error 'PHP message: PHP Warning: Illegal offset type in /var/www/fog/lib/fog/fogmanagercontroller.class.php on line 296\n', referer: http://foggy.adelphoi.org/fog/management/index.php?node=host&sub=edit&id=31
[Thu Jul 11 09:22:26.559418 2019] [proxy_fcgi:error] [pid 17656] [client 172.16.9.35:52826] AH01071: Got error 'PHP message: PHP Warning: Illegal offset type in /var/www/fog/lib/fog/fogmanagercontroller.class.php on line 296\n', referer: http://foggy.adelphoi.org/fog/management/index.php?node=host&sub=edit&id=46
Let me know what the next steps should be, in the mean time I will do more debug imaging and hopefully get one that has the drive size issue 
I was just looking under /usr/share and there is no fog folder? However I did do a search in terminal and found the procsfdisk.awk file is actually located under /root/fogproject/src/buildroot/package/fog/scripts/usr/share/fog/lib/procsfdisk.awk
So when I do the debug should I run the command with this path that I found rather than the one you posted? @Sebastian-Roth
Ok, we just updated to version 1.5.6.5 and we are still having the same issue as in this post. This happens for any image, I am going to include information for two of our most used images.
Here is the first image we use it is a Windows 10 Enterprise 1809:
d1.partitions file
label: gpt
label-id: 066202D1-4FDA-44C2-A0A0-3C26A816B87E
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158
/dev/nvme0n1p1 : start= 2048, size= 1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=3366A936-7B65-43E1-AFDF-9DE4F8FE13A7, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/nvme0n1p2 : start= 1024000, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=0DBFD8B3-44AC-4600-926D-FDFB469EFF2A, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 1228800, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=BC00D195-83B5-4B15-BFF8-DDCEC9B3ADFF, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p4 : start= 1261568, size= 498855936, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=890554EA-E1AB-4D7F-8C9D-7F8C83FA2A62, name="Basic data partition"
d1.minimum.partitions file
label: gpt
label-id: 066202D1-4FDA-44C2-A0A0-3C26A816B87E
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158
/dev/nvme0n1p1 : start= 2048, size= 1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=3366A936-7B65-43E1-AFDF-9DE4F8FE13A7, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/nvme0n1p2 : start= 1024000, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=0DBFD8B3-44AC-4600-926D-FDFB469EFF2A, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 1228800, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=BC00D195-83B5-4B15-BFF8-DDCEC9B3ADFF, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p4 : start= 1261568, size= 79997904, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=890554EA-E1AB-4D7F-8C9D-7F8C83FA2A62, name="Basic data partition"
d1.fixed_size_partitions
:2:3:1
The other image that we are primarily using that it is also happening on is a Windows 10 Professional 1809 build.
d1.partitions file
label: gpt
label-id: 066202D1-4FDA-44C2-A0A0-3C26A816B87E
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 250069646
/dev/nvme0n1p1 : start= 2048, size= 1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=13FC5702-27F9-49D6-8A69-F39933A23D1D, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/nvme0n1p2 : start= 1024000, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=12D97EEC-C05D-4AB2-85FC-E279C488B16C, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 1228800, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=7DEE0FD7-4583-417C-9FCE-58C0396BD356, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p4 : start= 1261568, size= 248807936, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=CB038B33-4E54-441D-80A5-6F8614224912, name="Basic data partition"
d1.minimum.partitions file
label: gpt
label-id: 066202D1-4FDA-44C2-A0A0-3C26A816B87E
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 250069646
/dev/nvme0n1p1 : start= 2048, size= 1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=13FC5702-27F9-49D6-8A69-F39933A23D1D, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/nvme0n1p2 : start= 1024000, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=12D97EEC-C05D-4AB2-85FC-E279C488B16C, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 1228800, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=7DEE0FD7-4583-417C-9FCE-58C0396BD356, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p4 : start= 1261568, size= 248807936, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=CB038B33-4E54-441D-80A5-6F8614224912, name="Basic data partition"
d1.fixed_size_partitions file
:2:3:1
Let me know if you need anything else with this. I figured I would try updating to the latest version before anything else. Everything seems to be imaging fine, except for this hit or miss issue.
So I have been having an odd issue lately of computers being imaged and their available C:\ space is 40gb after imaging and there is only 2% available. It can be fixed by doing and expand on C:\ under disk management. At first this only happened to two Lenovo T460 laptops with Intel SSD-SC2KF256H6L, and we imaged many other T460’s all with Samsung SSD’s in them with no issue. Now I just had it happen on one T460 and one T440. The T460 has a Samsung SSD MZ7LF192HCGS-000L1 and the T440 has a Toshiba MQ01ACF05Q (not a SSD).
I am able to fix the issue y right clicking on C:\ in Disk Management and expand it and the problem is resolved. But I am not sure on what would be the cause with this? Here are some screenshots…
https://drive.google.com/file/d/1Gb0ydZJNuicgRmMxhfN99VvUrXcESuJz/view?usp=sharing
https://drive.google.com/file/d/1T8HT4nS04HskXrZkUoyH_8NkiDkHP81s/view?usp=sharing
https://drive.google.com/file/d/1kR_xkBJ_G6mZxpXJ69UwyTOrSJLOegOd/view?usp=sharing
We are running 1.5.2, would updating FOG fix this? About a month ago we had a similar issue and it appeared to get fixed by updating the init files. We just started having this new issue a few days ago. It only has happened on a total of four computers out of 100 imaged. So its not wide spread at least.
Here is the link to the previous issue that we posted about…
https://forums.fogproject.org/topic/13336/partition-resizing/4
Let me know what the best idea is to resolve this.
Updating the FOG server to the latest image appears to have resolved the issues. Good thing is did not have to modify anything after the update all models appear to be imaging successfully.
@Sebastian-Roth
So when you image the image it and go into disk management it has the following when imaging to a 500 gb drive HHD…
Recovery:
499 MB NTFS
Healthy OEM Partition
100 MB Healthy (EFI System Partition)
C:\ 118 gb ntfs healthy boot page file crash dump, primary partition
346.52 gb unallocated
Also one thing I noticed on this FOG Server is after it images it gives the following warning on the machine being imaged:
Failed to set disk guid (sgdisk -U) restoreUUIDinformation
Args passed: /dev/nvme01n/images/Win10_Student_1809_v4/d1.original.uuids 1 /images/Win10_Student_1809_v4
It displays this warning and the machine reboots, only thing to appear wrong with machine is incorrect partitions.
Let me know if there is any additional info you need.
@Sebastian-Roth No clue, so what do I need to fix something in these files, I never really messed with any of the code in these files after capturing the image. Is there something specific I need to change? Please let me know I am trying to follow.
@Sebastian-Roth They are replicated exactly the same as on the 1.5.3 server.
Here is the image files:
d1.partitions
label: gpt
label-id: 066202D1-4FDA-44C2-A0A0-3C26A816B87E
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158
/dev/nvme0n1p1 : start= 2048, size= 1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=3366A936-7B65-43E1-AFDF-9DE4F8FE13A7, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/nvme0n1p2 : start= 1024000, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=0DBFD8B3-44AC-4600-926D-FDFB469EFF2A, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 1228800, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=BC00D195-83B5-4B15-BFF8-DDCEC9B3ADFF, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p4 : start= 1261568, size= 498855936, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=890554EA-E1AB-4D7F-8C9D-7F8C83FA2A62, name="Basic data partition"
d1.minimum.partitions
label: gpt
label-id: 066202D1-4FDA-44C2-A0A0-3C26A816B87E
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158
/dev/nvme0n1p1 : start= 2048, size= 1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=3366A936-7B65-43E1-AFDF-9DE4F8FE13A7, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/nvme0n1p2 : start= 1024000, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=0DBFD8B3-44AC-4600-926D-FDFB469EFF2A, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 1228800, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=BC00D195-83B5-4B15-BFF8-DDCEC9B3ADFF, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p4 : start= 1261568, size= 79997904, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=890554EA-E1AB-4D7F-8C9D-7F8C83FA2A62, name="Basic data partition"
d1.fixed_size_partitions
:2:3:1
I am having the same issue with the FOG partition resizing as in my previous post. In my previous post the issue was on a FOG Server with version 1.5.3 and updating the init files resolved the issue using the following link:
https://dev.fogproject.org/blue/organizations/jenkins/fos/detail/master/88/artifacts/
We have a second FOG Server running 1.5.0, this has the same images on it and the same issue as mentioned in this post:
https://forums.fogproject.org/topic/13336/partition-resizing/5
I tried updating the inits on it and it did not break anything it just did not fix the issue of the partitions not resizing. Any ideas on what to do. I am thinking of updating the FOG server that is running 1.5.0 to the latest version, but I just want to know if there is anything else suggested before I do the update.
@Sebastian-Roth
So when I download the inits where do I put them at specifically on the FOG Server?
Do you think something needs changed in my d1.fixed_size_partitions file?
Here is for the Enterprise Win 10 1809 Image:
d1.partitions
label: gpt
label-id: 066202D1-4FDA-44C2-A0A0-3C26A816B87E
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158
/dev/nvme0n1p1 : start= 2048, size= 1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=3366A936-7B65-43E1-AFDF-9DE4F8FE13A7, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/nvme0n1p2 : start= 1024000, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=0DBFD8B3-44AC-4600-926D-FDFB469EFF2A, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 1228800, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=BC00D195-83B5-4B15-BFF8-DDCEC9B3ADFF, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p4 : start= 1261568, size= 498855936, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=890554EA-E1AB-4D7F-8C9D-7F8C83FA2A62, name="Basic data partition"
d1.minimum.partitions
label: gpt
label-id: 066202D1-4FDA-44C2-A0A0-3C26A816B87E
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158
/dev/nvme0n1p1 : start= 2048, size= 1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=3366A936-7B65-43E1-AFDF-9DE4F8FE13A7, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/nvme0n1p2 : start= 1024000, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=0DBFD8B3-44AC-4600-926D-FDFB469EFF2A, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 1228800, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=BC00D195-83B5-4B15-BFF8-DDCEC9B3ADFF, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p4 : start= 1261568, size= 79997904, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=890554EA-E1AB-4D7F-8C9D-7F8C83FA2A62, name="Basic data partition"
d1.fixed_size_partitions
:2:3:1
Then here is the files for the 1809 Win 10 Pro image
d1.partitions
label: gpt
label-id: 066202D1-4FDA-44C2-A0A0-3C26A816B87E
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 250069646
/dev/nvme0n1p1 : start= 2048, size= 1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=13FC5702-27F9-49D6-8A69-F39933A23D1D, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/nvme0n1p2 : start= 1024000, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=12D97EEC-C05D-4AB2-85FC-E279C488B16C, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 1228800, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=7DEE0FD7-4583-417C-9FCE-58C0396BD356, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p4 : start= 1261568, size= 248807936, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=CB038B33-4E54-441D-80A5-6F8614224912, name="Basic data partition"
d1.minimum.partitions
label: gpt
label-id: 066202D1-4FDA-44C2-A0A0-3C26A816B87E
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 250069646
/dev/nvme0n1p1 : start= 2048, size= 1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=13FC5702-27F9-49D6-8A69-F39933A23D1D, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/nvme0n1p2 : start= 1024000, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=12D97EEC-C05D-4AB2-85FC-E279C488B16C, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p3 : start= 1228800, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=7DEE0FD7-4583-417C-9FCE-58C0396BD356, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p4 : start= 1261568, size= 67678380, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=CB038B33-4E54-441D-80A5-6F8614224912, name="Basic data partition"
d1.fixed_size_partitions
:2:3:1
I think these are mainly the same, let me know what we should changed? Maybe the 2:3:1?
So we just noticed an issue with our FOG imaging regarding the partitions being resized. This is occurring on two Windows 10 images, one is Professional and one is Enterprise. Both images were sysprepped with copy profile from the local admin account.
Windows 10 Enterprise 1809 image was built on 237gb Samsung SSD
Windows 10 Professional 1809 image was built on 110gb NVME drive.
When you image machines that have larger disk space it does not resize to the larger size. So for instance if you image a 500gb drive to te enterprise image it will say the C:\ drive has 237gb and the missing amount will be unallocated. Luckily you are able to easily expand it in Disk Manager so it shows the correct amount. I am wondering why the imaging is not properly resizing even thought I have single disk resizable selected.
Below are the screenshots of both images that have the same issue.
It is possible we may have had this issue longer and did not notice it since most of our machines are SSDs and are not very large size drives. We are running 1.5.2 right now but would like to avoid updating to fix this issue if at all possible. Any suggestions?
No I have not changed anything with the password for FOG, I only made sure it matched in the password settings within the FOG Web UI. It has actually remained the default as this is a test server.
@george1421 @Sebastian-Roth
Here is the error when capturing:
I am not sure if this error is related or not but when I try deleted the old image out of the We UI, I get this.
Also here is a screenshot of that line of code, not really seeing what is wrong with that line of code though.
