So far the removal has been very smooth. I’ve checked about 60 or so workstations in two computer labs and they have all done it just fine. Printers have also reappeared.

I have my images on a seperate internal hard drive and my database is already backed up. Thank you guys.

That is sooooo nice. Testing it out on my computer with a handful of my printers.

I’m running buid 5020 and found that the printers don’t show up correctly in the list. My .inf files are stored on a server share. For example, we’ll use //server/share/printer.inf.

When I add the printer, its added like the address above. When I save it, it changes to /server/share/printer.inf.

If I change it to ///server/share/printer.inf it will show correctly in the list of printers.

However, if you search for the printer instead of listing all printers and scrolling, its shows all three ///. It appears that its just a visual issue but doesn’t happen on all the printers, only some. I’ve had to go through all nearly 300 printers and ensure its typed correctly. can be a bit confusing.

I was running build an earlier build from a month ago but upgraded to see if it would fix the issue. It didn’t so the bug is still there, at least for me. Its something I can avoid since I know its there, but a bug is a bug.

It also appears that clicking Update Printer or Add Printer removes one / each time.

Had anyone found a way to issue a command to remove the old legacy client and install the new client? using the msiexec commands have proven unsuccessful to remove the old legacy client. I edited the new client’s msi file to put my servers IP address in and it looks like it’ll deploy out via AD just fine but removing the legacy client is the issue. I have 1000+ computers with it and manual removal looks to be a long process.

Nevermind, I had a brainfart moment and forgot I can just use the Product ID. msiexec /x {91C5D423-B6AB-4EAB-8F17-2BB3AE162CA1} if anyone happens to be looking for this info too.

if exist "C:\Program Files (x86)\FOG\Handlers.dll" goto end
if exist "C:\Program Files\FOG\Handlers.dll" goto end
goto update
:update
msiexec /x {91C5D423-B6AB-4EAB-8F17-2BB3AE162CA1} /quiet /passive
\\pathtomsi\FOGService.msi /qn /passive
net stop fogservice
net start fogservice
:end

I’m sure there is a more elegant way of doing it, but this works.

@Tom-Elliott I’m currently copying the images off the 1TB to a brand new 3TB drive as a backup. I’m going to look at the MD5 checksum info Wayne posted below after the copy goes through.

@Tom-Elliott The images have all been used a lot. I’ve used both old and new images. I took one of the machines I’m trying to image to a different site and imaged it there with no issue. The imaging process also fails randomly, its not always at the same spot with the same image. Tomorrow I plan on taking one of the images to a different site and seeing if that image works fine elsewhere.

I also tried to image a known working computer and it failed there too.

Is there a way to check the integrity of an image file? I have been getting CRC32 errors when imaging any computer and with any image I try. I checked the SMART data of the drive holding my images and it says everything passed. The computer I use as my FOG sever is older and needs to be replaced (my department was supposed to have ordered me another one by now but I swear a snail is after at doing things…) and I’m wondering if maybe the decompression of the image file on the fly is failing on the FOG server. The error that happens on the computer being imaged says

pigz: skipping: <stdin>: corrupt -- invalid deflate data (invalid code lengths set)  pigz: abort: internal threads error

Since it happens on every computer and with any image, I don’t think theres a problem with the image files themselves and the 1TB drive that holds my images isn’t very old either.

I’m on FOG SVN 5680 running Fedora 22 Server. I just updated it to see if it was the software The last two SVNs I was on, which had a bit of versions separating them, had the error too. Every once in a while I’ll get a successful image process to complete. I’ve used the images many times with success each time.

@Wayne-Workman I get that and I used describe userTracking. There is no utID or utHostID equal to 0 in the table userTracking.

I ran

select * from userTracking where utHostID = 0;

It returns Empty set.

I also checked to see if there was a utID of 29025280 since that is the row its referencing and it returns Empty set too. I realize now that the page number changes since users are logging in constantly on my site.

Just emptied that table. the data in it wasn’t relavent to me and I turned off the usertracking service for the time being too. The error is gone now. However, a machine that has been in FOG for a very long time has changed its ID to zero now. Not sure how or why but it did. It is also no longer listed in the host lists on the website but I know it was this summer when I imaged the thing.

@Wayne-Workman I removed the row from both tables that had teh value of 0 and those appear to be fine. the hostID was of a computer from a group of computers I had to remove manually before but probably missed that one. I now get this:

fog.userTracking
error    : Found key at page 29025280 that points to record outside datafile
error    : Corrupt

I know what that table is used for and where the data is displayed but no sure how to remove that entry. Also, could I simply empty the table since I don’t worry about who logs into and out of the computers. I’ve had to refer to it maybe twice in the last 8 or so years.

Sorry, yes I’m running an SVN version. 5171 to be exact. I’m staying on this version for now until I get my new hardware. My current machine is limping along.

I’ve googled the error and read both its ok to ignore and not ok to ignore. I know auto_increments shouldn’t be zero but am unsure if thats something set by the devs on purpose or if its an error.

fog.hosts
warning  : Found row where the auto_increment column has the value 0
status   : OK

fog.moduleStatusByHost
warning  : Found row where the auto_increment column has the value 0
status   : OK

Are those warnings ok to ignore? I checked the integrity of my database in preparation of replacing my fog server and those two came up.

@Jbob I used Handlers.dll because it doesn’t exist with the legacy client install. If in the next version of the client it doesn’t exist, I’ll change the argument to look for a different file. FOGService.exe exists for all versions so it would never uninstall if it found the file on the legacy install.

So far the removal has been very smooth. I’ve checked about 60 or so workstations in two computer labs and they have all done it just fine. Printers have also reappeared.

I had the same issue. Rolling back brought back an issue where the last printer in the list assigned to each host became the default printer and couldn’t be changed. I went back to the latest (at the time it was 5124) and the issue came back of printers disappearing. My computer was fine though and it turns out that the legacy client was doing the printer deleting. I decided to jump in and install client 0.9.5 on my workstations via a startup script in a group policy. That can be found here https://forums.fogproject.org/topic/6035/remove-legacy-client-and-install-0-9-5-client So far, its rolling out fine. The GP removes the legacy client and installs the new one. I edited the MSI installer of the new one to set my servers IP by default instead of fog-server. So far its working just fine. I have 1000+ workstations and waiting or installing the printers manually is out of the question.