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.
-
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?
-
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?
-
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.
-
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.
-
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?
-
No, after, I found out about it this weekend.
-
WooHoo!
-
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!!
-
It’s not a bug, persay, I just have to figure out why it’s storing the escaped sequence as the database value.
-
… but what about the double “\” part? It get’s the domain and username part right, it just adds an extra \
-
Yep, that’s kind of a bug, but not really.
If you look at your database, what does it show?
-
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?
-
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,
-
WOOT!
-
latest svn version typo under image management image path shows /images/images just need to remove the second images from path
[IMG]http://s12.postimg.org/84riji5nx/typo.jpg[/IMG] -
That should be a bug persay. It pulls the data from the StorageNode Path.
-
advanced menu stopped working. looks like it happened when code was moved from base.inc.php to BootMenuClass.php
changing advanced.php code from
[CODE]<?php
header(“Content-type: text/plain”);
require_once(‘…/…/commons/base.inc.php’);
print “#!ipxe\n”;
print $advanced;
?>
[/CODE] to
[CODE]<?php
header(“Content-type: text/plain”);
require_once(‘…/…/commons/base.inc.php’);
$advanced = $FOGCore->getSetting(‘FOG_PXE_ADVANCED’);
print “#!ipxe\n”;
print $advanced;
?>
[/CODE] makes it work again -
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] -
makes sense to me. thanks
