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

[Yousong Zhou]

On 9 August 2017 at 13:44, Nicolas Pace <nico at libre.ws> wrote:
> 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,

Have you tried passing through the USB wireless device to guest
machine?  Or making an image and run it insider docker?  I think there
are just too many details involved and isolation provided by
virtualisation is really nice in this situation.

                yousong