@sudburr said in TFTP error oh my (ESX Server):

PXE-T00: Permission denied

It looks like this might be a file permission issue (if not selinux). The permissions on the /tftpboot directory should be 655 or 755. Make sure the parent folder /tftpboot as well as all of the files have these rights.

@nrg Marking this as solved then. For the database connection issue, open up another thread please.

Hey! Thanks for the topic!

If it does not exist

mkdir /var/www/fog/iso

Copy ISO file

cp SOURCE_PATH/ISO_FILE /var/www/fog/iso

Add

/var/www/fog/iso * (ro, sync, no_wdelay, insecure_locks, no_root_squash, insecure )

in

/etc/exports

Run

sudo service nfs-kernel-server restart sudo service rpcbind restart

Add a new menu in FOG WEB GUI

initrd http://${fog-ip}/fog/iso/ISO_FILE.iso chain memdisk iso raw

WORKED PERFECTLY!

To add on to what @Sebastian-Roth is asking, is the machine efi or mbr booting?

@cedre It works ok for the other VLANS?

@wayne-workman

Very true but making the change in the live DB is a great plan B until a long term plan A is found. I checked the mysql mem calc link and I compared the mysqld.cnf settings for those calculations but many of those variables are not there. I think at this point it works and I don’t foresee needing many more storage nodes in the future for this fog server. I’m happy it’s working now. Thank you both for all your help.

@cnkpadobi

You might want to switch to the working branch.

FOG Install instructions on wiki

Here you will see instructions on how to install Git and switch to working branch. Hope this helps.

@tom-elliott thanks Tom! ok it’s working now, I forgot to change from dev branch to working one since my latest trouble. Everything is fine now! 🙂 keep on good work!

@coxm If you pxe boot the machine yes.

Thanks. I found the problem. Solved.

@sebastian-roth we had an extensive IM chat session. The OP found where the issue was and identified the need for snponly.efi for a specific hardware configuration. I had him start with the examples from the fog wiki and work from there. Where we left it was he was going to see if he could collect the system uuid to see if we could write a better dhcp filter to only send i386-efi/snponly.efi for that specific model and send ipxe.efi for the remainder of the arch 0007 hardware types.

well that really didn’t help readability at all.

But it looks like its a database issue. You might want to review this thread and see if it addresses the issue. https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

Especially if FOG was working one day and its broken the next day without any intentional changes.

@sebastian-roth Thank you very much! You are brilliant!

You saved to me an invaluable time!

I carried out the test of your procedure and all functions perfectly.

Thank you still for your assistance, and thank you for this software!

I love FOG ! It is the best !!

@sebastian-roth Thanks so much! That worked. ( I had those pre-config settings before when I ran the 1.4.0; however, I had reverted to a previous snapshot and didn’t re-configure them for round 2).

Thanks again,
Tamara

I had the same issue, updating the plugin.class.php file did the trick.

Thank you.

Maybe buy something like an active HDMI Switch just to make it happy (e.g. I found Vention HDMI Splitter Switch 5 input 1 output HDMI Switcher for $15). Also the specs of the board show a DSI/eDP interface. Maybe there is some kind of cheap adapter/or mini-TFT you could hook up to that.

But let’s see what you find out with tcpdump and take it from there.

Edit: Ahh, google is your friend again… (possibly related, but maybe not)
https://github.com/raspberrypi/firmware/issues/211
https://www.raspberrypi.org/forums/viewtopic.php?t=11259
https://communities.intel.com/thread/76913

Thanks for the info and suggestion George.

@filisdiez This is for sure not a general FOG problem as we don’t have other users reporting this as far as I know. I can’t replicate this issue either. So I am fairly sure this is something within your environment. Try opening the URL I posted for all the FOG servers you have and see if you always get the proper version printed in the browser.

Looks this could be some kind of HTTP redirect issue. Maybe try this: tail -f /var/log/apache2/*.log (or for CentOS/Redhat: tail -f /var/log/httpd/*_log). Then boot up a client for registration and keep an eye on the logs the moment you see the error on the client screen. Stop the tail log (Ctrl+c) right after you saw the error on the client screen and post a picture of the logs here.

@wayne-workman yes but I would set a windows task to manage the updates. I found fog daily work fails once the client fails. Then I don’t have daily info that I was aiming to collect.

@tom-elliott said in Updating DataBase Failed:

@zago123 FTP is port 21.

To add to what Tom posted, FTP actually uses 2 communications ports. From the fog server to the target (command channel) and then from the target back to the fog server (data channel). So ports 20 and 21 are used for a fully ftp connection.