PHP error Uncaught Exception: DateTimeZone
-
@Sebastian-Roth
I tried that also
Cleaning setup- delete /etc/httpd/conf.d/fog
- rm -rf /var/www/html/fog
- rm -rf /opt/fog/
- fully delete mysql (lke explained before)
restart install
- cd /opt/fogGit/
- git pull
- cd bin
- ./installfog.sh
I don’ think I’m missing something.
-
@kortnor On my system I was not able to fully remove the mariadb/mysql packages because mariadb/mysql-libs is needed by some very important system packages. So I am wondering if you somehow managed to install mysql-libs and are not able to get rid of it anymore?
rpm -qa | grep -e mysql -e mariadb
(just a wild guess) -
@Tom-Elliott
also, After deleting the whole opt/fog directory I suppose the install script reacts like it will be a new installation ==> so creating the folder again.Now what I’ve done is:
- yum remove mariadb*
- check 2 time if there is no mysql pkg wih ==> yum list installed | grep mysql
make a new installation again.
Now I arrived to the fog webui
for your info the script has installed the following mysql package
mysql.x86_64 5.5.48-1.el6.remi @remi
mysql-libs.x86_64 5.5.48-1.el6.remi @remi
mysql-server.x86_64 5.5.48-1.el6.remi @reminow, because mysql is replaced by mariadb , will there be any changed applied to the script when its run to centos 7 or rhel 7 ?
Best,
-
@kortnor Try running the following commands on your system. Here is what they show on my system (as well CentOS 7 fresh install but installs mariadb):
$ dnf list --enablerepo=remi mysql Using metadata from Tue Mar 15 19:11:26 2016 Available Packages mariadb.x86_64 1:5.5.44-2.el7.centos base $ yum --enablerepo=remi list mysql ... Error: No matching Packages to list $ yum --enablerepo=remi list mariadb ... Available Packages mariadb.x86_64 1:5.5.44-2.el7.centos base
I am wondering why you have mysql el6 packages installed…?!?
-
@Sebastian-Roth
hereunder the result of the requested command line[root@fog ~]# yum --enablerepo=remi list mysql Loaded plugins: fastestmirror, replace Loading mirror speeds from cached hostfile * base: ftp.belnet.be * epel: ftp.nluug.nl * extras: miroir.univ-paris13.fr * remi: mirror5.layerjet.com * remi-php70: mirror5.layerjet.com * remi-safe: mirror5.layerjet.com * rpmforge: ftp.nluug.nl * updates: miroir.univ-paris13.fr Installed Packages mysql.x86_64 5.5.48-1.el6.remi @remi [root@fog ~]# yum --enablerepo=remi list mariadb Loaded plugins: fastestmirror, replace Loading mirror speeds from cached hostfile * base: ftp.belnet.be * epel: ftp.nluug.nl * extras: miroir.univ-paris13.fr * remi: mirror5.layerjet.com * remi-php70: mirror5.layerjet.com * remi-safe: mirror5.layerjet.com * rpmforge: ftp.nluug.nl * updates: miroir.univ-paris13.fr Available Packages mariadb.x86_64 1:5.5.44-2.el7.centos base
-
@Sebastian-Roth
i’m using the following package[root@fog ~]# rpm -qa | grep -e mysql -e mariadb mysql-5.5.48-1.el6.remi.x86_64 mysql-libs-5.5.48-1.el6.remi.x86_64 php-mysqlnd-7.0.4-1.el7.remi.x86_64 mysql-server-5.5.48-1.el6.remi.x86_64
But i can’t use mariadb also and that’s a major threat for me:
everytime I restart my server host, I need to create the /var/run/mysqld /; touch /var/run/mysqld.pid ; chown -R mysql:mysql /var/run/mysqld
otherwise mysql won’t start -
@kortnor Ahhhh… the “old” mysql package is still newer than the mariadb package (5.5.48 vs 5.5.44). Therefore yum prefers to install the EL6 mysql version instead of using EL7 mariadb.
yum remove remi-release-6 rpm -Uvh http://rpms.remirepo.net/enterprise/remi-release-7.rpm yum -y update yum --enablerepo=remi list mysql
-
@Sebastian-Roth
that’s really interresting, I’ll create a fresh new vm ( aside the my running one, ) and try what’s you’re proposing, I should do that for thursday eveningIn the meantime, I need to learn how to fine tune the images because at the end I would like to apply it on a cluser created with 6 intel nuc.
On each nuc, I’ll push my images but after every nuc needs to be configurer with a static ip ( for sure different for everyone ) -
@kortnor The datetimezone issue should be fixed in the latest update. I wasn’t implicitly defining a Timezone, so it would not find any data in the case of a fresh install.
I found two places that I could use to ensure the timezone is set (albeit not necessarily accurate) in the case the DB hasn’t been loaded yet (fresh install), the php.ini file does not have a date.timezone specified (php defaults to commenting the timezone out). The fix, for now, is test the presence of the variable by means of checking if it’s empty or not.
Mind you if the php.ini file IS set with the date timezone setting, it will NOT try to use the one defined in the DB anyway. However, if you aren’t comfortable messing in /etc/php.ini, the current push of FOG should take over and operate as originally expected (no more 500 heres or erroneous error messages.)
-
@kortnor I am marking this solved as the initial OP is now properly handled, thanks Tom!!
Probably best if you start a new topic if you run into another problem. I am sure we’ll be able to help you fix it as well!