• Error when deploying images

    General Problems
    2
    0 Votes
    2 Posts
    555 Views
    P

    @Pingu Ok, i find out that my /images was a little bit bugged and got my snapshots in dev folder with the mac address as name folders, i moved them into /images and renamed them with the image name i configured on the Web Interface and it runs !!
    Hope this will not happen for the next snapshots.

  • Identical NVMe drives

    FOG Problems
    35
    0 Votes
    35 Posts
    10k Views
    S

    @mrp Added to the official FOS inits now. Can’t wait any longer for you to test.

  • 0 Votes
    5 Posts
    1k Views
    B

    @sebastian-roth Thanks for your reply, we will try the alpha version.

    My teammate ask me to say a big thank you because since 2008 we use fog and we see you’r answer are very quick and we are very happy to use fog.

    did i need to do something to indicate the post as resolved ?

  • Complete Novice Looking For Assistance

    General
    6
    0 Votes
    6 Posts
    893 Views
    C

    @george1421

    Thank you for this response. I am looking into getting Volume licenses. If it is viable for the company I will be moving forward with FOG Project.

  • 0 Votes
    2 Posts
    474 Views
    JJ FullmerJ

    That error says that partition 4 is too small. So it seems to think that the image is bigger than the spin 5’s drive.
    Looking at your image settings I’d recommend recapturing using partclone zstd at compression level 19. Probably won’t fix this problem, but might speed up your imaging while saving space on the server.

    I believe the when fog captures the image it shrinks it down to only what is actually in use, so your scenario should work. Personally, as a fail safe, I use a 80 GB virtual disk size for my images which never had an issue deploying to 120 GB drives. Granted after a while we found that users with 120 GB drives ran out of space just from windows maintenance (updates, caches, etc.), well that and the users never deleting an email in outlook.

    So if it’s feasible, maybe try recapturing the image with the virtual drive being smaller than anything in your environment. (80-120 GB perhaps).

  • 0 Votes
    9 Posts
    2k Views
    Q

    @Mr_Matten Ah, glad you figured it out!

  • 0 Votes
    2 Posts
    721 Views
    Tom ElliottT

    This is where computer imaging isn’t exactly a smooth process. Unfortunately, machines implement displaying a drive however they see fit, even across the same model of different machines. Typically the channels that an HDD is connected to (SATA 0, SATA 1, etc…) are followed to some level, but sometimes this isn’t the case (as I imagine you’re seeing now).

    It is possible to tell FOG which drive to use, though it doesn’t know if the drive is ssd or hybrid or spinner. This is completely dependent on the machine, and if you can’t rely on which will be populated as what letter (my guess is your machines were setup in RAID mode of sorts?) that isn’t really going to help you much.

    One way you could do this though, is to swap out the /usr/share/fog/lib/funcs.sh file and change the getHardDisk function to detect your drive sizes. (You can do the swap out using postinit scripts.) But then it’s implicit that all machines will follow the same method.

    The steps I would take, albeit more time consuming initially:

    Install the SSD to the 1st SATA Channel (if that’s how your machines are setup – I can’t help much in the case of NVMe/MMC builtin controllers as I have nothing to base them on yet).

    Move the 1TB to the second SATA Channel.

    Ensure the machine’s firmware is updated to the latest and greatest.

    Ensure the machine’s SATA operation mode is AHCI.

    If these don’t make your SSD display as /dev/sda then I don’t know else to tell you to try.

  • 0 Votes
    9 Posts
    5k Views
    K

    @Tom-Elliott absolutely, was looking for how I could mark resolved this side funnily enough,