Expected Behavior ----------------- Install qemux86 eSDK Build and run qemu image Observed Behavior ----------------- Install qemux86 eSDK Build qemu image qemu session fails to start $ runqemu runqemu - INFO - Assuming MACHINE = qemux86 runqemu - INFO - Can't find qemuboot conf file, DEPLOY_DIR_IMAGE is NULL! runqemu - INFO - Running MACHINE=qemux86 bitbake -e... runqemu - INFO - Overriding conf file setting of STAGING_DIR_NATIVE to /home/hbruce/Tools/yocto/qemux86-ext-2.2/tmp/sysroots/x86_64-linux from Bitbake environment runqemu - INFO - Overriding conf file setting of STAGING_BINDIR_NATIVE to /home/hbruce/Tools/yocto/qemux86-ext-2.2/tmp/sysroots/x86_64-linux/usr/bin from Bitbake environment Traceback (most recent call last): File "/home/hbruce/Tools/yocto/qemux86-ext-2.2/layers/poky/scripts/runqemu", line 1019, in <module> ret = main() File "/home/hbruce/Tools/yocto/qemux86-ext-2.2/layers/poky/scripts/runqemu", line 1007, in main config.check_and_set() File "/home/hbruce/Tools/yocto/qemux86-ext-2.2/layers/poky/scripts/runqemu", line 559, in check_and_set self.check_fstype() File "/home/hbruce/Tools/yocto/qemux86-ext-2.2/layers/poky/scripts/runqemu", line 451, in check_fstype raise Exception("FSTYPE is NULL!") Exception: FSTYPE is NULL! [hbruce@hbruce-desk3 qemux86-ext-2.2]$ . environment-setup-i586-poky-linux Workaround ---------- Manually set DEPLOY_DIR_IMAGE DEPLOY_DIR_IMAGE=/path/to/esdk/tmp/deploy/images/qemux86 runqemu qemux86 Steps to reproduce ------------------ 1. Build core-image-minimal image with MACHINE=qemux86 2. Build minimal extensible SDK installer 3. Install eSDK 4. Start eSDK session by running 'source environment-setup-i586-poky-linux' 4. Build image with 'devtool build-image' 5. Start qemu session with 'runqemu qemux86' An example eSDK installer can be found at http://downloads.yoctoproject.org/tools/support/workflow/poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-2.2.sh
Fix sent. The new runqemu script is making an assumption it should not - and not handling the error particularly well - but I think at this stage that's something we will have to fix later. For now the patch I've sent resolves the issue within the eSDK (although if you were to run runqemu directly, as you now can in master/morty by virtue of the fix to allow the Eclipse plugin to work, then it'll still be a problem).
*** Bug 10465 has been marked as a duplicate of this bug. ***
Fix merged to master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a8169807e85457d90016522a6eb7113c9159ec18 And morty: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=morty&id=2c0efd2f33fc152546128f9361e71d0dc93a90d5
Tested on morty and Failed I followed this Steps to reproduce ------------------ 1. Build core-image-minimal image with MACHINE=qemux86 2. Build minimal extensible SDK installer 3. Install eSDK 4. Start eSDK session by running 'source environment-setup-i586-poky-linux' 4. Build image with 'devtool build-image' 5. Start qemu session with 'runqemu qemux86' and I got the same error message: raise Exception("FSTYPE is NULL!") Exception: FSTYPE is NULL! Regards,
Failed on morty.
Which morty revision did you test?
I'm seeing same failure on master commit: e5815d0b607ff262663864d51fe51fbb37172329
Sigh. So it turns out I didn't quite read the bug properly - this is talking about running runqemu directly, which until recently wasn't even possible (we had to allow it in order for the Eclipse plugin to work - but I believe it runs it with arguments such that this problem doesn't occur). However if you read my comment above I did say that running runqemu directly would still cause this issue to happen. If you want to run qemu in the eSDK from the command line, the recommended way to do it is "devtool runqemu" which is what I fixed. So there is a way to do it that works. Alternatively you should be able to run it directly if you give it the full path to the image. Where does this leave us with this bug though? Running runqemu this way *should* work. The problem is the newly rewritten script is assuming it cannot run bitbake to get DEPLOY_DIR_IMAGE when that's not actually true in the eSDK. To compound things, it quite clearly does run bitbake later on so there is a disconnect in the logic.
BTW, I also entered bug 10471. Depending on how that is resolved it may end up fixing this.
When I first reported the bug, I saw the same behavior in 'runqemu' and 'devtool runquemu'. I reported the 'runqemu' variation as I assumed that was closer to the root cause. I'm OK with only having 'devtool runquemu' work, but if we take that option 'runqemu' should fail with a "don't run me directly" error.
I do agree, running runqemu directly should be made to work especially as it's now easily accessible. I just wanted to make sure people have a full understanding of what's going on and that there's a workaround.
I've send a patch working around this.
Fix merged to master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=9e267ad1739d460127e4c7ab71e886e0b1f153a1