Posts made by LOF

@Wayne-Workman Thanks Wayne, that’s good to know! LM is my favorite distro and what I’m most familiar with. They do have a version based on Debian called ‘LMDE’ https://www.linuxmint.com/download_lmde.php Being a long-time FOG user/fan it seems maybe a distro designed more for a server than a desktop role would be better. Up until now I’ve never had any issues at all running FOG on Linux Mint but I’m not averse to switching to something else that works better and is more stable. One of the things I’ve learned since becoming involved with Open Source projects way back in 1997 is “The right tool for the job.”

@george1421 Ok great and VERY helpful! Thanks!

@Sebastian-Roth Great, thanks for helping to get this working on Linux Mint! One last question: What’s the recommended/most-tested distro for running FOG? Is that still CentOS?

@Sebastian-Roth Good news! I did a git-pull this morning from dev-branch, ran the installer and it worked! I’ve created an image and will test capture/deploy but I expect it will work fine. Question: Any risk staying on the dev version or should I plan on switching to the next stable version when it’s GA?

@Sebastian-Roth Thanks for pointing that out, I didn’t do a git pull initially, just downloaded the .tar.gz I’ll grab that version and see how the install goes. I’ll let you know.

@Sebastian-Roth Hi Sebastian, thanks for the response and sorry for the delay. The version showing in the current installer script I have is: Version: 1.5.9-RC2.10 As for /opt/fog/.fogsettings I’ve confirmed again it isn’t there and the /opt directory is empty.

I ran the installer again to get the version number and it failed:

fog/fogproject-dev-branch/bin/error_logs/fog_error_1.5.9-RC2.10.log !!
!!!

ii wget 1.20.3-1ubuntu1 amd64 retrieves files from the web
ii xinetd 1:2.3.15.3-1 amd64 replacement for inetd with many enhancements
ii zlib1g:amd64 1:1.2.11.dfsg-2ubuntu1 amd64 compression library - runtime
New password: Retype new password: passwd: password updated successfully
Failed to stop php-fpm.service: Unit php-fpm.service not loaded.

Thanks and let me know if I should download/try a different version.

@Sebastian-Roth Thanks Sebastian, I already know the answer and it’s Yes. Also, I’ve already pulled down the dev-branch and got the error before my initial post. So what’s next? Should I delete the previous dev-branch install and download/run it again?

@george1421 / @Sebastian-Roth Sorry for the delayed response, it’s been a busy work-week. Since I have a fresh install of LM 20 I’d be happy to pitch in to help determine the cause of the issue if you can send me some instructions. This isn’t an urgent issue for me but I’m definitely willing to help out if I can. I also have a presence over at https://forums.linuxmint.com/ so I can request help there if needed. My ability might be delayed a bit during the work week but I’d have more time during weekends. I appreciate all the time/effort you both put into making FOG such a great imaging solution!

@Sebastian-Roth It’s a fresh install, /opt/fog/ hasn’t been created yet.

Sebastian/George, thanks for your responses. Let me know if you also need to see all or part of the fog_error_1.5.9-RC2.10.log file. I didn’t include it initially because the only error seemed to be at the bottom, i.e., Failed to stop php-fpm.service: Unit php-fpm.service not loaded. Then again, perhaps I missed something?

@george1421 said in Failed to start php-fpm.service:

systemctl --type=service|grep php

Hi George, here’s the output of that command:

php7.4-fpm.service loaded active running The PHP 7.4 FastCGI Process Manager

@Sebastian-Roth Hi Sabastian, I’m using the current version (Linux Mint 20 Ulyana - Cinnamon Edition) Here’s the output of ‘hostnamectl’:

Virtualization: vmware
Operating System: Linux Mint 20
Kernel: Linux 5.4.0-40-generic
Architecture: x86-64

Hi All, not sure if this is a FOG problem or Linux problem so forgive me if I’m posting in the wrong category. Since last week I’ve been trying to get FOG going on a Linux Mint VM on my laptop and never had so many issues getting the installer to work. Tried the latest stable version and that bombed at the end. Did a lot of searching in your forums and found a thread saying to install the latest development version for issues with php7 on Ubuntu. I did that but keep getting:

Failed to start php-fpm.service: Unit php-fpm.service not found.

…at the end and in the fog_error_1.5.9-RC2.10.log You guys are probably super tired of problems running on Ubuntu-based distros like Mint and I’m open to switching if that’s what it takes to get FOG working. It’s just that Mint is the distro I’m most familiar with.

I guess it’s not as simple as a tweak to the install script to have it refer to php-fpm as php7.4-fpm because that’s what’s showing in /etc/init.d and is what’s currently needed to start/stop the associated service.

Any help would be appreciated.

Thanks,

-LOF

@george1421 said in Adding storage nodes:

For your esxi server, how many network links does it have into your networking infrastructure? 2? or is it 10GbE?

The ESXi host is on a segmented network and has 4 physical adapter connections but I don’t think all of them are being used. I’m pretty sure the number is two because I’ve been talking to our network team about the possibility of going to 10GbE which they say will be a possibility down the road but not right now. I’ll definitely test deployments thoroughly before pulling the plug on the current/physical node.

Thanks for the tips about adding a LAG group and/or changing the location of /images, good to know about those options.

@george1421

Correct, we rack 20 - 22 laptops at a time and use a group deployment task to push images to them.

Image push time varies. I haven’t actually timed it but I’ll give a rough estimate and say it’s around 30 - 40 minutes for the first 6 - 10 laptops that we PXE-boot first but then the push time decreases quite a bit as soon as laptops receive the image and shut down. It seems like the last few remaining laptops that receive the image go really fast.

Based on the information you’ve provided, I’ll probably go with this plan: (1) Spin up a new storage node on our dedicated ESXi host, register it on the primary FOG VM and test to ensure deployments are working. (2) Power off the existing-physical storage node and remove it from the storage tab in the FOG console on the primary FOG VM. (3) Test deployments for a while and spin up/register an additional storage node or try multicast if we need faster deployments.

Let me know if you see any problems with that plan or have any other recommendations.

@george1421

Thanks George, we’ve been using FOG to do mass deployments for new computers. We typically deploy to up around 20 new laptops simultaneously multiple times a day. Meaning that in a typical day we could image 60 or more laptops. This has been working fine using a single storage node and deploy tasks from groups. I tried using the multicast deployment method a while back but couldn’t get it to work properly and thought it was because of problems with old switches we were using. We’ve since upgraded our infrastructure, including switches so I may try it again to see how it goes. I like using the group-task deployment method because of the auto-shutdown option that we can select. It makes the process a lot easier because we can schedule the task, PXE-boot a couple racks of laptops, walk away after they all start receiving the image and come back to see them all powered off. I haven’t looked yet after the upgrade but it seems like I remember auto-shutdown not being an option with multicast deployments.

Anyway, based on my description above, would you recommend two storage nodes or just stay with one?

Hi George, thanks for great explanation! So, even thought the primary FOG server isn’t set to deploy stored images, it still stores images that have been captured and will facilitate capturing any new images? i.e., I should see copies of all captured images in /images on the primary FOG server? Technically, the objective here is to create a new storage node as a VM so that we can safely retire the storage node running on physical PC hardware. If more than one node isn’t needed, I won’t create more than one.

Thanks!

-LOF

Dear FOG gods,

I recently upgraded my FOG VM to the current stable version and I’m planning to add two additional VMs configured as FOG Storage Nodes. A while back, I read somewhere (Wiki?) that having multiple storage nodes is recommended because it takes some of the performance load off the primary FOG server. In my current configuration I have the main FOG server NOT set as an active storage node and have a physical PC loaded up with 2 TB of storage set as an active storage node. I want to retire that PC, spin up two VMs and use them for image storage/distribution.

My question: If I do what I describe above, will the images stored on the existing (physical) storage node seed/replicate over to the new storage nodes automatically or will I need to manually copy the images over?

Apologies if my question has already been answered in a previous forum post or wiki entry, please include the url if that’s the case, no additional explanation required.

Thanks for all the great work you guys do to keep FOG the best-free imaging solution out there!

-LOF

Thanks George/Wayne, so the DHCP server at the office I was at yesterday didn’t have options 66/67 set so it’s not that and the ltsp.conf showed the correct IP addresses. I thinking now I may have been shooting myself in the foot because I previously mentioned that I changed the network configuration for my vm in VMware Workstation from Bridged over to NAT’d in order to test. I think that’s somehow related because I did that yesterday shortly before leaving and noticed default.ipxe was getting served from a new address, …from the NAT’d LAN address my vm was assigned when I switched over to a NAT’d connection. A NAT’d network configuration won’t work because clients I try to PXE-boot can’t see the FOG server, even when connected to the same switch. The only network configuration under VMware Workstation I’ve ever been able to get FOG working correctly with is a Bridged connection. At this point I’m probably just going to burn things down and start over, i.e., re-run the FOG install and also the dnsmasq installer. But this time I’ll leave it on the Bridged connection and won’t switch it. I’ll let you know how it goes after that.

@lof I spent a little time searching the forums and I checked every configuration file my searches referenced. I checked /tftpboot/default.ipxe and it’s got the right IP. I also checked /opt/fog/.fogsettings and it had the correct IP but wrong router/dns addresses I changed those to reflect my current environment and restarted my FOG server VM but it still tries serving up default.ipxe from the wrong IP. I’m at a loss where it’s getting that from. On the bright side, I’m getting a really good CLI/Vi refresher.