Topic: Kernel woes...

[Ian Lowe]

Okay, I am trying to get a Roketraid 404 controller working with E-smith..

Highpoint have compiled binary modules for RH 7.0/8.0/9.0 which work fine, however, E-smith doesn't use the same kernel versions as the released red hat versions, so the drivers won't work (unresolved symbols)..

As a fairly vocal advocate of linux and OSS options, I'm having to face the situation that I could have had a W2K Server running on this (or any other) hardware in a matter of hours, whereas I have burned about a week of time now, desperately trying to get a kernel compile working on the SME server, without success...

so.... has anyone managed to build a working kernel for SME 5.6 on one of the "proper" redhat distro kernel versions? what are the steps?

My key error (I think) is that the contents of the existing 2.4.18-5 /lib/modules is being picked up when I do a make modules_install, and borking the process..

That being said, I'm unable to even build a 2.4,18-5 kernel using the supplied .config file, so I suspect there's something messy in the environment.

I would be *gutted* if I had to rip out my SME server (using it since 5.1.2) and replace it with Micro$oft in order to support the hardware I need, especially as the published redhat distro supports the hardware perfectly well !

[Kelvin]

Hi Ian,

Welcome to the club.

If you search through the forums (search for highpoint), you will come across a number of my own sad attempts at getting "additional" and "unsupported" hardware to work on SME. In addition to the Highpoint cards, I also came across an IDE RAID card made by ACARD that actually had 2.4.18-5 version modules on its driver disk. This also refuses to install with unresolved symbols. One of ACARD's engineer also took the trouble to compile one for me that did the same thing.

As always, when working with the standard download versions of RH, it *always* works.

Kelvin

[Ian Lowe]

Annoying, isn't it...

When the #1 issue that people have with Linux solutions is hardware support, you have to ask why the e-smith project persists in producing builds around a different kernel version from the official red hat distros, when that's what the majority of compliant hardware is tested against

The only plan, I suppose, is to find a way to reliably build a kernel on (or for) SME, and see what happens.

AIUI, RH8.0 uses 2.4.18-14. I'm hoping that that's close enough to the 2.4.18-5  version to still work without too many problems. Time to do an RH8 install, and copy the kernel across I suppose...

I.

[Dan Brown]

The answer to that question, Ian, which has been posted _many_ times, is that e-smith DOES use official RedHat kernels--often, however, ones which have been released as updates by RedHat, rather than the ones originally shipped with the respective underlying versions of RedHat.  Or would you prefer that Mitel ignore security vulnerabilities with the earlier versions?

[Ian Lowe]

Put it that way.... Yes.

I personally consider wider hardware compatibility in a base product to be more important than a security vulnerability. However, I'm afraid I don't buy that as an explanation.

Here's the update list for 18-4: http://rhn.redhat.com/errata/RHBA-2002-085.html
and here's the one for 18-5: http://rhn.redhat.com/errata/RHBA-2002-110.html

These are not security patches, they are bug fix patches.

Fixing those bugs means that we can't use binary driver modules for the base Redhat 7.2 and that's one almighty PITA.

I can't help but think that if Mitel are patching their kernel for security reasons, then they might have posted some useful how-to information somewhere, so that we can keep our systems patched!

[Kelvin]

Hi Ian,

>I personally consider wider hardware compatibility in a base product to be more
>important than a security vulnerability. However, I'm afraid I don't buy that as an
>explanation.

I agree mostly.

On the understanding that SME is more than just a firewall (in fact as a firewall, it's not as flexible as some), I agree that I would prefer a broader hardware compatibility base. Hardware based router / firewall products are quickly coming down in costs. If firewall security and the like are a major issue, spend a little and put a hardware box in front of SME. If you are worried about LAN users hacking your server, you have a problem no matter what you use as your server !.

>I can't help but think that if Mitel are patching their kernel for security reasons,
>then they might have posted some useful how-to information somewhere, so that
>we can keep our systems patched!

Again, I agree.

I can't help feeling there is a double standard in place sometimes. I remember reading that Mitel's recently decommissioned FTP server was a 4.x ESSG that was patched, etc. to keep up to date. Therefore, when you read comments from Mitel that we should upgrade away from a particular version just because another version is out now is not practical. Better by far to have upgrade patches (or at least provide information to the less informed on how to get them) to keep up to date (within reason). I support a large number of Windows based servers. Quite a few are still NT 4 servers. Telling my clients to dump their perfectly working NT4 servers (which are working & serves all their needs) to upgrade to W2K or W2K3 servers just because its there does not make any sense. And just because the unsupported version of SME is free does not mean we should upgrade clients willy nilly because there is still a cost associated with upgrading (your own time cost, downtime to clients, etc.).

My 2 bits.

Kelvin

[Karl Ponsonby]

Kelvin,

>Hardware based router / firewall products are quickly coming down in costs
>put a hardware box in front of SME

My thoughts exactly. I don't feel comfortable having a domain/file/print (with user names) connected directly to the internet. I always have a firewall between the internet and any server, including mail...(not SME or for that matter old ESSG's)

But using SME as a domain/file/print server internally is a joy to use. Unfortuantly, it doesn't scope well to the hardware that I would like to use. But RH 7.2 and up does... I would consider hardware support to be of immense importance to all, it can only lead to the greater/wider use of SME, increasing thier market share over other distro's (M$ inc). Just do a search through the lists, to see the issues with SME raid (doesn't work), versus RH raid (does work), and you'll come across many,many postings...

My thoughts....

Karl

[Ian Lowe]

So, right there is the question... can we produce a hybrid of SME and a regular Red Hat Distro?

What is needed to take a highly compatible redhat base, and add the wonderful SME management tools and integration?

has anyone looked at this?

[Karl Ponsonby]

There was a fork  a few years ago, but I cannot remember what it was called or where it went. I do know that development stalled then fell away to nothing. I don't know where to start, but am willing to offer time if needed....

Karl

[Kelvin]

Hi Karl,

>There was a fork a few years ago

Yes, Axon Linux.

>where it went

It died, it died, it died

Kelvin

[Ian Lowe]

Okay, I have some great news

I now have a 5.6 SME Server running with Red Hat 8.0's Kernel: 2.4.18-14

All functions seem okay (some testing required obviously) and I can access my Highpoint Rocket Raid 404 Controller happily (with full Raid-5 support !)

At the moment, I have two problems:  firstly, I can't get the driver module to load at boot time (probably a gap in my own knowledge of Grub) and secondly, the built-in HPT driver spots the disks connected to the controller as raw devices, and gets a I/O error reading them..

There's a parameter in the highpoint manual, "hdx=noprobe" passed to the kernel via Grub (again, my grub knowledge is non-existant) which stops the inbuilt driver from trying to talk directly to the disks that form the array.

The process was *not* easy, but basically, I did this:

Got disk 1 from an RH8.0 box product, and from the RPMS folder, installed

kernel-2.4-18-14.i686.rpm (I have an athlon, but the 686 version works fine)

This complained about a lot of dependencies, so I installed each of them, using the -U option on rpm. The biggest problem I had was with glibc and glibc-common : they are mutually dependant, so I couldn't upgrade one without the other.

In the end, I used the --nodeps --force option to install the new glibc-common, then installed the glibc update. I then removed the older glibc and glibc-common.

At this point, I could boot the -14 kernel, but with a ridiculous number of errors on start-up. I installed the kernel source and kernel headers for the -14 kernel, plus the gcc-c++ gcc and required dependencies from the rh8.0 distro,

I was able to build a kernel, but with a problem at the modules_install stage. in the end, I moved all of the existing -5 versions from the /lib/modules folder (including the e-smith ones) removed System.Map from the /boot folder, and did a proper kernel build:

make mrproper
copy in the i686 .config file
make menuconfig (probably not needed, as I didn't change anything)
make deps
make bzImage
make modules
make modules_install

And that (pretty much) got me to this state: I have tested PHP, Mysql, apache, samba, backup, squid, dns, qmail, dungog's multipop, imp, imap (courier) and ssh with no problems.

Now, as I see it, I need to get the module auto-loading, and stop the existing HPT driver from probing the card.. and those seem slightly more do-able!

[Karl Ponsonby]

Hi Ian,


Great work, just needed a bigger hammer
Ok, where to now ? I have errors on install detecting my raid card in 5.6 but not 6b3, and am wondering where this leaves me. I have mashed together the boot disk images from 5.6 and 6b3, but havn't has a chance to get to the site and try. The disk boots ok on a regular pc, so I'm hoping that it might work, and not throw errors. If I can get it to load, I should in theroy be able to follow your directions and make/build a decent kernel and get full h/w support for the life of the server.....
'a penny for your thoughts '

Regards,

Karl