@george1421 nope I haven’t because I don’t know that it slows everybody down, and even if it is slow, it’s not broken.
Best posts made by Tom Elliott
-
RE: fog perform full host registration = no viable mac to use
-
RE: Replication: Only working on 1/5 nodes
@jflippen file b is handled separately and done on the remote side. This method receives that hash and uses it
-
RE: Unable to Install Kernel 4.17.0
@zer0cool this just adds a box firmware driver from something somebody post d on github issues.
-
RE: Unable to Install Kernel 4.17.0
@zer0cool Ultimately it doesn’t matter, it was just to ensure people knew there was a change, rather than just replacing the original 4.17.0
4.17 + bnx will be the default kernel for 1.5.5 so for now I suppose it doesn’t really matter.
-
RE: Unable to Install Kernel 4.17.0
@zer0cool It’s possible it’s a permissions issue. The /var/www/fog/service/ipxe folder should have
chown -R fog:apache
(redhat) orchown -R fog:www-data
(debian) ownership. You could just give full access asfog:fog
I suppose. -
RE: Update failed do to wget
@breit Then I’d recommend cleaning
/boot
This is likely what’s causing the problem. -
RE: FOG 1.5.4 Multicast sessions immediately end.
@solkre Mind checking out the working branch? I’ll like to know if my refactoring of the multicast code will help you out here.
I was aware multicast sessions being a PITA, and I had already refactored for 1.6. It was a tedious process to try to do the same for 1.5. I’ve been busy. I decided to attempt correcting the issues with 1.5 based code using the refactorization used in 1.6. I did some very basic testing and things appear to be working. I did not test normal multicast at all, just the session style MC tasks as that is what I was aware of as being broken. -
RE: Cannot update location association in group
@kafluke and there inlies the issue. Groups affect hosts. If you have no hosts no data is stored.
-
RE: Capture/Deploy tasks hang on erasing/saving partition tables.
https://news.fogproject.org/fog-1-5-4/
It’s already known about and noted with a work around.
I’ve also pushed up 4.17 kernel that at least in one case seems to have fixed the delayed saving/erasing element.
-
RE: Multitasking - Not All Clients Start Tasking
So chatting with @Joe-Gill We narrowed down what the problem.
First, the backstory.
So Multicast tasks would work for some machines, but not all. And, to add to that, it was always the same machines that failed to work. If the machines that failed were subsequently put into their own group, they would multicast without issue.
This lead me to ask if the machines that would fail were on a different switch from the rest of the machines, and indeed @Joe-Gill found out that this was the case. They are using Meraki switches and they replaced a few of them. Those that were replaced do not work fluidly with the older switches in place.
@Joe-Gill keep me truthful here, but this is the gist of this information.
-
RE: Trying out Fog for the very first time, already stuck at this tutorial....
Try instructions from here: https://wiki.fogproject.org/wiki/index.php/Include_any_ISO_in_the_FOG_Bootmenu#Hirens_15.04
Of note, it appears that it may only work with advanced menu, not the individual menu items directly though I’ll admit I have not really played around with having extra menus like this.
-
RE: Trying out Fog for the very first time, already stuck at this tutorial....
@george1421 was mandatory accidentally. In 1.5.4 it should be fixed so if the description is blank the label will be whatever the name was.
-
RE: Date off in dashboard #253 - Github
@mparlette You don’t need to. I’ll post information about this forum thread to the github so people know we were aware, just it wasn’t “technically” a bug, rather a misconfiguration.
-
RE: Can't image - attempting fixparts
@raju_inc you would likely need to run
git pull
after the checkout otherwise working is sitting at the same point as dev, master, etc… -
RE: Erasing current MBR/GPT table issue
This is not “stuck”. For some reason kernel 4.16.6 and possibly 4.17 have this issue.
The point, here, is if you wait long enough, it will finish. If you downgrade your kernel to 4.15.2 (which can be done right from the FOG GUI) and restart your machines, you should no longer have this issue.
-
RE: Can't image - attempting fixparts
@aysientor Please manually download the latest inits. I looked and the version is still set to “full” so it’s using the predownloaded binaries.
To download the latest run as root:
wget -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init.xz wget -O /var/www/fog/service/ipxe/init_32.xz https://fogproject.org/inits/init_32.xz
-
RE: Slow Unicast Deploy on new Machines
@george1421 Based on this, it would seem, to me, the 480 has a 10/100 NIC (possibly) vs the 410 having a 10/100/1000 NIC?
Just my thoughts on the whole thing.
Typically, because of the compression applied, you will see faster than your network speeds, though not by too much. For example, on a 1Gb network (both sides) and using SSD (both sides) you could see 13-18 GB/min, where on a 1Gb network the theoretical (goldilocks?) maximum (translated) would be 7.5 GB/min.
So compression is important in this. As CPU and write to disk is often much faster than the network itself. (This is also partially why Network->Disk is faster than Disk -> Disk, as the disk in question has to spin up, and locate the other point on the disk (same disk or not)).
It really seems that the NIC on the 480’s is different than the 410’s, or some other variable. Seeing as things seem normal on one, and not on the other, it really points to the machine being the problem, not something fog is doing.
-
RE: Replicated image not showing up under "List All Images"
If your other node is a server in its own right, then this is to be expected. Images aren’t automatically populated in the database, each one requires a definition to be available. So replicating an image from one server to another is fine, but it doesn’t automatically populate the receiving server with the definition.
-
RE: Fresh Debian 9 FOG server install no database?
@wayne-workman I believe it’s literally, error_logs
-
RE: problem with the speed of image capture
@alex84 reading the post I see no issues with what @Wayne-Workman has asked.
If indeed capture takes forever but deploy is fast as your post suggests, what is the compression set too? What is the RAM (size/speed)? What is the disk?(ssd/spinner) is the disk good?