Towards Core (microcore) on Raspberry Pi

[bmarkus]

Now I have Core 4.6 running in QEMU on WINDOWS XP.  As the first check I built a small C program. It works, so I will try with more complex programs mainained by me on TC.

[bmarkus]

I built John password cracker as it has no dependency and compiles on a traditional way. Works fine on Core. I packed it to a .tcz extension. Result is a rotating rotdash during load which never stops. Also I tried to loop mount manually but it doesn't work.

Is it expected to work already?

[roberts]

Yes! tce-load works. However you need the lastest posted version.
I am running links text web browser on Raspberry Pi Core.
Which loads links.tcz and 6 dependencies!   

[bmarkus]

Tested 20120907 version with a /tce dir on an ext4 image. It is found, drive mounted and /etc/sysconfig/tcedir linked to tce. However if extension is on onboot.lst boot procedure stops at extension loading.

Deleting onboot.lst system boots fine and works. Trying 'mount -o loop john.tcz 1' where 1 is an empty directory nothing happens. No message, no prompt.

john.tcz is packed on TC x86

[roberts]

I use tce-load -i /mnt/sda1/links.tcz and works as expected.
Does not matter if I pack on tinycore or raspbian.
Have not tried onboot as that would mean editing cmdline.txt on sdcard.

[bmarkus]

Found the problem. I'm using kernel 3.1.9+ with QEMU while rpiCore-20120907.img comes with 3.2.27+ modules therefore loop module is not loaded.

QEMU requries a specially compiled Raspbian kernel what I haven't found yet.

[bmarkus]

Found 3.2.27 QEMU kernel only

[bmarkus]

No loop module in QEMU kernels 

[roberts]

Knowing that it is a huge task of compiling and building extensions,
I have purposely made raspbianCore library compatible with Raspbian.

To that end I have been working on and testing dynamically creating
tczs directly from Raspbian repositories. If this is successful then
it will greatly lessen the need to build/compile hundreds of extensions.
So far initial tests look promising, example: Links browser and its dependencies.
Auto created by entering only links.

My goal is to easily and transparently gain access to the 40,000 debs
which the user can select. They, of course, become tczs and thus gain
the Core advantage of pristine boot, onboot, and ondemand features.
Our ibibio arm tcz repository might then host only custom extensions not
available in the Raspbian repositories.

So I would hold off building extensions until I accomplish a first
milestone of this tool. Then evaluate its performance and capabilities.

Of course, I am not going to abandon the community built extensions.
The support code for such will remain intact.
The new tool will be just another option.

[netnomad]

My goal is to easily and transparently gain access to the 40,000 debs
which the user can select. They, of course, become tczs and thus gain
the Core advantage of pristine boot, onboot, and ondemand features.

hi roberts,

that's such a fascinating idea, such a overwhelming concept:
the beauty of the lean and clean tinycore combined with the vast amount of debian packages.
it's unbelievable...
i love to use my lean every-day-tools on my tiny core sticks
and i admire and enjoy the possibilities in the debian world
(from embedded routers over all kind of desktop machines up and down to tiny or mighty servers...)
... great prospect for us all.

keep on going, thank you.

[bmarkus]

Hm..... There is nothing against to do the same on x86 platform, introduce debCore86 with the great Debian repository. This would position Core as one of the many Debian clones, loosing its original idea and unique ground, depending on a Big Brother giving up independency.

And half year later if someone asks what is Tiny Core Linux the answer is 'Just a strange Debian or Ubuntu something using uncommond approach, forget it.' And in one year time it is gone.

Back to RPI I understand lack of resources, but if TC on x86 is fine with current repository, RPI version can survive with less than 40,000 extensions. Current build scripts can be easily reused to have piCore offering similar functionality as TC today.

It is good to speed up the startup, to have a bootstrap toolchain, but thats all. If it is officially a .deb converter, no way back.  Making this move would mean to give up Tiny Core philosophy.

I'm sure it is possible to build a community keeping the original idea. Maybe it is slow, for sure different than existing, but can work. You need marketing. You can touch many RPI funs, both professionals and hobbist who do not know TC yet. To be 10th of RPI is different than to be 500th on x86.

Make available a minimal system with a development toolchain and introduce as an ideal platform for small systems for both hw and QEMU in the RPI community. They will like it.  There is a great momentum. Use it.

But please, do not piggiback on the Debian repository and do not kill Tiny Core!

P.S. Read this http://forum.tinycorelinux.net/index.php/topic,13864.0.html

[roberts]

I thought I was quite clear when I said I was not going to change in any way the support for user contributed extensions.

That I stated that this tool, a deb2tcz on steriods, would be evaluated. We have had Jason's basic deb2tcz for quite a while and there was no such outrage over its announcement or use!

I am expanding the concept of deb2tcz to process debian dependencies and with selection via  a package browser ala ab/tce/tce-ab. It is an option just at the current x86 deb2tcz. YOU don't have to use it!

I am NOT giving up on the concepts that I have developed over the many years of doing Linux distributions.

There is not going to be .deb files in your extension directory. There is no call for such a harsh reaction on an optional tool.

[vinnie]

if it is possible for us to have compatibility with .deb packages as additional features without alter the normal operation of the .tcz system, this seems very positive, otherwise I agree with bmarkus, it is best to keep the spirit that has made Core distro really different.

I hazard a proposal, if we had a script system repository like Aur of archlinux this could automate the compilation by architecture from which you start the script, thus making the creation of packages multiplatform.
I do not understand crosscompilation, so forgive me if I'm saying stupid things  .

[roberts]

No loop module in QEMU kernels 

Qemu kernels are not production kernels.
I don't mind to build and test a qemu kernel if on TinyCore. I have not Windows.
Does your present qemu kernel with piCore.gz  load using Core's qemu-extra.tcz
or does that extension need an update?

[bmarkus]

No loop module in QEMU kernels 

Qemu kernels are not production kernels.
I don't mind to build and test a qemu kernel if on TinyCore. I have not Windows.
Does your present qemu kernel with piCore.gz  load using Core's qemu-extra.tcz
or does that extension need an update?

Result is kernel panic.  TC repo version is 1.0 what I'm using is 1.1