WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: the CDE directory  (Read 8358 times)

Offline hiro

  • Hero Member
  • *****
  • Posts: 1229
Re: the CDE directory
« Reply #15 on: March 08, 2012, 03:46:30 PM »
So using 4.x kernels on 3.x would be no problem, right?
Only the other way around.

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11573
Re: the CDE directory
« Reply #16 on: March 08, 2012, 04:02:28 PM »
Hi hiro
Wrong. There may have been structural changes to the kernel on 4.x.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11040
Re: the CDE directory
« Reply #17 on: March 08, 2012, 04:34:09 PM »
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.
The only barriers that can stop you are the ones you create yourself.

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11573
Re: the CDE directory
« Reply #18 on: March 08, 2012, 04:42:45 PM »
If the interface or data structures used for drivers like wireless for example changed, that too might cause a problem.

Offline hiro

  • Hero Member
  • *****
  • Posts: 1229
Re: the CDE directory
« Reply #19 on: March 08, 2012, 05:18:00 PM »
Thanks, I think this clarified everything left.

Offline waslit

  • Newbie
  • *
  • Posts: 13
Re: the CDE directory
« Reply #20 on: March 09, 2012, 11:55:32 AM »
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"
The only limit to my abilities, lies in how much I feed my curiosities.

Offline hiro

  • Hero Member
  • *****
  • Posts: 1229
Re: the CDE directory
« Reply #21 on: March 09, 2012, 02:05:57 PM »
waslit: this scares me!

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11040
Re: the CDE directory
« Reply #22 on: March 09, 2012, 02:11:23 PM »
Ew, more proprietary unfixable software.
The only barriers that can stop you are the ones you create yourself.

Offline waslit

  • Newbie
  • *
  • Posts: 13
Re: the CDE directory
« Reply #23 on: March 09, 2012, 04:29:00 PM »
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 =)
The only limit to my abilities, lies in how much I feed my curiosities.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11040
Re: the CDE directory
« Reply #24 on: March 10, 2012, 02:47:08 AM »
Well, if you're from the LSI dark side, only then you can easily fix that ;)
The only barriers that can stop you are the ones you create yourself.

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11573
Re: the CDE directory
« Reply #25 on: March 10, 2012, 10:34:30 AM »
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:
Quote
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.