Posts made by zpoling

I left the server off during the weekend. I have seen issues before where tasks have been stuck and caused the server to do strange things. Last time all I did to fix it was unplug the damned ethernet cable and plugged it back in. This time I left the server off over the weekend. Came back in this morning, started the server up, and everything was working as expected. Very frustrating.

Just attempted to update Fog to 1.5.4 from 1.5.2. When instructed to install/update the database schema, I was able to get to the GUI. However, it simply took me to the login page rather than the database update page. After attempting to log in, it stopped loading and went back to the 504 error.

The install is stuck at “Ensuring node username and passwords match” which I assume has something to do with this https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP#Credentials_.2F_Passwords. However, I have not changed any passwords and the server has been fine for months.

I am no longer able to access the GUI or deploy images to machines.

I successfully captured a task this morning and have been using the GUI all day. I set up a group of machines, assigned them an image, and started a multicast. When they booted, they tftp booted okay, but http was not responding. When I tried to get to the GUI to stop the task and check things out, I could no longer reach the GUI. After a server reboot, it is still not working.

I’m unsure of what logs to look through to decipher what is happening.

Before this thread dies, I just want to mention how much better the newest Fog Client has been. The version offered with v1.4.4 always gave us issues of not restarting the computers correctly after imaging, resulting in needing a few manual restarts. Sometimes it wouldn’t join the domain or change the hostname properly either. v11.15 has been not shown any of these issues and has worked flawlessly for us so far!

@wayne-workman A re-capture did indeed fix the issue. I guess the biggest issue was just not understanding the verbiage. Thanks for your help explaining things.

Onto the next issues!

@wayne-workman Ah, so used space isn’t the size of the original drive/partition, but literally the used space. That makes much more sense.

I’m still not sure what happened to the image :/. I haven’t captured at all, I’ve only been multicasting. The 320GB failed but the other four laptops imaged just fine. I tried deploying to that specific laptop a few more times just to see if it was a consistent issue or not. Once we started talking, that’s when I noticed that the image suddenly showed 0.0GB of data.

I’m going to rebuild it off the other other image I mentioned. I’m building it again on one of the 500GB, but then I’ll upload it and try to deploy it to the 320GB and see what happens. Thank you for clearing up those terms for me.

@wayne-workman So ideally, an original image should be created on the smallest possible HDD?

@wayne-workman The image was captured as resizable, as far as I know. When I created the image, I chose single disk-resizable. As far as used space, this is the size of the image, right? It is only ~18GB.

I have no idea what happened to the image. It is now reporting on the GUI that there is no data for the image, but I imaged with it this morning. I’ve even imaged with it since I first had this issue… I am at a loss. I haven’t tried any reuploads to that image.

Maybe the image was just jacked up. I have a similar image, it’s the same exact one without Microsoft Office, and it images fine on the 320GB. Both images were made on the 500GB drive, both were created and uploaded as resizable, but only one works while the image in question still gives that error (assuming because of the 0.0GB of data). Not sure why the image data would suddenly disappear.

I have an image that was created on a 500GB HDD, uploaded as a resizable image. I was under the impression that a resizable image had the ability to be deployed to smaller drives than that of the original drive/ partition that it was created on. Yet, one laptop out of thirty happens to have a 320GB HDD and will not accept this image; I receive the error “Target partition size is smaller than source.” It is not random and happens every time I attempt to deploy the image to this specific machine. I do not have any spare drives to replace it with, so I’d like to just be able to image to the current 320GB drive.

Image was created on stable v1.4.4. I have updated to stable v1.5.0 since, but the issue has not changed.

I have read other threads about this issue. One thread stated that adding a 1 to d1.fixed_size_partitions could help on smaller drives, but I’m not sure where the file is, but the image is also not a fixed size image.

@wayne-workman

Good to know. So if I ever encounter an error, should I go to the Wiki first and not the forums? I found only one other post that referenced my same error, so I thought that it was a very small rare thing. Didn’t even think to check the wiki.

@tom-elliott

It uploaded properly this time, still with the drive being checked. Not sure how it was flagged as dirty that first time around.

Thanks again, and sorry for the pointless thread.

@tom-elliott

Sorry, the images were out of order. I thought that may be it, but I always sysprep so I know that it was shutdown correctly. I also set the disks to be checked, but have never received and error for doing it before. I’m going to sysprep and try to upload it once again.

We recently ran out of space on our Fog server. Since the server is a Hyper-V VM, I simply increased the drive space. After a very long process of getting the partition resized to use the new unallocated space (way harder than I feel it should have been), I had double the drive space and was ready to capture more images. When I first got the disk space expanded, Linux and Fog both did not see it, they were still reporting the old size. After running the command “lvextend -l +100%FREE”, Linux and Fog both started reporting with the new size. However, when uploading an image I am getting Exit Code 1, which asks if the server has plenty of disk space.

I am not very proficient in Linux, so I am at a loss as to what I could do or even look for.

@sebastian-roth

Not to ignore you, but when I came in this morning, me and my boss had a conversation. He was messing around with another VM that was also having speed issues. He turned off VMQ under the Hardware Acceleration for the VM’s NIC on Hyper-V. His file transfer speed issue immediately went away. Naturally, I tried this for the FOG VM. When I booted up a machine, PXE boot ran as expected. I never saw the TFTP spinning, and both bzimage and init loaded instantly. However, I turned VMQ back on and tried again and the speed issue was still gone, so I don’t know if this was a problematic setting or not.

If the speed issue comes back, I will go ahead and do the tcpdump, unless you’d like me to do it now anyways just for sake of gaining info. FOG is running on the latest Ubuntu Server OS.

We’ve been working with a physical host of Fog for a few years now that has been working great. No issues at all speed wise or imaging wise. However, our team decided to virtualize the server on Hyper-V so we could get rid of the old desktop that we’re currently using.

We got Fog set up with the newest version, but we just can’t seem to get it working right. When computers first PXE boot, the tftp icon comes up and spins for a bit (never even seen it before on the old server). Then once bzimage begins to load, it takes about 30 seconds to reach 100%, same with init.xz.

The switch port for the Hyper-V host is configured exactly the same way as the port for the physical host, so I’m doubting this being the issue.

Thanks, Wayne!

@Wayne-Workman I just wanted to update you on what I saw as I got it working.

In the multicast log, it was showing 0 tasks to be cleaned, but 3 tasks were found. Always. Every way I’ve seen here on the forums to destroy any udp casting tasks did not change the log continuing to show those 3 tasks. On two of the laptops I just happened to be trying to multicast that day, I took all source of power away and held the power button for 10 seconds. I then started a multicast task for those two, and they worked. Keep in mind that I haven’t been able to multicast for a few weeks now. I find it odd that that’s all I had to do, and on two random laptops at that.

Also with the timezone issue, the services not starting was happening before I even tried to set the timezone prefrences. I tried to set the timezone purely because my multicast log was showing dates four-five hours away. I don’t know the exact time, because the log is now reporting the dates correctly.

@Wayne-Workman What should I be looking for? There’s a lot of crap in it.

Reran the fog installer and now all of the services are running. I’m going to reboot and see if the services restart as well.