Unable to Install Kernel 4.17.0

[Zer0Cool]

FOG 1.5.3
CentOS 7.5

First noticed something odd in that when I click on the Kernel updates entry in the Settings its very slow to load (other aspects of the web GUI load just fine). Once loaded I noticed that 4.17 was available so I selected 4.17 x64 and clicked download, it starts then gives the following error:

Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 708, Message: ftp_put(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone., Host: 10.0.0.2, Username: fog

Seems like a programmatic issue but I am not certain, figured I’d check here.

Worth noting its the same issue with x86 version of the kernel too.

[Zer0Cool]

@tom-elliott I owe you a beer! (or your beverage of choice). Ownership of the ipxe dir resolved it.

I am going to ask a really dumb question now (because the likely answer is I goofed up and dont recall) but why would it have been set to apache:apache as owner (all the way up the tree to like /var/www/html/fog)? Is there anything that FOG does that could have changed that without me knowing (like updating from 1.5.2 to 1.5.3)?

Thanks a million times over, I now leave work and relax thanks to you!

[Quazz]

Seems to be the same problem as experienced here:

https://forums.fogproject.org/topic/12036/centos7-fog-1-5-3-image-capture-fails-with-incorrect-date-timezone-info

[Zer0Cool]

@quazz Interesting, as I had changed the server time to my timezone.

Tried changing back to UTC just via FOG GUI, still had issue

Changed in CentOS 7 using:

timedatectl set-timezone UTC

Still had the same issue.

I am going to do a reboot and see if it works post reboot.

EDIT: So far still have the issue after a reboot. FOG set to UTC, CentOS set to UTC.

Clicking the Kernel Update option in Settings takes about 1 minute to load (vs every other aspect of the web gui loading just as expected, basically instantly) and then trying to update give the error mentioned in OP.

[Zer0Cool]

Actually now the Kernel Update page wont even load. I get the following:

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

So now I do not even get the option to try and download a kernel. Again, just to point out, as far as I know the rest of the server (GUI and otherwise) is perfectly functional.

[Quazz]

@zer0cool What do the apache/php-fpm logs say? (you can see them under log viewer)

[Zer0Cool]

@quazz

PHP-FPM error log (www-error.log)

[08-Jun-2018 13:40:33 UTC] PHP Warning: ftp_mkdir(): Create directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 492
[08-Jun-2018 13:38:24 UTC] PHP Warning: ftp_put(): Could not create file. in /var/www/html/fog/lib/fog/fogftp.class.php on line 708
[08-Jun-2018 13:38:24 UTC] PHP Warning: ftp_rename(): Rename failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 807
[08-Jun-2018 13:38:24 UTC] PHP Warning: ftp_mkdir(): Create directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 492
[06-Jun-2018 16:46:21 UTC] PHP Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 823
[06-Jun-2018 16:15:57 UTC] PHP Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 823
[05-Jun-2018 20:37:57 UTC] PHP Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 823
[05-Jun-2018 20:13:25 UTC] PHP Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 823
[05-Jun-2018 20:12:47 UTC] PHP Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 823
[05-Jun-2018 19:49:23 UTC] PHP Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 823
[05-Jun-2018 14:23:37 UTC] PHP Warning: implode(): Invalid arguments passed in /var/www/html/fog/lib/reports/hosts_and_users.report.php on line 112
[05-Jun-2018 14:23:37 UTC] PHP Warning: implode(): Invalid arguments passed in /var/www/html/fog/lib/reports/hosts_and_users.report.php on line 112
[05-Jun-2018 14:23:37 UTC] PHP Warning: implode(): Invalid arguments passed in /var/www/html/fog/lib/reports/hosts_and_users.report.php on line 112

The Apache log didnt seem to have anything that stood out, but its possible I over looked something so I will keep checking.

[Quazz]

I’m currently also getting Service capacity problems, possibly the external site is having issues. It seems to hit the timeout set by Apache.

[Zer0Cool]

@quazz The Apache log just has a bunch of post and get’s, nothing seems abnormal there.

I was able to once again load the Kernel Update page, which is odd as I havent changed anything since the UTC updates. Still get the same error though when trying to install the kernel

[Quazz]

@zer0cool Can you create a phpinfo page?

Something like

nano /var/www/html/fog/phpinfo.php

<?php
phpinfo();
?>

Save and exit, then navigatie to your fogserver/fog/phpinfo.php

Do ctrl+f ‘timezone’ and tell me what you see in that section.

I’m kind of scratching my head over here, because things are working fine for me, though php reports my timezone being blank.

[Zer0Cool]

@quazz

date
date/time support	enabled
"Olson" Timezone Database Version	0.system
Timezone Database	internal
Default timezone	UTC

date.timezone	no value	no value

Here is what I think you are looking for.

[Quazz]

@zer0cool Very strange indeed, that’s what I have on my end. FOG has no issues with the timezone for me.

I’m using Europe/Brussels [CEST +02:00] though. Maybe there’s certain timezones giving issues?

[Zer0Cool]

@quazz To be honest, and likely completely due to my own ignorance, I am having trouble understanding what relation timezone could possibly have to downloading and installing these kernels.

Also, the kernel update page now seems to load fine for me, but still get the error trying to install. Is it possible this is an issue between FOG 1.5.3 and kernel 4.17.0?

I am a little reluctant to update FOG to 1.5.4 at this time as I just completed extensive testing and some customization and am not ready to redo at a minimum a couple of hours of work to get it back to that point post update. If, however, it was sure that it would fix the issue with the kernel then I would do the update.

[Zer0Cool]

@quazz @Tom-Elliott I noticed now some new entries for kernel 4.17.0 called:

“Kernel - 4.17.0-addbnx TomElliot …”

Whats the addbnx portion mean, I couldnt find any mention of this in a search?

[Tom Elliott]

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

[Zer0Cool]

@tom-elliott Should most of us then use the regularly named kernel?

[Tom Elliott]

@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]

This is really odd. So now the Kernel updates page loads straight away, no problem loading but still gives error trying to install kernels (even new ones with ‘addbnx’ in the name).

I also noticed I no longer get information under Settings | Home | FOG Version Information. It now just says “Failed to get latest info”. This morning and prior it would have information about my version of FOG, current version, and some other related info.

I tried rebooting and the issues persist.

I am also having issues imaging a machine, and am not sure if its somehow related. I imaged 3 identical machines yesterday with my image and snapin, all 3 worked no issue including joining domain, changing hostname and activating Windows, rebooting and running snapin to completion. Today I go to image a 4th identical machine (no changes made to anything FOG/snapin/etc) and it completes deploying the image but then seems to get stuck and either not activate Windows and/or not join the domain (despite all the information being entered for the host in FOG/web gui). It was earlier executing the snapin, but now doesnt do that either.

I have tried re-imaging this machine multiple times today along with deleting and re-registering the host many times. Is this likely related or a different issue?

[Zer0Cool]

Rolling back to a snapshot that was working a day or 2 ago exhibits the same issue. I have went back to my current snapshot/state.

I also noticed the Settings | Home | FOG Version Information is working now. Still have the error with the kernel update however.

I found this thread and tried both solutions, neither resolves my issue.

https://forums.fogproject.org/topic/11375/kernel-update-fails-oh-no-not-again/27

I did for some reason have an extra slash (double) in the path, so I removed it. Had the slash on the end of the path already. Checked the ftp password and storage password and they match, as does the entry in the file mentioned in the thread with the password in it.

I have rebooted, checked other tftp related settings in FOG (and all path fields in general), checked the xferlog file, seems tftp is grabbing the file as far as I can tell.

So I am basically in the same position still. Trying to get this worked out. Any help would be much appreciated, Thanks

[Tom Elliott]

@zer0cool You can directly download and replace the kernels if you’d like.

wget -O /var/www/fog/service/ipxe/bzImage --no-check-certificate https://fogproject.org/kernels/bzImage

wget -O /var/www/fog/service/ipxe/bzImage32 --no-check-certificate https://fogproject.org/kernels/bzImage32

[Zer0Cool]

@tom-elliott I am concerned that left unresolved the issue could affect other, yet unknown aspects of FOG.

Manually replacing the kernel would be a valid short term fix. I would still be very interested in trying to resolve the problem.