Posts made by BryceZ

What about swapping the order they’re listed?

It’s been a while since I last spent much time dealing with the rules of NFS; but I seem to recall there being a thing about subdirectory rules being inherited, and some searching around the web points to swapping your fsid’s for /images and /images/dev so that /images/dev is processed first.

Not really sure if that will solve anything, and I don’t have a linux box on hand to test with, but it looks plausible.

Did you check /etc/exports on 10.0.0.3 to make sure that it has write permissions?

Two things come to mind:

1. Is PortFast enabled on the switch ports feeding those computers?
   PortFast being disabled can cause issues when PXE booting because the link takes too long to establish, which shows up as PXE/TFTP timing out.

2. Is the Windows Firewall allowing the TFTP application?
   TFTP connections are established over UDP port 69, but the actual file transfer happens over a random UDP port. So just opening UDP port 69 probably isn’t going to work and it’s generally easier to just allow the TFTP application through the firewall.

As far as I’m aware… most VOIP phone are actually PXE booted, so it might be that somebody has replaced the global DHCP options 66 and 67 to point at the VOIP system.

OK, so you have another program creating the FOG tasks? If that’s the case then it sounds like it’s creating the files just fine but the database entries aren’t being added for the tasks.

Apart from the logs in the log viewer there are no central “FOG logs”; this issue would most likely appear in either your apache logs or your vsftpd logs, so I would check you configs on those two services to make sure they are logging properly, and then start digging.

Here is the wiki article on what an in place upgrade will change: [url]http://www.fogproject.org/wiki/index.php/Upgrading_the_FOG_Server[/url]

Are you getting any error messages after successfully deploying an image? What are the file permissions on /tftpboot/pxelinux.cfg/ and the files inside?

I’ve encountered this issue a few times, and it seems like it’s generally due to the web server or FTP server being unavailable when the task completes. However, I’ve never had time to dig into the cause of their unavailability when it happens, so it’s hard to be sure. There was at least one time that I came across this where tasks had been created and then the ftp user account had it’s password changed but not updated in FOG. There was also a time when permissions on the directory were modified so that root was the only user allowed to modify files.

I’ve never found any systemic issues with FOG that would indicate a bug, but I’ve found plenty of these little scenarios where for one reason or another the files are created but not deleted. If this is a consistent issue that is easily reproducible then I’d be very curious about your configs/permissions.

Quick update: Yes, 0.33 is still under development. Work has been stuck for a while due to the schedule of the developers and the fact that the one big remaining issue is UEFI. If anyone out there is interested in pushing things forward and has the time to spare, the devs could really use some help working out the whole UEFI booting.

Other than that, the rest is just fixing little things throughout the UI. FOG 0.33 didn’t start with a solid bug tracker, and the dev that did most of the rewrite has had to step back from the project, so there are pages that didn’t get finished but they’re not all documented in one place. So if anyone wants to systematically go through each page and track down all the little pieces that don’t load properly it would help a lot.

If I get some time today I’ll try to read back through these posts and answer individual questions that I know the answers to; like Stephen DiCato’s question about GitHub: they’re waiting for 0.33 to finish before migrating to GitHub.

Did you rename the WebUI account to admin? It looks like you just need to change the WebUI password reset from:
[CODE]UPDATE users SET uPass = MD5(‘password’) WHERE uName = ‘fog’;[/CODE]
to:
[CODE]UPDATE users SET uPass = MD5(‘password’) WHERE uName = ‘admin’;[/CODE]

Hmmmm…

What do you get from running:
[CODE]SELECT * FROM users;[/CODE]

Yeah, that sounds like there is a problem with the syntax. Could you paste a copy of the commands you used and their output?

The only time I’ve ever encountered a blank refresh of the login page is from attempting to login without a password. What happens if you try to put in an incorrect password? You might want to reset the WebUI password just to be certain.

I’d suggest resetting the WebUI password, but you said you already did that. What sort of message does it give you when you try to log in?

Check /var/www/fog/commons/config.php on your FOG server to make sure MYSQL_PASSWORD matches with the new password.

Christian, this sounds to me like it might be a switch configuration issue; if you’re using Cisco switches check to see if PortFast is enabled.

From the [URL=‘http://www.udpcast.linux.lu/cmd.html’]UDPCast[/URL] command line options:

[QUOTE]–min-receivers [I]n[/I]
Automatically start as soon as a minimal number of receivers have connected.

–min-wait [I]t[/I]
Even when the necessary amount of receivers [I]do[/I] have connected, still wait until [I]t[/I] seconds since first receiver connection have passed.[/QUOTE]

I’m pretty sure the javascript at the bottom of loginform.include.php is the script that actually pulls the stats. Try commenting that out and see if that helps.

Did you comment out the div that displays the stats or the javascript that obtains the stats or the whole thing?