Best posts made by glefebvr

I think I found the issue :

The problem is in the function “getAllMulticastTasks” in the “MulticastTask.class.php” and with that precise line

if (in_array($FOGCore->resolveHostname($Image->getStorageGroup()->getOptimalStorageNode()->get('ip')),$FOGCore->getIPAddress())) {

It means that if the IP Address of the node on which the FOGMulticastManager is running, is the same as an “optimal” IP address of any storage node of the same storage group, then the task will be created (stateID change from 0 to 1, my bad !).

Then problem with this, is the assumption that any node in the storage group can do Multi-Cast. This is not true, because some nodes of a same storage group could be on different subnets and in many companies (as the one where I work) multi-cast is not routed.

In my particular configuration, I use the storage node concept of FOG to circumvent the Multicast routing limitation. It was working like this in 0.32 and I expected that it worked the same in trunk.

Here is my solution (not yet tested for deployment, but the multicast task shows up correctly) :

if (in_array($FOGCore->resolveHostname($Image->getStorageGroup()->getMasterStorageNode()->get('ip')),$FOGCore->getIPAddress())) {

Would it be possible to implement either that solution directly (don’t know the implications) or at least to have an option saying "I want only my master node to do multicast) ?

Dear developpers,

I’m currently using FOG from the SVN, updating it from time to time in order to get bug fixes and new features. And I’m very pleased that this project has been reactivated in that way since 1 year and a half.

But now I’m concerned about the future of FOG. I have been checking here and there on the wiki, the forum and the news to check what are the plans of the developper team for the future, but without much success. I’ve seen talking about a new version named “fog-too”, but with no informations about what it is and what the roadmap is ?

So, here are my main questions. Would it be possible to know :

• What is the roadmap for current SVN branch (1.3). Will it be frozen one time ? Is it going to stay a dev branch ? What are the plans ? And do you have any timing for it ?

• Concerning “FOG-too” : what is this version supposed to be ? I saw that it is a complete rewrite of FOG, but in what aim ? Wasn’t FOG 1.00 a complete rewrite too ? What will be its features ? Any roadmap ?

• Would it be possible to do a sticky topic in the forum or a page on the wiki about roadmaps, timelines and the future of FOG ?

Thanks in advance for your answer !

Guillaume

Server

• Version: 1.3.0-RC-8
• OS: Debian Wheezy

Description

Issue 1 :
I changed the “Boot Key Sequence” in FOG settings to “Ctrl + N”. When I net boot on legacy systems, I indeed need to press Ctrl + N to enter the boot menu, but when I net boot on UEFI systems, I still need to press ESC to enter the boot menu.

Issue 2 :
With the setting “Exit to Hard Drive Type(EFI)” set to “REFIND_EFI”, when net booting a UEFI system without any user intervention, I have the following rEFInd message :
“NOTE: refind.conf’s scanfor line specifies scanning for one or more legacy (BIOS) boot options; […]
Hit any key to continue”
And the system is indeed waiting for user intervention, which I doesn’t want. I noticed that the rEFInd scanfor parameter is set to “scanfor internal,hdbios,external,biosexternal”. When I modify this parameter to “scanfor internal”, it just works flawlessly and boots right away to the internal disk. So two questions :

• In UEFI mode, is it necessary to try next boot on legacy devices ?
• Is it possible to have an option to handle UEFI with or without legacy support in FOG, option which could modify that file ?

Thank you

@Tom-Elliott Yes, this log is just informative, in case you wanted to have a look.

I confirm that snapins now work (1.3.0 working-RC-11, version 39)