So I found by myself.

The issue was the /etc/exports that was still referencing original /images folder instead of /cloning/fog

So this part is solved.

Hi,

I use FOG for years now.

I wanted to install a new server on an ubuntu 22.04.

I followed the wiki without any issue.
I imported, groups, hosts and images from a previous server.

I setup the storage node to use this path as image folder : /cloning/FOG
I edited /opt/.fogsettings and set storageLocation to “/cloning/FOG”
I checked that management password is the same as default storage config in web interface

My image are on and iSCSI LUN, previously used by another server.
So I mounted the iSCSI LUN in /cloning/FOG
I set right as follow :
fogproject:root for /cloning recursively
chmod 775 for /cloning recursively
same for /images

I can see images in /cloning/FOG
.mntchecks are in /images, /images/dev, /cloning/FOG, /cloning/FOG/dev

And I don’t know why when I try to load an image on a client I have this error message :

could not mount images folder (/bin/fog.download)
args passed:
Reason: mount: mounting 10.33.0.10:/cloning/FOG/ ON /images failed: permission denied

Many thanks in advance for any help.

By Proc.

@luilly23 said in Create scheduled task on a W10 with snapins:

@processor you can do bat with -> /ru “System”
schtasks /create /sc daily /tn “MYTASK-DAILY-20PM” /TR “shutdown /p /s” /ST 20:00 /ru “System” > C:\Users\AB\Desktop\done.txt

Thanks, that’s what I was searching for !

I did not found in the forum how to make it as valid answer, any idea?

Hi,

This is my configuration :

Server :

• Ubuntu 18.04
• list itemFOG Server 1.5.7

Clients :

• Windows 10 20H2
• Fog Client 0.11.16

I’m trying to create scheduled tasks on Windows using Fog Snapins.

Unfortunalely nothing worked.

It tried these both scripts :

Batch (shutdown.bat):

@echo off
IF EXIST "C:\Users\AB\Desktop\Extinction_Auto" (
	echo "exist"
	COPY /Y NUL C:\Users\AB\Desktop\done.txt
	schtasks /create /sc daily /tn "MYTASK-DAILY-20PM" /TR "shutdown /p /s" /ST 20:00 > C:\Users\AB\Desktop\done.txt
) else (
	COPY /Y NUL C:\Users\AB\Desktop\notdone.txt
)

This Powershell script also (shutdown.ps1):

$trigger = New-ScheduledTaskTrigger -Daily -At 8pm
$action = New-ScheduledTaskAction -Execute 'shutdown /p /s'
Register-ScheduledTask -Trigger $trigger -Action $action -TaskPath "\" -TaskName "SHUT-DAILY-20PM" > C:\shutdown.txt

None of both worked, using snapin dedicated templates or not.

Both scripts works without any issue if I run them directly on a client.

I found another solution which is to add them in the startup folder of a client, but then I have modify the registery of the client to allow autoadminlogin to apply them.
But modyfiying the registery did not work either, even with a message telling “it’s done”, in fact it’s not. I tried to use PsExec to run commands but it did not worked with the snapins.

I’ll take any help or suggestion to apply these scheduled task or a change to the registery.

Many thank in advance.

Proc.

Hi,

DB cleanup did the the trick.

Thanks

Hi,

I’m using FOG 1.5.7 on Ubuntu server 16.0.4.

This is not a big issue but I have always something in queue in storage group activity on the dashboard.
Any idea to know what it is and how to remove this?

here a screenshot :

I look at everything in tasks and nothing appears.

Many thanks by advance for your help.

@Sebastian-Roth

Hi I’m using fog 1.5.7 (upgrade from 1.5.6 and/or 1.5.5, I could not remember) on ubuntu 16.04.3.

I used the the script in the tar file to install it.

Thx

@Sebastian-Roth

Hi Sebastian,

thanks for your answer. Sorry but I don’t now how to do this.

Hi,

I exactly have the same behaviour.

I mean if I create a multicast session for 2 machines and I join with 2 already registered PCs, the session won’t start,
whereas it does with 2 unregistered ones.

This is what I see from Images>Multicast

This what I have in active tasks :

And this in Active Multicast :

In shell this is what “ps aux | grep udp” gives :

root      3571  0.0  0.0   4500   744 ?        S    09:57   0:00 sh -c /usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 300 --portbase 64776 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p1.img;/usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 10 --portbase 64776 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p2.img;
root      3572  0.0  0.0   8704   828 ?        S    09:57   0:00 /usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 300 --portbase 64776 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p1.img
root      7774  0.0  0.0   4500   844 ?        S    10:35   0:00 sh -c /usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 300 --portbase 62458 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p1.img;/usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 10 --portbase 62458 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p2.img;
root      7775  0.0  0.0   8704   828 ?        S    10:35   0:00 /usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 300 --portbase 62458 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p1.img
root     11289  0.0  0.0   4500   852 ?        S    11:09   0:00 sh -c /usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 300 --portbase 55058 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p1.img;/usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 10 --portbase 55058 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p2.img;
root     11290  0.0  0.0   8704   780 ?        S    11:09   0:00 /usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 300 --portbase 55058 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p1.img
fog-adm+ 11896  0.0  0.0  14228   868 pts/0    S+   11:20   0:00 grep --color=auto udp

I have only one session running. Is it normal to get so much processes?

Using ipxe.kpxe instead of undionly.kpxe solved the issue. Thanks for your help.

Thank you! I keep you informed

Hi george1421,

Thanks for your clear answer.
I’ll first update the machine bios, but Dell computers are less and less open so I’m pretty sure it won’t help.
Then I’ll give a try to ipxe.kpxe hoping it’l be compatible with all intel hardware we have as broadcom.
And at last, I’ll made 2k12 filters. (Which is barely already done in a kind of way)

Bye

Hi,

I’m using fog server 1.5.7 on ubuntu 16.04.3.

We have a little issue with some intel cards : PCI-E Intel chips 82574 on Dell Optiplex 5050 and 5060.
I get first an IP, the undionly.kpxe is downloaded but then I face the error :

DHCP Failed : no configuration methods succedeed.

In the pxe shell I tried to bind ip manually and then ping, but it seems finally the IP is already binded but
the ping does not work.

I tried all I had in mind without any success, I even disabled the integrated NIC did not helped.
What make this thing strange is the same card works without any issue on another PC (Dell Optiplex 9020 for instance).

I finally made it works using intel.kpxe instead of undionly.kpxe !

Any idea on how to make it works with undionly.kpxe?

Thanks by advance,

Proc.

Hi,

We have 2 servers that are synced.
Both are master for themselves.
Server 1 is master for both, this way Server 1 replicate itself on Server 2.
And I export/import for times to times
This way they are both independent and synced.

The servers are under Ubuntu 16.04 / FOG 1.5.6

on both servers a du in images folder give :
1340230528 or 1.3T

On server 1 Pie :

On server 2 Pie :

On the shell both servers show the same amount of data but not on the PIE. any idea?

Regards

@Sebastian-Roth

it worked ! Many thanks I did not even noticed this tab!

@george1421

Hi,

My skills in english are fair but that’s all, that’s may be why my message was not clear enough.

To resume :

-We had a NAS LUN linked to the legacy FOG Server
-We rarely do unicast deploy, 95% are multicast.
-Running 3 or more multicasts start causing slowdowns on the WebUI.
-Sometimes we have up to 10 simultaneous multicasts. Very have rarely more, even
with 23 classrooms on the main site.

As the nic used to access the WebUI is the same as the one that flood the images through the network we thought that we could mitigate this phenomenon using storage node.

We are note stuck to a model or another, we are still searching for the best compromise.

---

Now we have/had a second issue it’s image export/Import. We plan to use replication at the end but for the first load which represent several TB sync through a wan link is not possible.

It seems this issue is now solved, the remaining “problem” is only cosmetic, but may be I did something wrong, it was the first time I moved images from storage to another and tried the export/import.

@Sebastian-Roth
no worries.

I already tried what you suggested and it did not helped unfortunately.
I did not noticed the “deletemulti” in the url. To be sure I tried again with one
image only and strangely the result is exactly the same :

[Wed Jun 26 17:03:26.511411 2019] [proxy_fcgi:error] [pid 28204] [client 10.33.0.200:39938] AH01071: Got error 'PHP message: PHP Warning:  trim() expects parameter 1 to be string, array given in /var/www/html/fog/lib/fog/fogbase.class.php on line 1386\n', referer: http://10.33.0.11/fog/management/index.php?node=image&sub=deletemulti

whereas this time I’m sure I did not check more than one image.

for info my images are not stored in /images but in /mnt/FOG_iSCSI (mounted iSCSI LUN) so of course I adapted the chown to my configuration.

A little up for this remaining issue.

Ok, seems to work finally.
The error was because I deleted the test image thinking it will only remove infos from database whereas it has trully deleted the image in the storage node, even if it appeared in default() storage in image description.

Now, new image will be stored in the storage associate with the location of the captured machine despite the selected storage during image creation.

It’s quite confusing because this mean we could think that images are stored in the default storage whereas they are not and inversely.

Is it a bug or is this is a normal behaviour?
Does the storage setting in image creation has an influence or everything depends of location of the computer which deploy or capture?

HI Sebastian,

No worries, right now the fog server is an Ubuntu 16.04 VM build in an ESXI 5.5
the VM has 2 vNIC. One on our education network and another one storage network.
Each vNIC are supported by 2 physical Ethernet NIC teamed and configured to use ip hashing to load balance traffic.

The Ubuntu server is configured to use multipath iSCSI to access the NAS LUNs and multicast is massively used to install our classes.

We have to install between 200 and 300 machines per week. At start we have no severe issue but with programmed tasks starting the webui is dramatically slowing down. With 2 or 3 tasks running we can start seeing slowdowns.

Using nload and top to monitor where could be the issue, we could only see very high network load but no issue with memory or CPU.

We deploy at speed between 5GB/m and 27GB/m depending on the receiving hardware. No other resources that the FOG server are showing slowdowns.

So we thought the mutliple multicast sessions were cannibalizing the server bandwidth and having a server for the management and a storage node for the deploys would be a good idea.

Sorry for the long explanation. Are we wrong?

Then we are multi-site, right now only our main site is testing fog and we already have several TB of images.

At the end, sync via wan link will be OK but for the first load we will have to send a disk with all images on it. that’s the other reason we would like to test import.

Proc