Bug 6730

Summary: meta-intel microcode commits make valleyisland-32 unbootable
Product: [Build System, Metadata & Runtime] BSPs Reporter: Tom Zanussi <tom.zanussi>
Component: bsps-meta-intelAssignee: Nitin Kamble <nitin.a.kamble>
Status: RESOLVED NOTABUG QA Contact:
Severity: critical    
Priority: Low CC: stuart.weaver, tom.zanussi
Version: unspecified   
Target Milestone: 1.7 M4   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know
Attachments:
Description Flags
Git log for cloned repository none

Description Tom Zanussi 2014-09-16 14:21:19 UTC
From the meta-intel-mailing list:

I've just made a fresh Yocto/meta-intel repository and created an image based on core-image-sato for valleyisland-32. However when booting, the kernel was panicking as it could not load /initrd. Looking at the image created I found that initrd was not being included. After comparing with an older version of the repositories I had, I found that commenting out the following lines in meta-intel/conf/machine/include/meta-intel.inc solved the issue:

# include the user space intel microcode loading support in the generated images.
# MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = " intel-microcode iucode-tool"

# For the early boot time kernel microcode loading support,
# merge the microcode data in the final initrd image.
# INITRD_prepend = "${DEPLOY_DIR_IMAGE}/microcode.cpio "

I don't know anything bout intel microcode, and hence would it be possible to explain/point me to some place that has more information about the microcode and how to configure it to create the initrd correctly?
Comment 1 Nitin Kamble 2014-09-17 01:10:52 UTC
I have asked for more information to the person who reported the issue.
Comment 2 Stuart Weaver 2014-09-17 15:29:32 UTC
To answer Nitin's Questions,


  *   Build configuration: any changes done to build setup other than setting MACHINE=valleyisland-32

A:
In local.conf, LICENSE_FLAGS_WHITELIST ="commercial" was added to allow for Gstreamer packages.
In bblayers.conf, Added layers for meta-intel, meta-valleyisland and my own layer which adds in an application and custom image files (sato based with all gstreamer packages added in)
Only change made to meta-intel layer since cloning was the comments to disable the microcode in meta-intel.inc as described in original e-mail.


  *   Does this issue happen on valleyisland-64 system?

A:
Sorry, I haven't had the time to try and test this.


  *   Explain what do you mean by initrd was not included?

A:
By this I mean that with the older version of the repository, an .iso image was created and when mounting the .hddimg onto a filesystem, there was a file called initrd. When mounting the new .hddimg, no initrd existed. After commenting lines out and rebuilding, the .iso image was created and initrd existed when mounting .hddimg
Comment 3 Nitin Kamble 2014-09-17 16:15:31 UTC
Thanks Stuart for all the responses.

The missing initrd explained in the 3rd response, is a build time issue, and it should have not happened. Can you provide following further information.

* In your build setup execute these commands:
  bitbake -e core-image-minimal > core-image-minimal.env.txt
  bitbake -e <your_image_target> > custom.img.env.txt

  And attach the 2 env.txt files to this bug?

* Can you also try if the initrd file is missing when building the core-image-minimal ?

* Also have you tried building from scratch? means, building after deleting all the contents of the build area, or building in a new area. If not, can you try that, and see if you hit the same issue?

Thanks,
Nitin
Comment 4 Nitin Kamble 2014-09-17 20:19:07 UTC
Hi Stuart,
  I just build the core-image-minimal for vallyisland-32 machine, and the initrd inside the .hddimg is good. That means something else going on in your build environment.

Note that the intel microcode feature depends on some recent changes in the poky layer. Which version of poky are you using? Does it has this commit?

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=3b19f90bdfca520a6e00057cacb103f8a55feac6


Nitin
Comment 5 Stuart Weaver 2014-09-18 10:45:48 UTC
Created attachment 2128 [details]
Git log for cloned repository

Git log from when the repository was cloned. Deleted first lines to take out any local commits I've created.
Comment 6 Stuart Weaver 2014-09-18 10:47:26 UTC
Hi Nitin,

The poky repository that wasn't working was cloned with:

git clone -b daisy git://git.yoctoproject.org/poky.git 

aprox. a day before I sent the original posting to the mailing list. I've checked the git logs and yes the commit you mention was included far in the branch's history. I've included the output from git log so that you can see the commit history that I've cloned :)

I've also pulled/merged the origin/daisy branch to my local repository and hopefully will try another build today to see if there were any more commits that have relieved the issue.
Comment 7 Stuart Weaver 2014-09-18 12:19:01 UTC
Hi Nitin again,

Sincere apologies but after looking back through I've seemed to have made a mistake by pulling the latest origin/daisy into one branch and then looked at the git log for that branch instead of switching back to the original branch.

Checking out the original branch does not infact have the commit and hence the bug could be put down to a stale version of poky.

For my own knowledge, could you let me know why the commit wasn't in the repository I cloned as mentioned in my last comment (since it was commited late July and I cloned approx. a day before posting to mailing list)?


Best Regards and Many Thanks for looking into the issue,
Stuart
Comment 8 Nitin Kamble 2014-09-18 14:57:41 UTC
Thanks for the update Stuart. I am closing this bug, as it was not the issue with the code. To answer your question, the date of the commit, and when it shows up in the tree can vary. But the commit is in the oecore for a few weeks now.