On 23/2/18 8:59 am, Ed Greshko wrote:
On 02/23/18 05:27, Stephen Morris wrote:
 From the responses I am getting it seems that the meaning of 'taints the 
has morphed into something else?

Here is the definitive list of what taints the kernel.  This is from the 4.14
documentation but is also valid for 4.15 kernels.


The numbers in the list correspond to the bit positions in the value supplied by 

Why you don't get "tainted" messages in your dmesg output or journal?  Don't
know....and I'd not be interested in chasing it down.

I've a small program that converts the value from proc-tainted into real info 
if you
need it.

Access to that program would be great, the output from the cat command you mentioned above of 12289 is meaningless to me especially after looking at the web page you highlighted.

There has to be a reason for whether taint messages are produced or not. I ran a 'dnf upgrade' yesterday which wanted to upgrade/install 125 packages, and even though it produced messages about conflicts between kmod-nvidia-390.25 and the equivalent X11 drivers I told the upgrade to proceed, which then proceeded to completion. The upgrade did not install a new kernel, nor did it result in compiling my wireless driver or mouse drivers. I have done cold start of the machine after the upgrade. I have just issued commands 'dmesg | grep -i taint' and 'journalctl --system --user -b | grep -i taint' and these commands now produce the out of tree taint message about the nvidia driver not the wireless driver they were previously.

Is systemd's parallelism the reason for the changes in these taint messages? Is it possible that these out of tree taint messages are only produced for the first module encountered, and the reason for the message chopping and changing between modules is that systemd's parallelism is not loading the modules in the same order from boot to boot, and that they have never been produced for the mouse driver, not because the compile that is done for the driver not causing the issue but because the mouse driver is loaded after the nvidia or wifi drivers, hence a out of tree taint message has already been produced?

The other alternative to this is, if I go back to compiling the kernel myself will that stop the messages being produced?



users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Reply via email to