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

[Scott Garman]

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.

   some random thoughts on this
> before i dig back into the docs and code:
>
> 1) why the name "runqemu-extract-sdk"?  it seems that the point of
> that script is to just untar a root filesystem.  i don't see anything
> being "extracted" per se.

I suppose runqemu-extract-rootfs might be a better name for it. When the 
script was first developed, the main use case for it was extracting the 
-sdk images so they could be used with our application developer tools.

The key thing this script does is extract the rootfs tarball under 
pseudo, which creates a virtual mapping of file ownership that is 
necessary for the rootfs to be usable but not require root access from 
the end user's perspective.

> 2) i notice that the "dev" directory created by that script contains
> only regular files instead of actual special device files.  but if i
> use "sudo" to just untar exactly the same tarball, i get real device
> files.  is that the expected behaviour of that script?

Yes - since the invokation of pseudo from the runqemu-extract-rootfs 
script creates a pseudo database that will later be used when runqemu 
boots the rootfs to read the files.

> 3) what should i have done earlier to have the apparently necessary
> usr/sbin/rpc.mountd in my sysroot?

Just what the script said: bitbake meta-ide-support


   it seems odd that i can run my
> built qemu image just fine if i run it normally, but if i
> runqemu-extract-sdk to unload a rootfs, suddenly my sysroot is missing
> that utility.

By now I hope it should be clear that the rpc.mountd was not needed to 
boot a .ext3 image. It's only needed for NFS-based booting. So the file 
didn't suddenly disappear when you went to boot the NFS-based rootfs. It 
was just needed for the first time then.

>    and one more thing.  from that first link in the dev manual, there's
> that note that takes you over to the ADT manual.  and it's entirely
> possible that there some critical info *before* the section
> "Extracting the Root Filesystem" but given how one got there (by
> following the link), the reader might miss it.

I'll have to leave this one to our app dev folks and ScottR if they 
agree something should be changed.

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center