@Wolfbane8653 A BIOS update may be required.

Other than that, trying out this kernel here might be interesting: https://drive.google.com/open?id=1ZiRWrrN3dv26bLwW8GAEdLtzGw5xkyQI

@Wolfbane8653 Can you share a picture of the result with acpi=off?

Also can you share the specifications of the system?

The original problem in that thread was solved afaik.

That said, rcu_sched can actually be caused by many different things, your case seems different.

Since it’s directly preceded by ACPI errors, disabling ACPI as George suggested is a good start.

@Middle Unfortunately, aside from the latency kernel argument there isn’t anything else we can do from our side as far as I’m aware.

Unfortunately manufacturers don’t always check how their stuff works on linux…

@Mr_Matten Ah, glad you figured it out!

@Mr_Matten Is the VM hard disk “dynamic” in size or fixed? (if it’s dynamic, try making it fixed instead, large enough to deploy the image of course)

Might also be worth going over the settings, especially CPU, since during deploy the client (the device you’re deploying to) will uncompress the image and then write which is CPU intensive.

It also needs enough RAM ofc.

Might be worthwhile to show us the VM settings altogether

@Mr_Matten Just to clear things up are you trying to capture or deploy the image when it goes wrong?

This means that it couldn’t find any partitions it can resize automatically (eg NTFS, EXT4).

If you are using different partition types that it can’t resize, then you need to change your image type to a non-resizable option in the FOG WebUI

Dual boot is tricky since you’re dealing with potentially two different OS types (eg Windows and Linux) which require different processing.

That said, I believe the best image type settings are Multipartition Single Disk with OS as “Other”.

Of course this means that deploying to devices with different disk sizes is either not possible or otherwise produces undesirable results.

But if all devices are the same anyway, then it should work fine!

Final note: resizable image type doesn’t actually reduce the size of the captured image (as far as I know), it just provides flexibility for deployment.

Empty space is still not captured under Multiple Partition capture and it will get compressed so the size should be comparable.

Only RAW capture produces larger images I believe.

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