In our current boot scripts, two ways are used to determine whether
the rootfs is read-only or not. One by checking the READ_ONLY_ROOTFS
value in /etc/default/rcS, the other by checking the /etc/fstab entry.
>From a normal Linux user's point of view, the way of checking the
/etc/fstab entry is preferred. However, as there are several boot scripts
that need to know whether rootfs is read-only or not, checking /etc/fstab
in each script brings too much overhead. Thus, these boot scripts
use the READ_ONLY_ROOTFS value in /etc/default/rcS.
In normal use cases, there would be no problem, as both /etc/default/rcS and
the /etc/fstab are modified at rootfs time. However, if the user changes
the mount option for rootfs in /etc/fstab to read-write, and he/she forgets
to change the value in /etc/default/rcS, there would be unexpected results.
For example, the udev-cache would still be disabled.
So at a minimal, a check for conflicting configurations between /etc/fstab
and /etc/default/rcS should be added in checkroot.sh so that there would be
reasonable warnings if users have configured the system in a non-consistent
way.
[YOCTO #4880]
(From OE-Core rev: 1565a0c5a3f245703e280ca90cf11d3f9374788a)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, fsck is always disabled because the value of rootcheck in
the checkroot.sh script is always set to 'no'.
We should respect the value of ENABLE_ROOTFS_FSCK in /etc/default/rcS
to allow for filesystem check.
(From OE-Core rev: 5c11cf4db8f43003fb7132b92a78659f70f07ce0)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having one monolithic packages directory makes it hard to find things
and is generally overwhelming. This commit splits it into several
logical sections roughly based on function, recipes.txt gives more
information about the classifications used.
The opportunity is also used to switch from "packages" to "recipes"
as used in OpenEmbedded as the term "packages" can be confusing to
people and has many different meanings.
Not all recipes have been classified yet, this is just a first pass
at separating things out. Some packages are moved to meta-extras as
they're no longer actively used or maintained.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Chen Qi
Martin Jansa
Richard Purdie