On Wed, 19 Nov 2008 10:04:56 +0530 Sivakumar.R.J <rj.sivakumar@gmail.com> wrote: > After finish all the study i installed emdebian-tools in my debian > host (which is a chroot debian in ubuntu system as i come across it > will support in that only in one of your doc), then ran emsetup to > update the source.list and emchain ended with some error in binutils > for armel You shouldn't need emchain for armel if your Debian chroot is set up correctly. The problem is that Ubuntu just doesn't work well with Emdebian and using a chroot can make things a bit more difficult. If you want armel, persist with emsetup until it can locate the existing armel toolchains. You didn't say why it failed so I can't say how you need to fix the Debian chroot. > ( then i concluded that armel support is still not in > emdebian) There are no pre-built packages for armel at this time, correct. However, armel toolchains do exist and the current Emdebian packages can be built for armel. Emdebian does support armel. > .so, i just want to creat a minimal base filesystem for arm > with help of emsandbox, i still in the vague whether going in the > right direction. But when i try to run the ./emsanbox in target its > giving me some error What error? Be precise. Why are you trying to run emsandbox from a local directory? Ensure that the emdebian-rootfs package is installed inside the Debian chroot and run emsandbox from there. emsandbox does not run ./emsecondstage itself, it prepares the root filesystem tarball and copies emsecondstage into it. You are using a chroot inside a chroot to create a chroot inside a different chroot. ;-) (It's probably easier to have a box that runs Debian natively - Ubuntu complicates things unnecessarily, which is why I asked for emdebian-tools to be removed from Ubuntu.) The Debian chroot runs emsandbox to create the root filesystem. You copy that root filesystem out of the Debian chroot and onto the storage of the target board. Then you run ./emsecondstage to configure the installed root filesystem. The Debian chroot is only needed to cross-build new packages (e.g. for armel) and to prepare the root filesystem tarball - that's it. Everything about installing the root filesystem (including running ./emsecondstage) happens outside the Debian chroot, using your existing Ubuntu system to do things on the board. The rootfs tarball is self-contained (apart from the kernel and kernel modules). > Please Direct me in a right direction to create a minimal root > filesystem to support the datacard application 1. You do not need a toolchain to use the existing ARM packages. 2. You do need a toolchain to create your own packages for armel and one does exist but Ubuntu makes it hard for emsetup to do things properly. Your Debian chroot is not 100% complete the moment debootstap has finished - I have no Ubuntu systems and I cannot advise on how to fix the remaining problems of running a Debian chroot on Ubuntu as most are to do with the Ubuntu system underneath. The solution would be to use a native Debian system. 3. run the emdebian-rootfs scripts directly, not using some local directory - emsandbox not ./emsandbox 4. run emsandbox to create an ARM root filesystem tarball: # emsandbox -a arm create 5. Back outside the Debian chroot, from Ubuntu, copy the root filesystem tarball onto the target board storage. 6. From ubuntu, boot the board and connect. 7. Decompress the root filesystem and setup your kernel and kernel modules. 8. Run ./emsecondstage *on the board* to configure the packages. Do not run ./emsecondstage inside the Debian chroot. This is why I don't recommend using Ubuntu for Emdebian unless you are really very familiar with Debian and precisely how Debian differs from Ubuntu. Whilst I'm confident that emdebian-tools can work within a Debian chroot, there are unknown issues about exactly how to go from a bare Debian debootstrap environment to a usable Debian chroot for Emdebian when not using Debian itself. If these problems can be identified, I'm open to adding an --ubuntu mode to emsetup that checks for these changes and either advises how to achieve the change or possibly implements the change for you. A chroot is not a completely alien system, it is merely a jail located on top of an existing system and although processes running inside the chroot cannot affect files outside the chroot, the configuration of the external system (kernel, devices, modules etc.) does affect how processes inside the chroot behave. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpK51oGTXZam.pgp
Description: PGP signature