Bug 10473 - Fail to launch custom qemu image with runqemu
Summary: Fail to launch custom qemu image with runqemu
Status: RESOLVED OBSOLETE
Alias: None
Product: Meta-yocto
Classification: Build System, Metadata & Runtime
Component: meta-yocto (show other bugs)
Version: 2.2
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 2.5 M1
Assignee: Leonardo Sandoval Gonzalez
QA Contact: Yi Zhao
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-10-21 08:32 UTC by Yi Zhao
Modified: 2017-10-31 15:10 UTC (History)
7 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: Regression (Used to work)
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yi Zhao 2016-10-21 08:32:31 UTC
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

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] 
#####################################
Comment 1 Leonardo Sandoval Gonzalez 2016-10-21 13:44:59 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
Comment 2 Leonardo Sandoval Gonzalez 2017-07-19 14:49:19 UTC
Unfortunately, no time to tackle this issue at M2.
Comment 3 Leonardo Sandoval Gonzalez 2017-07-28 14:19:22 UTC
(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] 
> #####################################
Comment 4 Leonardo Sandoval Gonzalez 2017-07-28 15:50:16 UTC
Yi, ignore my previous request, I was able to reproduce the issue in master.
Comment 5 Leonardo Sandoval Gonzalez 2017-07-28 19:16:44 UTC
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 ----
Comment 6 Alejandro Hernandez 2017-07-28 20:11:45 UTC
(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.
Comment 7 Leonardo Sandoval Gonzalez 2017-07-28 20:56:32 UTC
(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.
Comment 8 Leonardo Sandoval Gonzalez 2017-07-28 22:45:55 UTC
(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 ----
Comment 9 Leonardo Sandoval Gonzalez 2017-07-28 22:51:45 UTC
(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.
Comment 10 Robert Yang 2017-08-29 02:53:49 UTC
(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
Comment 11 Stephen K Jolley 2017-09-01 18:51:27 UTC
It appears your question was answered.
Comment 12 Leonardo Sandoval Gonzalez 2017-09-01 19:06:04 UTC
(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?
Comment 13 Leonardo Sandoval Gonzalez 2017-09-20 14:54:36 UTC
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
Comment 14 Leonardo Sandoval Gonzalez 2017-10-31 15:10:33 UTC
The tool yocto-bsp will be deprecated during 2.5 M1 (due to lack of resources to maintain it) so this bug becomes obsolete