If we don't set PATH, then the shell will specify one for us.
Busybox adds the sbin dirs, but bash does not. I hit an
issue where bash (among other things) ended up in my initrd
and the boot scripts failed due to a bad default PATH. While
that is a separate issue, we should not be at the mercy of the
shell's default PATH. Update the initrdscripts to all specify:

PATH=/sbin:/bin:/usr/sbin:/usr/bin

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

RDEPENDS is package-specific, so add ${PN} to it.

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

grub2 needs a different set of install steps from grub 0.97.  This
adds them to init-install.sh and adds an install-time check that
determines which version is being used and which steps to use
depending on the version of grub selected.

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>

[YOCTO #1428]
Because the underlying grub 0.97 the initramfs-live-install RDEPDNEDS on
only supports 32bit x86 target, set the COMPATIBLE_HOST accordingly.

Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>

Both hddimg and livecd use init-live.sh script to boot the rootfs.img.
But the paths of rootfs.img in hddimg and livecd are different. So we add
a variable "ISOLINUX" to provide a correct path.

Signed-off-by: Jingdong Lu <jingdong.lu@windriver.com>

Fix bug: [YOCTO #686]
Because the variable "ROOT_IMAGE" in init-live.sh is not correct, it fails to
run when using liveCD. Modify value of "ROOT_IMAGE" to "isolinux/rootfs.img".
If we want to use liveCD, we also need to add some kernel options related to
CDROM support when compling kernel.

Signed-off-by: Jingdong Lu <jingdong.lu@windriver.com>

[YOCTO #1151]

Change the offset from the beginning of the disk to aligne the blocks.

In this script, we use mkfs.ext3 to create file system after partition, but we use mkpartfs to create file system repeatly,
and get some warnings about choose another specific tools to create file system for reliability.

So use mkpart instead of mkpartfs and only use mkfs.ext3 to create file system.

Signed-off-by: Mei Lei <lei.mei@intel.com>

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

initramfs-live-install is only compatible with i.86|x86_64 so
shouldn't inherit 'allarch'.  This comments it out.

More specifically, commit 52295fa3deef3b0374b99829626d524cefae6001
(Improve handling of 'all' architecture recipes and their interaction
with sstate) sets TARGET_ARCH which due to the COMPATIBLE_HOST setting
in the recipe causes it to be skipped and gives the following error
for any -live build:

NOTE: Resolving any missing task queue dependencies
NOTE: Runtime target 'initramfs-live-install' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['initramfs-live-install']
ERROR: Required build target 'core-image-sato-live' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-sato-live', 'core-ima\
ge-minimal-initramfs', 'initramfs-live-install']
ERROR: Nothing RPROVIDES 'initramfs-live-install'

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>

Commented out with explaination instead of remove

Signed-off-by: Saul Wold <sgw@linux.intel.com>

The existing PACKAGE_ARCH = "all" mechanism of sharing packages is problematic
with sstate since there are a variety of variables which have target specific
values and the sstate package therefore correctly changes signature depending
on the MACHINE setting.

This patch creates a new "allarch" class which sets:

PACKAGE_ARCH = "all"

(as per the existing convention)

INHIBIT_DEFAULT_DEPS = "1"

(since its not target specific and therefore can't depend on the cross
compiler or target libc)

TARGET_ARCH = "all"
TARGET_OS = "linux"
TARGET_CC_ARCH = "none"

(since these variables shouldn't change between the different packages and
target compiler flags shouldn't be getting used)

PACKAGE_EXTRA_ARCHS = ""

(since we shouldn't be depending on any architecture specific package architectures)

Not all PACKAGE_ARCH = "all" recipes can use this class since some run configure
checks on the compiler. This means they have target specific components and therefore
the "all" classification is incorrect.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>