Busybox compilation installed binaries to "real" Linux and not to chrooted "T2 Linux"

[Mike N]

Hello,

I'm a pretty recent T2 user. I have created HTPC Linux distro and so far it was a sort of spinoff of "Puppy" Linux distro. However, in the end "stock Puppy distro" was so heavily modified and customized that "HTPC" version started to live life ot its own.

I started to look for easy way to build to HTPC distro from ground up to make sure that everything is optimized for HTPC usage and nothing else. I was comparing LFS and T2 projects and eventually I decided I'm going to use T2 project. Looks like people around T2 project have done a lot I no longer need to do manually. Good work.

I have re-compiled "everything" in T2 (svn t2-trunk version) and compiling packages seems to work OK. However, I'm having a bit of troubles compiling a new initrd system using Busybox binaries (the real target system uses "real binaries" and not busybox replacements).

My "htpc customized" target doesn't include busybox in list of included packages because the "live" distro doesn't use busybox. Therefore I compiled busybox package as a separate command.

I compiled my "normal" target using following command:
./scripts/Build-Target -cfg vdrhtpc

This went just fine but I cannot use the "stock" T2 initrd so I used only binary packages from this compilation (and I know there seem to be udev issue with t2-trunk version and initrd bootscripts).


Then I downloaded and compiled busybox sources using following commands:
./scripts/Download busybox
./scripts/Build-Pkg -cfg vdrhtpc busybox

Downloading went just fine and compilation seem to go just fine but then catastrofen stroke. Build-Pkg command didn't install busybox binaries to "chrooted" environment but instead to "live linux" system and overwriting all my normal binaries in development environment (had to re-install my Linux but at least I got rid of all unnecessary stuff accumulated into it :-) ).

What did I do wrong? Probably a lot but is there something special I need to do if I compile single package (not part of normal target packages list) and NOT want it to install binaries over live Linux system?

Now when I think of this then probably installing busybox binaries over the "chrooted" vdrhtpc TOOLCHAIN/rootfs system would have been equally wrong result but naturally less hazardous.

Is the right way to create a new target specific for a this "initrd" compilation?  

Or can I create instruct T2 to prepare the Busybox source directory (all T2 magic with patches etc) and just compile the package but not install (not live linux and not into chrooted target rootfs)?

Or even instruct T2 to prepate Busybox source directory and then manually compiling (make) sources and skipping "make install" step?

Thanks in advance and best regards,
 Mike N

[t2]

On Mon, 10 Dec 2007 02:38:09 -0800 (PST)
Mike N <poiux@...> wrote:

> ./scripts/Build-Pkg -cfg vdrhtpc busybox

IMHO you should use 'Build-Target' with the option '-job' and define the stage. For example

./scripts/Build-Target -cfg vdrhtpc -job 5-busybox


And, yes, once I did the same mistake and blobed my system. The choice of the name is a bit confusing.

Would you like to upload the HTPC target definition to T2?


regards,
yokoy



-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
lists@... with a subject of: unsubscribe t2

[Mike N]

Thanks for the quick and excellent reply. The "Build-Target -cfg vdrhtpc -job 5-busybox" command did the magic and I was able to compile busybox on its own and not to nuke my host Linux system.

I have to admit that I had stopped reading manual after seeing "Build-Pkg" command with optional package parameter. I thought that "yes, that's the command" and went on running it. Well, now I know more. Thanks.

I'm happy to post this vdrhtpc (or whatever the final name will be) as an additional target to T2 once I have finalized it. I'm still learning T2 environment but have made already great progress. Doing all this manually would have taken ages to build tailored distro.

The vdrhtpc distro does have some featues not found from existing "general/embedded" targets so it might be some contribution. For example it runs completely in RAM filesystem but is still able to store modified files back to hard disk (squashed image file on disk) when needed (ie. log and temp files are never stored back to hd). It uses UnionFS also so if something goes seriously wrong in saved session then it is easy to revert back to "factory default" settings by discaring the additional UnionFS layer. BarryK in Puppy distro has done great work with Puppy and the use of RAM+UnionFS+Squash combination was inspired by Puppy.

However, Puppy distro is for desktop office usage so didn't quite fit in "set-top-box" HTPC environment. This is why T2 came in the picture. And don't tell my kids but Santa Claus is bringing in brand new Playstation3 console and I'm planning to test this vdrhtpc setup in PS3 also. T2 might be great environment to compile both PC and PS3 light-weight htpc distro easily. Yes, PS3 is for kids not for me :-)

- Mike

t2 wrote:

> ./scripts/Build-Pkg -cfg vdrhtpc busybox

IMHO you should use 'Build-Target' with the option '-job' and define the stage. For example
./scripts/Build-Target -cfg vdrhtpc -job 5-busybox

And, yes, once I did the same mistake and blobed my system. The choice of the name is a bit confusing.
Would you like to upload the HTPC target definition to T2?