Solved FOG 1.5.6.2 Issues with Resizable image

[Chris Whiteley]

I am having an issue where after imaging the machine with a Windows 10 resizable image, it is not making the image fill back out to the size of the drive. It is just staying the same as the image size. This is how I have always done it. Has something changed? I have tried both iterations of 1.5.6 and 1.5.6.2.

Process:
-> Create Pristine Windows 10 Image
-> Sysprep and reboot for upload and image is chosen as Windows 10 and resizable
-> Deploy image and the disk size doesn’t expand

Thanks,

[Sebastian Roth]

@Chris-Whiteley My fault. The new inits use a larger root filesystem. Please go to the FOG web UI -> FOG Configuration -> FOG Settings -> FTP Server and increase KERNEL RAMDISK SIZE from 127000 to 275000.

[Sebastian Roth]

@quinniedid said in FOG 1.5.6.2 Issues with Resizable image:

Sometimes the resize works and other times it doesn’t

Do you mean the same image sometimes resizes and sometimes not? We’d need the exact same information from your image (best to open a new topic) to look into this.

[quinniedid]

@Sebastian-Roth I have had this same issue in our environment but it has been intermittent. Sometimes the resize works and other times it doesn’t. We are running 1.5.6.

[Chris Whiteley]

@Sebastian-Roth That worked! Thanks so much! It did the resize and it looks good from within Windows.

[Sebastian Roth]

@Chris-Whiteley My fault. The new inits use a larger root filesystem. Please go to the FOG web UI -> FOG Configuration -> FOG Settings -> FTP Server and increase KERNEL RAMDISK SIZE from 127000 to 275000.

[Chris Whiteley]

@Sebastian-Roth I got this error this morning from the new file:

[Sebastian Roth]

@Chris-Whiteley See the chat bubble in the top right corner…

[Chris Whiteley]

@Sebastian-Roth Thanks for the update. I will look for this tomorrow and wait to hear word from you. Thanks again,

[Sebastian Roth]

@Chris-Whiteley More good news. Seems like it’s not as problematic a change as I had first thought it would be. So I managed to fix this and do some (hopefully) appropriate testing just now. New fixed init files are building at the moment and should be ready to test tomorrow (late evening here already).

Many thanks to you for posting this here. I really wonder why not many more people ran into this issue. As far as I understand it every system having NVMe drives (Linux device filenames /dev/nvme0n1pX) should run into this.

[Chris Whiteley]

@Sebastian-Roth Thanks for working on it! I am just glad that it wasn’t me doing something wrong I tried everything to make it work. I really appreciate everything you guys do to make an amazing product!

[Sebastian Roth]

@Chris-Whiteley Good news is that I am pretty close to know why this is causing trouble for you. Bad news is that we’ll need to fix the script that does the resizing and I might need a bit more time to make sure I don’t break things for other layouts.

[Chris Whiteley]

@Sebastian-Roth

Sorry it took so long to get back to you. Here are the updated pictures with the kernel args:

[Sebastian Roth]

@Chris-Whiteley Ok, this partition layout looks fine as well. In the pictures we see that it seems to try to expand the partitions and doesn’t hit any obvious error but the outcome is not what we expect. So we need to dive into this even more. Please add the following as Kernel Parameters to this hosts’ settings and run another debug deploy: isdebug=yes ismajordebug=1

When you get to the “Attempting to expand/file partitions” (that’s before the blue partclone screens) pay attention and take pictures again. It should give us more details this time.

[Chris Whiteley]

@Sebastian-Roth

Yes I messed up. Here is the right image:

d1.fixed_size_partitions:

:1:1

d1.minimum.partitions:

label: dos
label-id: 0xbb1896a4
device: /dev/nvme0n1
unit: sectors

/dev/nvme0n1p1 : start=        2048, size=     1124352, type=7, bootable
/dev/nvme0n1p2 : start=     1126400, size=    77984264, type=7

d1.partitons:

label: dos
label-id: 0xbb1896a4
device: /dev/nvme0n1
unit: sectors

/dev/nvme0n1p1 : start=        2048, size=     1124352, type=7, bootable
/dev/nvme0n1p2 : start=     1126400, size=    87136208, type=7

[Sebastian Roth]

@Chris-Whiteley I can’t imagine this being the exact same image as you posted the files contents from. The partition layout below tells us it’s a GPT layout with four partitions. The pictures on the other hand show a legacy MBR layout with just two partitions. So either there is something going terribly wrong in our scripts or you got the wrong files.

[Chris Whiteley]

@Sebastian-Roth

Here are the outputs and what was seen at the end:

[Sebastian Roth]

@Chris-Whiteley Partition layout looks perfectly fine from my point of view. This layout should expand properly. But sure I believe when you say it doesn’t. Can you please schedule a debug deploy task and step through the whole process while taking pictures of all the messages you see on screen? Possibly we find something that prevents from expanding the last partition.

[Chris Whiteley]

@Sebastian-Roth

d1.minimum.partitions:

label: gpt
label-id: 0EF8BFB0-8547-11E8-BD1D-1866DA4A79D9
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 500118158

/dev/sda1 : start=        2048, size=     1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=B09CBC62-337C-4F76-AB41-5CC15BC19BCE, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/sda2 : start=     1024000, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=5125EE82-07EE-400C-B923-455E1DF89F0A, name="EFI system partition", attrs="GUID:63"
/dev/sda3 : start=     1228800, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=8F38AD90-28EA-433F-B566-7CFF947E5A42, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda4 : start=     1261568, size=    70461368, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=C7A3FCC5-4446-4D7D-80DA-8A6A37FC797B, name="Basic data partition"

d1.fixed_size_partitions:

:2:3:1

d1.partitions:

label: gpt
label-id: 0EF8BFB0-8547-11E8-BD1D-1866DA4A79D9
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 500118158

/dev/sda1 : start=        2048, size=     1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=B09CBC62-337C-4F76-AB41-5CC15BC19BCE, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/sda2 : start=     1024000, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=5125EE82-07EE-400C-B923-455E1DF89F0A, name="EFI system partition", attrs="GUID:63"
/dev/sda3 : start=     1228800, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=8F38AD90-28EA-433F-B566-7CFF947E5A42, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda4 : start=     1261568, size=   498856448, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=C7A3FCC5-4446-4D7D-80DA-8A6A37FC797B, name="Basic data partition"

[Sebastian Roth]

@Chris-Whiteley Please post the contents of the text files p1.partitions, p1.minimum.partitions and p1.fixed_size_partitions of that image here in the forums.