Arch Linux User Repository

Interesting. While I'm sure this error is not intended and a bug indeed, since it seems to pop up pretty commonly (and popped up fairly recently), the impact is effectively zero. I'll dig in the commits if I have some spare time to see what commit might have caused this behaviour none the less as it is interesting indeed.

@eggz, "I assume that error does not concern this specific kernel version, because it seems to be a common error"

That is correct. I saw this error en latest kernel versions (not sure but maybe 3 or 4) but not before. I'll let it go because everything seems to be ok.

Thanks again

@Anarconda, I assume that error does not concern this specific kernel version, because it seems to be a common error:

This is what I could dig up:

with AMD 2nd generation EPYC (Rome) CPUs seems to report this error more frequently than other systems, but all x86 servers (both Intel and AMD CPUs) can experience this error.

Since that article was made back in the day, I assume its a thing for all zenv2+ CPUs.

A race condition between calibrating the TSC clock source and initializing the jitterentropy crypto code. This will remove the the jitterentropy source of entropy, but the kernel and rngd daemon can use other sources such as a hardware TRNG or the RDRAND/RDSEED instructions on newer x86 CPUs.
Source: https://access.redhat.com/solutions/4384951

This rings true, modern (AMD) CPUs use RDRAND/RDSEED now:

AMD’s Family 17h processor and other products of 2016 and beyond are equipped
with Cryptographic Co-processor 5.0 hardware that enables the generation of
cryptographically secure random numbers. 

Source: https://www.amd.com/content/dam/amd/en/documents/pdfs/developer/aocl/amd-secure-random-number-generator-library-2.0-whitepaper.pdf

The Cryptographic Co-processor is indeed capable of RDSEED/RDRAND.

As far as I can understand, this is really not worth losing any sleep over. The thing that failed seems to be legacy and superseeded by more modern means to generate random numbers by using capabilities already present on your CPU. I am always open to the contrary, but this seems to rings true to me.

Hi, I'm seeing a "jitterentropy: Initialization failed with host not compliant with requirements: 9" with dmesg.

I can't find anything about how to solve it. Should I be worried?

Thank you in advance.

@yuzer, ty for telling, its done.

Please enable the BT_HCIBTUSB_MTK by default, it's enable Bluetooth on many Asus laptop. Thank you.

Sorry, I only test my kernels on arch linux with mkinicpio. Can't help you with dracut, you are on your own there.

I would think to just let dracut rebuild the initramfs after a kernel install. You can probably fix this with a manual pacman hook in /etc/pacman.d/hooks, or you can just modify the linux.install file.

But I won't do this myself because I can't test/validate the behaviour since none of my systems have dracut. Because why should they. Good luck!

(29/47) upgrading linux-amd-znver3
>>> Updating module dependencies. Please wait ...
>>> Generating initial ramdisk, using mkinitcpio.  Please wait...
/tmp/alpm_QjMbAV/.INSTALL: line 24: mkinitcpio: command not found

Pacman can't execute mkinitcpio because it doesn't exists on my system. Could you add dracut support?

eggz, thank you

thx for telling bhtm1138, done