Created attachment 1304 [details] BSP_boot_log STATUS: FAILED BUILD: master:eaa5df34af42b6a37f6506847d0f3ef6ba0d298a ENVIRONMENT: Jasperforest STEPS TO REPRODUCE: 1. boot system 2. launch terminal and run "reboot" EXPECTED OUTCOME: System can reboot successfully . ACTUAL RESULT: Image/installation is compromised as follows: - qemu targets cannot boot anymore - live USB images cannot boot nor install NOTE: sato-sdk images are not affected by this. NOTE: using 'shutdown -h now' has no issues See attached log for more details: - qemu_reboot.log contains the serial output of the 'reboot' command - qemu_start_after_reboot.log contains the boot log after the 'reboot' command was issued - BSP_boot_log.jpg contains a screenshot of the boot screen after the shutdown/reboot command was given
Created attachment 1305 [details] qemu_reboot.log
Created attachment 1306 [details] qemu_start_after_reboot.log
See below for correction: NOTE: using 'shutdown -h now' has no issues on QEMU targets*
This looks udev cache is not been setup correctly for the LSB images, works ok with non-LSB.
The problem roots in the tar command. busybox's tar command works well, but the tar package's tar command doesn't work well in this situation. A very strange cause. I'll look into this problem tomorrow. //Chen Qi
In OE/Yocto, gnutar cannot correctly extract a device file. The device number is always 0. This is very strange, as on ubuntu, it works quite well with device files. See several tests and output below. TEST1: On ubuntu, create a tar ball which contains /dev/null and /dev/console, then extract the tar ball to see whether the extracted device files have the correct device numbers. RESULT1: OK chenqi@pek-qchen1-d1:~/Test$ (cd /; sudo tar cf /home/chenqi/Test/dev.tar dev/null dev/console;) chenqi@pek-qchen1-d1:~/Test$ ls dev.tar dev.tar chenqi@pek-qchen1-d1:~/Test$ sudo tar xf dev.tar chenqi@pek-qchen1-d1:~/Test$ stat dev/null File: `dev/null' Size: 0 Blocks: 0 IO Block: 4096 character special file Device: 803h/2051d Inode: 9822100 Links: 1 Device type: 1,3 Access: (0666/crw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2013-07-12 18:01:44.125875189 +0800 Modify: 2013-07-09 12:44:24.000000000 +0800 Change: 2013-07-12 18:01:44.125875189 +0800 Birth: - TEST2: On OE based image, extract the same dev.tar with busybox and gnutar to see whether the device files are extracted correctly. RESULT2: busybox's tar works well with device files while gnutar doesn't. root@qemux86:~# tar.tar xf /etc/dev.tar root@qemux86:~# stat dev/null File: dev/null Size: 0 Blocks: 0 IO Block: 1024 character special file Device: 300h/768d Inode: 7366 Links: 1 Device type: 0,0 Access: (0666/crw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2013-07-12 09:57:15.000000000 Modify: 2013-07-12 09:41:27.000000000 Change: 2013-07-12 09:57:15.000000000 root@qemux86:~# busybox tar xf /etc/dev.tar root@qemux86:~# stat dev/null File: dev/null Size: 0 Blocks: 0 IO Block: 1024 character special file Device: 300h/768d Inode: 7366 Links: 1 Device type: 1,3 Access: (0666/crw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2013-07-12 09:41:27.000000000 Modify: 2013-07-12 09:41:27.000000000 Change: 2013-07-12 09:57:50.000000000 From the above two tests, we can conclude that the gnutar's extraction process has some problem in an OE environment. For now, I can only think of one explanation for this situation, that is, something is wrong with our eglibc. But I'm not sure whether this is the right direction to go. Will look into problem next week. Any thoughts or comments are welcome. Thanks, Chen Qi
Can you verify with dylan and see if there is an issue with tar there? That would confirm if it's the newer version of eglibc or not.
@Saul: 1.4.1 RC1 did not have this issue. Please see report: https://wiki.yoctoproject.org/wiki/Full_Pass_Test_Report_for_Yocto_1.4.1_RC1_20130612-5_build#Jasperforest:_core-image-lsb-sdk Commit info: Branch: dylan Milestone: 1.4.1 RC1 poky commit: 73f103bf9b2cdf985464dc53bf4f1cfd71d4531f poky commit date: Tue Jun 11 18:00:03 2013 +0100
After retesting, it seems 'shutdown -h now' gives the same problem in QEMU targets as well. I apologize for the confusion.
Tested on core-image-lsb image with similar results. master:eaa5df34af42b6a37f6506847d0f3ef6ba0d298a
Some more information on the subject: While trying to discover why I initially thought 'shutdown -h now' did not cause any problems I came upon the following odd behavior: 1) checkout poky on master:eaa5df34af42b6a37f6506847d0f3ef6ba0d298a 2) 'bitbake core-image-lsb-sdk' 3) boot the image using qemu by alternating between the following commands: 'runqemu qemux86-64 core-image-lsb-sdk' 'runqemu qemux86-64 core-image-lsb-sdk nographic' Note that the issue described in this bug does not appear. Note that by using any of the 2 commands above in a row will trigger the error. NOTE: I used both 'shutdown -h now' and 'reboot' while testing to close the VM. I hope this helps
(In reply to comment #11) > Some more information on the subject: > > While trying to discover why I initially thought 'shutdown -h now' did not > cause any problems I came upon the following odd behavior: > > 1) checkout poky on master:eaa5df34af42b6a37f6506847d0f3ef6ba0d298a > 2) 'bitbake core-image-lsb-sdk' > 3) boot the image using qemu by alternating between the following commands: > > 'runqemu qemux86-64 core-image-lsb-sdk' > 'runqemu qemux86-64 core-image-lsb-sdk nographic' > > Note that the issue described in this bug does not appear. > Note that by using any of the 2 commands above in a row will trigger the > error. > > NOTE: I used both 'shutdown -h now' and 'reboot' while testing to close the > VM. > > > > I hope this helps This is because the udev cache is not used if two different commands are used, thus there's no process of extracting a tar ball which is created by gnutar and contains device files. The problem we have here is that the tar package in OE seems to be creating old V7 format tar ball, even when the default option is --format=gnu. Busybox extracts such tar ball correctly because it has no idea of V7 format and thus making st_rdev from devmajor and devminor. gnu has knowledge of v7 format, so even if the devmajor and devminor are correct, it sets st_rdev to 0, because it thinks that v7 format tar ball cannot handle special files, which is not true in our situation. Note that dylan has the same problem. Best Regards, Chen Qi
I finally found the root cause. It's meta/recipes-extended/tar/tar-1.26/tar-1.26-fortifysourcessigabrt.patch. This patch seems a little strange. In tar.h, we have: struct posix_header { /* byte offset */ char name[100]; /* 0 */ char mode[8]; /* 100 */ char uid[8]; /* 108 */ char gid[8]; /* 116 */ char size[12]; /* 124 */ char mtime[12]; /* 136 */ char chksum[8]; /* 148 */ char typeflag; /* 156 */ char linkname[100]; /* 157 */ char magic[6]; /* 257 */ char version[2]; /* 263 */ char uname[32]; /* 265 */ char gname[32]; /* 297 */ char devmajor[8]; /* 329 */ char devminor[8]; /* 337 */ char prefix[155]; /* 345 */ /* 500 */ }; #define OLDGNU_MAGIC "ustar " /* 7 chars and a null */ The original strcpy is actually setting magic and version field at the same time. The patch is only setting the magic field. I guess it's not doing completely right. So a quick fix for this bug would be something like: diff --git a/meta/recipes-extended/tar/tar_1.26.bb b/meta/recipes-extended/tar/tar_1.26.bb index d45c2b1..8b774e6 100644 --- a/meta/recipes-extended/tar/tar_1.26.bb +++ b/meta/recipes-extended/tar/tar_1.26.bb @@ -6,7 +6,6 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504" PR = "r5" SRC_URI += "file://remove-gets.patch \ - file://tar-1.26-fortifysourcessigabrt.patch\ " SRC_URI[md5sum] = "2cee42a2ff4f1cd4f9298eeeb2264519" (A quick test shows that the above patch works well with core-image-minimal+gnutar.) But since this patch has been in OE for a really long time, I suppose there might be a reason for it. I'll do more building and testing tomorrow to make sure everything's OK. Best Regards, Chen Qi
merged into poky/master: f1f5f7d3b45adb4e6d52dec11462fa658ccda1ec
This issue is not present in latest 1.5 M5 RC5 build. Setting to VERIFIED for: poky master:4d8ab87d25ea6e59dc88375813ef88ee0ac813d0