the CDE directory

[hiro]

So using 4.x kernels on 3.x would be no problem, right?
Only the other way around.

[Rich]

Hi hiro
Wrong. There may have been structural changes to the kernel on 4.x.

[curaga]

So using 4.x kernels on 3.x would be no problem, right?
Only the other way around.

In general, the kernel is backwards compatible with older userspace. But as Rich said, the config may have changed a bit from what the boot script expects.

[Rich]

If the interface or data structures used for drivers like wireless for example changed, that too might cause a problem.

[hiro]

Thanks, I think this clarified everything left.

[waslit]

Well I finally found a solution. So basically the reason I went on the venture was because of trying to use megacli which is a utility from lsi to interact with the raid controllers and drives. Basically when I ran the utility it would error out with no info. A strace of the execution made me see that it made a call to uname to see the kernel version and thought maybe it was an issue with kernel version. After some googling I found that megacli is looking for a 2.6 kernel and thats why I tried what I did. Obviously that didnt work.

So that made me think, what If I could fool the system into thinking its using 2.6?

The answer is to fake a uname syscall via LD_PRELOAD;

#vi fake-uname.c

###################################################
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <sys/utsname.h>

#include <stdio.h>
#include <string.h>

int uname(struct utsname *buf)
{
 int ret;

 ret = syscall(SYS_uname, buf);

 printf("uname release: \"%s\"\n", buf->release);
 strcpy(buf->release, "2.6.40");
 printf("uname release set to: \"%s\"\n", buf->release);
 printf("uname version: \"%s\"\n", buf->version);

 return ret;
}
###########################################################

Save it as fake-uname.c, and compile it with

# gcc -Wall -fPIC -c fake-uname.c
# gcc -Wall -shared -o libfake-uname.so fake-uname.o


Now we get libfake-uname.so, use LD_PRELOAD=./libfake-uname.so to preload it, over uname from glibc:

Gentoo-11 tmp # LD_PRELOAD=./libfake-uname.so LD_LIBRARY_PATH=./opt/lsi/3rdpartylibs/x86_64 ./opt/MegaRAID/MegaCli/MegaCli64 -adpCount
                                     
uname release: "3.0.3-tinycore"
uname release set to: "2.6.40"
uname version: "#1 SMP Mon Aug 1 02:33:28 UTC 2011"

[hiro]

waslit: this scares me!

[curaga]

Ew, more proprietary unfixable software.

[waslit]

do not be afraid. The dark side is not what you think I swear. We get way more girls and are more memorable than most action heros =)

[curaga]

Well, if you're from the LSI dark side, only then you can easily fix that

[Rich]

Hi waslit
Lets see:
1. You run a RAID array for data integrity
2. You trick a utility capable of manipulating that array into running on an OS version it was not intended for
3. It appears to work, so you assume everything will be OK
So, as long as there are no data errors or drive failures, 1+2=3 and life is good. What do you do when 1+2=4?
4. The utility misbehaves due to a change in the kernel behavior and quietly grinds your data into a jumble of 1s and 0s.

While on the surface, this might look clever, I don't think it's a smart thing to do. The smart thing to do is the obvious
thing to do, run it on a 2.6 kernel. From the LSI website:

16624, Using MegaCLI with Linux 3.0 based kernels

MegaCLI version 8.02.16 and older do not support Linux 3.0 based kernels.

 MegaRAID Storage Manager (MSM), and 3ware 3DM2/CLI work fine with Linux 3.0 based kernels.

 Once a working MegaCLI for the Linux 3.0 based kernels is available this KB article will be updated.