SOLVED Bugs in FOG 0.33

  • I see this issue and will work to correct it. I still see a report though, but maybe it’s the selections you’re choosing causing no display of report.

  • Developer

    imaging reports seemed to be broken (for me anyway) using latest svn, when option to set dates (start and end) i’m given the options of 1 to 3 and then two blank rather than actual dates and no matter what is set, no image tasks are shown in the report

  • Ok. Seems to be working good now. Thanks!

  • yes, but try
    [php]print “exit\n”;[/php]

  • @Tom - I’m looking in the boot.php file, and I see a line under “if ($option == ‘fog.local’)”

    It says: print “sanboot --no-describe --drive 0x80\n”;

    What should I be putting in it’s place? print “exit”; <–??

  • Developer

    we had this issue on a fair few dell models and setting up chain loading fixed it so i believe ipxe should do the trick! if not:


  • I’m going to PM you as a test for these troubled systems.

    The quickest thing I could think from iPXE though is to simply put the exit statement in place of the sanboot statement under the if ($option == ‘fog.local’) line. This should force it to exit ipxe and boot to the next device in line (bring it back to bios.)

  • I’ll try a workaround. We only have 3 790’s out of 180 anyway, so it’s not that big of an issue. Just let me know what I need to do.

  • I’ve been seeing this issue on and off again. Would you be willing to try the workaround fix for this issue through ipxe? I ask because, as you state, this isn’t really a big with fog but more a bug with the particular bios usually from dells.

  • So, I don’t know if this is a bug or not, but I just came across an interesting issue when the PXE menu comes up on Dell Optiplex 790 machines. I have PXE set to default to the HD after 3 seconds (I think that is standard), but when the 790 model tries to boot to the HD, it just reboots, thus and endless reboot cycle ensues… The odd thing is, the 780 and 7010 (older and newer model) boots to the HD just fine. I’ve also confirmed that all have the most updated BIOS and all have the same mobo settings, with regards to boot/HD options.

    Any ideas?

  • It could also be based on the info on the date of the file/directory itself, rather than stored in the db!

  • @falko - Do you have any sort of guide on how to have FOG update bginfo. We currently have to do this manually, and it would be so helpful to have it automated! Right now, we run bginfo, update the date and image name, then have a small batch that uses mini irfanview to change from bmp to jpg, then copies to the oobe folder for the lock screen. (this is for Win7).

  • While I don’t mind the suggestions, I would prefer if you refrain from using the word “missing” when requesting a “New Feature” as missing, at least in my eye’s, implies it was there to begin with, but then was removed. Once again, it will require a schema update, but ultimately you could actually use the “imaging” log to check when an image was uploaded/deployed last.

  • Another missing feature is a date when an image was last uploaded: (red font) [url][/url]

  • Moderator

    Whilst I think it would be good for deploy date, that still leaves the issue of having to find what image version you deployed. Of course maybe each deploy date could have the image version with it.
    For this (and other benefits) I have bginfo installed (connected to sql, and then MS Access for reporting) and have a reg key that bginfo picks up. The reg key gets updated to corresponde with the fog image it will become once uploaded

  • This isn’t really a bug, but a request. That’s okay though. It will require a minor schema change, but I have to do so anyway to enable shutdown to work with iPXE.

  • The deploy date in host management, as proposed/discussed here some days ago. Here is an example of how I think this could be (in red font): [url][/url]

    This way it is really easy to find “old” hosts which I have to get to my office for imaging.

  • Sorry I forgot to mention I refer to 0.33 beta…

  • Developer

    That is because FOG 0.32 is sorely outdated and was meant to run on the older versions of linux. Since then newer and updated packages are being used in the later distributions. Tom is working on FOG 0.33b and I’m sure when all is said and done he will iron out the issues with htmldocs and clamav by updating the repositories and versions it uses/installs.

    In the mean time please use the work arounds found on the forum to install and configure the services.

    Tom started working on FOG here recently he wasn’t always the maintainer so he doesn’t have access to edit the old FOG 0.32 files and NOR should he.

  • Could there be some kind of option during the installation wether to choose clamav and htmldocs or not? Installing these packages on Redhat/Centos needs editing in the config file as it will not work out of the box.