Tiny Core Base > Corepure64
libre kernel
FilthyJack:
Hello everyone,
I've been playing with corepure64 for quite some time and it works perfectly, I've been able to test the kernel compilation with in-ram compiletc suite and my own version of distcc which was a pleasure. Now I'd like to reproduce the steps leading to a working ramfs and would need some tips on how to proceed.
I'd like to use libre-kernel 3.16.6 (is the current one deblob already?)
Are the devs working on a base initramfs and compile BysyBox+LibC statically into it?
Can you share the base initramfs tree and give some details on compilation?
I guess I'd have to statically recompile other TC specific tools, is there a base tree showing what's added after basic busybox+libc?
Thanks for the work you put in TinyCore, happy coding!
curaga:
Our kernel is vanilla, ie it supports firmware blobs. Only ldconfig is statically linked (and from uclibc), everything else is dynamic.
The base initramfs is what you have in the ISOs or download as core.gz. Reproducing it all from scratch would be quite involved though.
FilthyJack:
Thanks for the answer!
I'm not really trying to reinvent the whole tinycore concept, I'm sure you've been through a lot to get it straight. What I'm after is the possibility to have a libre kernel + corepure64.gz + compiletc and then to be able to recompile everything from (full) source.
This is why I mentioned a pre-made initramfs , a template, before you add any pre-compiled stuff to it. Treating the binaries inside core.gz just like any package.
With that we could:
-Compile kernel.
-Get a fresh core.gz (populated with default stuff and portable scripts from TC).
-Compile ldconfig/busybox and all binary components. (creating a new core.gz)
-Compile any extension for the target system.
The whole OS could compile itself from full source and port itself to different platforms pretty easily. [/dream]
curaga:
The TC scripts are stored in git, but that's not really a complete template, there's various config files, etc. So if you want core.gz without binaries and libs, you'd need to take it and remove them, for example with the help of find, file, and xargs.
There aren't that many packages involved, we've had various ports, though now only ARM is active. There isn't documentation on what packages exactly, though - this is something you can help with, if you'd like. You can log in to the wiki with your forum credentials (after 5 posts, IIRC), and create a new page for this.
FilthyJack:
I have been able to uncompress core.gz, modify it and recompress it countless times. Everything works fine, which is strange since the bzip/cpio/advdef process never produces the same output size.
--- Code: ---# zcat core.gz | cpio -i -H newc -d
# find | cpio -o -H newc | gzip -2 > new_core.gz
--- End code ---
When I uncompress it again the custom binaries I put in there are clean and the core itself runs fine.
Assuming there is a random component in the compression then fine but this is bothering me.
Otherwise yes I'd love to share the script I made with some docs on the wiki when I reach 5 posts.
Assuming you have already compiled replacement bins/libs:
--- Code: ---sudo ./core_patch.sh <path to core.gz> <search path for replacement>
(must be executed from its own directory)
-Unpack core.gz
-List every binary/lib excluding kernel objects and charmaps
-Check if you have a replacement for them in <custom path>
-Replace them and repack everything in new_core.gz
--- End code ---
http://www.lotusrevenge.fr/PublicProjects/core_patch.sh
Navigation
[0] Message Index
[#] Next page
Go to full version