@pedro-0 where is the tar you downloaded stored on that machine?

@sebastian-roth Thank you very much for the response. Sorry for the delay, I was on a time crunch for delivering this image and I did not have enough time to continue troubleshooting. I ended up just deleting the image and recapturing and it replicated afterwards. Hopefully it was just a fluke. But i know how to check the replication log file now!

Thanks again for taking the time to respond.

@tomtom2770 Not exactly nicely.

While linux allows more than 15 character hostnames, windows does not. For this reason, the GUI was coded for Windows based machines. (Start with the most restrictive set)

https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/pages/hostmanagementpage.class.php#L418 is the first part of the hostname limitation for creating new hosts.
https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/pages/hostmanagementpage.class.php#L1038 is the second part for editing hosts
https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/fog/host.class.php#L638 is the third part for checking if the hostname is safe. Of note, the check is a regex, which can be changed for your needs. For the length specifically edit the 15 in the {1,15} portion.

You can change these however you like, but remember that changing this will not maintain these changes when you upgrade. Also, remember making the changes will allow you create hostnames on any entry longer than 15 characters and your environment may not like this.

Also, this only impacts the UI. There are some similar checks in the inits when you are trying to register hosts through the PXE menu item.

https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg#L164 Is the file that truncates hostnames to 15 characters. You’d have to comment the whole if statement to allow registering hosts with different length names. Of course there’s not validity checking so that would be handled in the UI elements.

@george1421 Thanks for your advice! I will consider building a more distributed FOG environment once more clients will be setup with FOG.

Btw should I mark the thread as resolved or something?

@asch75 said in How to increase time to get DHCP lease?:

Next thing: redesign our network topology and reconfigure the cisco switch/es.

Glad you have it sorted out. All you “need” to do is enable portfast on all of the interfaces where you need to pxe boot from. As you found the dumb switch is the quickest check if its spanning tree or not. Plus with it inline you can image before you get your infrastructure updated. So it has an extra benefit.

@sebastian-roth Thanks for that, The PC in question was in the pending hosts.
After approving it joined the domain as expected.

@lmaoroot said in Deploy install ISO over PXE with FogProject:

@george1421 No problem. I get the overall concept, I just dont know where to start on the WinPE part, I’ll have another look though. I got ubuntu 18.04 server installing properly, but not oddly enough… its like its server when i install the desktop version. It’s so weird, but I cant find the netboot.tar.gz for ubuntu 20.04. Does it no longer exist?

They use a different method of the net install now. Can’t remember how I found it but there are instructions.

As for windows the ipxe sight has great tutorials.

Thank you so much for your replies. I reinstalled and it fixed it. I didn’t realize a reinstall wouldn’t affect the existing install. It installed “php-gettext” and did all the checks. Database is perfect.

Thanks for the assist. I appreciate it.

Hello @george1421

I had already done a mount and it worked

I had also activated no mapping on the squash option

probleme2.PNG

Thank you!

@wayne-workman This call has to be made using the DELETE method.

@renard Usually those ACPI BIOS errors can be ignored as mostly being warnings. Though it’s strange you machine just reboots after that.

Which version of FOG do you use and more importantly, which kernel version (FOG web UI -> FOG Configuration -> pane “Kernel Versions” -> expand by clicking the “DefaultMember FOG Version…” bar).

Today w’ve tested FOG with one new switch (a Cisco) and every problems leaves away. So i didn’t test udp-sender modifications. Our 2 switches are 1GoMps. Sebastian, i wil look to improve the french translation and i’ll send you back the language pack

@george1421 So are you saying we should not alter the kernel config because of this? While you are right about it should be working when using the latest 5.10.19 kernel I still wonder if the CDC_ETHER will cause us trouble as we did not have that enabled in the 4.x series kernels.

@alan-lim

This is really just a starting point. You should adjust the instructions based on the mount point for your NetApp storage.

@fimlore I understand that,

What I meant by the ipxe is different from pxe and fog is:

PXE has it’s own DHCP mechanism. This then hands off to iPXE which handles DHCP on its own. This then hands off to FOS (FOG Operating System) which handles DHCP on its own.

@belac said in Problem with new FOG 1.5.9 installation:

manually update
on all your storage nodes

This is not for your FOG master node. Hope you have a copy of the old fogsettings file or we might be able to get the last fogmaster DB credentials from a backup of the config.class.php file in /home/fog_web_1.5.9.BACKUP/…

@choppaholic26 Oh well, I should have had look at the topic line again to know it’s about TFTP timeout.

I think the only way to maybe find out is to capture the network traffic exactly where this is happening. Either you have a managed switch and can enable a monitoring port or one of these really old network hubs to pick up that traffic from/to the PXE booting client machine.

@sebastian-roth said in Uninstall FOG-Client (Service) after deploying with Snapin?:

The fog-client runs as SYSTEM

@jcrod73

OK here is what I’m thinking. I’m not saying its the exact case here but I’ve experienced this in the past.

If the application that is running is 32 bits (regardless as who it runs as), windows knows this. Windows will map the 32bit application to this path (akin to chroot) to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node So if you have a 32 bit application creating the runonce key, the value should be found here: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\RunOnce Whereas a 64 bit application would create the key here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

Note the: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce would only “run once” the current user who created the key logs in again (i.e. SYSTEM). You will probably not get the response you expected from that reg key location.

I’m speculating the fog client is a 32 bit app because I don’t see an install for 32bit vs 64bit its just one install. I don’t know if the installer is smart enough to install the 32 bit stuff for a 32 bit machine and the 64 bit stuff for a 64 bit machine. So some of this is just an educated guess.