SVN BUGS
-
Working. Thanks!
-
A Wake task still requires an image, which honestly it shouldn’t.
-
[quote=“need2, post: 30716, member: 21891”]A Wake task still requires an image, which honestly it shouldn’t.[/quote]
SVN 1880
Removed need of image setting unless task type is specifically an imaging task (Download, Upload, Multicast, etc…)
-
Received a database error from the web GUI schema update while upgrading to SVN 1880 from 1.1.1 . I did not see a specific error, so here is the output:
See attached.
EDIT: So now I’m stuck in a limbo of sorts. I can’t get past the schema update. I’ll keep fiddling.
When the following is entered manually:
[CODE]Update ID: 1 - 10Database Error:
Database SQL:
INSERT INTO
fog.usersVALUES (‘’,‘fog’, MD5(‘password’),‘0000-00-00 00:00:00’,‘’)[/CODE]I get:
[CODE]Column count doesn’t match value count at row 1[/CODE]
[url=“/_imported_xf_attachments/1/1023_schema_output.txt?:”]schema_output.txt[/url]
-
You restarted mysql service?
-
Yes, that did not do anything for it. There appears to be either a problem with a table or a command being fed to that table.
-
Is this still occurring?
-
Yes, I still can’t get past the schema update step.
-
Okay,
Do me a favor, check your error logs for mysql.
In ubuntu (centos doesn’t have them that I’ve seen) it’s under:
/var/log/mysql/mysql.err or something liek that.Can you try these steps in conjunction with a reinstall? It sounds like mysql just isn’t running.
[url]https://github.com/mastacontrola/fogproject/issues/1[/url] -
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=“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.
