@Middle Try setting the kernel argument as a global setting instead of on the host page. (FOG Configuration -> FOG Settings -> General -> Kernel args)

This problem may also be resolved with SSD firmware updates if available.

I’d also be interested in the results of kernel args pcie_aspm=off and pcie_aspm=force (do not set the latter as global)

Only set one of the 3 kernel arguments.

This problem is caused by ASPM and how certain devices interact with it. The reason it’s a problem specifically for NVME devices is because of their PCIE connection. A lot of these drives have buggy implementations (sometimes fixed in firmware updates)

@Sebastian-Roth Hmm, I may have been misremembering, though their CONFIG_NR_CPUS
is going to be much higher than 8 at the very least. (at least 512 afaik)

The only difference I can find is that CONFIG_MAXSMP enables CPUMASK_OFFSTACK
, which it requires to function correctly I believe (or any high CONFIG_NR_CPUS would at least)

@markbam I’m unsure about how this would resolve the problem as it currently exists.

As I understand it, the problem is that nodes overwrite the status constantly.

While a time check would reduce server stress somewhat, it won’t prevent a certain subnet from ‘getting there’ first and setting an incorrect value. (presuming subnets can’t ping to other subnets, you’d only see what one specific subnet sees, in other words)

So the bug is that storage nodes try and ping all hosts rather than only their own, if I’m getting it right.

@Sebastian-Roth I believe there is a configuration where you can (ICH9 chipset + virtio-net network adapter)

@Sebastian-Roth As far as I understand it, Xenomai implements a patch to the kernel that does all kinds of stuff, potentially it’s not compatible with their patches, but as far as I know CONFIG_MAXSMP is in fact enabled by default on Kernel 4.4+ or so on all major distributions without issues.

That said, I don’t mind testing it.

As an aside, Linux kernel 5.3 has added native support for keyboard in these models.

@rocksteve69 You can set it for all under FOG Configuration -> FOG Settings -> General -> Kernel args

@rocksteve69

Can you give it a try with kernel parameter nvme_core.default_ps_max_latency_us=5500 ?

@Dan_Ansel No problem, there’s so much to think about, it can be hard to figure out what’s going wrong!

@Dan_Ansel Yes, /tmp can be permissions 777 safely.

This error can also be caused by AppArmor I believe, but we’ll start here.

@Dan_Ansel Can you check permissions on /tmp ? Something like sudo ls -lah /tmp

It can’t create it’s temporary file required for startup, which might be the entire cause of the issue.

Please give the output of tail -50 /var/log/mariadb/mariadb.log (not sure the path is same on Debian)

@george1421 Yes, I think that’s why it was left at 8 in the config, though perhaps some CPUs don’t handle a majority of their cores being ignored very well?

The problem here is that you have 2 DHCP Servers.

192.168.6.15 and 192.168.6.152

This error is typically resolved by using the Reset Encryption Data button for the host/group in question in the FOG web UI

We may have to enable kernel config option CONFIG_INTEL_IDLE to improve support for certain Intel CPUs.

We may also want to to bump up CONFIG_NR_CPUS from the default of 8 to 512 (common value on modern kernels) at least on the x64 config, though this one shouldn’t cause a crash.

That said, I am doubtful that would resolve this issue.

@astrugatch That error is usually resolved by resetting encryption data from FOG Webui for the host/group

grep "put ip of client here" /var/log/apache2/access.log | tail for the access log thing

@george1421 The unknown request type null also occurs when you try to start the imaging task without having booted in “imaging mode” (aka you can’t start fog capture/deploy from debug, only from Capture, Deploy or Debug Capture/Debug Deploy)

@TammyTinkleToes90

1. It’s possible the previous admin scheduled a daily image deployment that contains a broken NIC driver. (check scheduled tasks)
   The second possibility is a snapin that is done every day. (check snapins)

2. Check fog client hostname settings

3. Some devices have somewhat buggy UEFI firmware, especially with network boot. BIOS update might help.

@Jay-Bosworth That client is awaiting a scheduled reboot as far as I can tell, which is why other actions aren’t happening, you need to sort that out before any useful info is logged to begin with.