Bug 4815

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