@joshuaian What exactly was the date that it was passing. It wouldn’t matter if it was: 2018-05-13 but if the file was 2018/05/03 then it may have issues as the / represent directory separators in linux.

please update to the working branch where this is now addressed.

If you need immediate access, edit:
/etc/php/7.1/fpm/php.ini

Search for:
upload_max_filesize and replace the value 3000M
post_max_size and replace the value with 3000M

Save the file and restart php-fpm service: systemctl restart php7.1-fpm

I’m going to gues this is happening with kernel version 4.16.6? I ask because I found earlier the kernel architectures were backward. I’ve corrected this on the server, so you should be able to redownload the kernels and have success.

The search bar at the top is the search. I’m aware of what you’re talking about and this is semi intentional. 1.6 will have this addressed much more properly.

Just a show here:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP#Credentials_.2F_Passwords

Notice it tells you everything you are saying we need to add.

I’d also like to know what Wiki page you’re referring to that we shouldn’t refer you to, as well the ‘forums’ you found the correct answer on.

I’m happy that you solved your issue, but I’m finding a hard time knowing where the issue was with the wiki (when I don’t know what wiki page you were looking at.)

@andythemayor still waiting a bit more information on a few other bugs that were reported. If you’d like to test things as well checkout the working branch and install.

Setup the TX node as a master node in its own group? Associate the image directly to that group.

@vince-villarreal if you put the image in both groups you can.

@wayne-workman I want to reclassify the last point you made so hopefully easier reading.

A Storage Node Definition can only belong to one group. However, if you create a second storage node using the same information as a peer siting node, except changing the name of the node, it can belong to another group. The code has been adjusted to read all nodes.

I know this may seem arbitrary in explanation but it more directly points out that a node definition can only be in one group.

@vince-villarreal I’ll ad \G should not be used with ;, for example: alter table fog.groups auto_increment = 1\G; is trying to run two separate queries, one for the alter table and one that is blank, hence the error no query message.

\G is a means to display columns in a vertical format where ; will show each row horizontally.

@trialanderror that’s not an obviously known issue, and it has been addressed. The known issues come and go as versions increment and they aren’t all “common”. 1.5.2 brought php fpm usages, but it wasn’t known until well into the release. (The requests needing to be at 2000.) and even that isn’t strong enough as a known issue as it only seemed to have impacted a few people, not everybody.

I’m, by no means an expert, and Joe is currently in the middle of a move, so unable to respond directly. He asked me to post this:
https://github.com/FOGProject/zazzles/issues/24

Basically, what I gather based on what he’s told me is that PCI compliance is enabled for Credit Card information security (or something like that.) If you can disable this Compliance, it might help with the problem? (Or what I understand of it anyway).

The post is part of the issues Joe’s currently aware of so I imagine this may be fixed in the mid to near future.

@zer0cool I’m going to assume, based on your script, that gpupdate is setting the PCI Compliance? That’s assuming this is indeed the case.

@george1421 nope I haven’t because I don’t know that it slows everybody down, and even if it is slow, it’s not broken.

@jflippen file b is handled separately and done on the remote side. This method receives that hash and uses it

@zer0cool this just adds a box firmware driver from something somebody post d on github issues.

@zer0cool Ultimately it doesn’t matter, it was just to ensure people knew there was a change, rather than just replacing the original 4.17.0

4.17 + bnx will be the default kernel for 1.5.5 so for now I suppose it doesn’t really matter.

@zer0cool It’s possible it’s a permissions issue. The /var/www/fog/service/ipxe folder should have chown -R fog:apache (redhat) or chown -R fog:www-data (debian) ownership. You could just give full access as fog:fog I suppose.

@breit Then I’d recommend cleaning /boot This is likely what’s causing the problem.

https://askubuntu.com/questions/345588/what-is-the-safest-way-to-clean-up-boot-partition?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

@solkre Mind checking out the working branch? I’ll like to know if my refactoring of the multicast code will help you out here.
I was aware multicast sessions being a PITA, and I had already refactored for 1.6. It was a tedious process to try to do the same for 1.5. I’ve been busy. I decided to attempt correcting the issues with 1.5 based code using the refactorization used in 1.6. I did some very basic testing and things appear to be working. I did not test normal multicast at all, just the session style MC tasks as that is what I was aware of as being broken.