Tainted modules and possible boot problems!

Hi,
I have a server that risks being lost by this tainted modules problem.
I have a server that is on a data center. It has a 3Ware 9550 raid controller.
I know that this Raid controller is not GPL, it is a module in the kernel
since version 2.6.14.
My biggest problem right now is that I have made an up-grade with yast and
I have choosen to up-grade the kernel.
My problem is that in my home PC at home the same up-grade stopped
lm_sensors because lm85 does not have a GPL code license.

and dmesg gives the result:

hwmon: module not supported by Novell, setting U taint flag.
hwmon_vid: module not supported by Novell, setting U taint flag.
lm85: module not supported by Novell, setting U taint flag.

I am scared to reboot the server because I fear that the same could happen
to the raid controller module. As the raid is the only partition on the
server it might never recover because of this.
Can someone please let me know if this might happen.
Regards,
Pedro

pedrocsort-e@yahoo.com wrote:
> Hi,
> I have a server that risks being lost by this tainted modules problem.
> I have a server that is on a data center. It has a 3Ware 9550 raid controller.
> I know that this Raid controller is not GPL, it is a module in the kernel
> since version 2.6.14.
> My biggest problem right now is that I have made an up-grade with yast and
> I have choosen to up-grade the kernel.
> My problem is that in my home PC at home the same up-grade stopped
> lm_sensors because lm85 does not have a GPL code license.
>
> and dmesg gives the result:
>
> hwmon: module not supported by Novell, setting U taint flag.
> hwmon_vid: module not supported by Novell, setting U taint flag.
> lm85: module not supported by Novell, setting U taint flag.
>
> I am scared to reboot the server because I fear that the same could happen
> to the raid controller module. As the raid is the only partition on the
> server it might never recover because of this.
> Can someone please let me know if this might happen.
> Regards,
> Pedro
>

Sure it can happen.

To avoid getting stuck, you can add an entry for your old kernel
in the grub menu (use Yast) .

Of some reason Suse don't add the old kernel in the
boot menu as many other linux dists do , that is strange.

/birger

Hi,

I rebooted the server and everything was ok.
Even lm_sensors work.
So the problem in my home PC is not tainted drivers for sure.

> pedrocsort-e@yahoo.com wrote:
> > Hi,
> > I have a server that risks being lost by this tainted modules problem.
> > I have a server that is on a data center. It has a 3Ware 9550 raid
controller.
> > I know that this Raid controller is not GPL, it is a module in the kernel
> > since version 2.6.14.
> > My biggest problem right now is that I have made an up-grade with yast and
> > I have choosen to up-grade the kernel.
> > My problem is that in my home PC at home the same up-grade stopped
> > lm_sensors because lm85 does not have a GPL code license.
> >
> > and dmesg gives the result:
> >
> > hwmon: module not supported by Novell, setting U taint flag.
> > hwmon_vid: module not supported by Novell, setting U taint flag.
> > lm85: module not supported by Novell, setting U taint flag.
> >
> > I am scared to reboot the server because I fear that the same could happen
> > to the raid controller module. As the raid is the only partition on the
> > server it might never recover because of this.
> > Can someone please let me know if this might happen.
> > Regards,
> > Pedro
> >
>
> Sure it can happen.

Exactly my point and the reason for my concerns ...

>
> To avoid getting stuck, you can add an entry for your old kernel
> in the grub menu (use Yast) .

That was my problem ...
It as to be done Before the kernel upgrade.
But everything went ok fortunately.
Actually it would be good to have some peace of mind that the yast online
up-grade would made a backup of the previous kernel, so that we could have
a new entry on grub/lilo. But that is a responsability of the user.
If one takes a big step like a kernel upgrade, then one has to make a backup.
-> Very important note:
I am personaly not complaining about the kernel updates.
I have made many, in several versions of SuSE, and never had a single
problem so far.
And the backup is really up to the user ...

>
> Of some reason Suse don't add the old kernel in the
> boot menu as many other linux dists do , that is strange.
>
> /birger


Regards,
Pedro

Am 28.09.2006 11:55 schrieb pedrocsort-e@yahoo.com:
> I rebooted the server and everything was ok.
> Even lm_sensors work.
> So the problem in my home PC is not tainted drivers for sure.

That just goes to show what a very bad idea this SuSE-specific
"module not supported" message is. It really constitutes a
red herring for the user trying to figure out why something
went wrong, needlessly diverting his or her attention from
any real issues that might exist.

To reiterate:

- An "unsupported module" or "tainting kernel" message does
NOT indicate an error.

- Tainting the kernel does NOT impair the functioning of the
system.

- A module that taints the kernel may load and run just as
fine as one that doesn't.

- The only function of the tainting mechanism is to set a
marker in the system saying "tainted" and which cannot be
cleared later, not even by unloading the module.

- The only function of that marker is, that if you later ask
for support from SuSE/Novell for any problem whatsoever (not
necessarily related to the module that did the tainting!),
and the support person finds that marker set, he or she will
know you have loaded an unsupported module, and may
consequently refuse to give you support.

(The rationale being that any module you load could in theory
corrupt anything in the entire kernel, so once a "foreign"
module has been loaded you cannot rely on anything anymore.)

HTH
Tilman

--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
- In theory, there is no difference between theory and practice.
In practice, there is.

Tilman Schmidt wrote:
> Am 28.09.2006 11:55 schrieb pedrocsort-e@yahoo.com:
>> I rebooted the server and everything was ok.
>> Even lm_sensors work.
>> So the problem in my home PC is not tainted drivers for sure.
>
> That just goes to show what a very bad idea this SuSE-specific
> "module not supported" message is. It really constitutes a
> red herring for the user trying to figure out why something
> went wrong, needlessly diverting his or her attention from
> any real issues that might exist.
>
> To reiterate:
>
> - An "unsupported module" or "tainting kernel" message does
> NOT indicate an error.
>
> - Tainting the kernel does NOT impair the functioning of the
> system.
>
> - A module that taints the kernel may load and run just as
> fine as one that doesn't.
>
> - The only function of the tainting mechanism is to set a
> marker in the system saying "tainted" and which cannot be
> cleared later, not even by unloading the module.
>
> - The only function of that marker is, that if you later ask
> for support from SuSE/Novell for any problem whatsoever (not
> necessarily related to the module that did the tainting!),
> and the support person finds that marker set, he or she will
> know you have loaded an unsupported module, and may
> consequently refuse to give you support.
>
> (The rationale being that any module you load could in theory
> corrupt anything in the entire kernel, so once a "foreign"
> module has been loaded you cannot rely on anything anymore.)

No kernel maintainer will give any support. Once you allow any binary code unlimited access to the
inner ring of the machine, nothing can be trusted. Who wants to chase a bug introduced by a driver
written by someone who refuses to divulge the specifications of their device? I certainly do not.

Larry

Am 12.11.2006 00:06 schrieb Larry Finger:
> Tilman Schmidt wrote:

>> That just goes to show what a very bad idea this SuSE-specific
>> "module not supported" message is. It really constitutes a
>> red herring for the user trying to figure out why something
>> went wrong, needlessly diverting his or her attention from
>> any real issues that might exist.
[...]
> No kernel maintainer will give any support. Once you allow any binary code unlimited access to the
> inner ring of the machine, nothing can be trusted. Who wants to chase a bug introduced by a driver
> written by someone who refuses to divulge the specifications of their device? I certainly do not.

I think you neglected to read my posting properly before replying.

This isn't about "binary code" at all. SuSE sets the Taint flag for
modules which are properly GPLed Open Source, which is A Bad Thing.

--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
- In theory, there is no difference between theory and practice.
In practice, there is.

Tilman Schmidt wrote:
> Am 12.11.2006 00:06 schrieb Larry Finger:
>> Tilman Schmidt wrote:
>
>>> That just goes to show what a very bad idea this SuSE-specific
>>> "module not supported" message is. It really constitutes a
>>> red herring for the user trying to figure out why something
>>> went wrong, needlessly diverting his or her attention from
>>> any real issues that might exist.
> [...]
>> No kernel maintainer will give any support. Once you allow any binary code unlimited access to the
>> inner ring of the machine, nothing can be trusted. Who wants to chase a bug introduced by a driver
>> written by someone who refuses to divulge the specifications of their device? I certainly do not.
>
> I think you neglected to read my posting properly before replying.
>
> This isn't about "binary code" at all. SuSE sets the Taint flag for
> modules which are properly GPLed Open Source, which is A Bad Thing.
>

It is the kernel that sets the Taint flag, not SuSE.

Larry

>> This isn't about "binary code" at all. SuSE sets the Taint flag for
>> modules which are properly GPLed Open Source, which is A Bad Thing.
>>
>
> It is the kernel that sets the Taint flag, not SuSE.
It is the SuSE-kernel which sets the taint flag in a lot of more
conditions than the original kernel does, eg. if a kernel module is
loaded which does not have a "novell-flag" set.

Am 12.11.2006 01:06 schrieb Larry Finger:
> Tilman Schmidt wrote:
>> This isn't about "binary code" at all. SuSE sets the Taint flag for
>> modules which are properly GPLed Open Source, which is A Bad Thing.
>
> It is the kernel that sets the Taint flag, not SuSE.

Ok, I'll express myself more precisely:

This isn't about "binary code" at all. SuSE modified the kernel to
set the Taint flag for modules which are properly GPLed Open Source,
which is A Bad Thing.

I hope you are satisfied now.

--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
- In theory, there is no difference between theory and practice.
In practice, there is.

SuSE sets the "taint" flag all over the place. These are not in the default
kernel distribution. The only reason they are there is to give the Novell
support desk an "out" to deny you support if they see that a "taint" flag
is present. I agree that it is a bad thing.

Mike

Tilman Schmidt wrote:

> Am 12.11.2006 01:06 schrieb Larry Finger:
>> Tilman Schmidt wrote:
>>> This isn't about "binary code" at all. SuSE sets the Taint flag for
>>> modules which are properly GPLed Open Source, which is A Bad Thing.
>>
>> It is the kernel that sets the Taint flag, not SuSE.
>
> Ok, I'll express myself more precisely:
>
> This isn't about "binary code" at all. SuSE modified the kernel to
> set the Taint flag for modules which are properly GPLed Open Source,
> which is A Bad Thing.
>
> I hope you are satisfied now.
>