Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: waslit on March 07, 2012, 09:42:51 AM
-
??? Im just trying to understand something real simple. I noticed that in 4.3x there is a cde directory where extecnsions are located. But in 3.x, and I assume lower, the directory is not there. Is that because it was added later? And then how were the extensions located? I did find this in the wiki but not really sure if I'm just barking up the wrong tree. Man that diidnt make any sense, I meant looking in the wrong direction not barking up wrong tree :-[
cat microcore.gz Xlibs.gz Xprogs.gz Xvesa.gz > my_xcore.gz
-
Hi waslit
For most users, the tce directory is where all of your extensions are kept, and it must be writable.
Somewhere in the 4.x series, a CDE (CD Extensions) directory was added, this is a read only
directory to allow extensions to be included on read only media. That's the simple explanation,
if you want more details, you'll have to search the forum.
cat microcore.gz Xlibs.gz Xprogs.gz Xvesa.gz > my_xcore.gz
That command simply combines those files basically creating tinycore.gz. Most users have no
need to do this type of thing.
-
tce directory is where all of your extensions are kept, and it must be writable.
... and your backup file kept there too.
-
hmmmm I see. That would explain why when using the 2.6.xx kernel it doesnt see that directory or hangs. I will have to do further looking then but that does help ty.
-
hmm dont seem to really be getting anywhere. Is there something specific I need to do to make a 2.6.xx kernel to look for the cde directory? Or will a sipmle tce= option work?
-
It has nothing to do with the kernel.
-
weird? Cause it worked fine on kernel 3.0.3 but since I went down to 2.6 its not..... Maybe Im just getting side tracked because it appears to freeze around that area. More test I guess
-
weird? Cause it worked fine on kernel 3.0.3 but since I went down to 2.6 its not..... Maybe Im just getting side tracked because it appears to freeze around that area. More test I guess
Which TC version have you been using with 2.6 kernel?
-
been using the latest one, but needed to use an older kernel like 2.6. So I tried to use the kernel from the src tree in the TC repo and it appears to just halt. At first always at loop module loaded but after more trials it is pretty random. Initially I remembered the extensions loading next and that what made me thought that but then it should just go to prompt. Am I reaching to far trying the older kernel with the latest release maybe?
-
Hi waslit
If you need to run an older kernel, try running Tinycore 3.8.4.
It's quite possible that some of the files in the TC4.3 distribution were compiled to run on the 3.x kernel and won't
run with a 2.6 kernel.
-
Do not mix 3.x and 4.x systems. Obviously there is a reason why there are separate repositories.
-
Is there a list or something which wouldn't work anymore if used with older kernels?
I assume glibc for example won't work with older kernels because it was compiled against newer kernel headers.
-
Obviously there is a reason why there are separate repositories.
Obviously some things don't have a reason.
-
Yea its no biggie. Oh well
-
Is there a list or something which wouldn't work anymore if used with older kernels?
I assume glibc for example won't work with older kernels because it was compiled against newer kernel headers.
udev and glibc mainly, and by extension of glibc, everything compiled on 4.x.
-
So using 4.x kernels on 3.x would be no problem, right?
Only the other way around.
-
Hi hiro
Wrong. There may have been structural changes to the kernel on 4.x.
-
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.
-
If the interface or data structures used for drivers like wireless for example changed, that too might cause a problem.
-
Thanks, I think this clarified everything left.
-
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"
-
waslit: this scares me!
-
Ew, more proprietary unfixable software.
-
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 =)
-
Well, if you're from the LSI dark side, only then you can easily fix that ;)
-
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.