@christop Roger, sorry I’ve been doing a lot of programming in python lately and introduced “int(…)” which isn’t valid PHP syntax. This is corrected in the latest, please pull/install and let me know if it helps?

Thank you for letting me know.

@AUTH-IT-Center Sorry I hadn’t seen this, glad this is fixed now.

@Fog_Newb This should be fixed in the latest dev-branch please let me know if it’s not.

Thank you!

@christop Also, another output for informatoin would be:

sudo systemctl -l status FOGMulticastManager.servcie

Now I’m not saying this isn’t a feature that will (or will not) be added. I am not a C# programmer and wouldn’t really know how to start doing this.

That said, even if we did add this feature, you’d still need to disable the service for sysprep so that when the machine does boot you don’t have an issue.

Since you have to disable the service anyway, I’m not sure it’s worth the effort to put in a “stop” feature into the client.

Could even OOBE sysprep load/startup mode potentially be detected? Possibly, but why would we put that much into the FOG Client when it’s just as easy to disable to service when doing configuration stuff such as you’re doing?

@AlexisPHC Sure, it might be possible to do this, but you can just disable the service from actively running, which is actually suggested anyway?

Install the service (while totally disconnected from the FOG Server.)

Set the service to a disabled state.

Load machine into “Audit Mode” Do work…

This would be independent of dedicated hardware or anything like that.

https://wiki.fogproject.org/wiki/index.php/FOG_Client#FOG_Client_with_Sysprep

@AlexisPHC The FOG client has no knowledge that the machine is in audit mode. All other normal services for audit mode still run similarly. (Not just FOG Client related, but networking, Antivirus, etc… etc…)

Now what we normally have people do when building their “golden” image is basically turn off Domain joining or disable any items for the machine. That or just ensure the machine you’re working on isn’t registered to the FOG server until you’re ready to capture the image.

This baseline machine should only be used for “golden image” creation and shouldn’t have any direct relationship to the FOG server until you’re ready to capture and deploy to that machine (after all your configurations are completed.)

I just want to be clear your expectation of “Well the fog client should know that the machine is in audit mode and not do actions it would normally do otherwise” doesn’t really make much sense in the context of programming. Or machines. All the FOG Client knows is “I’m supposed to do x, y, and z actions, I’m going to do x, y, and z actions”.

All of these things can be enabled/disabled in the FOG UI as well, so if you’re really wanting it to do these things, you should disable the items you don’t want happening there if you really much use a machine that’s already pre-configured in the UI. At least for the time you don’t want those things occurring.

@christop I don’t know what OS version you’re using:

Most likely there’s an error I’m not seeing.

I have finally run into the odd issue of udp-sender not being where it used to be expected (‘/usr/sbin/udp-sender’ vs ‘/usr/local/sbin/udp-sender’) and just pushed a fix for it, but the fact that yours isn’t saying the file is missing but just dead stops is odd to me. Usually that’s indicative of a typo or syntax error which is why I’m going to ask for the logs.

See my Signature line here and it should point you to one of the varients of error files.

If redhat based, you’ll likely see the error in the www-error.log from php-fpm

If ubuntu based, you’ll like see the error in the apache2 error.log file.

If you can give us that we might help direct.

I did push a fix for a completely unrelated issue so maybe that helps you too? I doubt it, but you never know.

@christop The UDPCAST_MAXWAIT should be the time (in minutes) for all udpcast started jobs.

If your setting isn’t working (I don’t know why it wouldn’t be, but there could have been a change that broke this unexpectedly) it would default back to 60 seconds in total.

The value is stored in minutes on the UI side of things and then converted to seconds when and where required.

I see a potential typo in /var/www/fog/lib/service/multicasttask.class.php at line 660 though, that seems might have been there for a while.

If you can change it to multiply by 60. Otherwise you were just multiplying by six:

So 10 * 6 = 60 seconds (one minute). 15 * 6 = 90 (1 minute 30 seconds)

YOu can fix this by updating your UI value from 10 to the period you’re expecting. Or you can edit the file.

i’m pushing what i hope will fix the issue in dev-branch if you’re wanting to go by a method that’s more “developed already” kind of thing.

@JYost I’m not aware of anything that would have changed regarding the type of network used especially if it works fine for the on-board network but not when you do it through the USB C dongle adapter?

The FOG Client can use dongles as well, but the fact you’re seeing the recovery screen when coming off the USB Adapter? That is strange and different and more likely something manufacturer specific (best I can guess.)

As for the FOG Client software operationality: the USB Dongle should work just fine if it’s associated to the device and has the expected snapins, etc… If it’s a generic Adapter, you may have enabled “ignore for client” on the mac address just to ensure all machines using that dongle aren’t getting assigned the same Hostname, Snapins, printers, etc…

Though, normally/ideally when the FOG Client checks in it looks up all MAC’s passed in, and attempts to find the host using any one of the MAC addresses associated to that machine even if ti’s not the one directly plugged in. It’s possible the onboard mac (when unplugged and system initially loaded) isn’t even recognized or sending as part of this authentication process, but without the FOG Client logs, I can only make WAGs at this point. Probably still some what blind with the logs, but at least we have data to work with that way.

As for the recovery screen, I’m not sure I have an answer for that. I can make another Guess there, and most likely it’s related to the kernel version. You could try some older version kernels using the kernel updater page and see if one of those older ones don’t force your machine into a Recovery Screen. It still seems very vendor specific, but I’ve seen odd issues of firmware temporary writes that do some weird things to Network devices between the FOS and Windows boots that might be happening in your case as well. Again, just a WAG.

@Fog_Newb Does this mean things are working as you expected now?

@Fog_Newb Can you try pulling again?

I have made a slight change to what you performed as I’m handling this in /opt/fog/service/lib/service_lib.php under the Service_Register_Signal_handler function. This should be the central point where all the FOG Services get their base line order and configuration for starting the processes. So, from your original code, you are only applying it to MulticastManager.

While I believe that, currently, is the only service that may spawn children (due to the udpcast calls), I’m still of the mind to handle it more centrally so maybe a future process spawning thing will not need the same action.

I have pushed what i hope to fix this (using your baseline of course) and hope this hsould work for your needs.

Thank you for testing in advance and sorry for missing this before the stable release.

@RAThomas I wont make you do a PR. I already pushed it if you wanted to use the the pushed code. thanks for testing and letting us all know!

@RAThomas Even (slightly) better:

$GLOBALS['TimeZone'] = $fog_settings[4] ?? (ini_get('date.timezone') ?: 'UTC');

We lose a storage variable (freeing up a tiny bit of memory) and just get the value directly as possible.

@RAThomas What about simplifying the whole stanza?

I’m not saying I don’t like your suggestions, just that this stanza should effectively do exactly the same thing, just much more simplified.

$GLOBALS['TimeZone'] = $fog_settings[4] ?? ($defTz ?? 'UTC');

@RAThomas So the display time of thigns should follow the TZ Info, but hte /etc/php.ini (or its equivalent) for timezone will need to be set as well as that’s the point the service starts up with.

@Floppyrub We have performed the same action (we get all hdd’s and only return the unique drives on the system. it will fall back to preferring the order of the drive in which lsblk returns them instead of lexicographically sorting.)

@Floppyrub Have you updated to dev-branch? You are free to run any task as a debug, initially to validate things are working as expected before things get too far and do any actual “data loss activities”.

The latest FOS code is the default pull in:

if it helps you to see how it functions please review the getHardDisk funciton starts at line 1501 of the Code link I provided you:

If it helps to see the funciton as a whole:

getHardDisk() {
    hd=""
    disks=""

    # Get valid devices (filter out 0B disks) once, sort lexicographically for stable name order
    local devs
    devs=$(lsblk -dpno KNAME,SIZE -I 3,8,9,179,202,253,259 | awk '$2 != "0B" { print $1 }' | sort -u)

    if [[ -n $fdrive ]]; then
        local found_match=0
        for spec in ${fdrive//,/ }; do
            local spec_resolved spec_norm spec_normalized matched
            spec_resolved=$(resolve_path "$spec")
            spec_norm=$(normalize "$spec_resolved")
            spec_normalized=$(normalize "$spec")
            matched=0

            for dev in $devs; do
                local size uuid serial wwn
                size=$(blockdev --getsize64 "$dev" | normalize)
                uuid=$(blkid -s UUID -o value "$dev" 2>/dev/null | normalize)
                read -r serial wwn <<< "$(lsblk -pdno SERIAL,WWN "$dev" 2>/dev/null | normalize)"

                [[ -n $isdebug ]] && {
                    echo "Comparing spec='$spec' (resolved: '$spec_resolved') with dev=$dev"
                    echo "  size=$size serial=$serial wwn=$wwn uuid=$uuid"
                }
                if [[ "x$spec_resolved" == "x$dev" || \
                      "x$spec_normalized" == "x$size" || \
                      "x$spec_normalized" == "x$wwn" || \
                      "x$spec_normalized" == "x$serial" || \
                      "x$spec_normalized" == "x$uuid" ]]; then
                    [[ -n $isdebug ]] && echo "Matched spec '$spec' to device '$dev' (size=$size, serial=$serial, wwn=$wwn, uuid=$uuid)"
                    matched=1
                    found_match=1
                    disks="$disks $dev"
                    # remove matched dev from the pool
                    devs=${devs// $dev/}
                    break
                fi
            done

            [[ $matched -eq 0 ]] && echo "WARNING: Drive spec '$spec' does not match any available device." >&2
        done

        [[ $found_match -eq 0 ]] && handleError "Fatal: No valid drives found for 'Host Primary Disk'='$fdrive'."

        disks=$(echo "$disks $devs" | xargs)   # add unmatched devices for completeness

    elif [[ -r ${imagePath}/d1.size && -r ${imagePath}/d2.size ]]; then
        # Multi-disk image: keep stable name order
        disks="$devs"
    else
        if [[ -n $largesize ]]; then
            # Auto-select largest available drive
            hd=$(
                for d in $devs; do
                    echo "$(blockdev --getsize64 "$d") $d"
                done | sort -k1,1nr -k2,2 | head -1 | cut -d' ' -f2
            )
        else
            for d in $devs; do
                hd="$d"
                break
            done
        fi
        [[ -z $hd ]] && handleError "Could not determine a suitable disk automatically."
        disks="$hd"
    fi

    # Set primary hard disk
    hd=$(awk '{print $1}' <<< "$disks")
}

Ultimately, the part I’m worried about is the sort -u as that will lexographically sort the drives regardless of how lsblk returns (which is the part I was stating earlier, there’s no true OS load method as PCI tends to load faster than serial -> parallel:

I have adjusted the code slightly and am rebuilding with that adjustment in the beginning of the function where we get all available drives:

devs=$(lsblk -dpno KNAME,SIZE -I 3,8,9,179,202,253,259 | awk '$2 != "0B" { print $1 }' | sort -u)

Instead of sort -u I’m going to try:

devs=$(lsblk -dpno KNAME,SIZE -I 3,8,9,179,202,253,259 | awk '$2 != "0B" && !seen[$1]++ { print $1 }')

Basically that will get only unique drive entries but keep in in the order of which lsblk sees the drives.

I doubt this will “fix” the issue you’re seeing, but it’s worth noting.

I still need to clarify, however, that this isn’t the coding fault. There’s 0 guaranteed method to ensure we always get the right drive, because in newer systems what is labelled the drive this cycle, can easily be labelled something else the next cycle.

hdd will always load in hda, hdb, hdc, hdd - this is about the only “guarantee” we can give.

Serial (USB, SATA, etc…) SATA would load (generally) in the channel order appropriately, but USB might or might not load before: so Something in the USB might take /dev/sda on this boot, and on the next, the channel 0 controller might take /dev/sda.

NVME, what’s nvme0n1 on this cycle, might become nvme1n1 on the next.

This is why the function you see is “best guess” at best.

I am wanting to make this seemingly more stable on your side of things, for sure, but just want to be clear on what you’re seeing, there’s never any potential we can guarantee we got the “right” thing.

@jfernandz When you see this error (Attempting to check in … Fail) can you also look at your http/php error logs and see if anything is logging there?

I’m not aware of anything problematic due to the ability to “Force task”. Are you forcing the task and it’s causing the issue or just the ability to “Force task” is causing the issue? Just trying to understand.

@jfernandz THis sounds like (at first glance) the security token issue:

So the FOG server has a security token defined to a host, but the client is new on the same host:

Host prints out “Bad sec token data failed to authenticate”

One time, I think is fine as there is an initial time but the FOG Server believes something is already trusted.

You should be able to get around this by resetting the encryption data (from the fog server) for those hosts needing the client reinstalled.

You can do this via a group.