@infrapeya The quickest way is via the linux command prompt on the master FOG server.

If you are using a rhel based linux distribution then.

scp /var/www/html/fog/service/ipxe/bzImage* root@SN_IP:/var/www/html/fog/service/ipxe

i.e. scp /var/www/html/fog/service/ipxe/bzImage* root@192.168.20.40:/var/www/html/fog/service/ipxe

The debian/ubuntu versions are a bit more difficult.
Remote connect to the storage node using ssh (or putty from windows)

On the linux command prompt key in the following.

sudo su - scp <linux_user_on_master_fog>@<master_fog_ip>:/var/www/html/fog/service/ipxe/bzImage* /var/www/html/fog/service/ipxe

i.e. scp daffy@192.168.11.53:/var/www/html/fog/service/ipxe/bzImage* /var/www/html/fog/service/ipxe

@eseelke Are you still around?

I just updated the code to add the ${storage-ip} variable. Update to the latest dev-branch to be able to use it.

@djslimd1k Are you running into performance issues with this system?

If you look at top and sort by Processor what is your top task? mssql? Is it above 40%

How many fog clients do you have in your environment?

Lastly if you have the ram, you can increase the number of maximum handlers to 50 from 35. You may need to allocate 6GB of ram to the target computer. If you start dipping into swap space, then add more vRAM to the FOG server.

MOD Note: Topic of @DJslimD1k has been forked here: https://forums.fogproject.org/topic/14918/listing-all-hosts-gives-me-an-http-error-500

@tom-elliott Hello Tom,

Thank you for your quick response, I will try what you suggested and post my progress.

kind regards,

VlanFlex

@dadkins said in Can't perform Host Registration:

I have installed fog 1.5.9 on Ubuntu 16.04.

As you seem to be starting with a new installation I am wondering why you use such an old Ubuntu version. 16.04 is end of life kind of soon and newer versions work pretty much the same. I suggest you re-install before going ahead using Ubuntu 20.04.

@sebastian-roth That took care of the problem.

Thank you all.

@JJ-Fullmer We provide the PrinterManagerHelper with ever release of the fog-client, e.g. https://github.com/FOGProject/fog-client/releases/tag/0.12.0

I know it’s not perfect and sometimes doesn’t provide all the information correctly. Though I don’t have real printers in my test setup and can’t work on this part much.

@huecuva That is an interesting update for sure. I believe graphics cards have a bios of some sort and sometimes there’s some option rom boot option related to the gpu in the computer’s bios setting. It would make some sense for the graphics drivers to also update the bios or boot option roms on gpus.
What GPU’s do you have? GPU’s of the gtx 10xx series and newer have a ‘studio’ driver option that’s supposed to be the sort of ‘stable’ branch option. If your cards can use that, maybe using that as a standard could help if it’s not something you’re already doing?

@kdmiller45 Sounds as if the database update at the end of the capture task failed. Please run ls -al /images/dev/ on your FOG server and post output here.

Ok, let’s call it quits. I just pushed a commit to the fos repo to add this patch to our build of partclone and add the ignore_crc parameter back to the scripts.

Marking as solved.

@kdmiller45
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Installing_-_Linux

@KenM I am sure it’s the fog-client trying to update but fails in every loop because of the run out code signing cert. Re-installing the new version should fix that.

@Pingolin It’s probably a good idea to follow the things George lined out. Just want to add one question: Did you say yes or no to the installer question “Would you like to use the FOG server for DHCP service”?

If yes was selected then we better take this DHCP offline again as it might mess with your home setup.

@Detoss So your goal is to reset the web ui password for the fog system admin?

If yes then there is a wiki page for this: https://wiki.fogproject.org/wiki/index.php/Reset_WebUI_FOG_password

@george1421 Ahhh, missed that part. But nonetheless I think it doesn’t hurt to have it added even now so we don’t forget as soon as we update the kernel to 5.9 and later.

@Goll420 said in Multicasting:

I’ve set the remaining 8 going now, but I omitted the WOL part and started them manually. See if it makes any difference.
I never said before that this was a RAW image as the drive was encrypted with Bit Locker. I noticed an error on the end of the deployment on the hosts and then the reboot.
The tasks still show spinning and the hosts have all gone back to the deployment screen amd sitting there waiting for it to begin.
Logs show that the Multicast has finished, but I believe it’s this error that is stopping it progressing any further.

Sorry for the long delay. Time is sparse at the moment and digging into such things usually takes a bit. I just tested multicasting several times and they all worked perfectly fine finishing the task. I am fairly sure that what you describe is caused by some kind of “checkout” issue where hosts are don’t properly report back to the FOG server when finishing the multicast session. So it would be helpful to know what error message you see at the end. If you see this happening again you might want to take a look at the Apache and PHP logs (see my signature) on the FOG server to see if errors are reported there as well.

Image type being RAW shouldn’t play a role. As far as I can test and know the code this does not seem to be a general issue in the multicast code I reckon.

@george1421 Remember that during a capture, the $storage variable is defined, usually:

IPAddress:/images/dev

In the case of a deplooy the $storage variable is defined, usually:

IPAddress:/images

That’s why the checking.

If somebody wants to move the postinit into /images, then it should be symlinked, but that’s beyond our scope. That’s more of a preference .

@vemoya said in Cannot find disk on system:

develop something to remedy this issue with RAID BIOS configs

This is beyond the capabilities of the FOG Project. The FOG Project relies on the linux kernel developers to interface with the hardware. Intel will not release the drivers for their RST Raid controller. In tern the linux kernel developers can’t create a driver to see the disks behind the intel raid controller. This is an issue that impacts the entire linux community. The trifecta is uefi + intel RST Raid-On + linux. If you change any one of the elements FOG will be able to see the disks behind the controller.

Sorry, I’ll post a new topic.

After lots of trying I’ve been able to deploy printers. The main problem was the name of the printer, which is not clear what it should be.

I’ve put the details in a new topic: https://forums.fogproject.org/topic/14891/problems-deploying-printers

Thanks for your help!