@george1421

d1.partitions

label: gpt
label-id: F68C4898-B2D7-470A-920F-086D2F844D71
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158

/dev/nvme0n1p1 : start=        2048, size=     1024000, type=C12A7328-F81F-11D2$
/dev/nvme0n1p2 : start=     1026048, size=      262144, type=E3C9E316-0B5C-4DB8$
/dev/nvme0n1p3 : start=     1288192, size=   240150076, type=EBD0A0A2-B9E5-4433$
/dev/nvme0n1p4 : start=   479285248, size=     1742848, type=DE94BBA4-06D1-4D40$
/dev/nvme0n1p5 : start=   481028096, size=    19087360, type=DE94BBA4-06D1-4D40$

d1.fixed.size.partitions

:1:2

Yes, sorry I was confirming what you asked and added the image size for reference as well. I tired on a 1TB drive with the same results. It was a SATA HDD.

So after some more testing. It seems its something with the micro form factor m.2 is causing the issues. @george1421 suggested using VMs to build our images. Something honestly I hadn’t thought of. Since changing to that methodology we haven’t had any issues imaging. It is defiantly something hardware based that wasn’t jiving with the different computers hard drives and imaging with fog.

@george1421 i appreciate the help the firmware is upto date. I will try fedora and get back to you. even with legacy mode same error message.

I had to go in and manually delete each unused version. After that if fixed my issue. I was able to successfully update fog.

Thanks for your help.

I’ll throw my two-cents in here. Has anything changed network wise? I know I ran into an issue when one of the hubs we had went down and we replaced it with a 10/100 we had lying around. As soon as we put in a gigabit hub it was blazing again. Just an idea.

Thanks for everyones help. I decided to try it on an actual device and add the -Wait at the end and that worked. @jflippen your way worked as well. For what ever reason my VM was would both say complete right after the start of script. When I attempted to run it on a physical PC it worked without any issues and completed with the delays.

@jflippen Thanks. I’ll look into this.

@george1421 -Wait was one of the first things I tried. Same thing happened. I might try to make a batch script and try /wait for kicks and giggles. Curious to see if it would still happen or if it would work as expected. I might give that a go tomorrow.

@george1421 Yes you are following correctly. If I run the script manually it will run until that file shows up then exit as expected.

@george1421 the path.to.file is set to the network location location of the the setup.exe that runs the .msp. I am running ours via powershell which is why .\ is there, it wouldn’t run without it. Like I said above the script runs just fine. Its just that fog comes back saying its completed almost immediately. Which it will complete just 4 or 5 mins later. I will however try your suggestion.

@Wayne-Workman I tried that and it failed. Which lead me down this rabbit hole. This process worked minus the quick complete message. Takes about 4 to 5 mins and it completes. All my other processes are running fine with the way you’ve mentioned.

@jflippen I would appreciate that.

This install is for Office 2013.

So the script I built runs as expected but FOG reports it as being complete within 5 seconds of running. Even though Office 2013 hasn’t been installed yet. Any ideas?

Start-Process 'Path.To.File' -ArgumentList '/adminfile .\FogOffice2013.MSP' 

$file = "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Office 2013"

do{
$testpath = Test-Path -Path $file
Start-Sleep -s 90
}
until($testpath -eq $true)

I had to go in and manually delete each unused version. After that if fixed my issue. I was able to successfully update fog.

Thanks for your help.

Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/FOG--IP1--vg-root  835G  205G  595G  26% /

/boot is showing 100% when I do a regular df. I don’t think I’ve ever maxed out boot before but I’m not 100% sure.