My experience is sanboot works on most computers.

Dell Optiplex 9020s need Grub, even if they are in BIOS mode - not sure why on that but since it works I didn’t really spend time on it.

HP EliteBooks need Grub, even though they are in BIOS mode.

I should mention, every computer in my building - and we have maybe 15 different models - is successfully booting to the network every time they are turned on, and getting kicked to Windows when there isn’t a task scheduled. We’ve been working towards that for a long time, and finally got them all over the summer. Imaging is a dream now.

UEFI computers need various settings - I just go through the list until I find one that works. It’s usually refind.

Our environment has the correct exit mode per-machine. We have the global default set to sanboot, but we use fog groups when needed to set exit types where needed.

@Wayne-Workman it is there yes, but for some odd reason the wipe tasks don’t work correctly. They do not queue. The image task queues fine but wipe tasks do not.

The installer has an option to not exit if something fails. It’ll likely be a disaster in most cases to use, and it’s been a pretty flaky option in the past, but the argument is:

./installfog.sh -X

This - if it works - should not exit when the kernels/inits/client fail to download, and then you can place the files later.

Get a full description from the installer’s help menu:

./installfog.sh --help Usage: ./installfog.sh [-h?dEUuHSCKYXT] [-f <filename>] [-D </directory/to/document/root/>] [-c <sslPath>] [-W <webroot/to/fog/after/docroot/>] [-B </backup/path/>] [-s <192.168.1.10>] [-e <192.168.1.254>] [-b <undionly.kpxe>] -h -? --help Display this info -d --no-defaults Don't guess defaults -U --no-upgrade Don't attempt to upgrade -H --no-htmldoc No htmldoc, means no PDFs -S --force-https Force HTTPS redirect -C --recreate-CA Recreate the CA Keys -K --recreate-keys Recreate the SSL Keys -Y -y --autoaccept Auto accept defaults and install -f --file Use different update file -c --ssl-file Specify the ssl path defaults to /opt/fog/snapins/ssl -D --docroot Specify the Apache Docroot for fog defaults to OS DocumentRoot -W --webroot Specify the web root url want fog to use (E.G. http://127.0.0.1/fog, http://127.0.0.1/) Defaults to /fog/ -B --backuppath Specify the backup path --uninstall Uninstall FOG -s --startrange DHCP Start range -e --endrange DHCP End range -b --bootfile DHCP Boot file -E --no-exportbuild Skip building nfs file -X --exitFail Do not exit if item fails -T --no-tftpbuild Do not rebuild the tftpd config file -P --no-pxedefault Do not overwrite pxe default file

@Tom-Elliott I ended up just resetting the fogstorage password and replacing the $ with an s and ran a script to change this on all nodes.

I can continue to test escaping at home though.

any progression on this my FOG fellows?

Tom worked on a patch quietly since I started this thread - and I’ve tested it - and it works.

My storage node at home that I tested on is an old Pentium 4 with an IDE drive in it - so it’s very slow.
Results at home:

I could open 12 pages and let them sit on the fog dashboard - CPU usage on the storage node stayed below 4, there weren’t uncontrollable httpd processes spawning, Open files by the apache user stayed below 4k - and the bandwidth chart not only reported - but it’s now reporting more smoothly than ever, is actually accurate now, and doesn’t have spells of mental disability anymore. It’s like butter.

The issue, as it was explained to me, is that the JS which renders the bandwidth chart and does the polling of bandwidth.php on all nodes enabled for bandwidth reporting - it wasn’t waiting for a response, it would just re-issue another poll before the response was received. The more dashboards open, the worse it got, until eventually apache was unable to do anything do to it’s tremendous load of ‘stacked’ processes that were back-logged. I didn’t tell anyone but Tom - but this (now solved) issue would break imaging at remote locations, too - because we use the location plugin and apache on the remote nodes is relied upon to get imaging done in this setup. That too is solved now.

These fixes will all be in RC-9.

@Tom-Elliott I’m seeing this message on Storage Nodes at work - I can assure you I run everything as root. Here’s my thread where this error shows up, if it helps at all:
https://forums.fogproject.org/topic/8376/storage-nodes-stop-reporting-after-a-while/24

Also - an earlier picture posted by the OP makes me think if this isn’t EXACTLY the same issue I had in that above thread. Because some of his nodes were not reporting their version or interface names - exactly as my issue is.

For future readers, the below posted link to the “Troubleshoot FTP” wiki article contains the needed vsftpd configuration files that FOG needs, both for Debian and RHEL variants. The FOG installer automatically sets these up for you on a fresh install with a fresh OS. The OP’s problem was caused specifically by an OS migration from Ubuntu 12 to Ubuntu 14.

@Wayne-Workman I think he had missing packages.

So I removed all the php packages and libapache-mod-php packages.

Then I re-ran the installer after removing the packages line from the /opt/fog/.fogsettings file.

once that was done all worked properly.

I know you referenced another thread - but that thread is a year old.

Can you please post your errors that you are seeing. Take pictures of them.

@Tom-Elliott / @Wayne-Workman OK everything is working fine now. thank you fog team for the help. according to @Tom-Elliott it was because the tftp folder was misdirected. I’m not really sure how that occurred but he fixed it. also @Wayne-Workman the revert to kernel 4.7.0 fixed the messages issue. but being as I’m informed its not really an error ill just later revert to kernel 4.7.1 and downgrade the messaging

@3541 said in FOG boots to menu but can't open anything else Lenovo Thinkpad Helix:

iPXE just flat-out doesn’t have drivers for USB ethernet adapters.

That’s not correct, many people here use USB to Ethernet adapters to image with FOG. Support is less with them of course, but saying they don’t have support is incorrect. Often - it’s the host’s firmware that is the issue, or the adapter itself, not iPXE.

@Darrell-Lanson This normally presents itself on uploads by getting hung trying to create the partition table.

We have utilities already that allow you to fix this really quite easily, but does require you load up in a debug mode.

@alexf2132 Ah, seems you’re right, you can likely safely delete it then.

If your real host does not have its mac address as hostname then

delete from hosts where hostName = 28d244343edf

Thanks Wayne!

@george1421 @Tom-Elliott Just wanted to report back to say that everything looks to be working and thank you for your help!

@Wayne-Workman Thank you for all your help.

@Wayne-Workman

Sorry for the delayed response, I have been busy at other locations. I think that moving to a freshly installed server is probably the best solution. I don’t have time to do it today, but it will be a separate machine (a better machine). What will be the best way to get those images and hosts transferred? I greatly appreciate the help. Also, be aware that due to the failed upgrading process, the web gui is no longer working.

I changed ip address of my server, removed /opt/fog/.fogsettings and reinstalled fog again. Now it works like a charm. May be, there was a compatibility issue between old fog settings and new fog version. Now, I don’t see any strange error like above.

Have you tried using sudo to copy using the second account?