@abado Let’s start with some basic questions:
- Which version of FOG did you install?
- Is this your first try or did you have this running at some point in the past already?
@abado Let’s start with some basic questions:
@Foglalt It’s either the wrong IP again or username/password wrong. Take a look at FOG Configuration -> FOG Settings -> TFTP Server. First the items.
As well take a look at this: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP
And to fix all the IP things, check this out: https://wiki.fogproject.org/wiki/index.php/Change_FOG_Server_IP_Address
@Taspharel This is even after rebooting the FOG server? Still FOGTaskSchedule
with high CPU? Do you see anything useful in the apache logs (see my signature on where to find those)? As well, post the contents of your /var/log/fog/fogscheduler.log
here.
@Foglalt Great you figured it out! Too easy if you know what to look for, right?
I purged the post for you. Not sure who’s in charge of the forum rights at the moment. Pinging @joe.schmitt ?!
@st4tus said in (Another) Web UI Hangs:
I’ve tried that tactic and unfortunately it persists, even across machines
Ok so this sounds different to other UI issues we had so far. Sounds like this is not an issue on the client/browser.
load average: 1.32, 0.98, 0.49
Is this right when you have the issue? Do you have one CPU or several ones? 1.32 is not super high (whatever that means) but the values tell us that load’s been rising over the last 15 minutes.
@Foglalt Ok, I just saw that we added an extra message to make this more clear after 1.4.4 release. So this is only in the RC version and will be in the next release. But that’s ok for now. You don’t need that message.
Please open the URL http://10.0.0.12/fog/service/ipxe/boot.php?mac=00:11:22:33:44:55 in your browser (exchange 00:11:22:33:44:55
with the client’s MAC address). Is 10.0.0.12
your FOG server IP? Copy and paste the full text output you get in the browser here.
@kkroflin Great you tested this on the command line! To me this looks like a crude network issue. Are you good with wireshark analysis network traffic? I’d think you can find something there. Maybe it’s some kind of jumbo frame misconfiguration!?
I think I will be able to use multicast with physical hosts with or without a little bit of tuning, but it would be still nice to have some error state if imaging has failed.
I do understand that. I’ve looked through the forum posts myself and if might have been as a matter of trying to debug this issue.
@george1421 Do you remember the debugging session with Tom on 3rd/4th of April 2017? Could it be that Tom pushed this commit? Or do you have any other idea?
@foglalt said in Building a test environment:
I am a bit confused about what is written here about defalt.ipxe file and its chainloading. Can you pls be a bit more detailed?
This is kind of a long story but I try to give you a picture:
next-server
and filename
, called option 66 and 67 in DHCP speek)filename
from next-server
(BIOS use undionly.kpxe
and UEFI use ipxe.efi
by default - see in DHCP config, e.g. /etc/dhcp/dhcpd.conf
)default.ipxe
filedefault.ipxe
it chainloads to the FOG boot menu or runs a scheduled task (this part is auto-generated depending on which client sends the request…)You might wonder why we need so many DHCP handshakes? This is because FOG combines different open source software like iPXE and the Linux kernel to do what it does. Each part needs to setup network communication on it’s own.
Seems like the newer isc-dhcp-server version does start as IPv4 and IPv6 DHCP server if no interface is given in /etc/defaults/isc-dhcp-server
. As we don’t have any IPv6 definition in our config it fails to start. One way to fix this would be to add IPv6 defintion but as I don’t think this will be of much use to any of our FOG users I’d better follow Wayne’s idea on fixing /etc/defaults/isc-dhcp-server
.
Fix is pushed in working
branch. So here is another reason to push for the next release.
@st4tus Server load is minimal you said, right? Can you post the output of uptime
command with shows the load.
What happens if you logout and close all the browser tabs. Maybe even close the browser. Then re-open the login page and login. Is it still hanging?
@st4tus Sorry I am asking so many questions but I don’t seem to be able to replicate this issue yet. So I am just trying to narrow it down.
Do you see the hang straight from the start after login into the FOG web UI? Or does it take a little while to sort of build up?
@Foglalt The FOG boot process consists of several steps doing DHCP three times. At one point it requests default.ipxe. So this is all fine.
then it says things about ip it gots, lease time, then “failed to get ip via dhcp tried on eth0 interface”. it is strange, as it was starting with dhcp, so it must have gotten it already once in the process.
This might happen when spanning tree or auto negotiation or EEE is an issue. The later two do not play a role in earlier DHCP rounds as the other drivers don’t to much special things but only the linux kernel (maybe) does. So it can be many different things that is causing this issue. But it could also be a different problem because at that stage after requesting an IP cia DHCP it also checks connecting to the web UI and if that fails the error looks very similar. So you better take a picture of the actual error and post here so we can have a look.
Beside that you can use an unmanaged mini switch or hub to connect between client and your main switch and see if the problem goes away.
@st4tus We are using JavaScript setTimeout stuff to update website content over and over. This might get in conflict.
Does this happen on any page for you (images, hosts, storage, FOG settings)?
@st4tus Have you tried different browsers yet? Always got the same symptoms?
@st4tus Which version of FOG do you use? 1.4.4, RC10 (dev-branch
or working
)?
@Foglalt said:
if i rerun the setup, why tftpboot directory is populated? and if i did populate it with files, and it finds them (seemingly), why looks for a nonexistent file? (meaning default.ipxe, as it was not mentioned in config file at all).
Sorry but I don’t get why you mean by that. The issue is that in debian 9 the file /etc/defaults/isc-dhcp-server
needs some specific variable set to make things work. So by re-running the installer (after fixing the issue) the setup runs through all the way and also populates the /tftpboot directory.
I am working on this issue and will push a fix soon.
@stiger No I didn’t mean “mark this topic solved” but wanted to ask you how you solved the issue? It’s important to know for other people having the same issue.
I opened an issue on github for this. So we can leave this topic marked as solved.
@dsloan.ethra Take a look at this: https://www.rfc3092.net/2017/06/mysql-max_connections-limited-to-214-on-ubuntu-foo/ and/or https://support.plesk.com/hc/en-us/articles/213393029-MySQL-values-open-files-limit-and-max-connections-are-not-applied and/or https://codepoets.co.uk/2015/mysql-max_connections-stuck-on-214/ (depending on which distro/version you use)
@dsloan-ethra Try the following mysql queries to see if max_connection
is properly set after a reboot:
mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 151 |
+-----------------+-------+
… and connection limit (Connection_error_max_connections
) is being hit at all:
mysql> show status like '%onn%';
+----------------------------------+-------+
| Variable_name | Value |
+----------------------------------+-------+
| Aborted_connects | 0 |
| Connections | 8 |
| Max_used_connections | 4 |
| Connection_error_max_connections | 1421 |
| Ssl_client_connects | 0 |
| Ssl_connect_renegotiates | 0 |
| Ssl_finished_connects | 0 |
| Threads_connected | 4 |
+----------------------------------+-------+