@doogxela Thanks for using the latest release and letting us know about issues.

The initial topic on kernel problem seems weird to me because the installer script uses checksums and would re-download the kernel/init files 10 times in a row if the checksum doesn’t match and error out in the end. So I can’t really see why there could be anything wrong.

On the other hand I see from your post that you are using a custom kernel image (bzImage_5.6.18) and I am wondering if that customization had anything to do with the boot issue??

About the slowness you want to check out this topic: https://forums.fogproject.org/topic/14267/upgrade-from-1-5-7-to-1-5-8-issues

Unfortunately we didn’t get enough response and didn’t have enough time to keep up this topic and figure out which part is causing the slowness.

@wuast94 Which version of FOG do you use? Haven’t done it myself in Docker, so I am just searching the web and forums and found this: https://wiki.fogproject.org/wiki/index.php/Install_FOG_in_a_Docker_Container

Sounds like you need to make sure NFS is loaded on the system hosting the Docker container! modprobe nfs && modprobe nfsd

Someone started one on docker.com but never kept it up to date: https://hub.docker.com/u/fogproject and https://hub.docker.com/r/lspiehler/fogproject/

And you can find various more sources :https://github.com/RustyBower/docker-fog

i could register a machine and trying to make the image. no i get an mounting error for /bin/fog.upload but thats another topic 😄 try to find out what this problem is

Thanks for your help 🙂

@Fog_Newb said in Odd issue with Win 10 UEFI images after updating from 1.5.9-RC2.15 to 1.5.9-RC2.17:

Nobody else has access to either FOG server and the only change made was the update from RC2.15 to 1.5.9-RC2.17

And automated Updates…

RC2.19 is not much of a difference. Just preparing for the actual release to come very soon!

@Eazis Sounds good, thanks for the feedback!

@mwolfe60 @wambat10 Thanks for the quick response! I just pushed a fix to the dev-branch. So we have that right in the final release as well.

@Sebastian-Roth
https://forums.fogproject.org/topic/14733/permission-denied-on-boot-php

Mod note: Moved topics to new above thread -Geo

@Sebastian-Roth We have find out that bios mode had to set to “Legacy Support” with priority on “UEFI First” and not with bios mode on “UEFI”.
Problem wasn’t coming from FOG.

Sorry and thank you for your help.

@fogusnew Well done and thanks for posting this here. Might be useful for other users as well! 🙂

Solved. See here.
Basically I changed the php version to 7.3 (which took a lot of effort…)

@seribe I am sorry but the stack of things to do is huge and I haven’t found the time to look into this as I need to focus on the core code. The plugin code was developed (and is kind of maintained) by @Fernando-Gietz. He might find some time to look into this.

@lakk said in Host Management - "No Data" instead of date - FOG 1.5.7:

but when i open the “host management”, its is written “No Data” instead of a date when the image was captured:

Now that I have tested myself and read through this again I see what I have been missing here last time. The column Imaged is only being filed with a timestamp when a host is being deployed (imaged) but not when captured from it! This has not changed in the past and I don’t think your Vbox settings change has anything to do with this.

Now to your second point about the dashboard display. When I do a deploy I see:

Free: 9 Queued: 0 Active: 1

So working all fine from my point of view. Unfortunately the pictures you posted are not accessible anymore and so I can’t be sure I really get what you mean.

I’ll mark this topic as solved because the first question is being answered. Please open a new topic with screenshots about your other question. We try to keep things separate to make it easier for other people to follow and find help in the forums.

@3mu said in FOGSnapinReplicator.service failing on fresh install:

php[9501]: Could not open input file: env

I totally missed this part in the log when looking through this some time ago. Have been way too busy with other things at that time and obviously missed this. This issue has been fixed a while ago and I cannot imagine this to be the case in the release candidate versions or dev-branch anymore. I just did a test install using dev-branch on Ubuntu 18.04 and I don’t see the messages as stated above.

From my point of view this has nothing to do with specifying a router or not!

@bishopga Check out the BIOS settings to see if the disk controller is set to AHCI or RAID? FOG (Linux) is not able to handle the controller in RAID mode…

The answer lies in the configuration of the routers. They must be able to route client requests from the client’s network to the DHCP server’s network. One of these simple rules of the router is " IP helper."This simply tells the router to redirect DHCP requests to the known IP address of the DHP server. I used to always use a VPN or proxy server, but this slowed down my connection and my computer. There are some VPNs that are worse than google chrome, it was mostly because I was spending time on Pirate Bay and it was blocked a lot. You can use one of PirateBay proxies to access it always with no problem.

@george1421 said in Getting Kernel Panics after upgrade to 1.5.9-RC2:

I’m kind of curious if the installer looks specifically for 127000 and will only increase it if it matches. I’m surprised that 250000 remained after the upgrade to the latest release.

I have not had a look at the code for this yet but it might be the case…

george1421, you are a bad mofo! I’ll try this out later today and report back with the results.

Thanks brotha!

@george1421 Hi folks - so sorry huge influx of users back today, had to get on with other bits.

All three of your points correct though George yes. Although I’d add in on point 2 that it won’t WoL until power is unplugged for about 20 secs and also, following that, the PC is then booted to BIOS for a few seconds or paused at the polling for DHCP part of POST, and then shut down again. That will “prime it” for WoL and WoL will work thereafter until Windows is booted, then it won’t until you repeat the above “priming” process.

Thanks again everyone.

At this stage it’s not looking like a FOG problem strictly, so if you’re getting sick of it it’d be fair to say it’s outside you folks’ remit but I do appreciate the help muchly.

Hello,

This thread is very well referenced by search engines so I complete it with my experience.

I installed a new storage node on my FOG (Debian 8 + 1.5.7) setup (before : web server / central node + two storage nodes, after : web server / central node) + three storage nodes).

During the installation, I failed on question “What is the IP address or hostname of the FOG server running the fog database?”. The default value is the storage node itself. The mysql command given by Wayne Workman worked from my new storage node, the problem was on FOG side.

I understood my mistake. So, I modified “snmysqlhost” in /opt/fog/.fogsettings with the address of the FOG web server / central node.
I restarted the FOG services (systemctl restart FOGSnapinHash FOGImageReplicator FOGImageReplicator FOGImageSize FOGTaskScheduler FOGSnapinReplicator FOGPingHosts FOGMulticastManager).
The problem was still here.
I rebooted the server.
The problem was still here.

I executed installfog.sh a second time on my new storage node. It detected the existing installation. It did some stuff and… the new storage node works fine.

Regards.

@DJslimD1k the mysql value is still pretty high. Higher than I might expect. But switching from isam to innodb helps because isam uses table locking on update and innodb uses row locking. With a lot of clients polling that table locking method becomes a road block.

I didn’t look back in the tread, but didn’t your fog server have 10 vCPUs? If so I would drop those back to 4 and see where performance settles out to. Overcommiting on vCPU is worse then not providing enough vCPUs to handle the load.

Having that many php-fpm workers just means that your server is busy with requests. There is some performance tuning you can do with the php-fpm settings on a busy network by switching from dynamic to allocation to static allocation.