[LEDE-DEV] Running init in a chroot LEDE Image

Nicolas Pace nico at libre.ws
Tue Aug 8 22:44:51 PDT 2017


Thanks for replying!

On Wed, 2017-08-09 at 10:09 +0800, Yousong Zhou wrote:
> On 9 August 2017 at 08:01, Mirko Parthey <mirko.parthey at web.de>
> wrote:
> > On Tue, Aug 08, 2017 at 11:32:23PM +0300, Nicolas Pace wrote:
> > > I'm trying to run a rootfs chroot on my desktop computer to easen
> > > the
> > > development of userspace applications, but as I'm using ubus I
> > > need a
> > > complete LEDE environment.
> > > 

[snip]

> > >  but I somehow need to call init to
> > > get ubus running (and all of the other supporting systems).
> > > 
> > > Any suggestion on how to manually call init?
> > 
> > init must be started by the Linux kernel as the first userspace
> > process
> > to ensure it is asssigned pid 1 and gets special privileges for
> > supervising other processes.

Does it need to run as pid 1 or just as the parent of all the processes
it needs to oversee?

> > To start another init from a running system, you need some kind of
> > virtualization.  I am using qemu/kvm here, managed by virt-manager
> > and
> > libvirtd.  This has the advantage of running the LEDE userspace on
> > top
> > of the LEDE kernel instead of the host kernel, which may be missing

> ./script/qemustart can also be used to quickly start QEMU
> arm/mips/x86
> instances.

I've used qemu before... this time I wanted to run it from a chroot
because:
* want to access a wireless device I'm not being able to access from
qemu... a usb wireless adaptor ath9k_htc
* i want to run an LEDE-based system (LibreMesh) on top of already
running systems like Raspbian on a Raspberry-pi or ARMBian on a Banana-
pi.

I did the chroot and throught it I can access the ath9k_htc device...
so the only pending thing is to run init somehow... or to startup the
essential services manually.

Regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20170809/286752f5/attachment.sig>


More information about the Lede-dev mailing list