Tainted: [S]=CPU_OUT_OF_SPEC
On all five kernels
Booting with Fedora Live USB works fine. All disks, RAID5 partitions, volume groups and logical volumes are readable.
Other kernels are 6.19.11-200, 6.19.12-200, 6.19.13-200, 6.19.14-200 fail with the same errors.
Is this in a VM or something? I note the ancient BIOS date - is this an old machine or virtual tin?
The message means that the CPU is not running within normal validated parameters or specification - heavily overclocked, undervolted, overvolted, etc.
All kernels will fail if this really is the CPU either dying or being ran outside of what the kernel considers acceptable.
See: https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html for possible causes. What CPU do you have?
Yes, it is an old piece of physical hardware (BIOS 03/09/2012) with an Intel Core i5-2380P (4 cores). Still worked fine as file server.
There have been Intel microcode updates since 2012: https://www.techspot.com/drivers/driver/file/information/18136/, which would normally come in a BIOS update, but might be installed using linux.
First tried to load the defaults for the BIOS and boot, but that did not work.
Booted from a Fedora 44 Live USB (kernel 6.19.10-300.fc44) and that (still) works.
Tried to update the microcode, booted from that Live USB, but there is no /sys/devices/system/cpu/microcode/reload
A touch of that file results in “Permission denied”
I can try finding a newer BIOS update for the computer.
It’s a MEDION model It seems and medion.com has a download page for drivers and bios.
For Fedora, the Intel instructions for reload have:
Reload the microcode. Reloading applies the microcode update without needing to reboot the system. Reload will trigger a microcode refresh action.
Use this command for Linux v3.6 and later:
echo 1 > /sys/devices/system/cpu/microcode/reload
That needs to done with root privileges, but without a root login you can use:
echo 1 | sudo tee /sys/devices/system/cpu/microcode/reload
Started the SSH-daemon:
ssh liveuser@192.168.1.250
liveuser@192.168.1.250’s password:
liveuser@localhost-live:~$ su -
Password:
root@localhost-live:~# echo 1 > /sys/devices/system/cpu/microcode/reload
-bash: /sys/devices/system/cpu/microcode/reload: Permission denied
Still no luck.
Hi,
The key message here seems to be:
Tainted: [S]=CPU_OUT_OF_SPEC
From what I understand, this usually means the kernel thinks the CPU is not operating within expected parameters.
Common reasons can be:
- missing or outdated CPU microcode
- very old BIOS/firmware
- hardware instability (aging CPU, power issues)
- or sometimes firmware-level tuning
In your case:
- all kernels fail the same way
- Live USB works fine
- hardware is quite old (BIOS from 2012)
This doesn’t really look like a kernel regression. It points more toward a firmware or microcode-related issue.
One possible explanation is that the installed system loads CPU microcode early during boot, while the Live environment behaves slightly differently — which could explain why it still boots.
A few things you could check:
-
Is microcode installed?
dnf list installed | grep microcode -
Is it actually loaded at boot?
dmesg | grep microcode -
If possible, check for a BIOS update
(a lot of microcode fixes are delivered that way) -
As a quick test, you could try disabling early microcode loading:
dis_ucode_ldr
(just for testing, not as a long-term solution)
If microcode looks fine, another (less likely) angle could be an initramfs issue. In that case you could try rebuilding it:
dracut -f
Given the age of the system, it might also simply be hardware starting to show its limits, and newer kernels are just exposing it.
At this point, I’d lean more toward a firmware/hardware issue than a Fedora kernel problem.
Curious to hear what you find.
Regards,
G/T
As far as I know the microcode is installed and gets loaded at boot. But there is no way to check, because only a live USB disk works.
Tried to get into the storage to get the information, but:
root@localhost-live:~# mkdir /mnt/root
root@localhost-live:~# mount /dev/mapper/vg01-root /mnt/root/
root@localhost-live:~# mount /dev/md127 /mnt/root/boot/
root@localhost-live:~# mount -o bind /dev /mnt/root/dev/
root@localhost-live:~# mount -o bind /proc /mnt/root/proc/
root@localhost-live:~# mount -o bind /sys /mnt/root/sys/
root@localhost-live:~# mount -o bind /run /mnt/root/run/
root@localhost-live:~# chroot /mnt/root/
Bus error (core dumped) chroot /mnt/root/
root@localhost-live:~#
Hi,
That last detail you shared is actually quite important:
Bus error (core dumped) chroot /mnt/root/
That’s not something you’d normally see in this situation. At this point, you’re just using the Live USB and trying to enter your installed system — so a crash here means the problem is deeper than initramfs or systemd.
Put simply: this isn’t just a “boot config” issue anymore.
What it likely means
A bus error usually points to a low-level problem — either with the CPU, memory, or how the firmware interacts with them.
If we connect all the dots:
- Your installed system panics very early
- The kernel reports
CPU_OUT_OF_SPEC - The Live USB boots, but even a simple
chrootcrashes
This starts to look less like a Fedora issue and more like something unstable at the hardware/firmware level that newer kernels are exposing.
What I would check next
Nothing too invasive, just a few high-value checks:
1) Memory test (important)
If you have access to memtest86+ from GRUB or a tool on the Live USB, run it.
Unstable RAM can cause exactly this kind of random crash.
2) Look for CPU / hardware errors from the Live system
dmesg | grep -i mcedmesg | grep -i microcodedmesg | grep -i error
If there are machine check errors or microcode warnings, that’s a strong clue.
3) Try booting once with microcode disabled
From GRUB, add:
dis_ucode_ldr
Just for testing.
- If it suddenly behaves better, you’ve likely hit a microcode/firmware edge case.
4) BIOS update (really worth it here)
Your BIOS is from 2012. A lot of CPU fixes are actually delivered via BIOS updates, not the OS.
With modern kernels, that gap can start to show.
Bottom line
At first it looked like a microcode/initramfs issue.
But with the SIGBUS during chroot, it now leans more toward:
→ firmware or hardware instability (CPU / RAM),
possibly triggered by newer kernels.
If you can share what you get from dmesg | grep -i mce, that would help narrow it down quite a bit.
Regards,
G/T
1) Memory test → OK
2) Errors from Live system
root@localhost-live:~# dmesg | grep mce
root@localhost-live:~# dmesg | grep -i microcode
[ 0.352272] microcode: Current revision: 0x0000002f
[ 0.352274] microcode: Updated early from: 0x00000025
[ 3.586694] [drm] Loading TURKS Microcode
root@localhost-live:~# dmesg | grep -i error
[ 0.638772] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20250807/psargs-332)
[ 0.638783] ACPI Error: Aborting method _SB.PCI0.SAT0.SPT0._GTF due to previous error (AE_NOT_FOUND) (20250807/psparse-529)
[ 0.639744] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20250807/psargs-332)
[ 0.639754] ACPI Error: Aborting method _SB.PCI0.SAT0.SPT0._GTF due to previous error (AE_NOT_FOUND) (20250807/psparse-529)
[ 0.826463] RAS: Correctable Errors collector initialized.
[ 0.950857] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT1._GTF.DSSP], AE_NOT_FOUND (20250807/psargs-332)
[ 0.950872] ACPI Error: Aborting method _SB.PCI0.SAT0.SPT1._GTF due to previous error (AE_NOT_FOUND) (20250807/psparse-529)
[ 0.951965] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT1._GTF.DSSP], AE_NOT_FOUND (20250807/psargs-332)
[ 0.951974] ACPI Error: Aborting method _SB.PCI0.SAT0.SPT1._GTF due to previous error (AE_NOT_FOUND) (20250807/psparse-529)
[ 1.262700] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT4._GTF.DSSP], AE_NOT_FOUND (20250807/psargs-332)
[ 1.262728] ACPI Error: Aborting method _SB.PCI0.SAT0.SPT4._GTF due to previous error (AE_NOT_FOUND) (20250807/psparse-529)
[ 1.263764] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT4._GTF.DSSP], AE_NOT_FOUND (20250807/psargs-332)
[ 1.263782] ACPI Error: Aborting method _SB.PCI0.SAT0.SPT4._GTF due to previous error (AE_NOT_FOUND) (20250807/psparse-529)
→ seen a lot on internet
3) microcode disabled
fails too
4) BIOS update
Current BIOS version: E7728MLN.30E
New BIOS version found: E7728MLN.30G
But how to install, because the software is for Windows?
5) microcode errors from installed system
root@localhost-live:~# journalctl --root=/mnt/root | grep microcode
Feb 17 02:53:36 host.name dracut[1256267]: *** Generating early-microcode cpio image ***
Feb 21 02:37:46 host.name dracut[1534920]: *** Generating early-microcode cpio image ***
Feb 27 02:50:06 host.name dracut[1954780]: *** Generating early-microcode cpio image ***
Mar 01 03:00:41 host.name kernel: x86/CPU: Running old microcode
Mar 01 03:00:41 host.name kernel: MDS: Vulnerable: Clear CPU buffers attempted, no microcode
Mar 01 03:00:41 host.name kernel: core: PEBS disabled due to CPU errata, please upgrade microcode
Mar 01 03:00:41 host.name kernel: microcode: Current revision: 0x00000025
Mar 08 02:18:35 host.name dracut[543970]: *** Generating early-microcode cpio image ***
Mar 13 02:47:48 host.name dracut[889753]: *** Generating early-microcode cpio image ***
Mar 15 08:02:05 host.name dracut[1051350]: *** Generating early-microcode cpio image ***
Mar 17 03:04:59 host.name dracut[1185076]: *** Generating early-microcode cpio image ***
Mar 27 02:23:38 host.name dracut[1864721]: *** Generating early-microcode cpio image ***
Apr 01 01:40:34 host.name dracut[2441974]: *** Generating early-microcode cpio image ***
Apr 01 02:01:06 host.name kernel: x86/CPU: Running old microcode
Apr 01 02:01:06 host.name kernel: MDS: Vulnerable: Clear CPU buffers attempted, no microcode
Apr 01 02:01:06 host.name kernel: core: PEBS disabled due to CPU errata, please upgrade microcode
Apr 01 02:01:06 host.name kernel: microcode: Current revision: 0x00000025
Apr 04 08:46:56 host.name kernel: x86/CPU: Running old microcode
Apr 04 08:46:56 host.name kernel: MDS: Vulnerable: Clear CPU buffers attempted, no microcode
Apr 04 08:46:56 host.name kernel: core: PEBS disabled due to CPU errata, please upgrade microcode
Apr 04 08:46:56 host.name kernel: microcode: Current revision: 0x00000025
Apr 08 16:02:14 host.name kernel: x86/CPU: Running old microcode
Apr 08 16:02:14 host.name kernel: MDS: Vulnerable: Clear CPU buffers attempted, no microcode
Apr 08 16:02:14 host.name kernel: core: PEBS disabled due to CPU errata, please upgrade microcode
Apr 08 16:02:14 host.name kernel: microcode: Current revision: 0x00000025
Apr 08 14:10:08 host.name dracut[8799]: *** Generating early-microcode cpio image ***
Apr 08 15:22:54 host.name kernel: x86/CPU: Running old microcode
Apr 08 15:22:54 host.name kernel: MDS: Vulnerable: Clear CPU buffers attempted, no microcode
Apr 08 15:22:54 host.name kernel: core: PEBS disabled due to CPU errata, please upgrade microcode
Apr 08 15:22:54 host.name kernel: microcode: Current revision: 0x00000025
Apr 08 18:01:26 host.name kernel: x86/CPU: Running old microcode
Apr 08 18:01:26 host.name kernel: MDS: Vulnerable: Clear CPU buffers attempted, no microcode
Apr 08 18:01:26 host.name kernel: core: PEBS disabled due to CPU errata, please upgrade microcode
Apr 08 18:01:26 host.name kernel: microcode: Current revision: 0x00000025
Apr 08 19:35:54 host.name kernel: x86/CPU: Running old microcode
Apr 08 19:35:54 host.name kernel: MDS: Vulnerable: Clear CPU buffers attempted, no microcode
Apr 08 19:35:54 host.name kernel: core: PEBS disabled due to CPU errata, please upgrade microcode
Apr 08 19:35:54 host.name kernel: microcode: Current revision: 0x00000025
Apr 16 01:48:04 host.name dracut[489884]: *** Generating early-microcode cpio image ***
Apr 24 01:47:41 host.name dracut[1163598]: *** Generating early-microcode cpio image ***
Apr 28 18:51:29 host.name dracut[1438969]: *** Generating early-microcode cpio image ***
host.name kernel: x86/CPU: Running old microcode
is just after boot.
6) boot times with kernel version from installed system
Mar 01 03:00:41 host.name kernel: Linux version 6.18.13-200.fc43.x86_64
Apr 01 02:01:06 host.name kernel: Linux version 6.19.10-200.fc43.x86_64
Apr 04 08:46:56 host.name kernel: Linux version 6.19.10-200.fc43.x86_64
Apr 08 16:02:14 host.name kernel: Linux version 6.19.10-200.fc43.x86_64
Apr 08 15:22:54 host.name kernel: Linux version 6.19.11-200.fc43.x86_64
Apr 08 18:01:26 host.name kernel: Linux version 6.19.11-200.fc43.x86_64
Apr 08 19:35:54 host.name kernel: Linux version 6.19.11-200.fc43.x86_64
Reinstalled the system with Fedora Server 44.
Previous install, based on info from /etc/fstab, was from Sat Mar 10 14:07:54 2018
It would appear that you have been upgrading with no new installs for 8 years (16 fedora release versions). A new install was likely a good choice.
Did the new install solve the issue?
Is the system bios firmware up to date with the latest available for your machine?
So far, the new install solved my problem. Need to get a lot of services back online, like DNS, KVM, Samba and others.
The latest firmware (BIOS) that I could find is E7728MLN.30G Date:06/20/2012 Time:10:26:53. It has a Windows installer. My current BIOS is E7728MLN.30E 03/19/2012.
So I will probably leave it that way.
I used the Fedora 44 server installer with my old iMac 14,2 to install the LXQt desktop. This system has been requiring manual installation of nouveau firmware for a number of years. With the latest installation there are no messages about missing nouveau firmware. The falkon browser crashes, but firefox 150 works.
Others have used Windows PE to install firmware on Linux systems.
Or they use hirensbootcd
Thanks Jeff - I knew there was another ISO that I wanted on my Emergency Ventoy stick, and I couldn’t recall the name of it. All I could come up with was “boot’n’nuke” which was obviously not the puppy I was after - cheers for the reminder!