@snap7B Any news on your test using the netdom command? Unfortunately I don’t have such an AD setup and won’t find the time to set one up any time soon. But I could try adding more debug output and provide that as a new DLL to you so we can figure out what goes wrong.

We had a similar message in a different thread. The OP at that time had a 486 industrial machine that was stalling issues even after I rebuilt a 486 kernel. Anyway, to the point we had to add acpi=off as a kernel parameter for that 486 to boot correctly. Once that was done it imaged correctly.

So lets try a host specific kernel parameter of acpi=off for this host.

@markbam Thanks for testing und letting us know! I will add this to the official code und it will be in the new fog-client releases from then on. But I won’t update the official 0.11.16 version. Feel free to use that DLL provided.

@VictorV I’m not 100% sure if this works, but you could try to make the partitions the relative percentage of size as to what you want and then capture as Resizable type image.

If I’m not mistaken, it will try to resize those partitions according to their relative size.

So if for example you have 😄 as 20GB of a 100GB disk and 😧 as 80GB of a 100GB disk, then it should come out as roughly 100GB for 😄 on a 500GB disk and 400GB for 😧

Alternatively and perhaps more flexibly, you could make a non-Resizable image with just the 😄 partition and then include a SetupComplete script that automatically creates the new partition for you using diskpart.

Or, if you are more comfortable/knowledgeable in Linux, you could also try to do the same as the above, but using FOG postdownloadscripts (scripts that run after deploying the image, but before reboot)

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