FOG 1.5.6.2 Issues with Resizable image



  • 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,


  • Developer

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



  • @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.



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


  • Developer

    @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 I got this error this morning from the new file:

    IMG_0152.JPG


  • Developer

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



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


  • Developer

    @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 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!


  • Developer

    @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

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

    IMG_0147.JPG
    IMG_0148.JPG
    IMG_0149.JPG
    IMG_0150.JPG
    IMG_0151.JPG


  • Developer

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



  • @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
    
    

  • Developer

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



  • @Sebastian-Roth

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

    IMG_0131.JPG
    IMG_0132.JPG
    IMG_0134.JPG
    IMG_0136.JPG
    IMG_0137.JPG
    IMG_0138.JPG
    IMG_0141.JPG
    IMG_0142.JPG
    IMG_0144.JPG
    IMG_0145.JPG
    IMG_0146.JPG


  • Developer

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



  • @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"
    
    

  • Developer

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


Log in to reply
 

456
Online

6.0k
Users

13.3k
Topics

125.2k
Posts