@wayne-workman I believe it’s literally, error_logs
Best posts made by Tom Elliott
-
RE: Fresh Debian 9 FOG server install no database?
-
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?
-
RE: Red Exclamations on hosts
@lpetelik I will try to clean up just to make the posts more concise, for example, this one here is about the ping hosts specifically so I’ll remove #1, #2, #3 and just make the title tell us what is wrong.
-
RE: Duplicate USB NIC Mac Addresses
@waynejitehead might I make a simple suggestion.
If you’re using usb nics on multiple machine, I would preregister the machines Wi-Fi Macs and the usb Macs. Then I would make the usb nics ignore for client. This way your machines don’t need to worry about what is used for imaging. I know it’s more work but right now there isn’t a better option with FOG. We are hoping to have a more unique system of determining hosts but it will be a while.
-
RE: Already tried 4.15.2
@newlined you can fix this Behavior if you remove the /var/www/fog and then do:
sudo ln -s /var/www/html/fog /var/www/fog
-
RE: Image completes but the task doesn't
Is our postdownload telling the machine to reboot? Possibly there’s an error occurring during Post download?
As @george1421 suggested, please watch the machine. Maybe grab a slo-mo video of the tail end of the partclone screen until the machine reboots?
-
RE: Can no longer update using GIT
What’s your machine’s timestamp compared to an atomic clock?
Atomic clock can be found here: https://www.time.gov/
Of course your timezone will adjust slightly, but the main point is you cannot be more or less than 5 minutes of the atomic clocks (typically) as that will cause the SSL cert to be invalidated (hence the ssl error you’re seeing.) Of course there could be many other reasons to what’s causing this, but I would recommend checking the time first as its the simplest course of action.
-
RE: Help With Advanced Menu with Login
@quazz Typoed version, it is 1.5.4 they’re using.
@scosta What i’m seeing is:
#!ipxe clear username clear password login params param username ${username} param password ${password} chain ${boot-url}/service/ipxe/advanced.php##params #!ipxe
Do you know where the second
#!ipxe
is coming from? As far as I can tell, this is where things are breaking down. Essentially what it’s doing is clearing the login information, rebuilding it, then restarting the whole of iPXE. This would explain why you’re seeing an error.The advanced menu itself, should not be edited from the Boot Menu element, beyond telling it to display to all hosts if thats how you want it. However, you shouldn’t need to change this portion. You would put your information under:
FOG Configuration Page->FOG Settings->FOG_PXE_ADVANCED
In the advanced side you would put your necessary items, like your Hirens bootCD information.
The advanced menu element hasn’t changed in quite some time, and I’ll admit I haven’t exactly tested it, as creating a new item is usually just easier. That said your advanced field should contain the menu items you want. (Essentially Advanced Menu is a clean slate separate from the main FOG Default menu stuff.)
Here’s the wiki on example setup for the advanced system. https://wiki.fogproject.org/wiki/index.php?title=Advanced_Boot_Menu_Configuration_options (Though you don’t need the “secured” portion as that’s kind of the purpose of hte advanced login handling. But I could be wrong, I really haven’t played much with “advanced” stuff in a long time.)
An example put on the FOG_PXE_ADVANCED field might be (again untested):
goto MENU :MENU menu item --gap Please Select one of the items below item hirens Hirens BootCD 15.2 item return Return to main menu choose --default hirens target && goto ${target} :hirens initrd http://${fog-ip}/fog/iso/Hiren_s_BootCD_15_2.iso chain memdisk iso raw :return chain http://${fog-ip}/${fog-webroot}/service/ipxe/boot.php?mac=${net0/mac} || goto MENU autoboot
-
RE: Fog tftp only works when I disable firewalld
I understand your frustration and sorry you’ve had such a hard time getting things up and running. That said, you’ve only posted informing us that you even had a problem 5 days ago. I am certain we can help get this running but we need information as to the things you’ve tried, the exact messages you’re seeing, etc…
If you feel you must use another product, then I understand, but if you’re having this many issues with FOG, chances are likely that you’ll have similar issues using another product. Clonezilla, SCCM, MDT/WDS, etc… will have similar methods each with their own pros and cons.
As you said you’ve been working on this for 3 weeks, but from allowing us to help you we’ve only had 5 days (and 2 of them were a weekend.) I’m not sure how much you expect us to be able to help.
Can you provide more direct error messages? I’m not quite sure what error you’re referring too with the “Could not complete tasking” as it should provide more information. From the sounds of things, FTP is either not running, or something else is blocking FTP altogether. I don’t know.
3 Messages and you’re ready to give up seems a bit rash to me. Then again, I do understand your frustration. I just don’t know how you expected us to get you running with so little information and back and forth between the Senior Developer of FOG and our community.
-
RE: Help With Advanced Menu with Login
When I re-designed the boot menu, I created all the different elements I could think about. The intention, hopefully, for advanced menu was you could create menu’s like everything else and associate them to the “advanced” side. That said, I still don’t have a good understanding of how to implement a menu system that would link to the advanced system. The item is designed, but not flushed out. So for right now, the “Advanced” and “Advanced Login” are essentially simple placeholders for a feature I might get to think about and implement down the road. Mostly, these days, I’ve been more worried about working out bugs and minor things for 1.5 while working toward getting 1.6 to a more suitable testing state.
Mind you (et. al) that I just started a new job and have much less time than in the past to actually work on FOG. This doesn’t mean I won’t work on it, simply that I’m very busy during the working week and by the time I get home it’s nearly time for bed already
Hopefully this helps you understand the ideology, even if it doesn’t work quite as I would have hoped (or as anybody might expect.)
-
RE: Multicast data address not change from one task to another one
@Fernando-Gietz said in Multicast data address not change from one task to another one:
Se añade esta linea para que asigne direcciones IP diferentes a cada tarea multicast
I’ve added the patch, but a little more checking involved. This has been added to both the working and working-1.6 branches. It tests the set value for the
$address
variable. If this variable is set, it will calculate the address. Here’s the snippet of lines:if ($address) { $address = long2ip( ip2long($address) + ( ( $this->getPortBase() / 2 + 1 ) % self::getSetting('FOG_MULTICAST_MAX_SESSIONS') ) ); }
Hopefully this will address the problem people have been seeing and allow the use of multiple sessions.
-
RE: FOG doesn't detect the status of the clients
FOG Uses port 445 to detect the status of the client machines. This is usually UDP, though I think opening UDP and TCP would help things out.
We use this port as it can give a more direct status than a simple ICMP request.
Hopefully this help.s
-
RE: Replication Issue
@JGallo As you typically re-run the FOG installer, the restart of the service is already performed and therefore not necessary. I’d recommend letting it cycle once or twice on it’s own, then upload the logs. This will let us know if it’s working as it should. By restarting the service to “speed” things along, we actually only see “initial startup.” While, functionally, they’re the same thing, it’s just good to know the full time operation is working as expected as well.
-
RE: Cant pxe boot to fog.
@blindcat420 can you run a simple tftp transfer test? First can you double check rpcbind is running? Usually, I see tftp in a call port created when requested rather than a constant seeing of port 69 being open. This is usually handled by rpcbind utility. Xinetd May play a role as well but I don’t know if it running alone will prove anything.
https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP#Testing_TFTP
-
RE: Add New Snapin Login Incorrect
@Les https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP
Please start there. Mind you this thread is very old and while the message you’re seeing may be similar, hence my posting to the wiki article, chances are your circumstances, version, file, etc… are vastly different. It’d be recommended to open a new thread.
-
RE: Issues during installation on Debian 9.6 stretch
@thegiantcat can you get an exact screen shot of your /etc/wgetrc file?
If you literally have:
"no_proxy="localhost""
This may be a part of the problem.
I’d imagine you should have:
no_proxy=127.0.0.1,localhost,localhost.localdomain,X.X.X.X
Change X.X.X.X to whatever your fog IP actually is.
Also, I believe the installer uses curl for binaries and database backups, so I imagine editing the /etc/wgetrc is the wrong approach.
I believe you would edit the file for whom you’re installing at:
~/.curlrc
You could set the same information up in /etc/skel/curlrc too I suppose.
however you’d want lines like:
proxy = <proxyInfoHere> noproxy = localhost,127.0.0.1,localhost.localdomain,127.0.1.1,X.X.X.X
You could also edit your
~/.bashrc
To contain lines like:export http_proxy=<http://proxyInfoHere> export https_proxy=$http_proxy export ftp_proxy=$http_proxy export rsync_proxy=$http_proxy export no_proxy="localhost,127.0.0.1,localhost.localdomain,127.0.1.1,X.X.X.X"
If you do add to the .bashrc file, however, you’ll need to close the terminal/logout of the console, and log back in for the changes to take effect.
Hopefully this helps.
In the case you use the bashrc method, please change the X.X.X.X to that of your fog server’s actual IP address, and of course change your http_proxy line to be appropriate. It should include the schema (http{,s}://…) information as well.
-
RE: Active Directory after image deployment not working.
@astrugatch Yes, as it’s signed by the CA, it shouldn’t have any issues. Though you may need to have it initially recreate the private cert as it likely created it using the IP. Just a good to know thing for the future. (Particularly on fresh installs.) It would mean, however, that you’d have to update all your clients which could prove problematic in general.
Could be simpler just to remove the IP checking during fresh install. Or, maybe we could add a Hostname item as an inline option (or add to the /opt/fog/.fogsettings file of course) the builds a cert using the IP and allows an alternate name within the cert using the hostname.
Of course this is just thoughts being spewed out sorry.
-
RE: Issues during installation on Debian 9.6 stretch
@thegiantcat What’s the installer’s error log look like?
It should show us more information as to why backing up is failing.
I am a little confused too. Is your FOG Server also your PROXY machine?
-
RE: Snapin create fail ftp_put()
What version of FOG are you running?
Have you tried troubleshooting FTP information?
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP -
RE: Stuck at Stopping FOG status reporter
@fogger1 The links that are provided are the init’s in the most current state we have. The good thing is now that the init’s are separated from the main elements of FOG, and changes aren’t quite as frequent as the main elements, the init’s being provided should work with any 1.5.x version of FOG and even the 1.6 as the backend “functional” pieces aren’t being modified at the same scale between the two versions. So they’re not provided for 1.5.4, they’re whatever the most current version is. The init’s are not labelled in the same fashion as our normal releases which is why it’s important for the distinction here. The init’s in the links are what are provided for 1.5.5 and 1.5.5.2 (which is the most current dev-branch version).