• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. JJ Fullmer
    3. Posts
    • Profile
    • Following 5
    • Followers 4
    • Topics 55
    • Posts 947
    • Best 254
    • Controversial 0
    • Groups 3

    Posts made by JJ Fullmer

    • RE: Unable to Capture Using Single Disk - Resizable

      @shatchett0

      Glad to hear it’s working for capture now. You should be able to mount /images on a separate disk without issue, but having it all in the same place is fine too.

      I’m not 100% sure what that error is saying. At least not with enough detail to be helpful right off the bat.

      First thing that comes to mind is a sector mismatch. If your image was captured from a disk with 512e sectors and you try to deploy to a 4kn disk (or vice versa) you’ll get errors when it tries to align the partition table because the sector sizes can’t align. It’s a limitation in disk alignment at a lower hardware level. I have some notes on when I was debugging such an issue in this post https://forums.fogproject.org/topic/17112/surface-go-4-incompatible

      It could also be a simpler issue of the image doesn’t fit on the new disk. In most cases the resizable takes care of it, but if the image’s min size is bigger than the disk, not much can be done. But it looks like it’s an all disk or all partition image?

      posted in FOG Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: Using Snap Ins to run scripts post imaging...?

      @danieln said in Using Snap Ins to run scripts post imaging...?:

      @JJ-Fullmer Thanks for the reply! This is helpful.

      I feel like maybe the best way to go about it is to assign the Snap In to each host. Just to confirm, this will deploy the Snap In after each time that host is image, regardless of which image it receives?

      Yes that is correct, unless you specify otherwise (I think that’s really only available in the api though) the standard operation is to queue all assigned snapins to deploy after an image task

      I’m also thinking of separating my inventory into FOG Groups by computer model and then assigning the Image Associated with it and Snap Ins at the group level.

      Is this QC check also installing and or checking drivers? You could also use postdownload scripts to install drivers and have just 1 image that is universal and the drivers are injected and installed during sysprep specialize phase. Takes some setting up but works very well, see https://docs.fogproject.org/en/latest/kb/how-tos/post-download-scripts/?h=post

      Also, if you wanted to create groups based on the model in the FOG Inventory you could build that out pretty quickly with my FogApi powershell module ( see my signature)

      Something like this would get you a list of all unique model names you have in fog, this example uses is for 1.6 but should also work in 1.5.10.x
      It also doesn’t include the initial api connection bits.

      #get all your fog hosts with full details
      $allhosts = Get-FogHosts | % { (Get-foghost -hostID $_.id -ea 0)}
      #get the sysproduct field from the inventory of each host, and get the unique entries only
      $uniqueModelNames = ($allhosts).inventory.sysproduct | sort-object -Unique
      #list the model names in the shell
      $uniqueModelNames
      

      There may be some additional filtering to do here depending on your inventory (like HP sometimes has slight differentiations of a model) but if that list is what you want your groups to be

      $uniqueModelNames | Foreach-object {
        $jsonObj = @{
          name = $_;
          description = "Computers that are of the model $($_)"
        }
        #I have a pending issue for creating a simple New-FogGroup function
        new-fogobject -type object -coreObject group -jsonData ($jsonObj | convertto-json)
      }
      

      Then you’d set the membership of the matching hosts

      #loop through the model names you created groups of by name
      $uniqueModelNames | Foreach-object {
        #get the group name and the matching group object
        $groupname = $_;
        $group = get-FogGroupByName -name $groupName;
        #find any host that is the given model and loop through them
        $allhosts | Where-object { $_.inventory.sysproduct -eq $groupName;} | Foreach-Object { 
          #set the group association/membership required fields
          $jsonGroupData = @{
            groupID = $group.id
            hostID = $_.id
          }
          #create the group membership association
          New-FogObject -type object -coreObject groupassociation -jsonData ($jsonGroupData | convertto-json) -ea 0; 
        }
      }
      

      Then you can go in the Fog web gui and assign hosts to each image. This can also be done in the api, but I just don’t have time to work out an example for that.

      Also note that groups are not persistent config containers. Group membership sticks around, but it’s meant to be used as a bulk setter. If you set an image in a host it will set it on all the hosts in the group. But if you go change the image on 1 host in the group, it doesn’t auto change back, nor does it auto set when you add it to a group. There is a plugin that changes this behavior called persistent groups, but using it as a bulk setting and as a simple container/organizer of hosts is usually sufficient as you get into things more and more.

      posted in General Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: Using Snap Ins to run scripts post imaging...?

      @MatMurdock This could be implemented via a plugin where you build a db trigger and an imagesnapinassociation that assigns snapins assigned to an image to any host with that image. It could be done. I don’t think it would be added to the default config.

      Granted, you could create a postdownload script that assigns and deploys snapins via the api based on what image was used.

      posted in General Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: powershell snapin no output, non error

      @nathan67 @lebrun78

      When I configured the snapin with my example script that installs the FogApi Module and runs the universal command with the snapin setup with “powershell x64” like this

      a1465243-07f4-4295-a707-7b295fd19e15-image.png

      The snapin worked as expected and the host boots to pxe. I only tested this snapin method on a VM so far but I imagine it will work beyond that.

      posted in Windows Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: powershell snapin no output, non error

      @nathan67

      I’m just going to put these right here

      https://fogapi.readthedocs.io/en/latest/commands/Set-WinToBootToPxe/

      https://github.com/darksidemilk/FogApi/blob/master/FogApi/Public/Set-WinToBootToPxe.ps1

      Not an answer to the snapin issue with bcdedit, but I have published a powershell function within the FogApi module for managing the bcdedit commands and setting a host to boot ot pxe.

      I did just test it as a snapin with a simple script like this:

      #registery the psgallery repository and trust it
      Register-PSRepository -Default -ea 0;
      Set-PSRepository -Name PSGallery -InstallationPolicy Trusted;
      #install the fogapi module from the gallery
      install-module fogapi -Repository PSGallery -ea 0 -Confirm:$false -Force -Scope AllUsers;
      #run command to set pxe boot
      Set-WinToBootToPxe;
      

      But when run as a snapin it still isn’t working, run manually on a machine it does work.

      I’m not sure yet why the command run in the context of a snapin doesn’t work.

      posted in Windows Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: Using Snap Ins to run scripts post imaging...?

      @danieln I don’t know of a way to default assign a snapin to every new host that is built-in to fog.
      However, if a snapin is assigned to a host the deployment of said snapins is automatic when you deploy an image.

      Here’s a few ways you could make it close to or completely automatic on all new/existing hosts.

      • You can assign a snapin when you register a host via pxe, so you just standardize there
      • You can make an everyone/all group and assign the snapin in that group periodically.
      • You can assign hosts to a snapin from the snapin screen I believe (maybe that’s only in 1.6) point though is you can assign to all from there.
      • You can use the FogApi powershell module to write something that adds the snapin to all hosts that don’t have it, and make that a scheduled task somewhere to have that run every day or hour or what have you

      If you wanted to bake it into the image you would just have it as part of your setupcomplete.cmd or unattend.xml firstlogoncommands.

      posted in General Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: What Prevents a FOG Client from Connecting to A FOG Server?

      @Jim-Graczyk I agree with you and I actually ran into similar issues in my migration and I’m still working out what is the best approach for migrating without losing client connections.
      I took notes on my internal migration that I hope to utilize in creating a new doc for migrating a server without losing the client connection, but I also hope to make the PKI/Certs of fog more flexible in general, it’s just a matter of finding the time to work on it.
      If you want to help in creating such a doc in the new docs site (see also https://github.com/FOGProject/fog-docs/tree/master) that would be very welcome.

      I’d love to build a script for migrating, or include it as an option in the installer, but scaling that to support all supported linux distros and standard supported configurations would take some serious work that I don’t realistically have time to do.

      By the by, if the Powershell commands worked, that is something that can be scaled in most windows environments and could be deployed as a group policy script or you can use Powershell methods such as Invoke-Command to run it remotely on all machines.

      posted in FOG Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: What Prevents a FOG Client from Connecting to A FOG Server?

      @Jim-Graczyk said in What Prevents a FOG Client from Connecting to A FOG Server?:

      I DID run into 1.5.10.xxx when downloading FOG, somehow. I used the “master” branch in git for my installs. I follow what I believe are FOG wiki pages that contain specific instructions.

      Recently, as in back in like June of this year, we started doing more frequent releases and created a ‘stable’ branch. There were some security issues reported in 1.5.10 but the changes made didn’t fully justify a 1.5.11 release in our versioning schema. So we created a flow for more frequent releases, it’s described here https://github.com/FOGProject/fogproject/tree/stable?tab=readme-ov-file#versioning-and-branches
      We’ve built out a CI/CD automated release workflow to do monthly releases so that new minor features, bug fixes, and security fixes are released to users more frequently.
      The ‘stable’ branch is now the default branch which should be installed from. The wiki is being slowly migrated over to a new docs site and the latest install doc is found here: https://docs.fogproject.org/en/latest/install-fog-server

      Also yes, changing the ip address typically does involve a recommendation for updating the certs because the ip address is including in the public cert’s san. If you can re-use the same IP and have used that alias in the public cert, then you should be able to migrate without needing to re-install clients.

      posted in FOG Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: What Prevents a FOG Client from Connecting to A FOG Server?

      @Jim-Graczyk
      Re-reading through your post I realized you mentioned a fresh install of the client isn’t working.
      There may be a different issue. When I migrated from centos 7 recently I ended up rerunning the fog server installer with --recreate-ca --recreate-keys and reinstalled the fogservice on all my clients to have them use updated certs and an updated fog server name. I didn’t have the time to troubleshoot it and I also don’t have 8 locations so this wasn’t that big of a thing to deploy via other software deployment tools we have.

      In theory you should still be able to migrate the private and public keys (note that the private keys are hidden with a prepended . in the filename when you migrate them from the old fog server.

      posted in FOG Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: What Prevents a FOG Client from Connecting to A FOG Server?

      @Jim-Graczyk Firstly, are you running 1.5.10 on the new server or 1.5.10.1615 the latest stable release version? Granted it would be best to have updated the old server first and then migrate so you’re migrating between the same versions.

      If you maintained the same server name (or at least used a dns alias to point the old server name to the new server name) and you migrated the /opt/fog/snapins/ssl directory and all other fog stuff (like the database and the /opt/fog/.fogsettings file) before running the installer for the first time (you may be able to throw them in there afterwords in theory)
      then you would have the same CA cert and private cert and subject name for the public cert. So if all that PKI stuff remains the same then all your hosts would already trust the fog server ca (it gets added to trusted root certs when installing the fog client) and the public cert should be updated on the client or may even remain the same. Sounds like you’re using a dns alias so as long as that is updated in the migrated locations it can be made to work.

      If you ran the install of the new fog, and then migrated stuff, then you might have some conflicting settings and you’ll have generated a new Fog CA with a new private key for the web server certificate that the fog client uses to ensure you’re communicating with the right fog server.

      Granted, making a new CA and private key when migrating servers is a good idea and with a new CA it’s easiest to re-install the client to fix the issue so it gets the new CA and cert.

      I believe you could do something like this in an admin powershell session to force the fog service to use a new CA.

      #stop the service
      stop-service fogservice; 
      # delete the certs from the fog service program files path
      remove-item "C:\Program Files (x86)\fog\ca.cert.der","C:\Program Files (x86)\fog\fog.ca.cer","C:\Program Files (x86)\fog\tmp\public.cer"; 
      #remove the old Fog CA cert from the trusted root store
      Get-ChildItem Cert:\LocalMachine\Root\ | Where-Object Subject -match 'CN=FOG Server CA' | Remove-item -force -ea 0;
      #Download the new ca cert, replace "fog-server" with your fog server's name
      iwr "https://fog-server/fog/management/other/ca.cert.der" -OutFile "C:\Program Files (x86)\fog\ca.cert.der"
      #trust the new CA
      import-certificate -FilePath "C:\Program Files (x86)\fog\ca.cert.der" -CertStoreLocation Cert:\LocalMachine\Root\
      #reset the host encryption in the gui (or if you use my FogApi powershell module you can use the Reset-HostEncryption command)
      #after resetting the host encryption start the service back up
      Start-Service FogService;
      

      I just ran all that on a working client and it connected. I even stopped after removing the ca cert from the store and files to confirm that broke the client. Then imported it again and all was well. It’s possible that resetting the host encryption isn’t needed, but I imagine it’s needed as you have a new private key, etc.

      Granted, reinstalling the service should do all of the above, so it may be a null point.

      You could also restore the old CA cert and private key from where you’re migrating to and you may be able to make it work without touching the clients besides restarting the service and resetting host encryption.

      posted in FOG Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: Fog does not run on MSI

      @Tom-Elliott It sounded like he tried snponly and others in an earlier post.
      The initializing devices happens after the efi file is downloaded and booted to, secure boot would stop it from booting because it’s the efi file that isn’t signed.
      I’ve had some luck with the delay based ipxe files on troubleshome devices like this, though there also could just be some driver missing from the ipxe build that isn’t initializing for this device. I feel like it doesn’t boot to pxe at all if the ethernet adapter isn’t supported.
      @anube The other thing I’ve had luck with is booting directly to the ipxe.efi file. But on a new device that requires either the device to have a built-in uefi shell or you

      • setup 2 usbs
        • 1 a refind usb boot disk
        • 2 another usb where you have the efi boot files from /tftpboot (I usually just grab the ones I know work but you could just grab all of /tftpboot via winscp/filezilla/or some other ftp client off the fog server).
          • I would also go here https://www.realtek.com/Download/List?cate_id=584 and download the UEFI UNDI driver. Extract that and grab the x64 RtkUndiDxe.efi file and throw that on the usb too.
      • Then you boot the refind usb,
      • choose the uefi shell option
      • find the usb with the tftpboot folder and efi driver.
        • To find it in the uefi shell you switch to each disk like fs0: then enter, then run ls to see if it’s the right disk, then fs1: fs2: etc.
      • Once you find it you can run load RtkUndiDxe.efi hit enter so the latest uefi driver for that adapter is loaded.
      • Then find the efi boot file you want to use/try a bunch of them. i.e. /tftpboot/ipxe.efi simply entering the path will boot to the efi file and it will attempt to then boot to the fog server.

      If that does the trick you at least have a workaround and a simpler way to find which efi boot file works for that device. It may be possible to load the updated efi driver into the firmware, but that varies by device and I wouldn’t suggest it unless there’s an official way of doing it provided by MSI. It may also work with an older build of ipxe or a future one or there may be something that can be added to the ipxe build. You can also find ways to make this methodology more automated.

      posted in Hardware Compatibility
      JJ FullmerJ
      JJ Fullmer
    • RE: Fog does not run on MSI

      @anube Have you tried the 10sec-delay versions of the ipxe files?

      posted in Hardware Compatibility
      JJ FullmerJ
      JJ Fullmer
    • RE: Linux host name change after imaging?

      @adam1972 said in Linux host name change after imaging?:

      There’s nothing in AD
      b47c6e3a-d842-4a36-9630-0c97c8b77471-image.png

      That checkbox at the bottom of AD is where you enforce hostname changes I believe. Which I just noticed is also what @Tom-Elliott said 20 minutes ago.

      I would also look at the snapin definition, this screenshot is from 1.6, but these boxes still existed on snapin definitions in 1.5 (minus the No action, it’s just checkboxes for shutdown or reboot I believe)
      d810613a-d788-4c79-9ac9-fdfba821302e-image.png

      If those are checked it could be part of why it’s doing so many reboots.

      The fog client runs things in windows without being logged in, there’s actually 2 services running for it, a system service and a user service, I imagine linux works the same way.

      However, if it’s waiting to perform the hostname change, there could be something else that’s causing a reboot at the linux OS level when the hostname is attempted to be changed without a reboot? If that is waiting to happen I believe the client waits for that to finish before attempting snapins. It causing the random restarts is still perplexing.

      posted in Linux Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: Multicast stuck

      @Eazis The storagenode can be a master of a different storage group if I recall correctly, but the default storage group should have the master (where the web server is) as the master. There’s a lot of ways to configure it, but for simplicity in testing this out I would suggest 1 storage group with the master fog server as the master node.

      What version of FOG and kernel is on the master and the nodes. They should all be the same, latest stable, latest dev-branch, or latest working-1.6-beta would be best as we may have already fixed the issue if it’s not a configuration issue.

      posted in FOG Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: Fog does not run on MSI

      @anube Is the bios/uefi firmware up to date on the computer?
      Has this device worked before? Or similar MSI devices?
      Do you have a pxe capable usb adapter you could try?

      posted in Hardware Compatibility
      JJ FullmerJ
      JJ Fullmer
    • RE: Linux host name change after imaging?

      @adam1972 I was about to ask for the log.
      So it looks like you don’t have the enforce option enabled for renaming the hose and the client thinks that someone is logged in. I’d try enabling enforce, I think it’s actually under the Active Directory settings a little checkbox there, might be under service or client settings on the host.
      I’m using 1.6 where it’s moved to under service settings on a host.

      posted in Linux Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: Unable to Capture Using Single Disk - Resizable

      @shatchett0 you would cancel the capture task and then boot the host to pxe and you should see a compatibility check in the fog boot menu.
      The error also looks like an issue with ext4 thinking it’s a dirty filesystem being captured. If you schedule the capture task with debug checked you can try running the file system check tools interactively. This looks like a problem with this specific host and the image being captured more than a fog server issue.

      posted in FOG Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: Linux host name change after imaging?

      @adam1972 the double reboot is reminiscent of joining windows computers to the domain and then rebooting a second time to rename in the domain, though fog client has long since done it in one go. Are you setting the ad settings for the Linux hosts? Do the snapins have the reboot box checked in their definition?

      posted in Linux Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: Linux host name change after imaging?

      @adam1972 if you want to do this in fos right after deploying you could probably use a postdownload script to set the contents of /etc/hostname
      You would just need to mount the disk that was just imaged and use sed to edit the file with the $hostname variable. Well there’s a few other steps but I’m on my phone.
      I don’t know for sure if that’s still all there is to it as I feel like hostnamectl has gotten more robust in newer Linux releases across all distros, but it’s a good start.

      posted in Linux Problems
      JJ FullmerJ
      JJ Fullmer
    • RE: Fog does not run on MSI

      @anube Have you tried ipxe.efi as the boot file?
      What version of FOG are you running?

      posted in Hardware Compatibility
      JJ FullmerJ
      JJ Fullmer
    • 1 / 1