[yocto] odd(?) behaviour with qemu arm image and "runqemu-extract-sdk"

[Robert P. J. Day]

On Tue, 1 Jan 2013, Scott Garman wrote:

> On 12/29/2012 09:33 AM, Robert P. J. Day wrote:
> >
> >    first time perusing these sections in the yocto docs, kind of
> > puzzling result so i'm prepared to believe i did something silly.
> > reading:
> >
> > http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#workflow-using-stand-alone-cross-development-toolchains
> >
> > "Workflow Using Stand-alone Cross-development Toolchains", and i
> > already had an OE qemuarm core-image-minimal built that i can run
> > just fine with:
> >
> > $ runqemu qemuarm
> >
> > so i was reading that section and followed the link over to the ADT
> > manual:
> >
> > http://www.yoctoproject.org/docs/1.4/adt-manual/adt-manual.html#extracting-the-root-filesystem
> >
> > where it talked about "Extracting the Root Filesystem", so i figured,
> > what the heck, i'll give that a shot, so i ran "runqemu-extract-sdk"
> > on the very rootfs tarball that had been created by my build and
> > extracted it under ~/rootfs, then without reading any further, tried
> > this variation of runqemu for the first time:
> >
> > $ runqemu qemuarm ~/rootfs
> > Assuming /home/rpjday/rootfs is an nfs rootfs
> > Continuing with the following parameters:
> > KERNEL:
> > [/home/rpjday/oe/builds/oe/qemuarm/tmp-eglibc/deploy/images/zImage-qemuarm.bin]
> > ROOTFS: [/home/rpjday/rootfs]
> > FSTYPE: [nfs]
> > Setting up tap interface under sudo
> > [sudo] password for rpjday:
> > Acquiring lockfile for tap0...
> > runqemu-export-rootfs restart /home/rpjday/rootfs
> > Error: Unable to find rpc.mountd binary in
> > /home/rpjday/oe/builds/oe/qemuarm/tmp-eglibc/sysroots/x86_64-linux/usr/sbin/
> > Have you run 'bitbake meta-ide-support'?
> > Set 'tap0' nonpersistent
> > Releasing lockfile of preconfigured tap device 'tap0'
> > $
> >
> >    so ... how many things did i do wrong?
>
> Hi Robert,
>
> When you built your original image, it generated a filesystem in a
> file (in this case, an ext3 one) which the runqemu script used to
> boot with.
>
> But booting an nfs-based image with runqemu requires our userspace
> NFS server. This is a new requirement that requires you to build the
> meta-ide-support target.
>
> So in this case, what you're seeing is exactly what is intended -
> the runqemu script tells you what you need to do to proceed. You did
> nothing wrong.
>
> There was a time (a long time ago) when meta-ide-support was built
> anytime qemu was built, but we ended up splitting it out since it
> added an unnecessary build dependency on meta-ide-support when most
> users never needed to boot an NFS image.

  that's fine ... it's probably worth adding that tidbit to the docs
since the only thing that was concerning me was trying something
according to the docs and have it come back saying, "wait, did you do
X first?" when i didn't recall anything suggesting i do X in the first
place.  and i didn't want to simply follow the advice and do X until i
verified that i didn't miss the advice to run X earlier.

  ok, that's the mimosas talking ...

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================