Bug 12806

This works fine for me in my builds.

I need source/build based reproducers, since I can't debug these images.

With the help from Anuj: 
Following the steps give, able to reproduce the issue, boot hang and graphic display not showing. 

Login with serial, capture dmesg error related matchbox. 
[ 75.163957] connman-applet[471]: unhandled signal 11 at 0048503c nip 0048503c lr 007bfab4 code 2
[ 76.038291] matchbox-panel[496]: unhandled signal 11 at 0048503c nip 0048503c lr 007bfab4 code 2
[ 76.045562] matchbox-deskto[495]: unhandled signal 11 at 0048503c nip 0048503c lr 007bfab4 code 2
[ 77.684595] settings-daemon[462]: unhandled signal 11 at 00088340 nip 00088340 lr 000b1fe8 code 1

After login with serial:
root@qemuppc:~# export LD_USE_LOAD_BIAS=0; export DISPLAY=:0; matchbox-desktop

Successfully bring up the graphic. 

Also Anuj found the similar bug 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9131

Verified that the although runtime/xorg.py test passed with assert that ps -ef contain xinit, but the display was not loading. Since runtime/xorg.py was not able to identify every display issue, need to perform manual testing on coming QA release. 

NOTE:  ... ok
NOTE: test_xorg_running (xorg.XorgTest)
DEBUG: Checking if x11-base is in DISTRO_FEATURES or IMAGE_FEATURES
DEBUG: [Running]$ ssh -l root -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=ERROR 192.168.7.4 export PATH=/usr/sbin:/sbin:/usr/bin:/bin; ps -ef | grep -v xinit | grep [X]org
DEBUG: time: 1530146898.5619707, endtime: 1530147198.556345
DEBUG: Partial data from SSH call: root       398   392  4 00:47 ?        00:00:01 /usr/bin/Xorg :0 -br -pn

Reassigning to Mark, the prelink guy, for his take.  Certainly looks like prelink on arm64 is breaking.

However, I'm confused as to why we've a number of bugs recently that involve a convoluted way of booting images.  How I'd test this:

1) download core-image-sato-sdk.ext4, vmlinux, and core-image-sato-sdk.qemuboot.conf
2) source oe-init-build-env
3) runqemu core-image-sato-sdk.qemuboot.conf

I don't understand why the rootfs tarball and toolchain are downloaded, and extract-sdk used.  Can this bug be replicated by QA with the straightforward runqemu call?

(In reply to comment #4)
> Reassigning to Mark, the prelink guy, for his take.  Certainly looks like
> prelink on arm64 is breaking.
> 
> However, I'm confused as to why we've a number of bugs recently that involve
> a convoluted way of booting images.  How I'd test this:
> 
> 1) download core-image-sato-sdk.ext4, vmlinux, and
> core-image-sato-sdk.qemuboot.conf
> 2) source oe-init-build-env
> 3) runqemu core-image-sato-sdk.qemuboot.conf
> 
> I don't understand why the rootfs tarball and toolchain are downloaded, and
> extract-sdk used.  Can this bug be replicated by QA with the straightforward
> runqemu call?

Hi Ross, 

Sorry for confusion. The qemupcc graphic failed on both boot up with core-image-sato-sdk-qemuppc.ext4 as well as boot up from core-image-sato-sdk-qemuppc.tar.bz2 after extract rootfs with toolchain. 

As my understanding, some QA team member prefer download the core-image-sato-sdk tarball and toolchain to extract rootfs and runqemu for nfs because downloading core-image-sato-sdk.ext4 take 10x longer time. 

Hope this clear some confusion.

I don't have anything to do with qemu or BSP work.  However, if you think this is prelink, have you disabled it and checked that things now work?

If so, I don't see that anywhere in the comments or subject or this item.  I don't typically pay any attention to BSP related defects in the bug system, but I do care about prelink.

I suggest the subject be updated if someone believes this is a prelink issue.

Pravin, I didn't notice this defect in the YP-2.6-M2 test report.
Was it tested and if so was it reproduced?

Can you also re-test as Mark Hatle requested.

I have tested.
this bug is not reproducible in YP-2.6-M2.

Works as reported by Pravin.