Postinstall scripts /images not mounted


  • Moderator

    I just upgraded to the latest trunk build last night r6901. I’m having troubles with a post install script since the update. To try to debug the issue I setup a scheduled debug deploy task to get to the FOS console.

    As I started manually stepping through the postinstall script I ran into an issue in my script that references /images/drivers (as it should). But looking at the FOS system, there is no /images folder or any signs of it being mounted back to the FOG server. Is this mount not available with the debug task. If this /images link is not made I can understand why my post install script is failing.


  • Moderator

    @george1421

    For clarity the command Tom provided didn’t return any value, but it did set me on the right path (so to speak).

    Well its not as clean as I hoped, but this command will return what I want.
    find /ntfs -type d -iname "sysprep"|grep ystem32

    For what ever reason sysprep exists in System32 and SysWOW64. Either way the above command will return the proper case regardless of the target OS.

    [edit] And this command will find the proper unattend.xml regardless of the case.
    find /ntfs -type f -iname "unattend.xml"|grep ystem32
    [/edit]


  • Moderator

    @Tom-Elliott Once windows 10 is done installing I’ll give that a shot. Right now I just have a conditional, but I like your solution a bit better.


  • Senior Developer

    @george1421 Instead of implicitly doing a location of a directory, why not try to find it?

    Use something like:

    find /ntfs -iname "windows/system32/sysprep" and store the return into a variable?


  • Moderator

    While this is a bit off point, I did find the issue with my script.

    Win7
    /ntfs/Windows/System32/sysprep (folder)

    Does not equal

    Win10
    /ntfs/Windows/System32/Sysprep (folder).

    Ugh case sensitive paths and windows consistencies.


  • Senior Developer

    @george1421 The file handling mounting is located in:
    /bin/fog.mount

    The command sequence runs as:

    umount /ntfs
    umount /images
    umount /bcdstore
    mkdir /images #only if it doesn't already exist
    umount /images #just to ensure nothing is mounted to it.
    mount -o nolock,proto=tcp,rsize=32768,intr,noatime "192.168.1.53:/images"
    

  • Moderator

    @george1421 OK the fog route with a ctrl c got the shares I needed mounted. Now I can keep debugging.

    Solving this issue, thank you.


  • Moderator

    @Tom-Elliott I did schedule a download deployment and then selected a debug task from the download deployment.

    it kind of bugs me why the manual mount doesn’t work correctly. Same subnet and just confirmed no firewall on fog server.


  • Moderator

    Manually keying in

    mkdir /images
    mount -t nfs 192.168.1.53:/images /images
    

    Causes the FOS shell to hang

    From another linux server I can issue the command showmount -e 192.168.1.53 and get a listing of the nfs shares. I can mount the fog server /images to fog server itself at another mount point or on another server. So I’m pretty sure the fog server is OK.


  • Senior Developer

    /images is only mounted in upload (to the server:/images/dev) and download (to the server:/images).

    This happens before the imaging process starts.

    In a debug, make sure it’s a real tasking debug and NOT just a regular DEBUG task. While i could walk you through what to do, I’m too lazy. – :)

    I typically run fog, wait until it mounts the images drive, then break out with CTRL+C.


Log in to reply
 

395
Online

38721
Users

10548
Topics

99850
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.