Finally I found where the problem came from !

We are using a NAS Synology to share the printers drivers. It’s a share accessible without password (guest account enable on the NAS). We’ve got no access problem to this share at anytime.
This NAS is joined to the domain… And here is the problem !

As soos as we unjoined the NAS from the domain, FOG printers are pushed without problem.

I don’t know why but if you execute printui command as local system account when the drivers files are shared on a NAS member of a domain, there is an access error. If you try the same command as local Administrator, it works…

So unjoining the NAS from the domain was the solution.

At the end of fog.man.reg, just add those lines between “. /bin/fog.inventory” and “usleep 2000000”

sysuuid=$(dmidecode -s system-uuid)
sysuuid=${sysuuid,,}
mac=$(getMACAddresses)
curl -Lks -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=$mac" "${web}service/hostinfo.php" -A ''
[[ -f /tmp/hinfo.txt ]] && . /tmp/hinfo.txt

. /bin/fog.download

EUREKA !

In the Fog service properties, I change the “Open session as” in Connection Tab from “Local system account” to “Administrator” with his current password.
Then I reset the client Encryption Data on the Fog web console, restart the Fog client service and Voilà ! All printers are installed.

Now we need to find why this problem appears “randomly” on host which was working fine ?

@sebastian-roth Sorry, I didn’t see your answer. Yes it works.

@sebastian-roth Thank you very much !

@sebastian-roth
After reading the doc of the PrintUIEntry command, it seems that when you use the /sr parameter, all the values have to be placed at the end of the command :
/Sr Specifies what information about a printer is restored and how conflicts in settings are handled. Use with the following values placed at the end of the command line
So when you add ‘/q’ parameter after the m f g p values it could generate a problem ?

I dont know if this github issue is the same as mine. I should try the g/u value and compare results.

Sorry to bump this topic, can someone confirm this problem ?
If the fix is possible, could it be applied to the next fog update ?

Thanks for your time.

Hi,
Is the mac address different ? It seems both of them have the same.

Hi,

Same problem as Scoude here with Fog 1.5.9 on Debian 10.
I “defraged” (it’s a ssd), desactivated Fastboot, hibernate off, chkdsk…
Nothing fixed the problem.

Any idea ?

Thanks

Forget about it. It seems there is no easy way to do it and it’s not a big deal even if this kind of boot menu isn’t set up.
Thanks for your guidance.

In the web console>iPXE Menu Customization, when I change the fog.local item menu from “All Hosts” to “Registered Hosts” and sets it to default, it become the default setup for the “Not registered Host” menu fog.reginput too.

@george1421 Ok. I think I understand how it works. Let me try to resume :

When you call this url http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=xx:xx:xx:xx:xx:xx, the boot.php file (located in /var/www/fog/service/ipxe/boot.php) will get the host informations through the mac address then create a personalized boot menu

new BootMenu();

This function can be found in /var/www/fog/lib/fog/bootmenu.class.php.
So it seems I should try to modified this file to change the default selected item depending on the host is registered or not ?

Hi,

I know how to select a IPXE item menu by default through the web console.
I would like to know if we can select an item by default when the host is not registered and another if the host is ?
I can’t see a way to do it in http://@fogserverIP/fog/service/ipxe/boot.php.

Thanks for your time.