Unable to Install Kernel 4.17.0

  • 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:, 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.

  • @quazz Got the result:


    Not sure if thats good or bad.

  • Moderator


    grep Tftp /opt/fog/.fogsettings

    I recall you having symlinks or something that got deleted upon update, so maybe you disabled it to prevent that from happening?

  • @tom-elliott said in Unable to Install Kernel 4.17.0:

    Are you by chance bypassing TFTP file recreation?

    Not that I know of, how would I check?

    I am much more likely to believe I did something wrong than you guys, I may have goofed it up at one point and not known it.

    Seems to be working now, Thanks!

  • Senior Developer

    @zer0cool It’s probably some error that I missed. I know I do two things to setup permissions, maybe something got screwed up along the way?

    I looked at the code and it appears to be correct? Are you by chance bypassing TFTP file recreation?

  • @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!

  • Senior Developer

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

  • @tom-elliott Those settings appear correct to me;

    host is proper IP in x.x.x.x format.
    username: fog
    password, as I mentioned matches the same credentials used in the storage node (i only have 1).
    kernel dir is: /var/www/html/fog/service/ipxe/

    From what I can surmise, tftp/ftp is downloading the file, whatever it tries to do with it after that is whats failing.

    Whats it do with the download to “update” the kernel? From the logs/errors it seems its trying to move it and/or create a directory?

    Is it possible its a permissions issue for where the kernel needs to be placed? If so whats the proper ownership/permissions?

    If you have any ideas on logs to check id be happy to dig them up too, Ive checked all the ones I can think of or found researching the issue.

  • Senior Developer

    @zer0cool Me too, and I suspect the problem for your kernel issues lies in the TFTP_FTP information from fog settings, as that’s what’s used for kernel stuff (remnants that I’m afraid to remove from olden 0.32 and earlier days).

    You can try that? Check the TFTP_FTP fields, username/host/password and ensure they’re all correct? Maybe in the near future I’ll have it ask you for a storage node (or all) to set the kernel on, and use the storage node’s information to upload/store the kernels. But right now that’s kind of a long shot.

  • @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.

  • Senior Developer

    @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

  • 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.


    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

  • 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?

  • Senior Developer

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

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

  • Senior Developer

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

  • @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?

  • @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.

  • Moderator

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

  • @quazz

    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.

Log in to reply