@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.

@londonfog There is a long story about NVMe drives swaping around possibly on every reboot as the kernel does not seem to enumerate the drives always in the same order as it does with ATA/SCSI drives. For more details see here: https://forums.fogproject.org/topic/12959/dell-7730-precision-laptop-deploy-gpt-error-message

For your situation: I am not sure what we can do to help you work around this. Please read through the other topic and see if you can get an idea on this.

@Quazz Thank you. I’ll look into the API.

This issue could probably be closed now. The image “export/import through API”-issue seems to me is a new and separate, though closely connected, issue.

For future readers the best solution, if FTP is possible over your network, would be to set up the remote servers as a “storage node” with “Is Master Node” unchecked. When this is done you simply check the “Replicate?” field for the images you want to be synchronized across all sites. You will still need to use the import/export functionality to make the images available at the remote sites.

However if FTP is not possible over your network you need to use rsync or scp or your preferred file transfer method, to transfer the images. (More examples can be found here: https://wiki.fogproject.org/wiki/index.php?title=Migrate_images_manually) This also requires the use of the import/export functionality.

@JGwinner Please create a new thread with all the details of your problem.

@Richardpofnz Ok let’s see what the server side does. On the FOG server run tail -f /var/log/apache2/access.log (or tail -f /var/log/httpd/access_log if you are on CentOS/RHEL/fedora) while you do the menu stuff on the client.

On my test system it looks like this when I try “Deploy Image” from the menu:

192.168.2.10 - - [08/Jul/2019:14:11:10 +0200] "POST /fog/service/ipxe/boot.php HTTP/1.1" 200 2768 "-" "iPXE/1.0.0+ (9907f)" 192.168.2.10 - - [08/Jul/2019:14:11:10 +0200] "GET /fog/service/ipxe/bg.png HTTP/1.1" 200 21280 "-" "iPXE/1.0.0+ (9907f)" 192.168.2.10 - - [08/Jul/2019:14:11:31 +0200] "POST /fog/service/ipxe/boot.php HTTP/1.1" 200 813 "-" "iPXE/1.0.0+ (9907f)" 192.168.2.10 - - [08/Jul/2019:14:11:34 +0200] "POST /fog/service/ipxe/boot.php HTTP/1.1" 200 464 "-" "iPXE/1.0.0+ (9907f)" 192.168.2.10 - - [08/Jul/2019:14:11:35 +0200] "POST /fog/service/ipxe/boot.php HTTP/1.1" 200 481 "-" "iPXE/1.0.0+ (9907f)" 192.168.2.10 - - [08/Jul/2019:14:11:35 +0200] "GET /fog/service/ipxe/bzImage HTTP/1.1" 200 8389280 "-" "iPXE/1.0.0+ (9907f)" ...