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

[lejeczek]

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"?