Created attachment 180 [details] detailed messages Description: Tree/Branch : Poky/master Poky Commit : a1f79a7896b6411669b3ccada6204d2695e80fc5 Meta Branch : master Meta Commit : 50661bf038a34702f3aa139c3ea0d67fbb0ce5db Image location: http://autobuilder03.jf.intel.com/crownbay-master/nightly/20110627-1/machines/crownbay/x86_32/core-image-sato-sdk-live-crownbay-20110627161550.hddimg.bz2 Boot live image from USB device, X server message issue and you can check the Xorg.0.log file from attachment for more information. the error messages as below: ############### ……… [3782087.116] (II) EMGD: Intel(R) Embedded Media and Graphics Driver version 1.6.1922 for: Intel US15W Class [3782087.116] (--) using VT number 2 [3782087.119] (==) EMGD(0): RGB weight 888 [3782087.119] (==) EMGD(0): Default visual is TrueColor [3782087.120] drmOpenDevice: node name is /dev/dri/card0 [3782087.120] drmOpenDevice: open result is -1, (No such device) [3782087.120] drmOpenDevice: open result is -1, (No such device) [3782087.120] drmOpenDevice: Open failed [3782087.122] [drm] failed to load kernel module "emgd" [3782087.122] (II) EMGD(0): Graphics hardware initialization failed. [3782087.122] (II) EMGD(0): The cause was a failure to connect with the DRM during PreInit(). [3782087.122] (II) EMGD(0): Cannot open a connection with the DRM [3782087.122] (II) UnloadModule: "emgd" [3782087.122] (EE) Screen(s) found, but none have a usable configuration. [3782087.122] Fatal server error: [3782087.122] no screens found [3782087.122] Please consult the The X.Org Foundation support at http://wiki.x.org for help. ……… ###############
Tom, can you accept this one and have a look at this to see if there is a quick fix, it would be nice to get this fixed for M2. Beth, is this possibly an Autobuilder failure to build the right EMGD driver?
This looks like bug #963 again i.e. missing branches, and the meta branch from the beginning of April: commit ec411d4008dbfc03f609e32123703bcce9227410 Author: Bruce Ashfield <bruce.ashfield@windriver.com> Date: Mon Apr 4 10:02:17 2011 -0400
So with the same checkout of both poky and meta-intel, but pointed to a fresh local kernel checkout, there isn't any problem starting the X server. For reference, the commits used were: poky commit e0fc42b51a8209dac1163ae8126f8c687b6bfddf meta-intel commit 92fc07a5f1b98779806cdcc2341487ff5ea5a238 In essence, the kernel from the autobuilder isn't picking up the last 3 months of changes made to the kernel, resulting in kernel problems like this. So, I think this is not a new bug, but a bug that should be marked a duplicate of #963.
This is a manifestation of #963, not a new bug. *** This bug has been marked as a duplicate of bug 963 ***
(In reply to comment #4) > This is a manifestation of #963, not a new bug. > > *** This bug has been marked as a duplicate of bug 963 *** Yes. And at this point, the workaround for #963 is no longer possible on the autobuilder due to some upstream packages no longer existing.
(In reply to comment #5) > (In reply to comment #4) > > This is a manifestation of #963, not a new bug. > > > > *** This bug has been marked as a duplicate of bug 963 *** > > Yes. And at this point, the workaround for #963 is no longer possible on the > autobuilder due to some upstream packages no longer existing. Can we manually remove / prevent from being created - the kernel tarball on the autobuilder so that the build will fall back to the git fetcher - until this gets a proper fix?
*** Bug 1211 has been marked as a duplicate of this bug. ***
Saul asked me to re-look at this because this problem is still occurring despite the fix for 963. The kernel being downloaded during the build appears to be the same as before, i.e before the BUG 963 fix. From the build, here is what is being fetched from the autobuilder: NOTE: fetch http://autobuilder.yoctoproject.org/sources/git2_git.yoctoproject.org.linux-yocto-2.6.37.tar.gz DEBUG: executing /usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P /home/trz/yocto/crownbay/build/downloads 'http://autobuilder.yoctoproject.org/sources/git2_git.yoctoproject.org.linux-yocto-2.6.37.tar.gz' DEBUG: Fetcher accessed the network with the command /usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P /home/trz/yocto/crownbay/build/downloads 'http://autobuilder.yoctoproject.org/sources/git2_git.yoctoproject.org.linux-yocto-2.6.37.tar.gz' DEBUG: Running export HOME="/home/trz"; export SSH_AGENT_PID="1273"; export SSH_AUTH_SOCK="/tmp/keyring-CjehJH/ssh"; export GIT_CONFIG="/home/trz/yocto/crownbay/build/tmp/sysroots/x86_64-linux/usr/etc/gitconfig"; export PATH="/home/trz/yocto/crownbay/build/tmp/sysroots/x86_64-linux/usr/bin/core2-poky-linux:/home/trz/yocto/crownbay/build/tmp/sysroots/crownbay/usr/bin/crossscripts:/home/trz/yocto/crownbay/build/tmp/sysroots/x86_64-linux/usr/sbin:/home/trz/yocto/crownbay/build/tmp/sysroots/x86_64-linux/usr/bin:/home/trz/yocto/crownbay/build/tmp/sysroots/x86_64-linux/sbin:/home/trz/yocto/crownbay/build/tmp/sysroots/x86_64-linux//bin:/home/trz/yocto/crownbay/scripts:/home/trz/yocto/crownbay/bitbake/bin/:/home/trz/yocto/crownbay/scripts:/home/trz/yocto/crownbay/bitbake/bin/:/home/trz/yocto/crownbay/scripts:/home/trz/yocto/crownbay/bitbake/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/trz/yocto/crownbay/scripts"; /usr/bin/env wget -t 5 -q --passive-ftp --no-check-certificate -P /home/trz/yocto/crownbay/build/downloads 'http://autobuilder.yoctoproject.org/sources/git2_git.yoctoproject.org.linux-yocto-2.6.37.tar.gz' Manually fetching that tarball and looking at the branches: trz@elmorro:~/autobuilder$ git branch -a * master meta yocto/base yocto/eg20t yocto/emgd yocto/gma500 yocto/standard/arm-versatile-926ejs yocto/standard/base yocto/standard/beagleboard yocto/standard/common-pc-64/base yocto/standard/common-pc-64/jasperforest yocto/standard/common-pc-64/sugarbay yocto/standard/common-pc/atom-pc yocto/standard/common-pc/base yocto/standard/crownbay yocto/standard/emenlow yocto/standard/fsl-mpc8315e-rdb yocto/standard/mti-malta32-be yocto/standard/mti-malta32-le yocto/standard/preempt-rt/base yocto/standard/preempt-rt/common-pc yocto/standard/preempt-rt/common-pc-64 yocto/standard/qemu-ppc32 yocto/standard/routerstationpro remotes/origin/master remotes/origin/meta remotes/origin/yocto/base remotes/origin/yocto/eg20t remotes/origin/yocto/emgd remotes/origin/yocto/gma500 remotes/origin/yocto/standard/arm-versatile-926ejs remotes/origin/yocto/standard/base remotes/origin/yocto/standard/beagleboard remotes/origin/yocto/standard/common-pc-64/base remotes/origin/yocto/standard/common-pc-64/jasperforest remotes/origin/yocto/standard/common-pc-64/romley remotes/origin/yocto/standard/common-pc-64/sugarbay remotes/origin/yocto/standard/common-pc/atom-pc remotes/origin/yocto/standard/common-pc/base remotes/origin/yocto/standard/crownbay remotes/origin/yocto/standard/emenlow remotes/origin/yocto/standard/fishriver remotes/origin/yocto/standard/fsl-mpc8315e-rdb remotes/origin/yocto/standard/mti-malta32-be remotes/origin/yocto/standard/mti-malta32-le remotes/origin/yocto/standard/preempt-rt/base remotes/origin/yocto/standard/preempt-rt/common-pc remotes/origin/yocto/standard/preempt-rt/common-pc-64 remotes/origin/yocto/standard/qemu-ppc32 remotes/origin/yocto/standard/routerstationpro The reason the bug is still happening is still the same reason as in comment 2 i.e. the meta commit being used in the build is from April. So it seems the fix for #963 didn't actually fix the problem, or it wasn't applied to autobuilder.
I'm testing a fix on this this week. By setting PREMIRRORS = "", the fetcher should: Hit source (which is what we want for most things). If it can't find the source, it will hit the MIRROR. (which we need for PKGS that have lost the upstream) The process the autobuilder takes is to download this into it's DL_DIR and rsync it to the source mirror. It may have had an old tarball in it's DL_DIR, which continually ended up polluting itself (with no new rev it wouldn't have fetched). So, I've made a few changes, in the hopes that something here will stick: - Cleaned out every DL_DIR of git2* - Cleaned out the mirror of the kernel tarballs and the git2 repo. - set PREMIRROR = "" - removed any reference to MIRROR = "" If that doesn't fix it, then the problem isn't on the AB side and we need to look deeper. Reassigning this to me since this may end up being an AB issue. It's not so much a duplicate of 963 as it is a result of 963.
Tried after the changes on the autobuilder were made (Comment 9), and it worked - the X server started up fine. The commits used: poky/master: 068839698fe192d8846c0ed4db65861448e8e524 meta-intel/master: 92fc07a5f1b98779806cdcc2341487ff5ea5a238 Here are the git commands on the relevant branches for comparison: trz@elmorro:/usr/local/src/yocto/cleanup/build/tmp/work/crownbay-poky-linux/linux-yocto-2.6.37+git1+d5d3c6480d61f83503ccef7fbcd765f7aca8b71b_1+372c0ab135978bd8ca3a77c88816a25c5ed8f303-r20/linux$ git branch -a master meta yocto/base yocto/eg20t yocto/emgd yocto/gma500 yocto/standard/arm-versatile-926ejs yocto/standard/base yocto/standard/beagleboard yocto/standard/common-pc-64/base yocto/standard/common-pc-64/jasperforest yocto/standard/common-pc-64/romley yocto/standard/common-pc-64/sugarbay yocto/standard/common-pc/atom-pc yocto/standard/common-pc/base * yocto/standard/crownbay yocto/standard/emenlow yocto/standard/fishriver yocto/standard/fsl-mpc8315e-rdb yocto/standard/mti-malta32-be yocto/standard/mti-malta32-le yocto/standard/preempt-rt/base yocto/standard/preempt-rt/common-pc yocto/standard/preempt-rt/common-pc-64 yocto/standard/qemu-ppc32 yocto/standard/routerstationpro remotes/origin/master remotes/origin/meta remotes/origin/yocto/base remotes/origin/yocto/eg20t remotes/origin/yocto/emgd remotes/origin/yocto/gma500 remotes/origin/yocto/standard/arm-versatile-926ejs remotes/origin/yocto/standard/base remotes/origin/yocto/standard/beagleboard remotes/origin/yocto/standard/common-pc-64/base remotes/origin/yocto/standard/common-pc-64/jasperforest remotes/origin/yocto/standard/common-pc-64/romley remotes/origin/yocto/standard/common-pc-64/sugarbay remotes/origin/yocto/standard/common-pc/atom-pc remotes/origin/yocto/standard/common-pc/base remotes/origin/yocto/standard/crownbay remotes/origin/yocto/standard/emenlow remotes/origin/yocto/standard/fishriver remotes/origin/yocto/standard/fsl-mpc8315e-rdb remotes/origin/yocto/standard/mti-malta32-be remotes/origin/yocto/standard/mti-malta32-le remotes/origin/yocto/standard/preempt-rt/base remotes/origin/yocto/standard/preempt-rt/common-pc remotes/origin/yocto/standard/preempt-rt/common-pc-64 remotes/origin/yocto/standard/qemu-ppc32 remotes/origin/yocto/standard/routerstationpro trz@elmorro:/usr/local/src/yocto/cleanup/build/tmp/work/crownbay-poky-linux/linux-yocto-2.6.37+git1+d5d3c6480d61f83503ccef7fbcd765f7aca8b71b_1+372c0ab135978bd8ca3a77c88816a25c5ed8f303-r20/linux$ trz@elmorro:/usr/local/src/yocto/cleanup/build/tmp/work/crownbay-poky-linux/linux-yocto-2.6.37+git1+d5d3c6480d61f83503ccef7fbcd765f7aca8b71b_1+372c0ab135978bd8ca3a77c88816a25c5ed8f303-r20/linux$ git log meta commit d5d3c6480d61f83503ccef7fbcd765f7aca8b71b Author: Darren Hart <dvhart@linux.intel.com> Date: Wed Jun 8 08:44:32 2011 -0700 beagleboard: new config based on meta-texasinstruments trz@elmorro:/usr/local/src/yocto/cleanup/build/tmp/work/crownbay-poky-linux/linux-yocto-2.6.37+git1+d5d3c6480d61f83503ccef7fbcd765f7aca8b71b_1+372c0ab135978bd8ca3a77c88816a25c5ed8f303-r20/linux$ git log yocto/standard/crownbay commit c1389d4cc0ea63673319bbe37d26652b8e5bae43 Merge: 372c0ab 2264cdc Author: Tom Zanussi <tom.zanussi@intel.com> Date: Wed Jul 13 15:33:49 2011 -0500 Merge branch 'yocto/emgd' into yocto/standard/crownbay commit 372c0ab135978bd8ca3a77c88816a25c5ed8f303 Merge: f46a145 bb8e31f Author: Bruce Ashfield <bruce.ashfield@windriver.com> Date: Wed Jun 22 14:29:09 2011 -0400 Merge branch 'yocto/standard/base' into yocto/standard/crownbay
The issue here is that in kern-tools, the merge of meta onto the yocto/standard/crownbay branch never occurs because the autobuilders do not have a git config --global. This occurs during do_patch and the error never makes it up as a failure. Things that should be fixed: 1. The error never percolated up and was only found through reading all kernel log files. if the merge fails, it should it should fail the build. 2. Requiring a headless build system to have a valid git config seems wrong. I understand the reasons behind it, but either this should be checked during sanity or fixed as follows. I'd suggest something like BB_AUTO_GIT_CONFIG = True which adds a flag of --author="Yocto Build System" <$USER@localhost>" to the call made during do_patch that does this merge. My current work around for this is to give the AB a git config --global. I'd also suggest lowering the critical nature of this bug as there is a known work around. Below is the log file of do_patch that exposes this: --------------------- :::::::::::::: log.do_patch :::::::::::::: Deleted branch meta-temp (was cf7d7e5). [INFO] validating against known patches (crownbay-standard-meta) *** Please tell me who you are. Run git config --global user.email "you@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: empty ident <pokybuild@autobuilder03.(none)> not allowed [####### ] (\)(15 %) [############# ] (\)(24 %) [################### ] (-)(36 %) [######################### ] (-)(48 %) [############################### ] (-)(60 %) [#################################### ] (-)(72 %) *** Please tell me who you are. Run git config --global user.email "you@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: empty ident <pokybuild@autobuilder03.(none)> not allowed [##################################################] (completed in 16 seconds)
There is no such issue in Yocto1.1 M2 RC3 testing. Tree/Branch: Poky/1.1_M2 Poky Commit id: fa4bcfdb73167f8159b88e5a4d711c0d37627a70 Meta Branch: 1.1_M2 Meta Commit id: 738d2bc6d1a0d7ff6589000893c1c8b4f983d76f Image location: http://autobuilder03.jf.intel.com/crownbay-1.1_M2/nightly/20110717-1/machines/crownbay/x86_32/core-image-sato-sdk-live-crownbay-20110717223745.hddimg.bz2
Verify this bug.
There is a workaround in place for this, but a secondary fix will be done. So this is not verified yet.