@sebastian-roth I wanted to try and keep our exisitng pxeboot menu with an option in that menu to load the fog pxe menu.

i’ve reaslied that would limit so many features of automation that it would make more sense to just add any menu items we already have from our exiting pxe menu and add them to the fog one.

@sebastian-roth Well I ran into a snag by not being able to multicast to deploy images. So for now I have left the Fog server as the master node. If I run into a space issue further down the road I can always move images over to the NAS and vice-versa. Space was really the only reason for using the NAS.

There’s also this article:
https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit

i actually think i’ve found the steps

Part 3 FOG Storage Node Configuration](https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node/21?page=2)

@sebastian-roth
@george1421

So updating firmware fixed the issue.

I’m not sure why but some middle firmware versions weren’t working. The 790s with A11 worked fine, but A18 produced the error, and then when they updated to A21 it worked.

We can mark this as solved. I appreciate everyone helping.

@mesaman0182 Ubuntu server is preferred. Stick to 20.04 for now. FOG has not been tested with 21.04. I hear there are a few bugs since Ubuntu changed quite a bit between the two versions.

So 10.118.0.59/16 is valid for your network?

It would be interesting to see if arp -a would return any hear arp requests. These settings look good, it should be working.

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