having strange problems when using the ucode.cpio file loaded at bootup (new info added)(solved)

[bigpup]

Computer:
Desktop home built with a MSI MPG Z390 GAMING PLUS motherboard.
CPU Intel i7-9700 CPU @ 3.00GHz (8 cores)
RAM 32GB DDR4
Graphics Nvidia GeForce RTX 2060
Several different internal and external SSD drives (m-2 and USB type)

Bookworm Pup64 10.0.2
Frugal install as a directory on external USB SSD drive.
Using save folder.
Have the ucode.cpio file, provided in the Bookworm Pup64 ISO, in the frugal install directory.
Using boot loader provided by Frugalpup Installer.
Boot loader has commands in the boot loader menu entry to load the ucode.cpio file and use it.

You do need to be using a boot loader menu entry that does command to use the ucode.cpio file.
Not all boot loaders will have the boot loader entry setup to use it.
These do:
The boot loader that comes in the Bookworm Pup64 ISO that is used for a Live install on USB or CD.
Frugalpup Installer boot loader it installs.

I am reporting this mainly to see if anyone else is having similar issues.

When using the ucode.cpio file being loaded on boot.

I get all kinds of strange issues similar to these:

Do I need to update CPU microcode?
These updates provide bug fixes that can be critical to the stability of your system. Without them, you may experience spurious crashes or unexpected system halts that can be difficult to track down. All users with an AMD or Intel CPU should install the microcode updates to ensure system stability.Aug 23, 2023

Mainly I get issues with ROX file manager, the pinboard, and something big using up CPU resources or locking up the CPU.

If I do a boot up not using the ucode.cpio file.
Bookworm Pup64 runs with no issues.
Everything works normal and very well.

So, anyone else seeing these strange errors when the ucode.cpio is used.

I wonder.
Is there a ucode.cpio for AMD processors and one for Intel or does one provide for both?

[bigpup]

I am wondering if this ucode.cpio file is too old a version for the kernel that is in Bookworm Pup64 10.0.2 or the microcode software it already has.

Reason I say this is look at this procedure for updating the Intel microcode.
https://www.cyberciti.biz/faq/install-u ... are-linux/

Notice in the example output what they get when they run

Code: Select all

dmesg | grep microcode

in a terminal.

With no ucode.cpio file loaded and Bookworm Pup64 working 100% OK.

This is what I get when I run

Code: Select all

dmesg | grep microcode

# dmesg | grep microcode
[ 0.097968] TAA: Vulnerable: Clear CPU buffers attempted, no microcode
[ 0.097969] MMIO Stale Data: Vulnerable: Clear CPU buffers attempted, no microcode
[ 0.097970] SRBDS: Vulnerable: No microcode
[ 1.311939] microcode: sig=0x906ed, pf=0x2, revision=0xb0
[ 1.312108] microcode: Microcode Update Driver: v2.2.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If I do what this web site says to do to update microcode.

Run in a terminal this command for apt.

Code: Select all

apt install intel-microcode

This is what I get:

# apt install intel-microcode
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
intel-microcode is already the newest version (3.20230808.1~deb12u1).
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
#

According to info I can find about the microcode firmware. This version 3.20230808.1 is the latest one.
.
.

[d-pupp]

@bigpup My hardware is older than yours

Dell
Vostro 220 Series
x86_64
Pentium(R) Dual-Core CPU E5200 @ 2.50GHz

my dmesg

Code: Select all

[    0.187304] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[    3.174048] microcode: sig=0x1067a, pf=0x1, revision=0xa07
[    3.174058] microcode: Microcode Update Driver: v2.2.

I am using Vanilladpup and have no issues with rox or the pinboard, It sure sounds like your issue is related to microcode somehow. Do any of your other pup's use microcode?

[bigpup]

All Puppy versions use microcode firmware for the processors, but most of it is in the Linux kernel

But the kernel is only going to have what was the latest version at the time it was released.

Some is in the computers bios CPU support code. But it will not be the latest version.

It can also be microcode firmware files in the operating system.

Bookworm Pup64 has both which is usually normal setup.
Provided by the Linux kernel and updates provided by firmware files in the operating system.

As I understand.
The ucode.cpio file is another way of getting the latest microcode firmware into the operating system.
It is suppose to be the latest stuff and gets loaded during the boot process.
that is if the ucode.cpio file is provided to load.
I assume it needs to provide newer processor microcode firmware than is already being used.
So I assume there are different versions of the ucode.cpio file.

But the one provided in the Bookworm Pup64 ISO is causing errors for me when used.

Having a ucode.cpio file to use is something new to Puppy Linux.
Only a few very new versions provide one in their ISO.

[dimkr]

All Puppy versions use microcode firmware for the processors, but most of it is in the Linux kernel

Sadly, most Puppy releases ship without ucode.cpio and don't support microcode update.

But the kernel is only going to have what was the latest version at the time it was released.

The kernel doesn't include microcode. The CPU ships with a certain microcode version flashed in the factory, but the kernel can load a newer version inside ucode.cpio at boot time. Some CPUs ship with a faulty version that causes instability and lockups.

"Late loading" (loading after boot time) is not recommended because it's often unsupported and sometimes it's too late to apply some fixes when the system is fully booted.

But the one provided in the Bookworm Pup64 ISO is causing errors for me when used.

Try dmesg | grep -e ucode -e microc to see if microcode is loaded or not. This is weird, because the problems you describe are far more common when using the old and buggy microcode Intel some CPUs ship with.

[bigpup]

OK. You seem to understand how this all works better than I do.

I guess I am miss reading stuff I found on the Internet about how this microcode works.

But the issue I am having is real!

I looked at a few of the other ucode.cpio files provided in other Puppy versions.
They are all of different sizes.

The one provided in Bookworm Pup64 is the largest in size. About 2 times bigger.

wonder if inside the ucode.cpio something provided, specific to my CPU, could be messed up.
The CPU is a 9th generation Intel i7 Processor.

[LateAdopter]

Hello bigpup.
The steps are quite simple.

The cpio contains one or more binary blobs identified by cpuid.

The boot loader has to load the cpio into RAM before the initrd

When the kernel starts it checks whether there is a file that matches the cpuid of the running processor and whether it is newer than the one from the BIOS. If it is both, then it loads it.

Its the third line in the messages file on my copy of Fossapup64.

Code: Select all

Sep 18 10:15:07 puppypc7696 syslog.info syslogd started: BusyBox v1.31.0
Sep 18 10:15:07 puppypc7696 kern.notice kernel: klogd started: BusyBox v1.31.0 (2019-08-05 23:29:36 +08)
Sep 18 10:15:07 puppypc7696 kern.info kernel: microcode: microcode updated early to revision 0x368, date = 2019-04-23

What can possibly go wrong.

Late loading can cause breakage though. So you need to make sure it's not doing that.

[bigpup]

My messages lists it as the 3rd entry.

Sep 17 14:45:53.729 puppypc4488 syslog.info syslogd started: BusyBox v1.36.1
Sep 17 14:45:53 puppypc4488 kern.notice kernel: klogd started: BusyBox v1.36.1 (2023-09-04 07:51:15 +08)
Sep 17 14:45:53 puppypc4488 kern.info kernel: [ 0.000000] microcode: microcode updated early to revision 0xfa, date = 2023-02-27

This is the dmesg | grep -e ucode -e microc output

# dmesg | grep -e ucode -e microc
[ 0.000000] microcode: microcode updated early to revision 0xfa, date = 2023-02-27
[ 1.341244] microcode: sig=0x906ed, pf=0x2, revision=0xfa
[ 1.341381] microcode: Microcode Update Driver: v2.2.
[ 5.482460] nouveau 0000:01:00.0: firmware: direct-loading firmware nvidia/tu106/acr/ucode_ahesasc.bin
[ 5.482526] nouveau 0000:01:00.0: firmware: direct-loading firmware nvidia/tu106/acr/ucode_asb.bin
[ 5.482630] nouveau 0000:01:00.0: firmware: direct-loading firmware nvidia/tu106/acr/ucode_unload.bin
#

This is dmesg | grep microcode output

# dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0xfa, date = 2023-02-27
[ 1.341244] microcode: sig=0x906ed, pf=0x2, revision=0xfa
[ 1.341381] microcode: Microcode Update Driver: v2.2.
#

[dimkr]

The one provided in Bookworm Pup64 is the largest in size. About 2 times bigger.

It covers both Intel and AMD, and much newer (so it covers more models, plus more fixes for old models).

Maybe this is a regression in new microcode version - if it's a known problem reported to Intel and there's an open Debian bug for this, maybe it will be addressed.

[bigpup]

This is the boot loader entry I am using.

It is the boot loader installed by Frugalpup Installer v41 (grub.cfg)

Maybe it is sometimes not getting it all correctly booted.

menuentry "Puppy dpup 10.0.2" {
insmod ext2
search --no-floppy --fs-uuid --set=root b0f092c5-6a1c-4e04-b9d8-ddbeb91d4ab7
echo "Loading vmlinuz"
linux /bookworm10.0.2/vmlinuz pmedia=usbhd pdrv=b0f092c5-6a1c-4e04-b9d8-ddbeb91d4ab7 psubdir=/bookworm10.0.2 pfix=fsck,fsckp,trim TZ=EST5EDT,M3.2.0,M11.1.0
if [ -e /bookworm10.0.2/local-initrd.gz ]; then
set local_rd=/bookworm10.0.2/local-initrd.gz
else
set local_rd=
fi
if [ -e /bookworm10.0.2/ucode.cpio ]; then
set ucode_rd=/bookworm10.0.2/ucode.cpio
echo "Loading ucode.cpio and initrd.gz"
else
set ucode_rd=
echo "Loading initrd.gz"
fi
initrd $ucode_rd /bookworm10.0.2/initrd.gz $local_rd

.
.

[mikewalsh]

I wonder.
Is there a ucode.cpio for AMD processors and one for Intel or does one provide for both?

The one provided in Bookworm Pup64 is the largest in size. About 2 times bigger.

It covers both Intel and AMD, and much newer (so it covers more models, plus more fixes for old models).

Maybe this is a regression in new microcode version - if it's a known problem reported to Intel and there's an open Debian bug for this, maybe it will be addressed.

I'll confirm this, because if you open ucode.cpio with UExtract, you get

Code: Select all

/kernel/x86/microcode/AuthenticAMD.bin

AND

Code: Select all

/kernel/x86/microcode/GenuineIntel.bin

....both inside the /microcode directory. I'm assuming these are the binary 'blobs' mentioned by LateAdopter, and that each contains scores of microcode 'fixes', though from what I understand, these 'fixes' can often apply to more than one CPU.......sometimes, several from the same family of chips.

Mike.

[gyrog]

@bigpup,
I have a more modest i3 4160 CPU, but I installed Bookworm with FrugalPup, so I have a grub2 entry very much like yours,

On boot I see the "Loading ucode.cpio and initrd.gz" message from grub.
And the first 2 lines of my 'dmesg' is :

Code: Select all

[    0.000000] microcode: microcode updated early to revision 0x28, date = 2019-11-12
[    0.000000] Linux version 6.1.38 (root@689abfdd8673) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Tue Aug  1 03:16:23 UTC 2023

So it works on my machine.
Sorry, I have no real idea of why it's not working on your machine.

But perhaps you could try manually extracting it from the .iso file again, just in case the file is somehow corrupted.

[gyrog]

Where do these 'ucode.cpio' files come from?
Can we check if the one in Bookworm is the latest?

[LateAdopter]

It looks as though the system is working correctly and the kernel has found valid microcode and loaded it. It's just broken.

It could be that they have implemented some severe vulnerability mitigation that is making the software choke. You could try turning mitigations off to see whether that has any effect.

gyrog's microcode is from 2019, like mine. It's not been updated.

[bigpup]

Thanks everyone for your posts.

I started this to see if others are having the same issues.

Along the way I think we all learned some good info on these ucode.cpio files.
How to use them, what they do, and how to make sure they are being used correctly.

Well, I sure learned some stuff!

-------------------------------------------------------------------------------------------------------------------------------------------------------------------
I went back to basics and deleted the ucode.cpio file from the frugal install.
Copied it back in from a fresh download of the Bookworm Pup64 10.0.2 ISO.

Now using this fresh install ucode.cpio file.

Booted normally using the ucode.cpio file.

So far seems to be stable running Bookworm Pup64 and stuff seems to be working OK.
I will see how it goes.

But now that I have said it is working OK, now.
We all know the computer evil gods will smack me down, for being so sure!

Time will tell!

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

[dimkr]

Where do these 'ucode.cpio' files come from?
Can we check if the one in Bookworm is the latest?

It's built from Debian's microcode packages, see woof-CE's 3builddistro.