Run the following code in powershell (after editing it with your network’s subnets) to create a csv that will import all hosts on your network.

# examples, just gotta put subnets minus the final .x in a string array
# Could also be params if this was a function
$subnets = @("192.168.1", "192.168.2", "10.2.114", "192.168.0"); 
$subnets | ForEach-Object { # loop through each subnet
	for ($i=0; $i -lt 255; $i++) { # loop through 0 to 255 of the subnet
		$hn = nslookup "$_.$i"; # run nslookup on the current ip in the loop
		if ($hn[3] -ne $null -AND $hn[3] -ne "") { # does the ip have a dns entry
			$hostN = $hn[3].Replace("Name:","").Trim(); # parse the nslookup output into a fqdn host name
			$mac = getMac /S $hostN; # does the hostname have a mac addr. Can also add /U and /P for user and password if not running from a administrative account
			if ($mac -ne $null) { # was there a mac for the host?
				$macAddr = $mac[3].Split(' ')[0]; # use the first found mac address and parse it
				"$hostN,$macAddr" | Out-File C:\hosts.csv -Append -Encoding UTF8; # add the hostname,macaddress to the csv
			}
		}
	}
}

@Arrowhead-IT Scratch that, it totally worked after a restart. So if you go breaking your permissions just run the script posted and restart and violia!

Everything is working for me now! hooray for the new inits!

@Lee-Rowlett I think you are somewhat correct there. In all my testing I found that it relates to when a user first logs in it installs all the metro apps for that user including cortana. And when you do a profile copy in the system advanced settings control panel it ends up copying some of those installed apps to the default profile which causes the installation of metro apps on a new profile to fail, but there’s no error because the installs think they succeed since the files are already there.
At least I think that has some to do with it. My new script system seems to work flawlessly and it is much easier than my old way of having to change the registry everytime and such.

I would still test your theory for you, just for funzies, but I don’t actually use an unattend.xml. I don’t like sysprep. It breaks my default profile sometimes, and I’ve seen it break other things and it forces you to go back to oobe which messes with my computer naming system. I’ve kinda found it to not be necessary. Yes it resets some security id’s for activation this and that but if you are using windows enterprise volume licensing, that doesn’t cause any problems. In windows 7 I figured out the registry key to change and then just re-inputting the windows key and reactivating gave it a new sid. Windows 8 and 10 just work without issue without doing that. As for drivers, I make my images on a vm so they’re already hardware independent and I use the terminal tool devcon (included in the windows wdk 8.1, I just copy the devcon.exe over to my image vm after installing the wdk on my workstation) to uninstall all the devices in the device manager before rebooting with devcon -r remove *
It goes through the uninstalling of devices much much faster than sysprep does too.

So thank you sir for your help, but I think I got it figured out.

I created a powershell module for using the Fog API

https://www.powershellgallery.com/packages/FogApi

Install instructions are found at that link.

You can also use powershellget https://www.powershellgallery.com/packages/PowerShellGet the command Install-Module -Name FogApi;*

Importing that module will help you to set up a quick and easy and crossplatform way to manage fog from a powershell prompt.

It is structured based on the api documentation found here https://news.fogproject.org/simplified-api-documentation/
It even autocompletes the parameter options based on that documentation.

So if you read that documentation and see that you can get an ‘object’ you can then take that to the command by saying Get-FogObject -type object -CoreObject objecttype that object type validates/autocompletes to the list of available core objects found in the documentation.

If you install the module and run help Invoke-FogApi it will display a bit more verbose help and documentation on how it all works.

There are a few main functions to use that all make calling the Invoke-FogApi function a bit easier with autocompletion fun times

• For GET api calls : Get-FogObject
• For POST api calls : New-FogObject
• For PUT api calls : Update-FogObject
• For DELETE api calls : Remove-FogObject

Each of these return powershell objects. If you’re unfamiliar with powershell and powershell objects, then this is a good way to learn.
They make it so you can take information and easily find and manipulate their properties.
i.e. if you did a $hosts = Get-FogObject - type Object -CoreObject host $hosts would contain 2 properties, a count of returned objects and an array of all your fog hosts, each with all the information fog has on them. So lets say you want to see all your hosts that have a intel cpu, you can search all the hosts for where the inventory’s cpu manufacturer has ‘intel’ in its value. $intelPCs = $hosts.hosts | ? { $_.inventory.cpuman -match 'intel' } Then maybe you just want the hostids, names, and mac addresses. $intelPCList = $intelPCs | Select-Object id,name,primac; $intelPCList;

PS Objects can also easily be turned into json by piping them into a ConvertTo-Json command. Meaning that you can just change the values of an object’s properties, such as a host’s name, image, etc. And then convert that to json to use as the jsondata in any other command.

I also included a Install-FogService function in the module for good measure that downloads the latest version of the client msi installer from your server and then silently installs it. In theory, you could use Invoke-Command to run that command on remote computers (though you would also have to import the module on each computer).

There is a settings.json file that the module pulls from to get your api keys and servername. It needs to be set manually, but automatically opens in an appropriate editor for your OS if it finds that the settings are still set to default. The default settings are explanations of where to find the values on your server.

Help Info from function code Will be updated overtime, putting here as it is the help info uri listed in module manifest
Invoke-FogApi

<#
        .SYNOPSIS
           a cmdlet function for making fogAPI calls via powershell
        
        .DESCRIPTION
            Takes a few parameters with some pulled from settings.json and others are put in from the wrapper cmdlets
            Makes a call to the api of a fog server and returns the results of the call
            The returned value is an object that can then be easily filtered, processed,
             and otherwise manipulated in poweshell.
            The defaults for each setting explain how to find or a description of the property needed.
            fogApiToken = "fog API token found at https://fog-server/fog/management/index.php?node=about&sub=settings under API System";
            fogUserToken = "your fog user api token found in the user settings https://fog-server/fog/management/index.php?node=user&sub=list select your api enabled used and view the api tab";
            fogServer = "your fog server hostname or ip address to be used for created the url used in api calls default is fog-server or fogServer";
                    
        .PARAMETER serverSettings
            this variable pulls the values from settings.json and assigns the values to 
            the associated params. The defaults explain how to get the needed settings
            fogApiToken = "fog API token found at https://fog-server/fog/management/index.php?node=about&sub=settings under API System";
            fogUserToken = "your fog user api token found in the user settings https://fog-server/fog/management/index.php?node=user&sub=list select your api enabled used and view the api tab";
            fogServer = "your fog server hostname or ip address to be used for created the url used in api calls default is fog-server or fogServer";

        .PARAMETER fogApiToken
            a string of your fogApiToken gotten from the fog web ui. 
            this value is pulled from the settings.json file
        
        .PARAMETER fogUserToken
           a string of your fog user token gotten from the fog web ui in the user section.
           this value is pulled from the settings.json file
        
        .PARAMETER fogServer
            The hostname or ip address of your fogserver, 
            defaults to the default name fog-server
            this value is pulled from the settings.json file
        
        .PARAMETER uriPath
            Put in the path of the apicall that would follow http://fog-server/fog/
            i.e. 'host/1234' would access the host with an id of 1234
            This is filled by the wrapper commands using parameter validation to 
            help ensure using the proper object names for the url 
            
        .PARAMETER Method
          Defaults to 'Get' can also be Post, put, or delete, this param is handled better
          by the wrapper functions
          get is Get-fogObject
          post is New-fogObject
          delete is Remove-fogObject
          put is Update-fogObject
        
        .PARAMETER jsonData
            The jsondata string for including data in the body of a request
        
        .EXAMPLE
            #if you had the api tokens set as default values and wanted to get all hosts and info you could run this, assuming your fogserver is accessible on http://fog-server
            Invoke-FogApi;

        .Example
            #if your fogserver was named rawr and you wanted to put rename host 123 to meow
            Invoke-FogApi -fogServer "rawr" -uriPath "host/123" -Method "Put" -jsonData "{ `"name`": meow }";

        .Link
            https://news.fogproject.org/simplified-api-documentation/
        
        .NOTES
            The online version of this help takes you to the fog project api help page
            
    #>

I would suggest using the full path of the file in your batch script instead of changing the directory.
And when I say full path, I mean the true full path, not the mounted S:\ drive.
Even if S:\ is being mounted by active directory or is a mapped drive as part of your image, I would still suggest using the full network/unc path.
I would also suggest mounting it with net use and a username and password. This will ensure the system account that the Fog Service uses has access to the files you want
I would also add some logging and other error preventions.

i.e. if S:\ was mapped to \FileServer\Share …

@ECHO off

echo. Create variables to make scripting easier
set sharePath=\\FileServer\Share\Pat

echo. Mount S drive path, replace username and password with share credentials. 
echo. If share is public omit the /USER parameter and everything after it


net use %sharePath% /USER:username password

echo. make sure destination exists, create it if it doesn't
if not exist C:\temp mkdir C:\temp

echo. copy each file, add /Y to overwrite without any prompt
echo. copying tdpunt...
copy /Y %sharePath%\tdpunt.bat C:\temp\ > C:\temp\tdpunt-bat-Copy.log
echo. copying tundpt.exe...
copy /Y %sharePath%\tundpt.exe C:\temp\ > C:\temp\tundpt-exe-Copy.log

echo. Done!

exit

Use that and then see if the .log files show up after deploying the snapin.

Also, in the web gui snapin config, you should take out the /qn that does nothing.
The snapin arguments section is for custom arguments that you have in your script. Your script doesn’t do anything with the /qn and it could cause issues. The /c parameter is passed to the cmd.exe command which tells cmd.exe to open a prompt, run the command, and then close.
If you had a line in your script like this

if "%1" == "/qn" (
    echo. hey look a parameter, lets do something since it's there!
)

then the /qn would have a point.

Hope that helps a bit.

Thanks,
-JJ

New Module Version Published

Just wanted to let people know that there’s a new version of the API yay!
It’s been published to the psgallery here https://www.powershellgallery.com/packages/FogApi/1903.0.0.22 and it is awaiting a pull request to show up in the fog community scripts git.
It has new functions to help do some common tasks, particularly with snapins. Here’s a list of the current functions.

Add-FogSnapins
Set-FogObject
Get-FogAssociatedSnapins
Get-FogGroup
Get-FogHost
Get-FogHosts
Get-FogInventory
Get-FogLog
Get-FogObject
Get-FogServerSettings
Get-FogSnapins
Install-FogService
Invoke-FogApi
New-FogObject
Remove-FogObject
Remove-UsbMac
Set-FogInventory
Set-FogServerSettings
Set-FogSnapins
Start-FogSnapins
Update-FogObject

In the past I made a script for automating svn updates. Since sourceforge has been making a habit of crashing lately, I decided to start using the git repo instead and adjusted my script to work with git.
I figured others might benefit from it so why not share…

#!/bin/bash
clear
# -------------------------------------------
# Fog Git Updater
# -------------------------------------------
# -------------------------------------------
# Script Purpose
# -------------------------------------------
# This script is designed to run an automated update of the latest FOG Git dev build and it's cron friendly
# -------------------------------------------
# -------------------------------------------
# Some prereqs for this script
# -------------------------------------------
# 1. Already have an existing working install/configuration of FOG 1.0 or later
#
# 2. Have git installed and setup. You can do that by doing....
# 	sudo apt-get install git
#  	mkdir /home/fog/fogInstalls/git
#	git clone https://github.com/FOGProject/fogproject.git /home/fog/fogInstalls/git
#
# 3. A script to echo the encrypted version of your sudo password, create one with this function
#	just put in your password into the following in place of your_super_secret_password (leave the quotes)
#	and then uncomment and copy paste the function into a terminal and then run it with just the name of the function pw
	# pw(){
	# 	touch /home/fog/fogInstalls/.~
	# 	ossl=`echo "your_super_secret_password" | openssl enc -des -a -e -pass pass:PASSWORD`
	# 	echo 'echo "$(echo '$ossl' | openssl enc -des -a -d -pass pass:PASSWORD)"' >> /home/fog/fogInstalls/.~
	# 	sudo chown fog.root /home/fog/fogInstalls/.~
	# 	sudo chmod 700 /home/fog/fogInstalls/.~ 
	# }
# -------------------------------------------
# -------------------------------------------
# Variables
# -------------------------------------------
# -------------------------------------------
echo "Creating Script variables..."
fogInstalls='/home/fog/fogInstalls'
gitPath="$fogInstalls/git"
backup="$fogInstalls/backups"
pw=`sh $fogInstalls/.~` 
# -------------------------------------------
# -------------------------------------------
# Functions
# -------------------------------------------
# -------------------------------------------
perms(){
	sudo chmod -R 775 $1
	sudo chown -R fog.fog $1
}

srvUpdate(){
	# Enter sudo mode aand do some quick server maintenance update fun times
	# First, enter sudo mode by echoing the output of decrypting your encrypted password and pipe that into an apt-get update
	#	Don't worry, it doesn't output the password into the terminal
	#	Now that the password is in once the terminal will keep it stored for the next bunch of sudo commands
	echo "Running Sever updates!..."
	echo $pw | sudo -S apt-get update -y
	sudo apt-get upgrade -y # install any upgrades you just downloaded
}

backupConfig(){
	# Backup custom config and other files
	# Copy the latest versions of any files you've changed that will be overwritten by the update and backup the database just in case.
	# For example you may want to back up...
	# Config.php
	# 	To be on the safe side your config file in the /opt folder that has may have a corrected webroot for ubuntu 14.04 and may have stored encrypted credentials (i.e mysql)
	# 		I think that the installer uses this file and keeps it anyway, but I like to be careful
	# Exports file
	#	Because this runs the installer with a yes pipe, it ends up telling it that the image path is "y",
	# 		simply backing up and restoring your current one avoids the issue of fog not finding your precious images. 
	# Custom pxe boot background
	# 	If you have a custom background for the pxe menu, the bg.png file
	# Mysql database dump
	#	It would be rather troublesome if something went horribly wrong in the update and your database goes kaboom, it's unlikely but backups are a good thing 
	# Just a note, It's a good policy to also have backups of these outside of your server, which you could add to this script with an scp command or something like that
	# -------------------------------------------
	echo "make sure backup dir exists..."
	if [ ! -d $backup ]; then
		mkdir $backup
	fi
	echo "Dumping the database..."
	mysqldump -u root --all-databases --events > $backup/DatabaseBeforeLastUpdate.sql #backup database
	echo "Backing up config and custom files..."
	echo "config.php..."
	sudo cp /opt/fog/service/etc/config.php $backup/config.php
	echo "fog settings..."
	sudo cp /opt/fog/.fogsettings $backup/.fogsettings
	echo "nfs exports..."
	sudo cp /etc/exports $backup/exports
	echo "custom pxe background..."
	sudo cp /var/www/html/fog/service/ipxe/bg.png $backup/bg.png 
}

gitP(){
        perms $gitPath
	echo "git pull...."
	cd $gitPath
	git pull
}

updateFOG(){
	echo "running FOG installer..."
	cd $gitPath/bin
	sudo bash installfog.sh -Y
}

restoreConfig(){
	# Restore backed up files
	# Restore the backed up files to their proper places and make sure they're formatted correct too.
	echo "restoring custom pxe background..."
	sudo cp $backup/bg.png /var/www/html/fog/service/ipxe # Restore Custom Background 
	# I found that I needed to do this in some configurations, but it may no longer be neccesarry...
	echo "Creating undionly for iPxe boot in ipxe folder, just in case..." 
	sudo cp /tftpboot/undionly.kpxe /tftpboot/undionly.0 # backup original then rename undionly 
	sudo cp /tftpboot/undionly.0 /var/www/html/fog/service/ipxe/undionly.0
	sudo cp /var/www/html/fog/service/ipxe/undionly.0 /var/www/html/fog/service/ipxe/undionly.kpxe
}

fixPerms(){
	echo "Changing Permissions of webroot..."
	perms '/var/www/html/fog'
	echo "Changing permissions of images...."
	perms '/images'
	echo "Changing permissions of tftpboot...."
	perms '/tftpboot'
}

# -------------------------------------------
# -------------------------------------------
# Run the script
# -------------------------------------------
# -------------------------------------------
srvUpdate
backupConfig
gitP
updateFOG
restoreConfig
fixPerms
echo "Done!"

@anthonyglamis Fogcrypt is essentially obsolete, yes. You can still put the fogcrypt output into the legacy input but I find the new auto-encrypt to work better. But yes I’m pretty sure that the fogcrypt tool is still there

I hadn’t noticed that the hashes were different before, so I checked mine and they are different. I haven’t had any problems though, so I would say it shouldn’t be an issue.

I just finished working with @Tom-Elliott we got it working. It was a simple fix.
It’s in the latest fog update now. So nvme drives work with fog 100% now right out of the box. Awesome like a possum!

@alexamore90 I’m not sure where you are wanting to change your ip.

Is fog your DHCP server?
Are you needing to change the ip of the Fog Server?
Did you change or add a different DHCP server on this new ip?
If it’s a new DHCP server, have you pointed option 66 to fog? (https://docs.fogproject.org/en/latest/installation/network-setup/dhcp-server-settings/)

@FRG You can specify the disk to image to in the host settings screen with the host primary disk field

By default Fog will use the first disk it finds (I believe) or you can specify per host.
i.e. if you wanted it to image to a second disk you could specify /dev/sda2 or /dev/nvmen1n1

@cul3r0 It does not, that configuration is elsewhere. If you enabled https support at install then you have to do something special to get that disabled for pxe because it embeds the self-signed cert made at install into the on-the-fly pxe compilation process.

@ksrvpvl Ok, I think I’m getting what you’re saying. I misunderstood earlier.

Is your custom menu option to boot to winPE working? Or are you asking for help with that part too? There is some very basic guidelines on creating a winpe boot option here https://docs.fogproject.org/en/latest/ipxe

The plugin system needs to be enabled in the fog settings, then you should see a plugin menu where you can activate and then install the tasktypeedit plugin. Some basic plugin system info is here https://docs.fogproject.org/en/latest/plugins but it looks like you got past that bit now.

I also found this post https://forums.fogproject.org/topic/10274/creating-task-with-tasktypemanagement?lang=en-US&page=1 where someone was doing the same thing. Perhaps it may offer some help.

It’s looking like I have to find a way to either capture the image or a separate image from a device that defaults to 4k logical sectors or a way to force the device to change sector size to 512 when deploying a 512e based image

I tried hdparm but got this error

hdparm --set-sector-size 512 --please-destroy-my-drive /dev/sda

/dev/sda:
READ_LOG_EXT(SECTOR_CONFIGURATION) failed: No such file or directory

I also tried capturing the image using the new kernel on the off chance that would make a difference, but no good.

I guess I will have to try making an image from a 4k native device since it’s not being changed?

@Sebastian-Roth or @Tom-Elliott any chance you have some time to help me out with this issue?
It’s looking like its a 4k block issue.
I was trying to find a formulaic way to change the partitions files to line up to the 4k layout, like dividing by 8 and some other tweaking as needed but found it more complicated than expected.

Any ideas?

The image did complete but it did not boot into Windows. Looks like I need to embed the storage controller driver for UFS.

Or it could be a 512b vs 4k block disk type issue.

So more findings

Did a test of a different image that is based on /dev/sda instead of /dev/nvmeXnX

That image deployed with the modified kernel just fine (minus booting to the OS, but that was a windows server image, which I didn’t expect to work on a surface go).

But wait there’s more!

As I started playing around in a debug session I found that the UFS disk wants to have a sector size of 4096. This is the dump after manually creating the partitions to match the d1.minimum.partitions of the image

 sfdisk --dump /dev/sda
label: gpt
label-id: 745A6813-735A-4940-840D-28D0E805850A
device: /dev/sda
unit: sectors
first-lba: 6
last-lba: 31246330
sector-size: 4096


/dev/sda1 : start=         256, size=       25600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFB2D745-2975-480D-BD56-EA18B65E03C5, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=       25856, size=        4096, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=57426B89-9DEE-4BDF-9CBF-E9452D985FD5, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=       29952, size=     7340032, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=857B1626-9DC1-44FD-8120-2AB922BBBD85, name="Basic data partition"
/dev/sda4 : start=     7369984, size=      140032, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE086091-5C6A-4D63-89E2-579581B9BD63, attrs="RequiredPartition GUID:63"

Whereas the header of d1.minimum.partitions in my normal base image is 512, though it seems like it might actually be 2048 based on math of partitionSectors/sector-size = size in MB (but I might be wrong about that formula, it’s been a minute since I’ve had to deal with sectors).

This is the contents of my d1.minimum.partitions from the image I want to deploy

label: gpt
label-id: 745A6813-735A-4940-840D-28D0E805850A
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 83886046
sector-size: 512

/dev/nvme0n1p1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFB2D745-2975-480D-BD56-EA18B65E03C5, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=57426B89-9DEE-4BDF-9CBF-E9452D985FD5, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=      239616, size=    57417925, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=857B1626-9DC1-44FD-8120-2AB922BBBD85, name="Basic data partition"
/dev/nvme0n1p4 : start=    82761728, size=     1120256, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE086091-5C6A-4D63-89E2-579581B9BD63, attrs="RequiredPartition GUID:63"

I tried what @Sebastian-Roth mentions in another post here https://forums.fogproject.org/topic/15608/imaging-from-large-drive-to-small-drive/4?=1700488459744 and what @Tom-Elliott mentions here https://forums.fogproject.org/topic/13004/error-trying-to-restore-gpt-partition-tables-on-multiple-dell-machines/13?=1700488480736

When I try to restore from the original file I get an error saying the last-lba is invalid/too high for the disk.

What’s weird, is I can use that syntax to restore the server based image, and that min parts file also has a higher lba, but it makes a little sense as the final sector is below the drive’s “31246330” last lba.

cat ../SVR-Base-Stable/d1.minimum.partitions
label: gpt
label-id: 0B6865A1-3053-4F45-9371-B73F033C7395
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 188743646
sector-size: 512

/dev/sda1 : start=        2048, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=3DF3DEBB-C856-4CC2-9263-EAF0AABF2DDF, name="EFI system partition", attrs="GUID:63"
/dev/sda2 : start=      206848, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=C9738054-91F0-4B3A-AFFA-A9C9ABCC9663, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda3 : start=      239616, size=    27175378, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=42364778-3F9E-4421-88C1-698974428C14, name="Basic data partition", attrs="GUID:63"
/dev/sda4 : start=    27415040, size=     1269760, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=CA25B771-91EC-40A3-B200-1360371A0AD8, attrs="RequiredPartition GUID:63"

So I made a backup of my original image mbr and patition files and edited the d1.minimum.partitions to look like this

label: gpt
label-id: 745A6813-735A-4940-840D-28D0E805850A
device: /dev/nvme0n1
unit: sectors
first-lba: 6
last-lba: 31246330
sector-size: 4096

/dev/nvme0n1p1 : start=        256, size=      25600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=CFB2D745-2975-480D-BD56-EA18B65E03C5, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p2 : start=      25856, size=       4096, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=57426B89-9DEE-4BDF-9CBF-E9452D985FD5, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=      29952, size=    7340032, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=857B1626-9DC1-44FD-8120-2AB922BBBD85, name="Basic data partition"
/dev/nvme0n1p4 : start=    7369984, size=     140032, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DE086091-5C6A-4D63-89E2-579581B9BD63, attrs="RequiredPartition GUID:63"

Making it match the dump after making the partitions by MB and GB size manually.

After editing it this command worked without error

sfdisk /dev/sda < /images/Base-Stable/d1.minimum.partitions

So I made a new version of the d1.mbr
sgdisk -b /mnt/d1.mbr /dev/sda

And popped that on the server to test deploying with that. ON this test, I’m not editing the d1.partitions or d1.shrunken.partitions which may make it so it doesn’t expand properly, but we’ll see how it goes…

It got past the previous errors and is now imaging! woo hoo!
How to fix this permanently though, that’s a different question.

@matthewadams12 Why do you need the Fog Server to be offline?
Maybe there’s a solution where we can isolate just the part you want to isolate. i.e. if you are trying to remove internet access where images are stored you could setup a storage node and keep that offline after initial install. The storage node would also need packages and updates to fog, but you could capture them during updates on the main server and then sneakernet them to the storage node.

Storage nodes are just what I’m using as an example. If it’s not the images stored on the server you’re trying to isolate, then there could still be another solution. You could also firewall the server with your external firewall or the os firewall to only allow access to the fog github page for update downloads and then the repo sites that download the package updates?

Just thought I’d throw out some other possibilities.

@ksrvpvl said in ability to load a menu item on a specific machine as an immediate task:

@baovipboy156 I don’t understand where is this plugin? is there documentation?

There is documentation! https://docs.fogproject.org/en/latest/tasks
The documentation is still under construction a bit, but task info can be found there