Problem with the resize (expanding) on a hard drive



  • Hi all !

    I come here because of a problem of resize of the hard drive. Fog don’t expand the hard drive and I don’t know why 😕

    For example here, my image made 40GB and the hard drive made 60GB (on a VM) and I have the same problem with physical machines with SSD of 256GB.
    Corners-Machine-Test - VMware Remote Console.jpg

    I read the documentation (https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#Images) and I choose the type : “Single Disk - Resizable” like you can see here :
    Image Management - Google Chrome.jpg

    I use Fog 1.5.7 and the image is a Windows 10. In which log or file can I have more information on this problem ?

    I found eventually this solution : http://www.troliver.com/?p=102 but it’s not a clear solution…

    Thank you for your answers !



  • @Quazz
    @Sebastian-Roth

    Thank you, you found the solution !

    Here is the result of the tmpoutput.txt file
    Corners-Motherimage - VMware Remote Console.jpg

    Indeed, the problem came from a problem with the filesystem of my “mother” image. After several chkdsk (I had reboot only once the first time), the expand works well.

    Thank you guys ! The problem is so solve now.


  • Senior Developer

    @loutrage See it says Not shrinking (/dev/sda2) trying fixed size in the pictures. So there is an issue with trying to shrink that filesystem. I’d suggest you do another debug capture task and step all the way to the point where you see that message. Now press Ctrl+c to stop the script and get back to the shell. Now run cat /tmp/tmpoutput.txt to see all the messages the last command (ntfsresize) produced. Take a picture and post here.


  • Moderator

    @loutrage Looks the resize test fails, which automatically marks the partition as fixed size.

    Possibly the filesystem or disk is damaged causing the failure.

    Try and fix the filesystem by running chkdsk C: /f on the windows client you want to capture. (you’ll then need to confirm to schedule on reboot and then ofc reboot)



  • @Sebastian-Roth
    Here is 2 screens about SDA2. Everything seems good I think.

    SDA2.jpg
    SDA2_4.jpg


  • Senior Developer

    @loutrage said in Problem with the resize (expanding) on a hard drive:

    I also tried to see a message like this Not resizing filesystem /dev/sda2 (part too small) but it was too fast.

    The messages we see in the picture all seem fine up to that point. It detects sda1 as fixed because it has the boot flag set. Probably wait a little bit longer to see what it says when it tries to shrink sda2.

    It if’s all going to fast you can just schedule a debug capture task. Just as you would create a normal task bit just before you click the last button there is a checkbox for debug. Boot up the machine and hit ENTER twice to get to a shell. Key in fog as command and fire it up with ENTER. Now you step through the whole process with plenty of time to read and take pictures.



  • @Sebastian-Roth

    I replaced the files init.xz & init_32.xz with the last version then I made a new capture but I had always the same problem.

    Then I tried the “dirty fix” by editing the file d1.fixed_size_partitions but I receive this error :

    PrtScr capture_2.jpg

    Maybe because the file d1.fixed_size_partitions changed with my new image ?

    The content of the file is now :

    1:2
    

    I also tried to see a message like this Not resizing filesystem /dev/sda2 (part too small) but it was too fast.

    I just saw thisCorners-Motherimage - VMware Remote Console_2.jpg


  • Senior Developer

    @loutrage Interesting, the second partition doesn’t have any flags set. This is how it should be and shouldn’t cause it to be seen as non-resizable.

    Do you keep an eye on the screen when the image is captured. Possibly the resize test fails with Not resizing filesystem /dev/sda2 (part too small)???

    As a dirty quick fix you can edit d1.fixed_size_partitions and make it look like this:

    1
    

    Then try deploying again.

    I do remember that I made I change to the inits after 1.5.7 was release that is related to detecting which partitions can/cannot be resized. Though I didn’t think this would help in your situation. But still you can update to the latest inits and see if that helps. Login to your FOG server as root and run the following commands:

    cd /var/www/html/fog/service/ipxe
    mv -i init.xz init.xz.orig
    wget https://fogproject.org/inits/init.xz
    mv -i init_32.xz init_32.xz.orig
    wget https://fogproject.org/inits/init_32.xz
    chown www-data:www-data init*
    

    The last command fails if you are on CentOS. Use chown apache:apache init* instead…



  • @Sebastian-Roth

    Here is the information :

    Corners-Motherimage - VMware Remote Console.jpg

    Visibly, there is just the boot flag.

    @george1421 I let the “single disk resizable” option by default. I only changed 2 days ago to make a test.


  • Senior Developer

    @george1421 said in Problem with the resize (expanding) on a hard drive:

    We also need to confirm that single disk resizable was set BEFORE the image was captured and not changed AFTER the image was captured.

    Good point, but I don’t think that’s the case here because some of the files, like d1.minimum.partitions are only being created when you have resizable image type set on capture.


  • Moderator

    @Sebastian-Roth said in Problem with the resize (expanding) on a hard drive:

    For some reason FOS (FOG Linux OS) detects both your Windows partitions as non-resizable.

    We also need to confirm that single disk resizable was set BEFORE the image was captured and not changed AFTER the image was captured.

    It would be an interesting case if FOS misidentified the resizable partitions. I’d like to see the conditions that created this incorrect setting too.


  • Senior Developer

    @loutrage For some reason FOS (FOG Linux OS) detects both your Windows partitions as non-resizable. Sure you could use a snapin to expand the 😄 drive after deployment. But for your very straight forward partition layout we should also be able to find out why it detects it as non-resizable in the first place. Quite possible we can find an fix this so the snapin is not needed.

    Please schedule a debug capture task (as a normal capture task but before you click create in the web UI there is a checkbox for debug), boot up the host and hit ENTER twice to get to the shell. There you run parted -s /dev/sda print - take a picture of the output on screen and post here. You don’t need to actually start the capture task after taking the picture. You can cancel the task in the web UI and switch off the host.

    My guess is that your 😄 drive has some flag set that FOS detects as “problematic”.



  • @Sebastian-Roth

    Thank you for the answer ! Here is the content of the 3 files :

    root@fog:/images/2019-09-23# cat d1.partitions
    label: dos
    label-id: 0x7d78d5ad
    device: /dev/sda
    unit: sectors
    
    /dev/sda1 : start=        2048, size=     1124352, type=7, bootable
    /dev/sda2 : start=     1126400, size=    82757632, type=7
    root@fog:/images/2019-09-23# ls
    
    
    root@fog:/images/2019-09-23# cat d1.minimum.partitions
    label: dos
    label-id: 0x7d78d5ad
    device: /dev/sda
    unit: sectors
    
    /dev/sda1 : start=        2048, size=     1124352, type=7, bootable
    /dev/sda2 : start=     1126400, size=    82757632, type=7
    
    root@fog:/images/2019-09-23# cat d1.fixed_size_partitions
    :1:1:2
    

  • Senior Developer

    @loutrage We need some more information from you. Go to your FOG server’s image directory (/images/2019-09-23), grab the contents of the following text files: d1.partitions, d1.minimum.partiitons and d1.fixed_size_partitions and post here.


Log in to reply
 

286
Online

7.4k
Users

14.5k
Topics

136.6k
Posts