| Summary: | Fail to launch custom qemu image with runqemu | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Meta-yocto | Reporter: | Yi Zhao <yi.zhao> |
| Component: | meta-yocto | Assignee: | Leonardo Sandoval Gonzalez <leonardo.sandoval.gonzalez> |
| Status: | RESOLVED OBSOLETE | QA Contact: | Yi Zhao <yi.zhao> |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | alejandro.hernandez, california.l.sullivan, jose.perez.carranza, leonardo.sandoval.gonzalez, liezhi.yang, poky.bs.watcher, poky.watcher |
| Version: | 2.2 | ||
| Target Milestone: | 2.5 M1 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | Regression (Used to work) |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Yi Zhao
2016-10-21 08:32:31 UTC
The fix would consist on fixing the runqemu code (this bug) and using a qemu.conf file produced from the yocto-bsp script, for the later work is tracked on https://bugzilla.yoctoproject.org/show_bug.cgi?id=10477 Unfortunately, no time to tackle this issue at M2. (In reply to comment #0) > Git rev: morty/4b94b498e21aeba945fe7e72a6b7c4bb0314fb83 > > This issue was found when I tried to verify bug 10026 and bug 10301. > > Steps: > 1. Build a custom qemu image following the bug 10026 comment 1 > 2. Run "runqemu myqemuarm" to boot up the image > Yi, can you provide the options you selected when creating the ARM machine layer? The references you provided are all x86-64 related, and this particular issue is for ARM. > The qemu can not boot up with following error: > ################################ > runqemu - INFO - Assuming MACHINE = qemuarm > runqemu - INFO - Running MACHINE=qemuarm bitbake -e... > runqemu - ERROR - > /buildarea/jenkins-yocto/workspace/Yocto2.2-yocto-bsp_create_qemu_bsp/ > build_1/tmp/deploy/images/qemuarm not a directory valid DEPLOY_DIR_IMAGE > runqemu - INFO - CONFFILE: > /buildarea/jenkins-yocto/workspace/Yocto2.2-yocto-bsp_create_qemu_bsp/ > build_1/tmp/deploy/images/myqemuarm/core-image-sato-myqemuarm.qemuboot.conf > runqemu - INFO - Continuing with the following parameters: > runqemu - INFO - Running /sbin/ip link... > runqemu - INFO - Setting up tap interface under sudo > runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock... > runqemu - INFO - Created tap: tap0 > runqemu - INFO - Running sudo > /buildarea/jenkins-yocto/poky/scripts/runqemu-ifdown tap0 > /buildarea/jenkins-yocto/workspace/Yocto2.2-yocto-bsp_create_qemu_bsp/ > build_1/tmp/sysroots/x86_64-linux > Set 'tap0' nonpersistent > runqemu - INFO - Releasing lockfile for tap device 'tap0' > Traceback (most recent call last): > File "/buildarea/jenkins-yocto/poky/scripts/runqemu", line 1019, in > <module> > ret = main() > File "/buildarea/jenkins-yocto/poky/scripts/runqemu", line 1011, in main > config.setup_final() > File "/buildarea/jenkins-yocto/poky/scripts/runqemu", line 900, in > setup_final > qemu_system = self.guess_qb_system() > File "/buildarea/jenkins-yocto/poky/scripts/runqemu", line 895, in > guess_qb_system > return 'qemu-system-%s' % qbsys > UnboundLocalError: local variable 'qbsys' referenced before assignment > KERNEL: > [/buildarea/jenkins-yocto/workspace/Yocto2.2-yocto-bsp_create_qemu_bsp/ > build_1/tmp/deploy/images/myqemuarm/zImage-myqemuarm.bin] > MACHINE: [myqemuarm] > FSTYPE: [ext4] > ROOTFS: > [/buildarea/jenkins-yocto/workspace/Yocto2.2-yocto-bsp_create_qemu_bsp/ > build_1/tmp/deploy/images/myqemuarm/core-image-sato-myqemuarm.ext4] > CONFFILE: > [/buildarea/jenkins-yocto/workspace/Yocto2.2-yocto-bsp_create_qemu_bsp/ > build_1/tmp/deploy/images/myqemuarm/core-image-sato-myqemuarm.qemuboot.conf] > ##################################### Yi, ignore my previous request, I was able to reproduce the issue in master. Robert, I am proposing the following change to solve this issue http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=lsandov1/poky-launch-custom-qemu&id=8923b98ec196fdc19ea9b3b973dcf7673e99af44 However, I ran into another one issue and after poking a bit, I need your help to faster the solution. The problem is happening when booting (hangs at the start of the runqemu script) an image where the latter was constructed including a custom BSP. These are the details to reproduce it: create a custom qemu bsp with the yocto-bsp script, include it to BBLAYERS and construct a core-image-minimal image. Launch it with runqemu (but before, patch your poky with the above patch), and one sees a hang like the snipped below. Let me know if you see something wrong being picked from the .conf file, which is reflected on the qemu-system cmd. ----- snipped ---- > runqemu myqemux86 core-image-minimal nographic -d runqemu - DEBUG - Assuming MACHINE = myqemux86 runqemu - INFO - Running MACHINE=myqemux86 bitbake -e... runqemu - DEBUG - MACHINE: myqemux86 runqemu - DEBUG - DEPLOY_DIR_IMAGE: /home/lsandov1/poky-testing/poky-launch-custom-qemu/build/tmp/deploy/images/myqemux86 runqemu - DEBUG - CONFFILE: /home/lsandov1/poky-testing/poky-launch-custom-qemu/build/tmp/deploy/images/myqemux86/core-image-minimal-m\ yqemux86.qemuboot.conf runqemu - INFO - Continuing with the following parameters: KERNEL: [tmp/deploy/images/myqemux86/bzImage--4.10.17+git0+d6ece63221_6648a34e00-r0.1-myqemux86-20170728181509.bin] MACHINE: [myqemux86] FSTYPE: [ext4] ROOTFS: [tmp/deploy/images/myqemux86/core-image-minimal-myqemux86.ext4] CONFFILE: [/home/lsandov1/poky-testing/poky-launch-custom-qemu/build/tmp/deploy/images/myqemux86/core-image-minimal-myqemux86.qemuboot\ .conf] runqemu - DEBUG - Running /bin/ip link... runqemu - DEBUG - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock... runqemu - INFO - Using preconfigured tap device tap0 runqemu - INFO - If this is not intended, touch /tmp/qemu-tap-locks/tap0.skip to make runqemu skip tap0. runqemu - INFO - Network configuration: 192.168.7.2::192.168.7.1:255.255.255.0 runqemu - DEBUG - Running ldd tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-i386... runqemu - INFO - Running tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-i386 -device virti\ o-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive file=tmp/deploy/images/myqe\ mux86/core-image-minimal-myqemux86.ext4,if=virtio,format=raw -show-cursor -nographic -m 256 -serial mon:stdio -serial null -kernel \ tmp/deploy/images/myqemux86/bzImage--4.10.17+git0+d6ece63221_6648a34e00-r0.1-myqemux86-20170728181509.bin -append 'root=/dev/vda rw hi\ ghres=off console=ttyS0 mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 ' ----- snipped ---- (In reply to comment #5) > Robert, > > I am proposing the following change to solve this issue > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=lsandov1/poky- > launch-custom-qemu&id=8923b98ec196fdc19ea9b3b973dcf7673e99af44 > Hey Leo, I havent tried to run it yet or anything but I skimmed through your code and it seems that if mach = qemumipsel, it wouldmatch when qemumachine = qemumips AND if qemumachine = qemumipsel wouldnt it? qemumips in qemumipsel = True qemumipsel in qemumipsel = True + qemumachines = {'qemuarm64' : 'aarch64', + 'qemuarm' : 'arm', + 'qemux86-64' : 'x86_64', + 'qemux86' : 'i386', + 'qemupcc' : 'pcc', + 'qemumips64el' : 'mips64el', + 'qemumips64' : 'mips64', + 'qemumips' : 'mips', + 'qemumipsel' : 'mipsel'} + + for qemumachine, qbsys in qemumachines.items(): + if qemumachine in mach: + return 'qemu-system-%s' % qbsys The same would happen for qemux86 and qemux86-64 and other cases as well. (In reply to comment #6) > (In reply to comment #5) > > Robert, > > > > I am proposing the following change to solve this issue > > > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=lsandov1/poky- > > launch-custom-qemu&id=8923b98ec196fdc19ea9b3b973dcf7673e99af44 > > > > > Hey Leo, > > I havent tried to run it yet or anything but I skimmed through your code and > it seems that if mach = qemumipsel, it wouldmatch when qemumachine = > qemumips AND if qemumachine = qemumipsel wouldnt it? > > qemumips in qemumipsel = True > qemumipsel in qemumipsel = True > You are right. The problem here is that the items() may return a different set of keys/values that those that initialize the dict. A tuple may be better, where order is set at the start. One we have this, matches would be ok, I believe. > + qemumachines = {'qemuarm64' : 'aarch64', > + 'qemuarm' : 'arm', > + 'qemux86-64' : 'x86_64', > + 'qemux86' : 'i386', > + 'qemupcc' : 'pcc', > + 'qemumips64el' : 'mips64el', > + 'qemumips64' : 'mips64', > + 'qemumips' : 'mips', > + 'qemumipsel' : 'mipsel'} > + > + for qemumachine, qbsys in qemumachines.items(): > + if qemumachine in mach: > + return 'qemu-system-%s' % qbsys > > The same would happen for qemux86 and qemux86-64 and other cases as well. (In reply to comment #5) > Robert, > > I am proposing the following change to solve this issue > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=lsandov1/poky- > launch-custom-qemu&id=8923b98ec196fdc19ea9b3b973dcf7673e99af44 SHA updated http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=lsandov1/poky-launch-custom-qemu&id=7fb56f2d2ebfd65edf19a178ccf4b6eee36dcc52 > > However, I ran into another one issue and after poking a bit, I need your > help to faster the solution. The problem is happening when booting (hangs at > the start of the runqemu script) an image where the latter was constructed > including a custom BSP. These are the details to reproduce it: create a > custom qemu bsp with the yocto-bsp script, include it to BBLAYERS and > construct a core-image-minimal image. Launch it with runqemu (but before, > patch your poky with the above patch), and one sees a hang like the snipped > below. Let me know if you see something wrong being picked from the .conf > file, which is reflected on the qemu-system cmd. > > > ----- snipped ---- > > runqemu myqemux86 core-image-minimal nographic -d > runqemu - DEBUG - Assuming MACHINE = myqemux86 > runqemu - INFO - Running MACHINE=myqemux86 bitbake -e... > runqemu - DEBUG - MACHINE: myqemux86 > runqemu - DEBUG - DEPLOY_DIR_IMAGE: > /home/lsandov1/poky-testing/poky-launch-custom-qemu/build/tmp/deploy/images/ > myqemux86 > runqemu - DEBUG - CONFFILE: > /home/lsandov1/poky-testing/poky-launch-custom-qemu/build/tmp/deploy/images/ > myqemux86/core-image-minimal-m\ > yqemux86.qemuboot.conf > runqemu - INFO - Continuing with the following parameters: > > KERNEL: > [tmp/deploy/images/myqemux86/bzImage--4.10.17+git0+d6ece63221_6648a34e00-r0. > 1-myqemux86-20170728181509.bin] > MACHINE: [myqemux86] > FSTYPE: [ext4] > ROOTFS: [tmp/deploy/images/myqemux86/core-image-minimal-myqemux86.ext4] > CONFFILE: > [/home/lsandov1/poky-testing/poky-launch-custom-qemu/build/tmp/deploy/images/ > myqemux86/core-image-minimal-myqemux86.qemuboot\ > .conf] > > runqemu - DEBUG - Running /bin/ip link... > runqemu - DEBUG - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock... > runqemu - INFO - Using preconfigured tap device tap0 > runqemu - INFO - If this is not intended, touch > /tmp/qemu-tap-locks/tap0.skip to make runqemu skip tap0. > runqemu - INFO - Network configuration: > 192.168.7.2::192.168.7.1:255.255.255.0 > runqemu - DEBUG - Running ldd > tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/ > bin//qemu-system-i386... > runqemu - INFO - Running > tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/ > bin//qemu-system-i386 -device virti\ > o-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev > tap,id=net0,ifname=tap0,script=no,downscript=no -drive > file=tmp/deploy/images/myqe\ > mux86/core-image-minimal-myqemux86.ext4,if=virtio,format=raw -show-cursor > -nographic -m 256 -serial mon:stdio -serial null -kernel \ > tmp/deploy/images/myqemux86/bzImage--4.10.17+git0+d6ece63221_6648a34e00-r0.1- > myqemux86-20170728181509.bin -append 'root=/dev/vda rw hi\ > ghres=off console=ttyS0 mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 > ' > ----- snipped ---- (In reply to comment #8) > (In reply to comment #5) > > Robert, > > > > I am proposing the following change to solve this issue > > > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=lsandov1/poky- > > launch-custom-qemu&id=8923b98ec196fdc19ea9b3b973dcf7673e99af44 > > SHA updated > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=lsandov1/poky- > launch-custom-qemu&id=7fb56f2d2ebfd65edf19a178ccf4b6eee36dcc52 My bad. this is the correct URL: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lsandov1/poky-launch-custom-qemu sorry for the spam. (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #5) > > > Robert, > > > > > > I am proposing the following change to solve this issue > > > > > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=lsandov1/poky- > > > launch-custom-qemu&id=8923b98ec196fdc19ea9b3b973dcf7673e99af44 > > > > SHA updated > > > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=lsandov1/poky- > > launch-custom-qemu&id=7fb56f2d2ebfd65edf19a178ccf4b6eee36dcc52 > > My bad. this is the correct URL: > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lsandov1/poky- > launch-custom-qemu > > sorry for the spam. Hi, I looked at the newest patch, I didn't see any problems: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=lsandov1/poky-launch-custom-qemu&id=82f4cf037e4d73be4fa4098df5da45feb5d82d26 It appears your question was answered. (In reply to comment #5) > Robert, > > I am proposing the following change to solve this issue > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=lsandov1/poky- > launch-custom-qemu&id=8923b98ec196fdc19ea9b3b973dcf7673e99af44 > > However, I ran into another one issue and after poking a bit, I need your > help to faster the solution. The problem is happening when booting (hangs at > the start of the runqemu script) an image where the latter was constructed > including a custom BSP. These are the details to reproduce it: create a > custom qemu bsp with the yocto-bsp script, include it to BBLAYERS and > construct a core-image-minimal image. Launch it with runqemu (but before, > patch your poky with the above patch), and one sees a hang like the snipped > below. Let me know if you see something wrong being picked from the .conf > file, which is reflected on the qemu-system cmd. > > > ----- snipped ---- > > runqemu myqemux86 core-image-minimal nographic -d > runqemu - DEBUG - Assuming MACHINE = myqemux86 > runqemu - INFO - Running MACHINE=myqemux86 bitbake -e... > runqemu - DEBUG - MACHINE: myqemux86 > runqemu - DEBUG - DEPLOY_DIR_IMAGE: > /home/lsandov1/poky-testing/poky-launch-custom-qemu/build/tmp/deploy/images/ > myqemux86 > runqemu - DEBUG - CONFFILE: > /home/lsandov1/poky-testing/poky-launch-custom-qemu/build/tmp/deploy/images/ > myqemux86/core-image-minimal-m\ > yqemux86.qemuboot.conf > runqemu - INFO - Continuing with the following parameters: > > KERNEL: > [tmp/deploy/images/myqemux86/bzImage--4.10.17+git0+d6ece63221_6648a34e00-r0. > 1-myqemux86-20170728181509.bin] > MACHINE: [myqemux86] > FSTYPE: [ext4] > ROOTFS: [tmp/deploy/images/myqemux86/core-image-minimal-myqemux86.ext4] > CONFFILE: > [/home/lsandov1/poky-testing/poky-launch-custom-qemu/build/tmp/deploy/images/ > myqemux86/core-image-minimal-myqemux86.qemuboot\ > .conf] > > runqemu - DEBUG - Running /bin/ip link... > runqemu - DEBUG - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock... > runqemu - INFO - Using preconfigured tap device tap0 > runqemu - INFO - If this is not intended, touch > /tmp/qemu-tap-locks/tap0.skip to make runqemu skip tap0. > runqemu - INFO - Network configuration: > 192.168.7.2::192.168.7.1:255.255.255.0 > runqemu - DEBUG - Running ldd > tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/ > bin//qemu-system-i386... > runqemu - INFO - Running > tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/ > bin//qemu-system-i386 -device virti\ > o-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev > tap,id=net0,ifname=tap0,script=no,downscript=no -drive > file=tmp/deploy/images/myqe\ > mux86/core-image-minimal-myqemux86.ext4,if=virtio,format=raw -show-cursor > -nographic -m 256 -serial mon:stdio -serial null -kernel \ > tmp/deploy/images/myqemux86/bzImage--4.10.17+git0+d6ece63221_6648a34e00-r0.1- > myqemux86-20170728181509.bin -append 'root=/dev/vda rw hi\ > ghres=off console=ttyS0 mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 > ' > ----- snipped ---- Robert, any reason why I am seeing the above hang? Although there is solution to this problem, patch has not been sent to the community and a post-merge issue is happening as reported. All these two should be work during 2.5 The tool yocto-bsp will be deprecated during 2.5 M1 (due to lack of resources to maintain it) so this bug becomes obsolete |