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

@Sebastian-Roth It’s alive!!

1232845e-7912-4553-b385-dddb8cb4ec12-image.png

Thanks for the help on this, really appreciated.

I just updated the official init files on the webserver. Marking as fixed.

@Julianh No it won’t wipe the image definitions or anything else important. It only removes DB entries that are obviously wrong (not pointing to valid entries or something like that).

It’s not very hard to do - just enter the DB password you find in /var/www/html/fog/lib/fog/config.class.php - might even be empty so you just hit ENTER on the password entry:

shell> mysql -u root -p Password: ... mysql> use fog; ... mysql> DELETE FROM `hosts` WHERE `hostID` = '0'; ...

Run all the commands mentioned in the wiki article.

@blackburn56789 Can you please give us some more details on the use case you think of when asking about this? Possibly we can help you with this if we know what you are trying to do.

As far as I know there is no way to add snapins automatically right now. And I am wondering what the trigger would be to add a snapin to a host. Registration!?

@gazzer82 said in Unable to boot to HDD whilst using PXE Boot USB:

Is their any way for me to target specific machines with different settings?

You can set specific EXIT TYPES for each host machines. Unfortunately there is no way to specify individual refind.conf files in FOG yet. Though it’s not very hard to manually add this to the code. I might suggest you give this a try as we won’t have the time to add this as a feature as quickly.

Edit /var/www/html/fog/lib/fog/bootmenu.class.php and jump to line 135. Here you add another variable same as the one above in line 131-135 so it looks like this:

$refind = sprintf( 'imgfetch ${boot-url}/service/ipxe/refind.conf%s' . 'chain -ar ${boot-url}/service/ipxe/refind_x64.efi', "\n" ); $refindbugged = sprintf( 'imgfetch ${boot-url}/service/ipxe/refindbugged.conf%s' . 'chain -ar ${boot-url}/service/ipxe/refind_x64.efi', "\n" ); ...

The only difference between the two is the variable name and the conf file name.

In that same file jump to line 170 (166 if you have not added the code above yet) and add the new item to the list here:

... self::$_exitTypes = array( 'sanboot' => $sanboot, 'grub' => $grub['basic'], 'grub_first_hdd' => $grub['basic'], 'grub_first_cdrom' => $grub['1cd'], 'grub_first_found_windows' => $grub['1fw'], 'refind_efi' => $refind, 'refindbugged_efi' => $refindbugged, 'exit' => 'exit', ); ...

And now there is one more place to edit to make this new item available in the web UI: /var/www/html/fog/lib/fog/service.class.php - around line 210:

.... $types = array( 'sanboot', 'grub', 'grub_first_hdd', 'grub_first_cdrom', 'grub_first_found_windows', 'refind_efi', 'refindbugged_efi', 'exit', ); ...

Save the changes and go back to the web UI. You should be able to select “REFINDBUGGED_EFI” in the host settings now. Create a file /var/www/html/fog/service/ipxe/refindbugged.conf with the specific settings you want for those clients.

Those changes will be lost when you update your FOG installation. This is definitely not a proper fix for your situation. But this should help you work around the issue for now.

@Matdes “check the fog server to ensure disk space is good to go” is not a very detailed error. Partclone doesn’t pass back the actual error to the calling program, only the capture failed. The FOG code tries its best to determine the root cause of the partclone capture failure, but some times it misses.

What we really need to see is the text that sprawls across the partclone screen when it errors out. To get this info please do the following.

Schedule another capture task, but before you submit the capture task, tick the debug checkbox. Schedule the task PXE boot the target computer After several screens of text (where you need to hit enter to clear) you will be dropped to the FOS Linux command prompt. At the FOS Linux command prompt key in fog This will start the capture process in debug mode. At each breakpoint the code will stop waiting for you to press enter to go on to the next step. Somewhere when partclone is capturing partition 3 you will see this error. Take a clear picture of the sprawling text with a mobile phone and post the results here.

That text will actually be the root of why partclone can’t capture that partition.

@Matdes When you delete images on the image list overview the files are not being deleted. This is intended.

If you want to see the files being deleted then go the image settings and use the tab named Delete…