Posts made by zacadams

@sebastian-roth the campus has multiple DHCP servers so I am not completely sure, but we use Infoblox as a means of applying settings across networks.

@george1421 I have not yet, unfortunately my office flooded last week so I am just now getting back in. I will attempt to get it today.

@hammett131 the problem occurs when downloading the image from the fog server.

@hammett131 said in UEFI PXE not downloading ipxe.efi file:

@zacadams I have had a few issues with ipxe.efi file boot a couple options I have found one @george1421 already mentioned updating the bios helped but I also legacy booted with an undionly.kpxe and then have it download the uefi image then before it tries to boot into windows change back to uefi. I know it’s alittle annoying but it did work for those that even when I updated the bios was having an issue. (and where I work quick turn around is more important then spending along time on imaging)

So you are saying I should try to boot with undionly.kpxe in UEFI?

I am trying to UEFI PXE boot an Optiplex 7010 and have already changed the boot file from undionly.kpxe to ipxe.efi in the DHCP sever settings. When booted the machine shows:

Start PXE over IPv4.
Station IP address is 129.120.251.101
Server IP address is 129.120.123.171
NBP filename is ipxe.efi*
NBP filesize is 0 Bytes
PXE-E23:Client received TFTP error from server.

I have ran a tcpdump on ports 67,68,69, and 4011 from the FOG server and have included that on this post and have successfully been able to do a TFTP get on the ipxe.efi file from my own machine. Any ideas on what is going on?

@sebastian-roth ok after fixing my error to the multicasttask.class.php I ran the 3 tests you suggested

• do not turn off any of the clients to see if it still is reliable

• pull the network cable of one of the clients while multicast is on for 5 seconds - see if that is enough for it to be dropped already

• turn off one of the clients while multicasting and see how long it takes for it to drop

During the first test, multicast worked normally and the new argument added to multicasttask.class.php was reflecting in the logs. During the second test pulling the network cable did not appear to drop the disconnected host, but upon plugging the network cable back in the session returned to normal speeds. During the last lest of powering a client off during a session, the multicast session came to a near halt and is only transferring at around 100 MBpm. I’ve left the session going all night and the session is still active and moving at the throttled pace.

Oh lord I see what I may have done wrong, I need to remove the retries. Let me try this again this morning.

@sebastian-roth to line 421 I have changed to:

$buildcmd = array(
            UDPSENDERPATH,
            (
                $this->getBitrate() ?
                sprintf(' --max-bitrate %s', $this->getBitrate()) :
                null
            ),
            (
                $this->getInterface() ?
                sprintf(' --interface %s', $this->getInterface()) :
                null
            ),
            sprintf(
                ' --min-receivers %d',
                (
                    $this->getClientCount() ?
                    $this->getClientCount():
                    self::getClass('HostManager')->count()
                )
            ),
            sprintf(' --max-wait %s', '%d'),
            (
                $address ?
                sprintf(' --mcast-data-address %s', $address) :
                null
            ),
            (
                $multicastrdv ?
                sprintf(' --mcast-rdv-address %s', $multicastrdv) :
                null
            ),
            sprintf(' --portbase %s', $this->getPortBase()),
            sprintf(' %s', $duplex),
            ' --ttl 32',
            ' --nokbd',
            ' --nopointopoint',
            ' --retries-until-drop retries 100',
        );

This has been done to the main fog server and the fog storage node that will be performing the multicast session. The udp-sendercalls did look different in the logs as well.

@sebastian-roth that did not appear to do anything.

@sebastian-roth I apologize again they have had me bouncing around all last week so I haven’t had a change to test the
–retries-until-drop option yet. I’ll report back this morning about what I find.

@sebastian-roth sorry for the delayed response. We are currently running FOG 1.5.0

@Sebastian-Roth where will I need to apply these options? I went to 420 on multicasttask.class.php but it was the end of a block?

@sebastian-roth @george1421 Thank you for the input I’m gonna look into it tomorrow and then follow up here

I am testing the multicast capabilities of Fog and the handling of a host that is disconnected during a multicast session. In our organization users will sometimes walk into a room and power off a machine that is currently being imaged (no matter what we tell them or what dialogue is present on the machine during an imaging session) in a Ghost Multicast session. When this happens we are able to see in the Ghost console that the specific host has disconnected and can assign a unicast or another multicast session to it.

I recently tested this event in Fog and has some questions on how it was handled. During the power off of a host in a multicast session the rest of the hosts still connected to the session experienced a severe drop in speed. I understand the drop in speed is how the system was designed but the disconnected host stayed in the task list and never notified the fog server it had disconnected and none of the other hosts returned to their previous imaging speed.

Was this a bug, feature, or am I missing a setting here?

The other question I am having is when the host is powered back on and the multicast session is still in the task list, the host will boot into Partclone and perpetually waits for the multicast session to start although the multicast session already in progress.

Should the host eventually time out and leave the session and report back to the WebUI that the session has failed?

@tom-elliott That is the one I have been using, the passwords were correct on the fog storage node as well.

I was able to resolve the issue:

One of the problems was that the multicast interface was set to the interface of the main fog sever (a vm running on ens192 interface) to the interface of what my storage nodes would be (physical machines on eno1 interfaces).

The other issue was the MySQL table on the main fog server being not accessible by remote storage nodes.
I could image from the remote storage nodes but the nodes themselves always had shown “A valid database connection could not be made” on the dashboard. The fix for this could be found here under the “Enable remote mysql access” section, granting remote users all privileges.

@tom-elliott in this particular scenario the host is trying to communicate with the “remote” fog storage node, which is now a master node in it’s own storage group, and is on the same network as the host.

@tom-elliott the log currently is showing:

/var/log/fog/multicast.log
[03-26-18 12:17:58 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:18:08 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:18:18 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:18:28 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:18:38 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:18:48 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:18:58 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:19:08 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:19:18 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:19:28 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:19:38 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:19:48 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:19:58 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:20:08 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:20:18 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:20:28 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:20:39 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:20:49 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:20:59 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:21:09 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.```

@tom-elliott I am currently using 1.5.0, I tried using a configuration similar to @Wayne-Workman’s suggestion and the host just seems to stay at the multicast initialization screen but the session never starts.

@wayne-workman said in Multi-cast with Location plugin enabled:

To keep replication of images & snapins working, you’ll have to do cross-group sharing at the image level, you’d do that in image management on each individual image & each individual snapin.

I am having trouble finding this setting in image management, would you be able to illuminate me to where I could find this?