FOG 1.5.6.2 Issues with Resizable image
-
@Chris-Whiteley Please post the contents of the text files
p1.partitions
,p1.minimum.partitions
andp1.fixed_size_partitions
of that image here in the forums. -
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"
-
@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 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.
-
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
-
@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.
-
Sorry it took so long to get back to you. Here are the updated pictures with the kernel args:
-
@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.
-
@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!
-
@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. -
@Sebastian-Roth Thanks for the update. I will look for this tomorrow and wait to hear word from you. Thanks again,
-
@Chris-Whiteley See the chat bubble in the top right corner…
-
@Sebastian-Roth I got this error this morning from the new file:
-
@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
to275000
. -
@Sebastian-Roth That worked! Thanks so much! It did the resize and it looks good from within Windows.
-
@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.
-
@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.