| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add awareness of /dev/nvme* block devices to install scripts. As
presently
written, installer knows only of /dev/sd* and /dev/mmcblk* block
devices.
Building upon scaffolding put in place by Awais in...
80ec9f627915 ("initrdscripts: handle mmc device as installer
medium")
(From OE-Core rev: b5a036ce958e3fe24690531712071abc14b48033)
Signed-off-by: Joe Konno <joe.konno@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From Poky rev: 85c9b9f9c602459b32f8f301b161c9a3f6f14d4e)
Ported the changes from poky meta layer into BSP layer. As the
original commit was changing 2 files, this has been rework for
meta-intel layer.
[YOCTO #11367]
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Ng, Wei Tee <wei.tee.ng@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Move script to the files/intel-x86-common sub-dir which will be used
based on the added override in MACHINEOVERRIDES
Signed-off-by: Saul Wold <sgw@linux.intel.com>
foo
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RMC installer copies RMC entries after copying default entries. But
default entries aren't overwritten when RMC entries have different file
names from them, so they will be kept on target after installation.
RMC Bootloader skips loading default entries when it can get RMC entries
from RMC database file. However, RMC database file isn't deployed onto
target in installation by design.
As a result, default entries show up along with deployed RMC entries once
target reboots after installation.
We cannot get rid of these default entries in RMC deployment section because
it doesn't know which entry file should be removed.
An easier way is not to deploy default entries when any boot entry files
assumingly from RMC are already deployed at a later step. Similar logic
applies to loader.conf too.
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Reviewed-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
POSTINSTALL.sh provides developer a final chance to retouch
almost anything deployed on target before unmounting partitions
and reboot at the end of an installation session.
RMC installer executes this script if it can be queried from
RMC database file for the running board.
Some steps to make system bootable still happen after this hook.
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Reviewed-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the existing init-install-efi.sh in OE to call RMC tool
so that it can deploy file blobs and a global kernel cmdline
fragment associated to the type of current running board.
At first, it tries to retrieve a special configuration file
INSTALLER.CONFIG associated to the board from RMC database file
on ESP.
If the config file is fetched successfully, installer parses
configuration file to know which file blobs should be deployed
from database to target, also with other necessary information
like FS attributes of deployed file.
If a rule in config file is to create a directory, installer
creates it accordingly. Developer must direct installer to create
new directory first if destination of a file is in that directory
by adding a '/' at the end of a line.
The below is an example of INSTALLER.CONFIG. It directs installer to
deploy a boot entry boot.conf to EFI partition, create a
directory /etc/mylib/ on target's rootfs, and deploy a config
file mylib.conf in the created directory. The first several lines
started with '#' are comment.
efi_entry_dir:root:disk:770:/boot/loader/entries/
boot.conf:root:disk:770:/boot/loader/entries/rmcboot.conf
mylibdir:root:root:770:/tgt_root/etc/mylib/
mylib.conf:root:root:660:/tgt_root/etc/mylib/mylib.conf
When installer cannot get config file for the type of running board,
it skips any board-specific deployment. If a command fails at any
step, installer simply moves to the next.
After all the boot entries are deployed, installer seeks a config file
KBOOTPARAM from RMC database file. In success, it appends the content
of KBOOTPARAM to the end of kernel command line of every deployed
entry. KBOOTPARAM works as a global kernel command line fragment
specific to the type of running board.
The installer is copied and modified from OE:
./recipes-core/initrdscripts/files/init-install-efi.sh:
(OE-Core rev: 031c2f6ced917a81b4f39dca371773d0275ddf73)
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Reviewed-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
|
| |
|
|
|
|
|
| |
This has been moved into oe-core, so remove it and init-install.sh
from meta-intel.
Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
|
| |
|
|
|
|
|
|
|
| |
The parted 3.0 release introduced some API changes such as the removal
of mkpartfs. This updates init-install.sh to use mkpart instead.
Fixes [YOCTO #1387]
Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
|
|
|
Add a /common dir to contain code shared by multiple BSPs in the
meta-intel repo, along with a couple recipes to live there
temporarily.
In this case, there are two BSPs that need to share the common grub2
and associated initramfs-live-install changes (sugarbay and
jasperforest).
The grub2 and associated initramfs-live-install changes will soon be
submitted to the main poky repo, but for now it makes more sense to
keep them here - they're needed for live-install of the two BSPs
mentioned, but they contain a couple hacks that need to be addressed
and are untested with anything else.
Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
|
