@sudburr said:
PHP Fatal error: Cannot create references to elements of a temporary array expression in ...
To me this sounds like you have an older version of PHP installed. Maybe something went wrong in the installer when external repos were added. Check to see which version of php is installed rpm -qa | grep php
Tom pointed me to a discussion here in the forum about a similar issue some time ago. Search for emmc and you’ll find a thread with a user called d4rk3.
Could you please enter a FOG debug session and run the following two commands fdisk -l /dev/mmcblk0 and lsblk /dev/mmcblk0
I guess the output of fdisk will be empty. Would be interesting to see what you get from lsblk.
As far as I can see clonezilla is showing the partitions with fdisk because it is debian based and debian has added the mentioned patch. See here: https://launchpad.net/debian/+source/linux/3.16.7-ckt9-1 (“eMMC: Don’t initialize partitions on RPMB flagged areas”) I downloaded the debian patchset to look through it and it’s got this patch by Nell Hardcastle (https://dev-nell.com/rpmb-emmc-errors-under-linux.html) in it!
@Tom-Elliott Would you mind adding this patch to 4.2? I know you’ve done this for d4rk3 some months ago. Didn’t seam to work for him but I wonder why.
@cassie_280 Options 66 and 67 sound correct (no typo there, hmm??). Is the TFTP service running on the FOG server? Please run netstat -antup | grep ":69" as root (sudo) on your server and post the output here. And just to make sure the firewall is properly disabled run iptables -L and post the results you get.
Not sure if you are aware of this. The boot menu is mostly generated by /var/www/fog/lib/fog/BootMenu.class.php which itself is called when clients access http://ip.of.fog.srv/fog/service/ipxe/boot.php
You can simulate this by opening the URL in your browser and adding a parameter with a MAC address of one of your clients: http://ip.of.fog.srv/fog/service/ipxe/boot.php?mac=aa:bb:cc:dd:ee:ff
You should see the full menu code in your browser. Hope I could give you a little more insight into this.
I guess it should be yum -y --enablerepo=remi-php56 update (instead of ‘… remi-php5-56 …’), hmm?
Are you still seeing the update schema page? Looking through the error logs again I noticed this:
... php_network_getaddresses: getaddrinfo failed: Name or service not known ...
Sounds a bit like the hostname cannot be resolved. But as I see in the other errors you have the database on the same host as the webserver (as pretty much everyone else) using localhost as hostname. Maybe your /etc/hosts files is gone wild. Please take a look and post the content of /etc/hosts file on your FOG server.
@dylan123 said in Climbing Imaging Speed:
I don’t think that’s the case as I’m able to move a file from the FP server down to my computer at 60-110MB/s so I don’t think there’s any shaping of that kind on the network.
Traffic shaping can be implemented on protocol/port basis. So transferring files through let’s say SMB might work at full speed but NFS could be slow.
Then as well there is one question not being asked as far as I can see. Is this imaging multicast or unicast and how many clients at any one time?
Screw this !!! I think this was happening because I haven’t properly disabled SElinux on that machine! Really strange that this would cause such a weird thing.
setenforce 0 and now both ways work for me as well. Thanks a lot for testing and your answers!
FOG stores images in /images/dev/<mac-address> temporarly while upload is going on. This image is usually moved to /images/<image-name> (/images/HP in your case I guess) after upload was finished successfully.
But this did not happen in your case. Hard to say why as I don’t have any more information about this. As a quick fix you could try uploading again or moving the image by hand (mv /images/dev/d48564bb7172 /images/HP).
Did you see any error message at the end when uploading the image? Maybe your FTP settings are boged: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP
@george1421 Great, thanks for looking at the code! Seeing the figure now, 200, I notice that it’s hard to estimate how long it takes for a client to drop as the timeout for each single package seems to be some kind of calculated waitAverage time in the code (senddata.c).
@zacadams Nevertheless you can just start playing with the option to see if you can pull enhance the slowdown situation when a client is being shut down in the middle of multicasting. For testing this I’d suggest the following strategy: Do three tests each:
I’d suggest first try a value of 100, if that is working great (client not dropping even for the 5 second disconnect test) test 50, then 25, then 12. The closer you get to 1 the more “responsive” your dropout will be noticed and speed coming backup again hopefully. If you see the client being dropped on the 5-second-disconnect-test I’d go the other way, so if it drops at 50, do your next test with 75…
@Wayne-Workman There is no simple answer to this I suppose. A great plus is that the used chipset is mentioned: ASIX AX88772A/B
Looking through the forums you can find people who successfully netbooted iPXE with that USB NIC (legacy BIOS/undionly.kkpxe!). Not sure about EFI - I guess it will cause trouble!
And you should never forget that USB NIC PXE booting depends on the client machine as well. The BIOS needs to properly talk to the USB NIC/chipset in question. So ASIX AX88772A/B working on a HP stream book for example does not mean it will work with all other tablets/gadgets as well. It’s very hard to tell beforehand. You just need to give it a try I reckon.
Edit: Not even sure which version (v1/AX88772A or v2/AX88772B) to suggest…
@mr626 It’s all over the forums. Try searching…
It means that your FTP credentials are incorrect. This usually happens if you change those but don’t reflect the change in /opt/fog/.fogsettings. When re-running the installer things mess up. Follow this article: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP and don’t forget to get your .fogsettings correct as well!
@Pikmin Here is a list of files you’d need to copy over (don’t just overwrite but backup or move the ones on FOG server #2 before, just in case):
/opt/fog/snapins/ssl/CA/.fogCA.key
/opt/fog/snapins/ssl/CA/.fogCA.pem
/opt/fog/snapins/ssl/.srvprivate.key
/var/www/html/fog/management/other/ssl/srvpublic.crt
/var/www/html/fog/management/other/ca.cert.pem
/var/www/html/fog/management/other/ca.cert.der
Hint: The later two are copies of the first file - CA cert - available to the clients in two different formats, you definitely need those in place if you add new fog-clients later on.
@ManofValor See it written… “Access denied”. FOG is not able to login to the database. Either the database is not running (ps ax | grep mysql) or your password is screwed: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL
I know there is other more important stuff to get done but today I felt like trying to find out about those two kernel boot messages that all of us see when the linux kernel loads.
EXT4-fs (ram0): couldn’t mount as ext3 due to feature incompatibilities
udevd[...]: error creating epoll fd: Function not implemented
The first one is very easy to address by adding this kernel parameter rootfstype=ext4. Sure people could just add this to their host’s kernel parameter field but as we all have it I request this being added in boot.php for all the kernel command lines.
For the second error we need to re-compile the kernel (no need to do this in a hurry! Just add the kernel config change and it will be ready with the next major kernel compile). For the error to disappear we need CONFIG_EPOLL=y.
Tom is absolutely right. You need to define this in ipxe/src/config/general.h
...
#define PARAM_CMD /* Form parameter commands */
...
See Tom’s config here: http://sourceforge.net/p/freeghost/code/HEAD/tree/trunk/src/ipxe/src/config/
@jack_chapman2020 said in Image not joining the domain:
We are using FOG 10.2.0.60
Where did you get this version info from? Login to the FOG Web UI and you should see the version in the bottom right corner.
As well we need the log file from the client that doesn’t want to join the domain. C:\fog.log or C:\Program Files (x86)\FOG\fog.log
@fredlwal Most probably a FTP credentials problem: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP