[elrepo] kmod-ecryptfs.x86_64 on Centos Stream fails

[Phil Perry]

On 06/02/2021 23:00, lejeczek via elrepo wrote:
> 
> 
> On 03/02/2021 10:11, Manuel Wolfshant wrote:
>> On 2/3/21 11:48 AM, lejeczek via elrepo wrote:
>>>
>>>
>>> On 31/01/2021 15:51, Akemi Yagi wrote:
>>>> On Sun, Jan 31, 2021 at 7:43 AM Manuel Wolfshant 
>>>> <wolfy at nobugconsulting.ro <mailto:wolfy at nobugconsulting.ro>> wrote:
>>>>
>>>>     On January 31, 2021 4:14:17 PM GMT+02:00, lejeczek via
>>>>     elrepo <elrepo at lists.elrepo.org
>>>>     <mailto:elrepo at lists.elrepo.org>> wrote:
>>>>     >
>>>>     >
>>>>     >On 31/01/2021 13:44, Trevor Hemsley wrote:
>>>>     >> On 31/01/2021 10:38, lejeczek via elrepo wrote:
>>>>     >> > Does anybody else get this and if yes then should
>>>>     it go to
>>>>     >> > bugzilla?
>>>>     >>
>>>>     >> ELRepo do not support Stream since it uses a
>>>>     different,
>>>>     >> non-KABI stable,
>>>>     >> kernel series to RHEL. This is something that's
>>>>     come up
>>>>     >> several times in
>>>>     >> the mailing list etc threads on what Red Hat are doing
>>>>     >> with CentOS Linux 8.
>>>>     >>
>>>>     >> Trevor
>>>>     >>
>>>>     >And what is the actual problem? Surely it's not one of
>>>>     >technical nature.
>>>>     >Increasingly more of us will be ridding "Stream" as
>>>>     months
>>>>     >go by.
>>>>     >many thanks, L.
>>>>
>>>>     The problem is that Stream has a rolling kernel with
>>>>     no stable kABI, released whenever someone in RH feels
>>>>     like releasing a new test upon users.
>>>>     The volunteers from ElRepo do not have the resources
>>>>     to support that and RH, so far, does not give a s**t
>>>>     on the features not supported directly by _their_
>>>>     kernel.  Which , incidentally, means exactly what
>>>>     ElRepo ships.
>>>>
>>>>     wolfy
>>>>
>>>>
>>>> In addition to the detailed explanation by Trovor and also by wolfy, 
>>>> you can refer to the ELRepo blog post:
>>>>
>>>> http://elrepoproject.blogspot.com/2021/01/elrepo-and-centos-stream.html 
>>>> <http://elrepoproject.blogspot.com/2021/01/elrepo-and-centos-stream.html> 
>>>>
>>>>
>>>> Akemi
>>>>
>>> You guys sound really worried as if RH is about to spit a new kernel 
>>> every other day - do you really think that?
>>
>> Experience has shown that RH issues quite a few different intermediate 
>> kernels before minor releases, each time they want to test some fix in 
>> any kernel sub-system. Just compare the changelog differences between 
>> the last kernel issued as update for a minor release and the first 
>> kernel released for the next minor release.
>>
>>
>>
>>> Are Elrepo's kernel a work-around solution for cases with kmods and 
>>> similar?
>>
>> As already mentioned several times, ElRepo packages are maintained by 
>> volunteers who have limited time and resources and cannot commit to a 
>> moving target. Especially as
>>
>> a) there is no integration between the kernel infra and ELRepo. We are 
>> limited to reacting post-factum.
>>
>> b) the packages from ElRepo do not have a guarantee of using only the 
>> symbols from RHEL's kABI list. Therefore any update may break one or 
>> more packages. Not to forget here that RH introduces backports which 
>> can change significantly the kernel interface between minor releases 
>> of RHEL. All those backports would almost certainly break "stuff".
>>
>>
>> Rebuilding the affected kmods each time a new Stream kernel is 
>> released looks more like a job for a CentOS SIG, assuming that there 
>> is enough traction to create one.
>>
>>
>> wolfy
>>
>>
> Thanks,
> Still hoping for an answer to - Are Elrepo's kernels a work-around 
> solution for cases with kmods and similar?
> Are kernel-lt & ml good for all these problematic cases where 
> Stream/RH's kernels "fail"?
> 

Kernel-lt and kernel-ml will not be a solution for everything. Many 
kmods offered by elrepo for el8 are to reinstate support for legacy 
hardware devices that Red Hat no longer wanted to support and removed 
from the el8 kernel. Running a vanilla upstream kernel (such as 
kernel-lt or kernel-ml) will have support for those legacy devices and 
should work for Stream users.

Likewise, in a situation like yours where the ecryptfs code exits in the 
upstream kernel but Red Hat have chosen not to enable / build it, using 
a vanilla upstream kernel with it enabled may provide an alternative 
solution for you.

We generally do not recommend kernel-lt or kernel-ml for production use, 
and that said, Red Hat do not recommend Stream for production use 
either, so they seem a reasonable fit if Stream is otherwise what you 
want to use. However, if ecryptfs is a deal breaker for you, I would be 
looking for a distro that has native support for it.

Phil