Re: [dm-crypt] dm-crypt + mdadm

[Milan Broz <gmazyland@gmail.com>]

On 23.11.2013 12:58, Arno Wagner wrote:
> I had 3 immediate issues with older, reliable hardware that
> never gave me any trouble with any other kernels:
>
> 1. Kernel panic due to missing radeon firmware image.
>     Newer kernels do not panic on this. Older ones do not
>     even detect the integrated graphis as anything special,
>     just as VGA, and hence do not panic either.
>     I finally had to switch off the inegrated graphics to get
>     it to boot at all.

I think we are off topic here, but do not forget I was paid
for several years to work on kernel parts in RHEL :)

Once you install new hw, you have to also install fw packages
and ebuild initramfs. For VGA you can quite safely boot in
text mode and fix it later, it is just special know-how
about some kernel options... And yes, it is ****
  
> 2. A perfectly fine RTL8139 card was not even recognized.

First, this Realtek is really cheap hw, but it works. There are
many revisions and I guess you had some new which was not yet
recognised - there are also some workarounds but you just
cannot expect installation will detect hw which was not
available when image was built.
(There are new installation images in RHN available for minor updates.)

> 3. A perfectly fine RTL8168 card caused the driver to spam
>     the syslog and text-console with warnings and made it unusable.
>     (No X11 on this installation....)
>
> Sorry, but that is not what I would call a stable kernel. Feels
> more like something hacked together...

Well, this is exactly what support should solve. But usually
short search on RH bugzilla works as well.
(And yes, I was sometimes desperate how it works but that's another story :)


Enterprise Linux is always trade-off - you cannot have stable ABI
for ~10years, expect 5 years old installation images to work
on new motherboards. Usually next update works though.

So in general, this kind of distro is not the best option for you.
I think Debian or something similar will work much better.


> The only possible explantion I have is that this very standard
> hardware is not "enterpriese" enough (being cheap) and did not
> make it on the hardware compatibility list and hence does not
> get tested well or at all.

Obviously not everything is tested but I am sure these are.
(I had many such cheap cards myself - and working :)

>> (And my experience is that RHEL/CentOS kernel are pretty stable
>> in comparison with manual upstream builds. I would not
>> suggest any customer to build own kernel for these enterprise
>> distributions
>
> The suggestion was for tests, not to create a stable installation
> this way. If there is still a performance-hit with a current
> kernel, then it is likely not a kernel issue. If not, then
> it is and moving away from CentOS may be a viable solution...

Regarding  performance hit - it CAN be userspace as well.
For storage, if you need to handle multipath, lvm2 etc you know what
I am talking about.

(E.g. RAID misalignment because of using old userspace tool is very common.)

...

Anyway, sorry for spam :)

Milan