@george1421 My original FOS image is the latest available at Kernel Update GUI page, which currently is 4.19.6 (both bzImage and bzImage32)

I just finished one of the 2 machines with systems as described in OP. The capture job succeeded with not much as a single warning! The system with American Megatrends BIOS is also smoothly past the point in which the issue was happening. I also noticed another change, all of these machines sometimes got stuck in iPXE boot while loading “/default.ipxe”, at 0%, and forced me to reboot lots of times until randomly it boot correctly. After changing kernel and init versions, that problem vanished (I don’t know if things are related, tho).

My last machine with legacy Phoenix Awards BIOS did not complete the capture job, but looking at partclone.log I found out a bad block issue. I’m now trying to capture it using DD method, which increased time but is worth the test. I’ll report on it later.

I’m having this same issue with another type of Legacy BIOS machine, which BIOS and CPU details are:

• System Type Type: Main Server Chassis
• BIOS Vendor: American Megatrends Inc.
• BIOS Version: 2.1
• BIOS Date: 12/30/2011
• Motherboard Manufacturer: Supermicro
• Motherboard Product Name: X8DAL
• CPU Manufacturer: Intel
• CPU Version: Intel® Xeon® CPU E5620 @ 2.40GHz Intel® Xeon® CPU E5620 @ 2.40GHz
• CPU Normal Speed: Current Speed: 2400 MHz
• CPU Max Speed: Max Speed: 2400 MHz

I’m executing the tests as I post it, including that above described machine.

@george1421 Glad to know the details sufficed! I did the kernel rollback test before but didn’t uptade the init.xz file like you said. I will test this workaround right away and post the outcomes as soon as finished.

About the CPU details, follows below:

Main Processor: Intel® 2.12GHz (266x8.0)
CPU Brand Name: Intel® Core™2 Duo CPU
C1E BIOS Supported
EM64T CPU
Thanks!

Hello everyone,

• OS version: CentOS 7
• FOG version: 1.5.5

We deployed FOG 1.2.0 here, with which we had no problems at all, until some UEFI machines came to our network and we faced a need to upgrade the system. That upgrade was made by a fresh install on a brand new VM server.

The error on the title occurs when I try to capture image from machines with legacy BIOS. It starts well, but at some point it presents the mentioned error and stucks. I already tried a sort of bzImages, both x86 and x64 archs, to no avail.

I read about it in this topic:
https://forums.fogproject.org/topic/12181/rcu_sched-self-detected-stall-on-cpu-when-capture

… and tried to roll back kernel for 4.15.2, but I get a “FATAL: kernel too old” message and then everything freezes on client machine. I made Surface Disk Tests and Memtests, all passed.

These are machines that worked very well while I was using FOG 1.2.0, so I don’t know what happened. Unfortunatelly I cannot upgrade these machines BIOS firmwares because they communicate with industrial hardware that might fail if this kind of change is made.

My inventory data from these machines follows:

• System Type: Type: Desktop
• BIOS Vendor: Phoenix Technologies, LTD
• BIOS Version: 6.00 PG
• BIOS Date: 03/31/2008
• Motherboard Manufacturer: Intel
• Motherboard Product Name: Broadwater
• Motherboard Version: Fab D

That machine is on a different subnet than my FOG server and because I have both UEFI and Legacy BIOS in my network but DHCP is Win2k8 with no access for me, I’m using dnsmasq directing “undionly.kpxe” to these machines.

Any help will be appreciated! Thank you all in advance.