Bug 1599 - GRUB 2 installed with GRUB 1 menu config on n450
Summary: GRUB 2 installed with GRUB 1 menu config on n450
Status: RESOLVED INVALID
Alias: None
Product: BSPs
Classification: Build System, Metadata & Runtime
Component: bsps-configuration (show other bugs)
Version: unspecified
Hardware: Blacksand Multiple
: High critical
Target Milestone: 1.1
Assignee: Saul Wold
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2011-10-04 09:07 UTC by Darren Hart
Modified: 2011-10-04 13:24 UTC (History)
2 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments
core-image-minimal log.do_rootfs for ipk build (55.92 KB, text/plain)
2011-10-04 09:54 UTC, Darren Hart
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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.