| Summary: | [rocko] [Test Case 1534] runqemu fails using esdk in nfs mode | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Jair Gonzalez <jair.de.jesus.gonzalez.plascencia> |
| Component: | Scripts and Tools | Assignee: | Robert Yang <liezhi.yang> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | bluelightning, brian.avery, ioanax.grigoropol, javierx.zepeda.murguia, randy.macleod, ross.burton, yp.ep.watcher, yp.watcher |
| Version: | 2.4 | ||
| Target Milestone: | 2.5 M2 | ||
| Hardware: | x86 | ||
| OS: | x86_64 | ||
| Whiteboard: | Backport 2.3.3 and 2.4.1? | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
Changing to oe-core from eclipse-plugin. The root problem is that you cannot use runqemu from the extensible sdk in userspace nfs mode. This fails on the command line as well as in eclipse. runqemu is making the assumption that if DEPLOY_DIR_IMAGE is set, that there must be a *qemuboot.conf file available. It also ends up assuming that if DEPLOY_DIR_IMAGE is set, that we are not doing userspace nfs. To replicate from the command line: 1) grab a kernel, a qemu image, and an EXTENSIBLE sdk from http://downloads.yoctoproject.org 2) install and source the extensible sdk env script. 3) extract the image into one that unfs can use: $ runqemu-extract-sdk core-image-sato-sdk-qemux86-64.tar.bz2 core-image-sato-sdk-qemux86-64_ROOTFS 4) run qemu $ runqemu bzImage-qemux86-64.bin core-image-sato-sdk-qemux86-64_ROOTFS If we are using the sdk, this works and uses userspace nfs. in the extensible sdk, it fails. 5) To get it to work in the esdk $ unset DEPLOY_DIR_IMAGE $ runqemu bzImage-qemux86-64.bin core-image-sato-sdk-qemux86-64_ROOTFS ++++++++++++++++ Note: runqemu bzImage-qemux86-64.bin core-image-sato-sdk-qemux86-64_ROOTFS is how the eclipse plugin calls runqemu, it is also how we have historically called runqemu to use userspace nfs, so it would be nice not to break that. ++++ Rather than giving up if DEPLOY_DIR_IMAGE is set and no *qemuboot.conf file exists, it would be nice if the code noticed that it had been given a kernel and a rootfs and therefore did not *need* to use a *qemuboot.conf file. changed importance to undecided so it can be retriaged. This bug doesn't reproduce on 2.3.3 rc1: STATUS: PASS BUILD: 2.3.3: rc1-022df4653576c72752156bef8fda0e1aa46733d2 ENVIRONMENT: Fedora 24 x86_64 (Eclipse Oxygen) IMAGE: core-image-sato-sdk MACHINE: qemux86 TOOLCHAIN: Extensible SDK Thanks, I will close it. |
STATUS: FAILED BUILD: 2.4 M4: rc3-65d23bd7986615fdfb0f1717b615534a2a14ab80 ENVIRONMENT: Fedora 22 x86_64 (Eclipse Neon and Oxygen) IMAGE: core-image-sato-sdk MACHINE: qemux86 TOOLCHAIN: Extensible SDK STEPS TO REPRODUCE: Set the Yocto SDK's toolchain root location, sysroot location and kernel, in the menu Window -> Preferences -> Yocto SDK. (a)Point to the Toolchain: If you are using a stand-alone pre-built toolchain, you should be pointing to the /opt/poky/{test-version} directory as Toolchain Root Location. The eSDK should be used instead of regular SDK. If you are using a system-derived toolchain, the path you provide for the Toolchain Root Location field is the Yocto Project's build directory. E.g:”/home/user/yocto/poky/build” (b)Specify the Sysroot Location: Sysroot Location is the location where the root filesystem for the target hardware is created on the development system. The sysroot should be extracted with runqem-extract-sdk from an eSDK toolchain. (c)Select the Target Architecture: The target architecture is the type of hardware you are going to use or emulate. Use the pull-down Target Architecture menu to make your selection. (d) QEMU: Select this option if you will be using the QEMU emulator. Specify the Kernel matchingg the QEMU architecture you are using. e.g:” /home/$USER/yocto/adt-installer/download_image/bzImage-qemux86.bin” (e) select OK to save the settings. Create a New Project with New> Project > C/C ++ C Project > Yocto Project Autotools > Select Autotools Project > Finish In the Eclipse toolbar, expose the Run -> External Tools menu. Your image should appear as a selectable menu item. Select your image in the navigation pane to launch the emulator in a new window. If needed, enter your host root password in the shell window at the prompt. This sets up a Tap 0 connection needed for running in user-space NFS mode. EXPECTED OUTCOME: QEMU can be lauched normally. ACTUAL OUTCOME: Eclipse opens the first terminal from where QEMU is launched but then it throws the error: SDK environment now set up; additionally you may now run devtool to perform development tasks. Run devtool --help for further details. ls: cannot access '/home/<user>/poky_sdk/tmp/deploy/images/qemux86/*.qemuboot.conf': No such file or directory runqemu - ERROR - Command 'ls -t /home/<user>/poky_sdk/tmp/deploy/images/qemux86/*.qemuboot.conf' returned non-zero exit status 2 Cleanup If we manually copy the *.qemuboot.conf file on the previous path, then QEMU works. This is different than when setting the normal SDK, where the same file is not required to launch QEMU correctly. For more reference, the behavior occurs either with a pre-compiled or a locally built toolchain.