SOLVED Bugs in FOG 0.33

  • Developer

    link added to footer directs to wrong location
    instead of

  • Developer

    makes sense to me. thanks

  • I’m going to push this fix, but with one minor mod.

    Instead of assigning the advanced variable, why not just print the variable setting itself?

    e.g. instead of:
    [code]$advanced = $FOGCore->getSetting(‘FOG_PXE_ADVANCED’);
    print “#!ipxe\n”;
    print $advanced;[/code]

    have this:
    [code]print “#!ipxe\n”
    print $FOGCore->getSetting(‘FOG_PXE_ADVANCED’);[/code]

  • Developer

    advanced menu stopped working. looks like it happened when code was moved from to BootMenuClass.php
    changing advanced.php code from
    header(“Content-type: text/plain”);
    print “#!ipxe\n”;
    print $advanced;
    [/CODE] to
    header(“Content-type: text/plain”);
    $advanced = $FOGCore->getSetting(‘FOG_PXE_ADVANCED’);
    print “#!ipxe\n”;
    print $advanced;
    [/CODE] makes it work again

  • That should be a bug persay. It pulls the data from the StorageNode Path.

  • Developer

    latest svn version typo under image management image path shows /images/images just need to remove the second images from path

  • WOOT! 😄

  • lol.

    I see the issue and it is a …confirmed bug. Looking into as we speak. In the midst of this, I found another bug, so I’ve also released r1280 to correct that bug.

    Thank you,

  • I couldn’t tell you… I don’t mess with the database stuff.
    I’m like a bull in the proverbial “China Shop”. Next thing I know, the database gets deleted…

    …Not really, but I’m feeling froggy today! o_O

    Here’s a lesson kids… Don’t drink and image!

    BTW Tom, you have a quick tutorial on how to “examine” my database?

  • Yep, that’s kind of a bug, but not really.

    If you look at your database, what does it show?

  • 😞

    … but what about the double “\” part? It get’s the domain and username part right, it just adds an extra \

  • It’s not a bug, persay, I just have to figure out why it’s storing the escaped sequence as the database value.

  • Ok! I’m pretty sure I found a bug this time! 😉

    If I go into Group Management and update the AD settings for a group, and save them, the settings default back to showing previous AD info. (I feel like I read somewhere, this was already known…) BUT… The new buggy thing I found, was after updating this, I noticed that the settings I entered are showing up for the individual members of the group, and under the username section, it’s showing up like this: intranet\admin <-- (given that your domain is called “intranet” and the user is “admin”) I’m just pointing out the double “\” part.

    Come on Tom, tell me it’s a bug! I’m really trying to help out!! 😄

  • WooHoo! 😄

  • No, after, I found out about it this weekend.

  • I’m currently on build 1237. I’m going to update as soon as I get done pulling an image. Was this fixed before that build?

  • Try updating and retry the tasking. I noticed the “looping of no active tasks found” earlier and I believe it was due to the service files still trying to remove the “PXE” file which of course no longer exists.

  • Yes. The same thing happens. I pulled an image yesterday afternoon, and when I got to work this morning, the machine still hadn’t booted to Windows yet. It was stuck in the same “no tasks for this machine” loop.

  • It doesn’t sound like an iPXE or System issue.

    This sounds more like your database was locked at the time between the end of the tasking and the system rebooting. Can you try again and see if the same issue happens?

  • I just came across another issue. I just pulled a sysprepped Win7 64-bit image, and once the image pull was complete, the system rebooted and went back into iPXE, but instead of defaulting to the hard drive like it should, it started loading like it would if there was a task for the machine. Then, a message kept repeating, saying There are no tasks for the machine. Once I held down the power button for a hard shutdown and restarted, it was like a normal reboot. Any ideas?