Bugs in FOG 0.33
-
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.
-
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’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.)
-
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:
[url]http://fogproject.org/forum/threads/dell-bootloop-chainloader-problem.4147/#post-11373[/url]
-
@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”; <–??
-
yes, but try
[php]print “exit\n”;[/php] -
Ok. Seems to be working good now. Thanks!
-
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
-
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?
