Bugs in FOG 1.0.0
-
Whether in virtual or physical machine, this problem appears in a unpredictable way:
[URL=‘http://pix.toile-libre.org/?img=1400057772.png’][IMG]http://pix.toile-libre.org/upload/thumb/1400057772.png[/IMG][/URL]I don’t understand how to solve this issue with that : [url]http://ipxe.org/err/040ee1[/url]
My report about the init scripts is refused ?
[B]---- FOG SVN INFO[/B]
[CODE]Chemin : .
URL : http://svn.code.sf.net/p/freeghost/code/trunk
Racine du dépôt : http://svn.code.sf.net/p/freeghost/code
UUID du dépôt : 71f96598-fa45-0410-b640-bcd6f8691b32
Révision : 1687
Type de nœud : répertoire
Tâche programmée : normale
Auteur de la dernière modification : masterzune
Révision de la dernière modification : 1687
Date de la dernière modification: 2014-05-14 03:43:19 +0200 (mer. 14 mai 2014)[/CODE] -
[quote=“aruhuno, post: 27060, member: 105”]Whether in virtual or physical machine, this problem appears in a unpredictable way:
[URL=‘http://pix.toile-libre.org/?img=1400057772.png’][IMG]http://pix.toile-libre.org/upload/thumb/1400057772.png[/IMG][/URL]I don’t understand how to solve this issue with that : [url]http://ipxe.org/err/040ee1[/url]
My report about the init scripts is refused ?
[B]---- FOG SVN INFO[/B]
[CODE]Chemin : .
URL : http://svn.code.sf.net/p/freeghost/code/trunk
Racine du dépôt : http://svn.code.sf.net/p/freeghost/code
UUID du dépôt : 71f96598-fa45-0410-b640-bcd6f8691b32
Révision : 1687
Type de nœud : répertoire
Tâche programmée : normale
Auteur de la dernière modification : masterzune
Révision de la dernière modification : 1687
Date de la dernière modification: 2014-05-14 03:43:19 +0200 (mer. 14 mai 2014)[/CODE][/quote]Your report about the init scripts is not “refused” just not an issue. Things are still working as you described earlier, therefore there’s not likely to be any change within them. Unless they’re causing issues with the services starting, nobody else has described this issue besides you. I don’t want to make a change that’s not hurting anybody else for one person’s issues.
In regards to your network issue as described, have you tried powering down the system and powering back up? If you do this is the problem still present?
I ask because I’m aware of a few quirks in iPXE and configuring network devices. For the most part, they all work fine, but there are a few times where this issue pops up. This is especially pertinent within VirtualBox Virtual Machines, which from what I can tell is a bug in VirtualBox, not a bug in iPXE. I’ve heard of this occurring on a few physical machines, and once again they seem to go away if the system is powered down, then powered back up. This could be a simple fix for physical machines by booting into windows and disabling the LAN Link Speed option to disabled.
-
[quote=“Tom Elliott, post: 27062, member: 7271”]Your report about the init scripts is not “refused” just not an issue. Things are still working as you described earlier, therefore there’s not likely to be any change within them. Unless they’re causing issues with the services starting, nobody else has described this issue besides you. I don’t want to make a change that’s not hurting anybody else for one person’s issues.[/quote]
Ok but using LSB tag is a best practice on Debian (all others scripts have them!).In fact, update-rc.d need LSB tags but sysv-rc-conf don’t. So, when you install the init scripts, prefer use this command :
[CODE]update-rc.d FOGImageReplicator defaults
update-rc.d FOGMulticastManager defaults
update-rc.d FOGScheduler defaults[/CODE]
Now, you need to use LSB tags and you are compliant with Ubuntu and Debian!
You can use [URL=‘https://wiki.debian.org/LSBInitScripts’]this documentation[/URL] from Debian website.[quote=“Tom Elliott, post: 27062, member: 7271”]In regards to your network issue as described, have you tried powering down the system and powering back up? If you do this is the problem still present?[/quote]
Apparently, VirtualBox make most often this issue.
For physical, it’s an report by users of my compagny and I see that only two times. If it reproduce, I would try your fix, thanks!FOG installs by default mysql while he can be used with Oracle…
-
I had posted this in a new thread for Fog 1.0.1 bugs, but I figured it might get more attention in here and that other thread might be redundant for bug reports anyway, so I’ll go delete it.
I just updated to the latest trunk (1696) with my update script ([url]http://fogproject.org/forum/threads/automating-fog-0-33b-svn-updates-in-ubuntu-14-04-with-cron-easily-adapted-to-other-linux-distros.10409/#post-26438[/url]) that has been working just fine for the last 2 weeks. It did update to the first release of 1.0.1 just fine, but I was getting a TFTP can’t find the file error so I figured I could just try updating it to the latest release in case that fixed it. But now all of a sudden I can’t get to the fog management web page and still get the TFTP error when I try to get into the PXE boot. When I try to go to the FOG management webpage all I get is an that says “Content Encoding Error” in firefox and [COLOR=#000000]“[FONT=Helvetica]ERR_CONTENT_DECODING_FAILED” in chrome.[/FONT][/COLOR]
So, in summary, even though all my settings are as they’ve been with everything working perfectly (I’ve double checked this) I suddenly have this content encoding error. According to what I’ve found on the web it probably has something to do with gzip encoding something something.
Any thoughts?
Thanks,
-JJ -
If you see this:
Edit /var/www/{FOGWEB}/management/index.php
Change the line that says:
[code]ob_start(‘ob_gzhandler’);[/code]
to:
[code]ob_start();[/code] -
I found that and changed it but it’s still broken
Any other thoughts? -
I downgraded to the official release of 1.0.1 and I was still having the same problem.
So I tried again doing an install without my script and re-editing and moving the files. According to the error I found in the apache error.log it had to do with not connecting to the database. I believe that the line in my script
“wget -O - --post-data=“confirm=yes” “[url]http://{FOGWEBIP}/commons/schemaupdater/index.php[/url]” 2>/dev/null”
was the problem. It’s the only thing I didn’t do. I also made a symlink from /var/www/fog to /var/www/html/fog instead of moving the folder to satisfy the ubuntu 14.04 webroot.Thanks for the help.
-JJ -
I figure I should mention this. I’m not sure if this was on purpose to encourage a better default password or not, but in the /var/www/fog/commons/config.php there was a password in the ftp and tftp password field that looked like it was left in by accident perhaps. I recall before the default was either blank or “password”
Thanks,
-JJ -
There’s always a password for the ftp and tftp password. The password you’re seeing in those fields is set at install time and should be the first 6 characters of the hash that’s generated.
-
In 1.0.1 Fog requires a Host to have an image associated in order to perform a WOL task.
-
Please lock thread when you all have time.
Thank you,
-
Locked
