• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. Mentaloid
    3. Posts
    M
    • Profile
    • Following 0
    • Followers 0
    • Topics 7
    • Posts 59
    • Best 5
    • Controversial 0
    • Groups 0

    Posts made by Mentaloid

    • RE: Trying to push image to client - Mounting File System Fail

      @fry_p sidenote: The only SB switches I had issues with were some of the <24 port switches - and this was a issue with the stupid security they had messing with UDP/NFS; this was fixed with a firmware upgrade.

      posted in Linux Problems
      M
      Mentaloid
    • RE: Snapins - Snapins with reboot after cause infinite boot loop

      @Tom-Elliott
      Thanks Tom, whatever you changed seems to have fixed things right up!

      Reboot after is now working without causing tasks to be re-created when next checkin occurs.

      You guys are awesome - did I mention that before?

      posted in FOG Problems
      M
      Mentaloid
    • RE: Snapins - Snapins with reboot after cause infinite boot loop

      @Junkhacker

      I had thought of the restart in the power shell script - but thats a problem as the next snapin starts executing while the host shuts down.

      The snapin runs fine with a clean exit - and this did work before I upgraded from client9.X/trunk7224 to client10.6/trunk7591

      Powershell with -File runs the script called in the current environment - not as a separate thread/subproccess - so it does wait for the script to completely finish before exiting.

      posted in FOG Problems
      M
      Mentaloid
    • RE: Snapins - Snapins with reboot after cause infinite boot loop

      0_1463029874126_RebootSnapin.png

      reboot.ps1

      Start-Transcript -path c:\SnapinLogs\Reboot.log
      #restart-computer
      echo "Fogservice will issue reboot, this is a dummy file"
      Stop-Transcript
      

      I’ve got tons of other powershell snapins that work fine (infact, snapin 1 and 2 are powershell), so it’s not powershell related. Simply unchecking “reboot after install” will break the loop, but is obviously not the desired operation.

      I’ll see if I can pull an apache log to see if there is anything pertinent in there.

      yes, I realize I could simply put the reboot after on the snapin prior - but some people I work with require a more visual aid to see whats going on, hence the snapin

      posted in FOG Problems
      M
      Mentaloid
    • Snapins - Snapins with reboot after cause infinite boot loop

      I upgraded to 7591/client10.6 this morning - and since then I’ve got infinite boot loop happening when snapins are being deployed;

      Snapin 1 (no reboot after) runs, installs, disappears from task list
      snapin 2 (no reboot after) runs, installs, disappears from task list
      snapin 3 (reboot after) runs, installs, disappears from task list
      snapin 4 (no reboot after) - checked in
      (client reboots)
      next checkin, snapins 1,2,3 suddenly show up in the snapin task list, and the cycle restarts.

      I can break the loop by unchecking reboot after install on snapin 3.

      Any idea’s whats going on? this worked on 7224 (was using client 9.x (9.6?))

      posted in FOG Problems
      M
      Mentaloid
    • RE: FOG + Powershell (WinUpdate) Question

      @Wayne-Workman

      Yep - I ended up doing that as well, but things I noted:

      Some stuff the AD join and hostname change should be completed first (wsus server and policies and proxy via AD and group policies) - and without the service running, that won’t be completed. Enabling the service at the send of the setupcomplete.cmd means the rename and join hasn’t been completed. Doing it at the beginning, and then running other tasks mean that it will reboot while completing the other tasks.

      This is what I’ve done to get the best of both…

      example sysprep.cmd

      sc stop FOGService
      sc config FOGService start=disabled
      sc stop FOGService
      
      copy \\fog\Deploy\W10\unattend.xml %systemroot%\System32\sysprep\unattend.xml
      mkdir %systemroot%\setup\scripts
      copy \\fog\Deploy\W10\setupcomplete.cmd %systemroot%\setup\scripts\setupcomplete.cmd
      
      net use * /del
      del c:\users\administrator\desktop\*.lnk
      c:
      cd \windows\system32\sysprep
      c:\windows\System32\sysprep\sysprep.exe /quiet /oobe /generalize /shutdown /unattend:unattend.xml
      

      and my setupcomplete.cmd

      @echo off
      del /Q /F c:\windows\system32\sysprep\unattend.xml
      del /Q /F c:\windows\panther\unattend.xml
      net user Administrator /active:yes
      sc config FOGService start=auto
      sc start FOGService
      net use * /del
      exit
      

      Then the snapins run after fog service renames and joins the domain.

      The reason I use snapins for everything else - because I like my setupcomplete to be simple and fast - anything I want beyond the basics, I can choose to implement or not without changing the setupcomplete; just add the snapins (which for @RLane, would be the windowsupdate snapin).

      posted in Windows Problems
      M
      Mentaloid
    • RE: FOG + Powershell (WinUpdate) Question

      I used a snapin for tasks like this - because I found fog service was renaming and rebooting before any tasks that took more than a few seconds in my setupcomplete.bat. Any snapins are installed after domain join, at least by my testing.

      Snapin Run With : %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe
      Snapin run with argument : -ExecutionPolicy Bypass -File
      Snapin File : WindowsUpdate.ps1
      Snapin Args: Y Y

      Snapin Command should look like this:
      %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File WindowsUpdate.ps1 Y Y

      That should work fine - and it seems snapins are pushed in order now, so I have this snapin named as 005.wsus for example.

      posted in Windows Problems
      M
      Mentaloid
    • RE: Multicast from second storage group

      @george1421

      Same dhcp server, same scope. The VPN is hardware tunnel, so any computers @ both sites act as if they are in the same physical network/scope.

      posted in FOG Problems
      M
      Mentaloid
    • RE: Multicast from second storage group

      @george1421
      Thanks George - I had contemplated that, but I’d have to then have different pxe boot structures.

      I have already written a bit of a bodge script that checks multicast tasks on my main FOG server, and starts the UDPCAST process on the storage server if the image is found locally (storage group and image = local). This seems to have worked for my purposes.

      Thanks everyone for their input!

      posted in FOG Problems
      M
      Mentaloid
    • RE: Multicast from second storage group

      @Wayne-Workman
      Yep - I had noticed. 170 gigs worth of images @ full speed of the VPN connection doesn’t outpace sneakernet in this case though!

      wow… I haven’t referenced sneakernet in way to long a time 🙂

      posted in FOG Problems
      M
      Mentaloid
    • RE: Multicast from second storage group

      @Tom-Elliott

      The image is only stored on the second server - hence the separate storage group. The reason for this is the middle is a VPN - FOG13 sits on one side, and acts as a storage server for systems on that side. The other storage server is on the other side of the VPN. Replication between the 2 should not happen as they are 2 different storage groups, and is undesired as the VPN is well… too slow 🙂

      The trick is, I’d like to be able to multicast from either storage group, so I can essentially pick which server to use.

      It won’t kill me, and I’ll probably bodge a script or plugin eventually. Unicast works fairly well in the mean time.

      posted in FOG Problems
      M
      Mentaloid
    • RE: Deleting multiple images

      Thanks, good to know Wayne!

      posted in Bug Reports
      M
      Mentaloid
    • Deleting multiple images

      I’ve got several test images, and was about to delete multiple old images :
      Image management > all > select 1 or more > delete selected images

      I get a 500 ISE

      [Wed Apr 20 20:04:15.872957 2016] [:error] [pid 45782] [client 10.1.0.130:62643] PHP Fatal error:  Call to a member function get() on null in /var/www/fog/lib/fog/fogpage.class.php on line 487, referer: http://fog13/fog/management/index.php?node=image&sub=list
      
      posted in Bug Reports
      M
      Mentaloid
    • RE: Multicast from second storage group

      Wow… that seems like a lot of bother, and possibly recipe for an “oops”!

      It seems to me (OMG, I am so no volunteering to figure out how to do this out… yet), that there should be a way to have a storage server check in with the main server to see if it should be creating multicast host processes, and the main server to point the clients to the correct storage server.

      Future Feature request? :):)

      posted in FOG Problems
      M
      Mentaloid
    • Multicast from second storage group

      I have 2 fog systems:
      FOG13 = main + default storage, only member of default
      FOGStorage02 = storage only, group #2, only member of #2

      Multicast works fine when using an image stored on FOG13, but fails with

      [04-20-16 7:13:40 pm]  Task (3) Multi-Cast Task failed to execute, image file:/images/W10Audit_05 not found!
      

      when attempting to start a multicast for an image on group#2

      Is this not supported for images not on the default storage/group/main server?

      posted in FOG Problems
      M
      Mentaloid
    • RE: No Replication to second Fog server, after updating to latest Rev. 5157

      @Tom-Elliott

      FOG13.domain.local = FOG + storage node (Default, only member, replication enabled (to nowhere))
      FOGStorage02.domain.local = storage only node (ID#2, only member, replication enabled (to nowhere))
      Running Debian 8.4, PHP Version 5.6.19-0+deb8u1

      Log is from main fog server (FOG13) running 7242 (updated now), FOGStorage02 also 7242.

      I updated to 7196 yesterday to reconfirm another issue, and at that time journalctl entries changed to

      Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards:  Non-static method FOGBase::getSetting() should not be called statically in /opt/fog/service/lib/service_lib.php on line 3
      Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards:  Non-static method FOGBase::getSetting() should not be called statically in /opt/fog/service/lib/service_lib.php on line 3
      Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards:  Non-static method FOGBase::getSetting() should not be called statically in /opt/fog/service/lib/service_lib.php on line 4
      Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards:  Non-static method FOGService::getDateTime() should not be called statically in /var/www/fog/lib/service/fogservice.class.php on line 92
      Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards:  Non-static method FOGBase::getSetting() should not be called statically in /var/www/fog/lib/service/fogservice.class.php on line 90
      

      every 3 minutes. These entries persist to today, after updating to 7242.

      I haven’t confirmed if the services are functional at this time.

      posted in FOG Problems
      M
      Mentaloid
    • RE: Snapins being truncated

      @Tom-Elliott

      Thanks Tom!
      (wow, that was fast!)

      posted in Bug Reports
      M
      Mentaloid
    • RE: Snapins being truncated

      Updated to 7218 (latest as of this post). Same issue - file uploads fine: Edit afterwards, and the file is truncated.

      posted in Bug Reports
      M
      Mentaloid
    • RE: Snapins being truncated

      Sure:
      So I have a snap in - in this case for example a snap in that installs chrome. The file was uploaded via the fog web interface originally.

      I go to edit - eg add some description, anything really. The snap in file is instantly truncated to 0 length when the update button is pressed.

      Before update: Notice the file size of googlechromestandaloneenterprise64.msi
      0_1461038134614_Snapinbefore.png
      After update: Notice the file size of googlechromestandaloneenterprise64.msi
      0_1461038146965_Snapinafter.png
      Relevant apache log entry:

      POST /fog/management/index.php?node=snapin&sub=edit&id=4&tab=snap-gen HTTP/1.1" 302 498 "http://fog13/fog/management/index.php?node=snapin&sub=edit&id=4" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
      
      posted in Bug Reports
      M
      Mentaloid
    • RE: No Replication to second Fog server, after updating to latest Rev. 5157

      I’m not sure if this is related or not - I’m using Debian 8.4, with fog trunk (git 7190).
      The service master logs aren’t showing any issues, however if you check the output from the daemon itself

      journalctl -u FOGImageReplicator.service
      

      this shows up

      Apr 16 13:50:56 FOG13 FOGImageReplicator[38336]: PHP Warning:  Error while sending QUERY packet. PID=11398 in /var/www/fog/lib/db/mysql.class.php on line 49
      Apr 16 13:50:56 FOG13 FOGImageReplicator[38336]: PHP Fatal error:  Using $this when not in object context in /var/www/fog/lib/service/fogservice.class.php on line 77
      

      This repeats every service loop (approx 3 minutes) . This isn’t restricted to ImageReplicator either, all FOGservices are affected

      journalctl -u FOGMulticastManager.service
      journalctl -u FOGPingHosts.service
      journalctl -u FOGScheduler.service
      journalctl -u FOGSnapinReplicator.service
      

      My imagereplication, snapin replication, multicast, etc aren’t working either. I haven’t had time to delve into the why’s as this isn’t mission critical yet for me.

      posted in FOG Problems
      M
      Mentaloid
    • 1 / 1