@sebastian-roth
Thank you. I will check it out.
I am toying with a test server before I nose around in our production fog server.

@jyost Use that value set as password=... in /opt/fog/.fogsettings to (re)set the fogproject account password.

@brucehu said in Fog1.5.9, the php-fpm.service service exited abnormally and could not be started:

After compiling and installing php7.2.3 and pre installing PHP FPM

What exactly do you mean by that? Please give us more details on what commands you used.

There is no need to compile or manually install things beforehand. A plain CentOS install will do. Then run the FOG installer. The more you try to customize things (like compile and install things manually) the more issues you run into!

I just did a fresh FOG 1.5.9 install on a clean new CentOS Linux release 7.9.2009 setup. Worked perfectly fine. No issues.

UPDATE: After doing some investigation of the network device(s) configuration; I discovered the multicast looks to be configured properly on the router and switch stack.

For curiosity sake, I have attempted a multicast session for 4 laptops - my transfer rate is approximately 1.85GB/per min. This is exciting. I am going to gradually increase the load from there. If I can get away with 8 devices at a time that would be ideal.

Its strange because I know for a fact upon my first attempt a month ago, multicasting was terrible; it was virtually stationary.

Well, sync’ing everything up a second time worked like a charm. Thank you for your help Sebastian!!

@mesaman0182 You can find the login credentials for the database in /var/www/html/fog/lib/fog/config.class.php. Use those and run mysql -u username -p to open a connection to the local database. Instead of username put in what you find in the config file. It’s usually fogmaster for FOG 1.5.8/newer and root for older installs.

@bryan-wright said in Boot hangs after init.xz on Dell OptiPlex 9030 All-In-One:

It looks like the per-host kernel arguments get concatenated onto the global ones, though.

Yes, correct, all kernel args are pulled together. Tough I can’t tell you why it was coded this way back in the days. I fear changing this behaviour in FOG will cause trouble for many people. But you could modify /var/www/html/fog/lib/fog/bootmenu.class.php on your FOG server to skip the global kernel args when it’s set for a specific host.

@wasps-d said in Shutdown after image deployment instead of reboot:

I’m booting via USB (Unable to use PXE booting due to limitation set by admin)

This is where the problem is. Using the USB booting, its getting the kernel parameters from the grub config and not iPXE (because iPXE isn’t being used). What you need to use is edit the grub.cfg file and add shutdown=1 at the end of the kernel parameters for menu item 1.

As below:

menuentry "1. FOG Image Deploy/Capture" { echo loading the kernel linux $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4 shutdown=1 echo loading the virtual hard drive initrd $myinits echo booting kernel... }

Understand this will tell the kernel to shut down after any imaging task.

Okay so after George was kind enough to assist me with building a USB deployment method (which works great)

I have played around with the FZ-G1 on a docking station and I have been able to get these to PXE boot directly using a UEFI method.

It seems for some insane reason when selecting the IPV4 PXE option in the BIOS under boot override (which is 99% of the time the method I have used). It will become stuck at"ipxe initialising devices…"

If you specify LAN as the primary boot device and allow the machine to boot organically, it works… go figure?

So anyway this is now solved! Thanks for your help guys.

@GeorgeBells

This depends on how you downloaded fog in the past.

You could:

cp -r /path/to/fogproject/installation/packages/fog/lib/plugins/* /var/www/fog/lib/plugins/

Otherwise you could download it with:

git clone https://github.com/fogproject/fogproject cd fogproject/packages/web/lib cp -r plugins/* /var/www/fog/lib/plugins/

The only difference between yesterday and today was manually adding the repo, I’m not sure why it just instantly worked as soon as I did that. The major difference I can tell is that I have two ethernet cards, 1 internet connectivity, and 1 for the imaging network. Another service I’m running is sshd for remote control.

Before I installed the extra repo when I would run the script it would run without error and installed everything that it needed, and then it broke afterwards.

@sebastian-roth my colleague made me a joke by activating a second dhcp on a 4G terminal …

ty for answser

@gchartrandCRL For multicast to work properly all the hosts need to be “in sync”. Notice that when all the machines boot up they all wait on the blue partclone screen for everyone to join before it actually starts.

This is not only true for the first start but repeated on every partition. So all hosts need to wait and sync on the second, third, … partition. If a hosts arrives too late it can’t join this session and will drop out.

On the first partition FOG’s multicast manager waits for FOG_UDPCAST_MAXWAIT * 60 seconds but for all the other partitions the wait time is set to 10 seconds. This is usually enough but in some cases causes problems.

So to make a long story short, edit /var/www/html/fog/lib/service/multicasttask.class.php, jump to line 567 and change the value of 10 to 30 for example.

Before the change:

$i == 0 ? $maxwait * 60 : 10

After the change:

$i == 0 ? $maxwait * 60 : 30

Cancel all multicast tasks (or let them run to the end) and restart your whole FOG server to make sure it’s in a clean state. Then schedule a new multicast task and see if the same thing happens again.

@george1421 Thanks again for the help. This is probably where I’ll have to put a pin in this for now, because we restored the original sever and the duplicate server has been shut down for the time being. Hopefully we can circle back around to it soon, though.

@dashwell The linked post is years old. Please take a picture of the exact error you have on screen and post that here.

@SomeITGuy The adapter settings look fine I think. I suggest you configure your DHCP to serve UEFI and BIOS machines (see wiki article) and test PXE booting a hardware machine. Or if you want to quickly check UEFI PXE boot, then just change the filename to ipxe.efi for the moment and try it out.

@george1421 When i tape uname -a i got this: Linux fogclient.localdomain 4.19.145 #1 SMP Sun Sep 13 05:35:01 CDT 2020 x86_64 GNU/Linux
I don’t know why m not in the version Kernel.TomElliott.5.10.34.64
So i did it again, i downloaded this new version and now FOS see the second card and its working 😃
Thanks a lot for your help George, you can close this ticket.
Have a nice day.

@markus1204 Ahhh, I knew it would be something simple… 🙂

Run du -h --max-depth=1 /images/ on your FOG server to get a listing of the images’ size.

As well check out this post: https://forums.fogproject.org/topic/15501/request-dev-branch-web-ui-show-how-much-space-an-image-takes-up-on-the-server

@tesparza said in When do I know if image replication is done on a Storage node?:

Also when installing the Smart Installer client, what IP do i put.

fog-client communicates with the main FOG node.