Bug 1599

Summary: GRUB 2 installed with GRUB 1 menu config on n450
Product: [Build System, Metadata & Runtime] BSPs Reporter: Darren Hart <dvhart>
Component: bsps-configurationAssignee: Saul Wold <sgw>
Status: RESOLVED INVALID QA Contact:
Severity: critical    
Priority: High CC: yp.bsp.watcher, yp.watcher
Version: unspecified   
Target Milestone: 1.1   
Hardware: Blacksand   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---
Attachments:
Description Flags
core-image-minimal log.do_rootfs for ipk build none

Description Darren Hart 2011-10-04 09:07:43 UTC 
When installing from a core-image-minimal live image to the n450 I see the legacy 1.0 grub menu installed rather than the GRUB 2.0 menu. The init-install.sh script looks for /etc/grub.d/40_custom for the GRUB 2 menu - this file doesn't exist in the rootfs. In fact, no grub 2 files exist. The grub package built and installed successfully and the grub image/ directory contains all the appropriate install files. The core-image-minimal log.do_rootfs does not list grub as one of the packages it installs.

I built using ipk, while others have been building successfully with rpm.
Comment 1 Darren Hart 2011-10-04 09:52:08 UTC 
The ipk package is constructed and copied to tmp/deploy/ipk/core2/grub_1.99-r1_core2.ipk. It contains the etc/grub.d/40_custom file as well as the other grub related installation files.
Comment 2 Darren Hart 2011-10-04 09:54:43 UTC 
Created attachment 269 [details]
core-image-minimal log.do_rootfs for ipk build

This core-image-minimal log.do_rootfs for the ipk build doesn't list the grub package in the installed package list.
Comment 3 Darren Hart 2011-10-04 10:15:05 UTC 
I built clean using rpm and grub2 installs correctly.
Comment 4 Darren Hart 2011-10-04 12:16:07 UTC 
After using a new (empty) sstate-cache, this problem no longer reproduces. A clean edison build does not exhibit the failure. I tried another build using the previous sstate-cache, but multiple packages now fail to configure or compile, making it impossible to try and reproduce the original failure.
Comment 5 Darren Hart 2011-10-04 12:17:45 UTC 
Assigning to Saul to decide how to close it and whether another bug should be opened to track the possible sstate-cache related issue. Without a reproducer however, I suggest this be closed as WONTFIX or INVALID, and we open another issue if we run into something similar in the future.
Comment 6 Saul Wold 2011-10-04 13:24:29 UTC 
Agree with Darren, if we can get a reproducer for the sstate issue (if there is one), then we can open a new bug.