@Sebastian-Roth @Wayne-Workman Just an update, making a folder for the image, switching the type, renaming image file to sys.img.000 and copying partition info into the new folder made the image work.

@george1421 Thanks so much for your response. Just to share with anyone else who might use it, I just created a Powershell script that gets the hostname and emails me an alert about the system. Script below if you want it…(I am calling the script if certain criteria are not met (like missing drivers or something)…

$test=Test-Connection $env:COMPUTERNAME -count 1 | select Ipv4Address
$IP=$test.IPV4Address.IPAddressToString
$MAC=(gwmi -Class Win32_NetworkAdapterConfiguration | where { $_.IpAddress -eq $IP }).MACAddress


$Hostname=Invoke-WebRequest http://192.168.64.14/fog/service/hostname.php?mac=$MAC
$Hostname=$Hostname -split("\n")
$Hostname=$Hostname[0]
$Hostname=$Hostname.Replace("#!ok=", "")
$Hostname=$Hostname.Trim()

Send-MailMessage -To "YOURTOEMAIL" -From "FOG_WARNING@FOGALERTS.NET" -Subject "$Hostname Alert" -SmtpServer "YOUR SMTP SERVER" -Body "$Hostname had a problem... You need to fix this!!!!!"

Mod edited to use codebox.

@jbonilla Just in-case anyone else is trying to get this working, I had to add “union=overlay” after the “filesystem.squashfs” portion to get it working on my server.

:CLONEZILLA
kernel http://${fog-ip}/fog/service/ipxe/clonezilla/vmlinuz
initrd http://${fog-ip}/fog/service/ipxe/clonezilla/initrd.img
imgargs vmlinuz boot=live username=user fetch=http://${fog-ip}/fog/service/ipxe/clonezilla/filesystem.squashfs union=overlay locale=en_US.UTF-8 keyboard-layouts=NONE
boot || echo failed to boot
prompt
goto MENU```

@Sebastian-Roth @Tom-Elliott @george1421

I took your advice and modified the init.xz to make a custom init, and all I did was just add “auto eth0” and “auto iface eth0 inet dhcp” to the interfaces file. It brings up eth0 and it images after adding this. So at this point it works. The fix is probably not the best fix in the world, but hey, it works!

I installed a fresh copy of 12.04 server with the same version of Fog that my current server had (0.31) and imported the database. After importing the database I installed the upgrade to 1.2.0. It was Friday evening and I was doing work on the Fog server through a VPN connection, so when I tried to upgrade the Schema it did it’s usual “hang”. I thought I would just figure it out on Tuesday when I came in for work. When I came in for work, to my surprise the test box had upgraded. My only theory is that it took some time to do, not sure why, but it ended up upgrading over the weekend.

This can be closed for now, but I am still unsure why the Schema would hang for such a long period of time to update the tables in the SQL database.

A quick note to anyone installing an older version (like 0.31) on ubuntu server 12.04, you will need to install SQL server BEFORE you run the install. I had to run “sudo rm -rf /var/lib/apt/lists/*” and “sudo apt-get update” before SQL server would install properly.

@Tom-Elliott Thanks Tom.

I upgraded all the nodes. What cleared the error is below.

The issue was that this was a “part-image” type of image that I updated and re-uploaded which converted it into a partclone image. The master node overwrote the old file when I uploaded the image. The other nodes though, which get the image updated from the master still had the old image on them which was a file, not a directory which partclone seems to use. Once I deleted the old image from the nodes, it replicated to the others without the error.

I have just solved this issue. The problem is that the image was uploaded with the “vista” OS type. I think this must be broken in 1.2. I was able to recover my image by changing the name of the image file inside the folder to “sys.img.000” and changing the OS type of the image to “Windows 7”. To do this, simply browse on your master node, or where your images are stored and rename the largest file inside the image folder to the “sys.img.000”. I was able to fix two images I uploaded with the vista OS type.

Not Hijacking this post, but just wanted to “upvote” this and say I am having the same exact problem with the same exact model , Lenovo T14 Gen 2. I narrowed it down to what you guys have found so far before finding this post (that the nic driver in the kernel is most likely the issue). Using a lan adapter as a workaround, but if I find anything I more I will let you guys know.

Dustin

@Sebastian-Roth Just want to say this is resolved. Not sure why, but installing on Debian fixed the issue. We tried the same exact thing with Ubuntu and CentOS on a reinstall importing the same exact database but couldn’t resolve it…I know as a tech person that doesn’t make sense as to why Debian would fix the issue…but it did and has been working for a few weeks now solid.

Dustin

@Sebastian-Roth Sorry I did not see your response before my “update” post, but thank you for the reply. I tried changing that on the other installs that we had (the 14.04, 16.04 and CentOS), but it the unresponsiveness stayed. The weird thing is that we have not changed the client checkin time on the Debian install and it is still working great. Does Debian handle Fog better in general?

Just a quick update…We installed on Debian and imported the database and it is working… Web GUI is responding much better as of now, but we have not changed anything except the OS it is installed on. We have no idea why it is all the sudden working but it is. So a reinstall on Ubuntu 16.04 had the same issues, CentOS has the same issues, but Debian works. I will update later today if it is still working well.

Dustin

Version - 1.5.4
VM - 8GB Ram

A few days ago our Fog server stopped acting normally. The web GUI was super slow, almost unresponsive. We tried everything we knew to figure out why, and even re-installed to see if that would fix the issue. Our original server is Ubuntu 14.04 where the problems started happening. We tried to re-install fresh on 16.04, same problem. We also tried installing on CentOS and got the same issues. The web GUI might work for a short time, but eventually it will fail or just “spin” and do nothing. If the web GUI does work, trying to start an image task or going to the storage node section are things that cause it to just “spin”. Logins take forever…etc… I have tried searching the forums and doing things like https://forums.fogproject.org/topic/10717/can-php-fpm-make-fog-web-gui-fast to no avail. If I run “top” typically we see lots of php-fpm processes. I also tried updating to trunk to see if that fixed the issue, but same results (super slow, unresponsive GUI). Maybe we have royally screwed something up along the way and did not realize it, but we have not been able to solve the issue. If someone has ideas, just let me know, any help is appreciated.

Dustin

Server

• FOG Version:
• OS:

Client

• Service Version:
• OS:

Description

This isn’t really related to FOG specifically, but I have seen that others have posted Windows 10 issues that have to do with imaging in here (so I thought I would try). I have made many Windows 10 images, and have never ran into the issue that I am currently experiencing with any of the past builds (1511, 1607). Basically the issue I am having is after deploying my image (Windows 10 - Version 1703), the administrator auto-logins indefinitely when it should only auto-login once. The auto-login option is in the unattend.xml file that is ran with sysprep. I have my auto-login count set to “1” currently, but it will re-login to the administrator profile multiple times which is causing issues. I haven’t changed anything in the way I do things, and it has always worked before (which leads me to believe this is a 1703 issue)… Let me know if you have any suggestions or if you too have been experiencing this. I haven’t been able to find a fix or even anyone experiencing the same issue. Thanks!

Dustin Olson

@Sebastian-Roth @Wayne-Workman Just an update, making a folder for the image, switching the type, renaming image file to sys.img.000 and copying partition info into the new folder made the image work.

@Sebastian-Roth @Wayne-Workman Sorry for the late reply, I was out of the office until now. They were already set as partimage images. Good catch Sebastian, yes they were Vista images that were actually Windows 7 images (old images that were pre 1.2 when one had to use Vista to upload Win7 images). I changed the image type to Windows 7 from Vista, and since the image file was not a “folder”, I created a folder for the image, moved the image file into the folder and named it “sys.img.000”, and copied partition files from another Win7 image and put them in the folder with it. The image is downloading right now, but I am not positive it will work with me hacking at it haha. Is there a better way to recover those old images or should my process work? (Ill update this if it does or doesn’t work). Thank for the replies, I appreciate the help and feedback!

Dustin

Server

• FOG Version: 1.4
• OS: Ubuntu 14.04

Client

• Service Version:
• OS:

Description

I update my images on VM’s, and recently I have ran into an issue where I get the error message “Could Not Remove Old Parition” when trying to download a few images(pic below). I saw some posts on the forum with the issue, but I didn’t see an answer for something I should try. The images I am trying to download are Win7 images uploaded with partimage not partclone (I believe, as they are not folders on the storage node). Any ideas on how I can troubleshoot this? Let me know what you are thinking when you have time, thanks!

Dustin

@Tom-Elliott I see. Ya it should have at least told me what interface after the “from”, didn’t realize that until now. Thanks Tom!