The rootfs can be addressed also by referring to the PartUUID
value from the GPT.
This patch enables such type of reference.

Signed-off-by: Igor Stoppa <igor.stoppa@intel.com>
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

On some hardware platforms (Gigabyte, qemu), detection of USB devices
by the kernel is slow enough such that it happens only after the first
attempt to mount the rootfs. We need to keep trying for a while
(default: 5s seconds, controlled by roottimeout=<seconds>) and sleep
between each attempt (default: one second, rootdelay=<seconds>).

This change intentionally splits finding the rootfs (in the new
"rootfs") and switching to it ("finish"). That is needed to keep udev
running while waiting for the rootfs, because it shuts down before
"finish" starts. It is also the direction that was discussed on the OE
mailing list for future changes to initramfs-framework (like
supporting a "live CD" module, which would replace or further augment
mounting of the rootfs).

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Depending on the module we use, the /run/lock may be required. This
creates it as part of initial setup and thus makes it available for
every sub module.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>

The following error occurs when udevd startup:
udevd[146]: bind failed: No such file or directory
error binding udev control socket
udevd[146]: error binding udev control socket

Signed-off-by: Wills Wang <wills.wang@live.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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 <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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 <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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 <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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 <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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 <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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 <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>