SVN BUGS
-
[quote=“need2, post: 30856, member: 21891”]As far as I can tell, MySQL is running. It just doesn’t like some part of the schema update. The .log and .err files appear to be empty when viewed by nano. I also did a partial uninstall (deleted everything except my DB and images) and reinstall, and still got stuck on the schema update.
I have now reverted back to 1.1.1, and everything is working normally, but I cannot test the fixes introduced in the newer revisions.[/quote]
So it’s quite possibly a bug I entered, but that doesn’t sound right that “reverting back” fixed the problem. How did you revert back? Just download and re-run installer? or Did you just place backup sql dump?
-
Since the database never appears to have been successfully modified by the installer, I just reran the 1.1.1 installer after deleting all of the FOG pieces except images and the database.
-
I also received the same SQL error(s) when installing SVN 1880. Using fresh installs of the fog, when it prompts for Install/Update SQL data base, it always fails with 20/30 different sql fails (a cascading fail). It fails even with a database upgrade.
I am seeing a lot of warnings like this in my httpd/error_log.
[CODE]PHP Warning: mysqli::escape_string(): Couldn’t fetch mysqli in /var/www/html/fog/lib/db/MySQL.class.php on line 247[/CODE]
There are allot of references to MySQL.class.php in the error_log.
[CODE] PHP Warning: MySQL::sqlerror(): Couldn’t fetch mysqli in /var/www/html/fog/lib/db/MySQL.class.php on line 180, referer: http://192.168.1.4/fog/commons/schemaupdater/index.php[/CODE]Nothing out of the ordinary in mysqld logs.
-
Found and hopefully fixed in 1882, thanks for reporting.
-
Thanks Tom. Your not going to believe this, the timezone thing is back. I’m seeing this over and over in the logs;
[CODE][Thu Jun 19 18:24:11.832481 2014] [:error] [pid 26346] [client 192.168.1.4:38335] PHP Warning: date_default_timezone_get(): 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. in /var/www/html/fog/commons/system.php on line 26, referer: http://192.168.1.4/fog/commons/schemaupdater/index.php[/CODE] -
1884 released.
Trying another approach to default setting timezone.
We’re going to force it to UTC so logs don’t complain. -
I wonder if we shouldn’t complain the PHP maintainers. A warning like that should not get dumped into logs unless verbosity is really high. Besides, which is more ‘dangerous’. Trusting the system’s timezone with or date_default_timezone_get() or forcing a programmer to fix it to UTC just to avoid an overzealous warning?
-
Currently you can create a host with a MAC address of invalid length (you can type just anything into the field). It’s saved as hostID 0 with a blank MAC address, and doesn’t show up on the host list for modification/deletion.
-
Thanks I’ll take a look
-
[quote=“xvierc, post: 31003, member: 24383”]Currently you can create a host with a MAC address of invalid length (you can type just anything into the field). It’s saved as hostID 0 with a blank MAC address, and doesn’t show up on the host list for modification/deletion.[/quote]
1896 should have this fixed. Thank you much and sorry about the hassle this could’ve caused.
-
Disk Surface Test does not leave its console open on the host for your to see the results nor does it report back to the server at any place I could find.
-
Hi,
[quote=“need2, post: 30839, member: 21891”]Yes, I still can’t get past the schema update step.[/quote]
i think i have a similar problem:
[url]http://fogproject.org/forum/threads/german-translation-from-0-32-does-not-appear-in-dropdown.11115/#post-32899[/url]Regards X23
-
That is unrelated to my issue, which was fixed quite a while ago by Tom. If you don’t need your DB or settings, I would suggest doing a full wipe of your FOG install, followed by a reinstall. There is a bad DB password entry that gets left in a settings file, I just can’t recall what file it is right now.
