@george1421 said in Mounting failed, connection refused:

@faresalandlos Well at this point I don’t think its a firewall issue, but to answer your question for ubuntu this is the command to disable the firewall sudo ufw disable

So what do I think:

You need to understand why nfs is not starting on that system. your exports are right and once nfs is running the when you run the showmount command you should see what is posted in the /etc/exports file. The exports file is configured correctly. Your /images/dev directory is not complete. You are missing the post init scripts directory.
Your directory should look like this: [root@sonic ~]# ls -la /images/dev total 428 drwxrwxrwx 5 fog fog 4096 Jun 24 13:11 . drwxrwxrwx 18 fog root 4096 May 28 11:11 .. -rwxrwxrwx 1 fog fog 0 Mar 16 2016 .mntcheck drwxrwxrwx 2 fog root 4096 Oct 4 2018 postinitscripts

You may need to just rerun the fog installer and it should fix this file path.

For your nfs service there are a number of sub services like portmapper and such that nfs depends on. Does running sudo systemctl status nfs.service give you any clue to why nfs is not starting?

thank you so much for all the help turning off the firewall fixed the problem! it’s like the system was not happy that i used FTP to play with the folders

@Sebastian-Roth Actually, on the latest VirtualBox it seems that there is a way to UEFI PXE boot now. (chipset ICH9 and network adapter type to virtio-net), but I haven’t really tested it any significant amount. It gets to the FOG menu at any rate.

@thebrennan47 why don’t you explain more how you fixed it?

@Quazz said in Corrupt file in image?:

then it could also potentially be something far more silly such as a faulty ethernet cable.

Or faulty RAM in the client machine.

@Sebastian-Roth
thx, cp this comand’s and now is works!!!

❤

Solved!

@altitudehack

Right, I upload a .bat and use the batch snap-in template

@adamkesy said in FOG 1.5.4 - capture win 10 (1903) - issue:

This new value in kernel ramdisk size can be impacted for previous images/hosts somehow?

No, this should Not cause an trouble unless you have machines with less that 512 MB RAM which is very unlikely these days…

@george1421 Its working now 🙂

I forgot my options 66 and 67 on that 192.168.5.x scope!

Thanks you very much!

@DJGRP Guess we are on the right track here to find out what’s going on here. Which Linux OS do you use on the storage and which on the master node?

Run the following command on your storage node and post the output here: find /etc/ -name "fog.conf" -exec grep "DocumentRoot" {} /dev/null \; (make sure you got all the braces and slashes right)

File dates (Aug 28 2018) definitely show us that the storage node was not properly installed with 1.5.6.5. Which method do you use? Using git I suppose? Please take a look at the error logs and upload the full log here - you should find it in fogproject/bin/error_logs/fog_error_1.5.6.5.log.

@george1421 thank you for this. I have hit a bit of a snag as I made some network changes on the VM without a snapshot and am experiencing connectivity issues. once I have resolved I will test and advise.
1.I have registered a host manually
2. I have scheculed a debug deploy
3. I will feedback once I have resolved my network issues with step 3-6

@imagingmaster21 Thanks for the heads up. I will mark this solved now here. If you see any new issues feel free to call out.

@george1421 The weird and suspicious part is that 1.5.5 was last known working version, 1.5.7…I’ll also note that the parrallel behavior has always performed that way, at least for quite some versions now. I could actually transfer a single new captured image to all nodes at the same time and they would all run at their perspective top speeds (I have 4 schools that only have 100Mb connection and the rest are all gigabit. This speed is definitely new though.

Note I just manually transfered the file via ftp and the speed was back to normal at another node…then on this node in question and it is indeed a port going bad or the cable itself only allowing a very minimal top speed of 10-15 Mb. This can be closed, but I appreciate the new command.

Dear george1421 ,
Finally i solved my problem. For Future guys ,
you need to add this line also to your /etc/dhcp/dhcpd.conf file .
next-server and some ip address , like : next-server 192.168.x.x.
my mistake was that i was writing it with “option” word . But next-server is string and it must be without option word. 🙂
Thank you for your support ,
This can be marked as solved .
Good Luck to all.

Never mind I have found the answer at https://www.youtube.com/watch?v=QSpGaeHlkoE
Made it so easy even a cave man could do it

@Sebastian-Roth Got it. Thank you very much!

@londonfog I don’t specifically know the wipe function, but I might guess it would only wipe the target (defined) hard drive in the host configuration.

If you were ok with scripting it wouldn’t be that difficult to update the fog.wipe module to just loop through the disks instead of the one pointed to by getHardDisk function.

ref: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.wipe

patching FOS is pretty simple to do too without needing to unpack and pack the inits.

@Sebastian-Roth Hi, thanks so much for your work and help, I’ll test as soon as I came back to work, after 19th August.

Just got round to reapplying the upgrade and testing. Everything seems to working perfectly now.

Thanks for the quick response and fix.

@marcolefo New inits are ready for testing. Download 64 Bit and 32 Bit and put those in /var/www/html/fog/service/ipxe/ dir on your FOG server. Probably good to rename the original ones instead of overwriting.

As well you need to check the RAM SIZE option in FOG configuration, FOG settings. Need to be 275000 with the newer inits.

@Bullet I suggest you update to the latest FOG version 1.5.7 we just released. There is a chance this might help you here.