openembedded-core.git/meta/recipes-core/initrdscripts, branch jethro

init-install.sh: fix disk_size

2016-09-27T21:22:53+00:00

It mis-matched "SanDisk" or "Disk Flags" before, which caused unexpected
error.

Signed-off-by: Robert Yang 
Signed-off-by: Richard Purdie 
(cherry picked from commit a68ac76c1b6ed4c1a2fbc944c5021c89fd26217f)
[YOCTO #10333]
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie

init-install-efi: fix script for gummiboot loader

2015-12-08T08:18:12+00:00

After running gummiboot loader install option, the installed target
storage device boot parameter for root=PARTUUID is empty causing boot failure.
This issue is only observed with gummiboot and not with GRUB loader.

This fix assign the rootuuid of the rootfs partition for gummiboot loader.

[YOCTO #8709]
Signed-off-by: Ng, Mei Yeen 
Signed-off-by: Ross Burton 
Signed-off-by: Saul Wold 
Signed-off-by: Robert Yang

init-install-efi: fix script for eMMC installation

2015-12-08T08:18:12+00:00

Running the install option from bootloader to install image to eMMC will fail
with error:
Formatting /dev/mmcblk01 to vfat...
mkfs.fat 3.0.28 (2015-05-16)
/dev/mmcblk01: No such file or directory

This issue impacts both grub and gummiboot install option to eMMC device.
The installation failure is due to the following:
[1] Unable to partition eMMC as the partition prefix 'p' is not appended
The condition checking failed with the additional /dev/ appended with
the target device name.
[2] The partition uuid for boot, root and swap partition is not captured
for eMMC

This fix updated the condition checking and changed the variables to
reference the boot, root and swap partitions for UUID.

[YOCTO #8710]
(master rev: a7d081c3db776c8b0734942df6bf96f811f15bd3)

Signed-off-by: Ng, Mei Yeen 
Signed-off-by: Ross Burton 
Signed-off-by: Saul Wold 
Signed-off-by: Robert Yang

initramfs-framework: better error reporting for invalid root boot parameter

2015-09-21T14:39:32+00:00

When the "boot" parameter refers to a non-existent device, the only
visible output at normal log levels was a rather confusing:
   ERROR: There's no '/dev' on rootfs.

That's because the actual error, not being able to find the root
device, was only a debug message, which gets ignored in the default
mode.

Promoting the "root '$bootparam_root' doesn't exist." message from
"debug" to "msg" gives sufficient context to understand the error. A
more intrusive change would be to change also the control flow.

Signed-off-by: Patrick Ohly 
Signed-off-by: Ross Burton

initramfs-framework: fix "support dropping into shell on failure"

2015-09-21T14:39:31+00:00

Due to a missing $ before the variable name, all fatal errors ended up
invoking a shell, instead of only doing that when init_fatal_sh is set
as boot parameter.

Signed-off-by: Patrick Ohly 
Signed-off-by: Ross Burton

init-install-efi.sh: Avoid /mnt/mtab creation if already present

2015-09-15T16:49:22+00:00

The base-files recipe installs /mnt/mtab (it is a softlink of /proc/mounts),
so if an image includes the latter, there is no new to created it again inside
the install-efi.sh script, otherwise an error may occur as indicated on the
bug's site.

[YOCTO #7971]

Signed-off-by: Leonardo Sandoval 
Signed-off-by: Richard Purdie

initramfs-framework: support dropping into shell on failure

2015-09-12T21:47:20+00:00

When the init_fatal_sh boot parameter is present (i.e. used without
value) and a fatal problem occurs inside the initramfs-module, a shell
will be started instead of looping forever.

Useful for debugging.

Interestingly enough, the code was already indented to support such an
if check...

Signed-off-by: Patrick Ohly 
Signed-off-by: Ross Burton

initramfs-framework: support init boot parameter

2015-09-12T21:47:20+00:00

It can be useful for debugging to override the default /sbin/init.
This is something typically done via the init boot parameter which
then gets interpreted by the kernel. But when using an initramfs, it
is the initramfs which must react to the option.

Signed-off-by: Patrick Ohly 
Signed-off-by: Ross Burton

initramfs-framework: support ro boot parameter

2015-09-12T21:47:19+00:00

Default is to mount the rootfs read/write. "ro" can be used to turn
that into read-only, which is useful on systems where userspace does
an fsck before remounting read-write.

Giving both "ro" and "rw" will still mount read-only regardless of the
order, because the ordering information is not preserved by the
initramfs-framework's boot param support.

Signed-off-by: Patrick Ohly 
Signed-off-by: Ross Burton

initramfs-framework: support rootflags and rootfstype boot parameter

2015-09-12T21:47:19+00:00

These two parameters are supported by the kernel
(https://www.kernel.org/doc/Documentation/kernel-parameters.txt). When
an initramfs is used, the kernel does not mount the rootfs and the
initramfs needs to react to them.

The boot parameters can be set both by the image creator and
by users.

Supporting these two parameters is useful:
- rootflags is needed to ensure that the rootfs is already mounted as
  intended in the time between starting init and init remounting
  it (as systemd does); this is critical for IMA where iversion must be
  active already when system starts writing files.
- setting it correctly up-front avoids messages from the kernel ("cannot
  mount ... as ext2 because ...") when trying to guess the desired type.

For example, assuming that only one of ext4/ext3/ext2 is set,
rootfstype could be set in an image recipe with:
APPEND_append = "${@''.join([' rootfstype=' + i for i in ['ext4', 'ext3', 'ext2'] if i in d.getVar('IMAGE_FSTYPES', True).split()])}"

Signed-off-by: Patrick Ohly 
Signed-off-by: Ross Burton