@FogNewUser Ok this one almost tells me what I need to know, from the picture perspective it would be handy to see more to the left edge to get the complete interface name.

But what I see you have built in network adapters (knowing its a P710) helps with the guessing and maybe 3 riser card network adapters. At this point I don’t see any interfaces with IP addresses, so it looks like you have a bunch of unconfigured interfaces.

From the screen shot it looks like you have a debian based OS (could be ubuntu which is debian based). So you will need to use the network manager if you have the gui loaded to define an IP address for your fog server. IF you have fog installed AND it was working you can refer to the file /opt/fog/.fogsettings to what the IP address of the fog server was when FOG was installed. You need to move it back to that IP address or you will have to make several changes to the fog configuration since the IP address is hardcoded in a few spots.

@Sebastian-Roth Didn’t has time, sorry. The whole PLUGIN thing was actually new to me, so now after quick navigation in settings, I’ve explored PLUGINSYS checkbox. 😃 Thank you, now I’ll sped some time to investigate all of the “mainline” plugins. Thank you for advising me to use this plugin.

PS
Aaan,d I could’t find any functionality that I’ve implemented, also the whole thing seems not working, because I couldn’t restrict Support role from accessing “Access Controls”, where they can revert everything back.
I also reported to this topic about last problem: /topic/10918/access-control-plugin/10

@zclift15 As well read through this: https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit

@Sebastian-Roth sorry for late reply. looks like its ok now

@Tom-Elliott looks like the password was different than in the setting gonna change it to that and i will let you know

@AndrewG78 I’ll try to answer all the things you brought up. But first let me state that so far you haven’t been clear (from my point of view) what has happened on which FOG server. For replication there are at least two parties (servers) involved and it’s important for me to understand which one showed the issue. I will get to that point later on again.

Although replication services are disabled, there is still some replication done between storage groups.

Disabled on which server? All FOG servers?

1 a) The question is, was this a proper behaviour?
I thought replication is done only within the storage group members(nodes).

As I haven’t invented the replication algorithm I don’t know it as much as Tom would. But reading the docs I get the impression that this is expected to happen: https://wiki.fogproject.org/wiki/index.php?title=Replication
6. If the node currently checking is the "primary master group" for the data it's working, it will attempt replicating its data to the master of each of the other groups the data is assigned under.

1 b) Are there any other services that could do this replication?

You have two nodes and both have replication services running on them!

The high cpu load(kworker and vsftpd) was related to replication and lack of disk space. Replication processes did not stop even if there was 0% of free space.
I think this is a bug.

The vsftpd part is what I would call the receiving node in this constellation. This might give you an idea which node was causing this. Disks can run out of space for many different reasons. I don’t see why our replication service should constantly check and stop replication just because of little space. Every server needs a good working disk space monitoring to warn the sysadmin to take care of it. See it from this side: If we add a check and simply stop replicating because of a lack of disk space people who don’t monitor their disk space won’t notice possibly for month and might blame us about replication not working. Although it’s not nice to hit a full disk this will eventually cause trouble and make the sleeping sysadmin aware.

3 a) Should there be some smarter log rotation ?

As well something a sysadmin should be able to handle. Linux has logrotate and I don’t see why we should invent that again.

3 b) "No new tasks found "is logged every 10s - Can we change this time somehow ?

Yes, web UI -> FOG Configuration -> FOG Settings -> FOG Linux Service Sleep Times -> MULTICASTSLEEPTIME

Sorry if my answers sound a bit impolite. I don’t mean it that way! Just wanted to show you that things can be seen from the other side as well.

Ok update on this thread so we can put it to bed.

I built 2 custom FOS Linux kernels the fist was targeted to a 486 and the second was targeted to the Geode processor. Bot would throw the issue with an unstable clocksouce. We could only see this error when we change the linux kernel logging level to 7. After some google fu and attempting a few kernel parameters that dealt with the clocksouce I found a references to apci=off. That was the actual parameter that solved the kernel boot errors. The OP was then able to run a deployment in debug mode to completion.

So while the actual problem isn’t in line with the thread subject. The issues were this.

The standard FOS Linux kernel has a minimum supported level of processor of i586. I had to build a custom kernel with a minimum processor level of i486 to get the kernel to boot.

Because of the hardware we had to specifically turn off acpi in the kernel using the kernel parameter of apci=off

@davido38 said in kernel panic:

After update fog from 1.5.6 to 1.5.7 i have kernel panic

As George just said this shouldn’t happen on an upgrade. The schema update should take care of this. Possibly you have not opened the web UI since upgrading??

@cammykool Is this topic still being discussed or done? From what I see in the PCAP the PXE boot cannot work. No servername (next server) given, two DHCP answers that might confuse the client…

@Jurgen-Goedbloed I am not exactly sure I get what you say. Has the SSL path option been wrong? What was it set to? Is this something the installer messed up?

Or do you mean the permissions were causing this issue? I have not messed with umask in a long time but I do remember this can cause quite some unexpected situations. I can imagine this could also cause trouble in other places where the FOG installer does not explicitly set permissions.

Just in case anyone comes across this. The version used here (0.11.0) had an issue with that. The most current version (0.11.16 as of now) is known to do rename/ad join, reboot, snapin properly (ref).

@Mr-Taco Here is an article from Chris at Microsoft that covers reimaging rights. https://community.spiceworks.com/how_to/124056-reimaging-rights-for-windows-10-licensing-how-to

I can tell you that if you have 100 Window 10 OEM licenses, you only need to purchase (1) Windows 10 Pro VLK key to deploy to all 100 of those Windows 10 Pro OEM machines. That rule only works for the same version. You can not purchase 1 Windows 10 Enterprise VLK key to do a version upgrade to those 100 Win10 Pro OEM machines. For a version upgrade you need a 1 for 1 volume key. So 100 OEM would require 100 Enterprise keys.

But back on the 1 Win10 Pro VLK key, you can purchase that key but you need to get a count of 5 so people will often purchase Win 10 Pro VLK key and 4 windows (4) server CALs (or something else cheap that you can’t get enough of anyway) to get to your count of 5.

@Quazz and @george1421 Thank you both. I appreciate the assistance. I tried ipxe.efi and it worked! I now have my Dell Optiplex models PXE booting using UEFI just the way I was hoping. Only oddities is the screens are a bit smaller, and the PXE boot shortcut is now “esc” instead of my custom shortcut. That is a small first world problem however. Thank you all again this community is fantastic!

@Arjenbulkens Any news on this?

@vanopstp15d try

mysqlcheck -r fog

There is a wiki page to reset the default fog admin’s password. Its here: https://wiki.fogproject.org/wiki/index.php/Reset_WebUI_FOG_password

I would also look at both the apache and php-fpm’s log files in /var/logs directory to see if there is any error messages listed in there.

Next Server IP address was wrong on DHCP server. TFTP is working now! Thank you @george1421

@rodluz said in 503 Error and stuck at "attempting to update database":

So I changed the pm.max_children setting to 150

Good catch on the max_children setting. If you would have had a current version of FOG that setting would be 35. I think 150 is a bit excessive since each child consumes ram. I think 50 might be a better choice to start with. Most people don’t start 20 simultaneous unicast streams so I can say we’ve not run into this issue before with the standard 35 max children. 5 IS a bit low.

So to recap you had 2 issues, one was the memory limit and the other was the max children setting.

Once you get past your image push crunch, you might consider upgrading to the latest version of FOG.

Well I can say, that is a VERY good question. FOG is only intended to clone local block level devices. iSCSI is not necessarily in scope. With that said, it would be interesting to see it work. 😉

So let me ask you this, if you manually register this VM and then schedule a debug deploy task (tick the debug checkbox before you hit the the schedule task button. Then pxe boot the VM. This will drop you to a linux command prompt on the VM. So to the question (since you seem to be familiar with iSCSI) can you mount the iSCSI lun from the FOS Linux client? If you can then we might have a solution. I don’t know off the top of my head if the iscsi tools are install in FOG Linux (they should be but I don’t know for absolute). If you can connect to the iSCSI LUN then document the process so we can create a bash script to do the same.

@Sebastian-Roth It’s worked ! I’ve done your solution three times in a row and it seems worked.
Thanks you for your job and your disponibility.