The initramfs.img from kernel builds do not store kernel modules under
_16k directory. Currently, init is programmed to only load kernel
modules from _16k dir if running on 16K page size kernel. Relax this
restriction so that booting on custom 16K kernel would work without
going through platform rebuild.
Test: th
Bug: 293313353
Bug: 300184677
Change-Id: I9ee3c74066ad9ec5127f1e8662f7c1273445994c
The macros isn't used anywhere but was a distraction when tracking down
/data mounting behaviour.
Test: build
Change-Id: Ie23574326cbebd7f515c8409e1dcb91a00cafc6f
Noticed while looking at riscv64. Looks like a bug, but actually nothing
we can do about it now or for the foreseeable future.
Bug: https://github.com/google/android-riscv64/issues/45
Test: treehugger
Change-Id: I2be81b2fd7095df40958a1f641d7b89cf5a8e41d
Improve the comment, and increase the "minimum maximum" to 24 --- we
only support 64-bit, and 64-bit never has less than 24 bits.
Bug: https://github.com/google/android-riscv64/issues/1
Test: treehugger
Change-Id: I478c7649aa19258352c908a449cabe12da94952c
OEM can add self-owned groups, but the system init cannot support if the group numbers are over than 12, relax some restrictions as appropriate.
Bug: b/296826987
Signed-off-by: Haichao Li <liuhc3@motorola.com>
Change-Id: I231d9f6c82e93c08bc97ca32df70e5b28760acbc
do_start() ignores ENOENT intentionally to avoid logspam. It's
implemented in ErrorIgnoreEnoent. However, without resetting errno,
ErrorIgnoreEnoent will ignore unrelated errors from Service::Start() due
to the sticking errono set from other commands.
Bug: 296821716
Test: launch_cvd
Change-Id: I71d3113bdb69bdca82e2ff4f3a793301749f6c08
ServiceList's services_update_finished flag was overlapped with the
global flag: is_default_mount_namespace_ready. Now DelayService() relies
on the is_default_mount_namespace_ready flag.
Add a service description with 'updatable' flag and invoke 'start
<name>' in 'on init' block (which comes before APEX activation).
See the log for "Cannot start an updatable service".
Bug: 293535323
Test: see the comment
Change-Id: I9341ba1a95d9b3b7c6081b530850d61f105f0a56
To support booting from both 4k/16k kernels, init need to tell which
kernel we are currently booting and load the right modules. To resolve
this issue, we store 16K modules into /lib/modules/`uname -r`_16k
directory.
Test: th
Bug: 293313353
Change-Id: I4a8296384537a71e16cd20e76e6c5dfb9074f574
It is expected that /metadata/ota/rollback-indicator and /metadata/gsi
don't always exist, so don't call selinux_android_restorecon() on them
when they don't exist. This eliminates the following error messages:
0 0 E selinux : SELinux: Could not get canonical path for /metadata/ota/rollback-indicator restorecon: No such file or directory.
0 0 E selinux : SELinux: Could not stat /metadata/gsi: No such file or directory.
Test: Booted Cuttlefish and verified the error messages are gone
Change-Id: I94c998556c85adde5f11f134178219ba7880c2be
create_apex_data_dirs() now uses GetApexListFrom(dir) in
apex_init_util.cpp.
This is essentially a refactoring, but there are a few behavioral
changes, which I think make more sense.
- Emits no error when opendir(/apex) fails.
- Emits errors when mkdir fails for each apex.
- Does not abort `perform_apex_config` even though create_apex_data_dirs
fails.
Bug: 293546778
Test: check /data/misc/apexdata/ after boot
Change-Id: I9d1a9710a6a626eec087c8c0fb1768667ffb036e
Reading .rc files from bootstrap APEXes causes "double loading".
This works for services because init just ignores duplicates. But it
emits error logs, which can mislead even though there's no actual
errors. Besides, for actions, duplicates can cause a problem when
commands are not idempotent.
So, when loading RC files from APEXes for the second time, we'd better
skip those bootstrap APEXes.
Bug: 290148081
Test: VendorApexHostTestCases
Change-Id: Ia630dbd14046064b5e5c612c01ebacf57091c8d4
To start an early_hal service from a bootstrap vendor apex, init now
reads .rc files from bootstrap apexes as well.
In this change, perform_apex_config command is re-purposed to support
bootstrap mode. Now we have some similarity between two apexd calls:
- for bootstrap apexes (in the bootstrap mount namespace):
exec_start apexd-bootstrap
perform_apex_config --bootstrap
- for normal apexes (in the default mount namespace):
restart apexd
...
wait_for_prop apexd.status activated
perform_apex_config
Note that some tasks in perform_apex_config are not needed in the
bootstrap. For example, we don't need to create apexdata directories
for bootstrap apexes.
Bug: 290148081
Test: VendorApexHostTestCases
Change-Id: I8f683a4dcd7cd9a2466a4b1b417d84c025c37761
This new directory is bind-mounted to /apex in the bootstrap mount
namespace so that apexd-bootstrap mounts bootstrap APEXes there via
/apex.
The directory is shared between two mount namespaces, hence visible
in the default mount namespace.
Bug: 290148078
Test: VendorApexHostTestCases
Change-Id: I841480e41be8def5a4c6a4aa874c4e21465a71d3
Right now there are two bootconfig parsers that gets linked into `init`.
One is from libinit itself and the other is from libfs_mgr.
The one in libinit removes all space characters between list elements,
so `key = "val1", "val2"` gets unquoted and squeezed into:
`key=val1,val2`
The one in libfs_mgr doesn't remove spaces, it only unquotes:
`key=val1, val2`
The libinit behavior is due to existing systems (such as sysprop)
expect the config value to be in the same format as kernel cmdline.
(aosp/1757971)
THe libfs_mgr behavior is due to the `androidboot.boot_device[s]`
format explicitly allows quoted comma appear in its list value, thus
relies on space, not comma, as the list value delimeter.
This commit merges the two parsers into libfs_mgr. Since all usages in
libfs_mgr besides `boot_device[s]` do not care about how list value are
delimited, and most usages in init expects the bootconfig value format
to be the same format as cmdline. We just special case the
`boot_device` scenario.
Also harden the test cases to cover all the different config value
format and expected result.
Note:
The format of kernel bootconfig is described here
https://docs.kernel.org/admin-guide/bootconfig.html
Bug: 293695109
Test: CtsFsMgrTestCases
Change-Id: I42b9bf626e8de38a60e8e09fac0693126b7efd91
init and libfs_mgr both defines get_android_dt_dir() with subtle
differences. Merge the two implementations into libfs_mgr to reduce code
duplication (in terms of source code and code gen)
Note:
init's implementation checks the kernel cmdline first and then the
kernel bootconfig, while libfs_mgr's order is the opposite.
Realistically I don't think this order matter much though. If any, we
should prioritize bootconfig over kernel cmdline most of the time.
Bug: 293695109
Test: Presubmit
Merged-In: Ic8d2c965c62f9e873ccdaf77d67c7708f25a7b56
Change-Id: Ic8d2c965c62f9e873ccdaf77d67c7708f25a7b56
This new directory is bind-mounted to /apex in the bootstrap mount
namespace so that apexd-bootstrap mounts bootstrap APEXes there via
/apex.
The directory is detached from /apex in the default mount namespace but
still visible in case bootstrap APEXes are needed.
However, there are (mostly, virtual) devices which don't need two mount
namespaces. Those devices don't need to make /bootstrap-apex directory
at all.
Bug: 290148078
Test: atest VendorApexHostTestCases
Test: atest MicrodroidTests
Change-Id: I541cec71d9970b14971d46e01e4808b23590dbed
MarkServicesUpdate() starts delayed services which are mostly for
APEXes. (e.g. start a service from APEX). But before
"DefaultNamespaceReady", services are started in "bootstrap" mount
namespace, which makes services from non-bootstrap APEXes fail to start.
This is a quick fix for the problem before coming up with better
solution in the future.
Bug: 293535323
Test: add 'start adbd' before 'perform_apex_config' in init.rc
adbd starts successfully.
Change-Id: I846689f7c38cdca83c1f7faec0106b8174527e09
VFIO nodes, both the container (`vfio`) node and group (numbered)
nodes, should be located in `/dev/vfio`. This change prevents
ueventd from flattening that structure.
Test: Bind a device to VFIO driver to create a VFIO group
Change-Id: I635e9febe6bb52718df263e735479f361eacad4c
One of the first ERROR messages in logcat of a normal boot of Cuttlefish
is from failure to open SEPolicy.zip. This condition is expected.
Therefore don't try to load SEPolicy.zip when it doesn't exist. This
replaces the following log messages:
0 0 I init : Error: Apex SEPolicy failed signature check
0 0 I init : Loading APEX Sepolicy from /system/etc/selinux/apex/SEPolicy.zip
0 0 E init : Failed to open package /system/etc/selinux/apex/SEPolicy.zip: No such file or directory
... with just:
0 0 I init : No APEX Sepolicy found
Change-Id: If3a77407c35130165df5782b9ef91912e8374dbf
Combine some cases that are handled identically, and remove the
'userdata_remount' parameter which is unused. No change in behavior.
Test: presubmit
Change-Id: I0567e47d02942af7865c155dab76e6d0e9d71a1f
Until the verification of the /vendor partition we restrict the usage of
the feature to only debuggable VMs. If a non-debuggable Microdroid VM
is requested to mount /vendor, first_stage_init will crash and the VM
won't boot.
Bug: 285855436
Test: vm run-microdroid --debug none --vendor test_vendor.img
Change-Id: I9d44ad5c1d971bac1a9173c291ce61b628f2f8e9
first_stage_init will only mount the /vendor partition in Microdroid if
the androidboot.microdroid.mount_vendor=1 is provided in the kernel
cmdline.
Bug: 285855433
Test: atest MicrodroidTestApp
Change-Id: I5b840b5474bc52ec2696a0ba6ead0476acddfb1a
The existing approach in first_stage_init/first_stage_mount makes it
harder to add conditional logic that should only be applied for
Microdroid. Additionally, it forces the FirstStageMount object to be
created twice.
This change refactors the control flow to make first_stage_init take the
ownership of the FirstStageMount object. It will help with the follow up
change (which will add logic to conditionally mount /vendor partition
while booting Microdroid). As a nice side effect, this refactoring also
fixes the problem of the FirstStageMount being created twice.
This change also merges the FirstStageMount and FirstStageMountVBootV2
in a single class, since nobody actually uses FirstStageMount.
Bug: 285855433
Test: device boots
Test: atest MicrodroidTestApp
Change-Id: I38a72c0f20e7c1ac70031498aeeca22b091fa827
The APEX sepolicy feature has unfinished support for verifying the
sepolicy file using fsverity with a builtin signature. However, this
was never finished and doesn't really make sense, since the
already-implemented scheme that uses a full-file hash combined with a
userspace signature check is better suited to the problem. Therefore,
remove this unfinished code.
Bug: 290064770
Test: presubmit and booting Cuttlefish
Change-Id: I3403a3303bcea32c7340642b843cd1541fe1fd2f
We are now conditionally compiling init binaries & libinit for
Microdroid (adding -DMICRODROID=1 cflag), so instead of checking for the
presence of the /system/etc/selinux/microdroid_precompiled_sepolicy we
can check if the code is compiled for Microdroid.
In a follow-up changes we can split the sepolicy loading logic into 2
separate headers (one for Android and one for Microdroid) and include
the necessary one depending on the target we compile for.
Bug: 287206497
Test: atest MicrodroidTestApp
Change-Id: Id9c837d03a96ff9564688d33955ec85094eee487
This is likely waiting for the Java garbage collector to run,
and due to the lockless implementation of BinderProxyNativeData
and BpBinder, it's very difficult to efficiently force this
object to be deleted.
Change-Id: I4df667b9b47327967a43d75664fb506b8704f905
Fixes: 285458033
Test: N/A
These variants will compile with -DMICRODROID flag, which will allow us
to exclude init features that are not needed for Microdroid, and
introduce features that only work in Microdroid.
Bug: 287206497
Test: build com.android.virt APEX
Change-Id: Ib9af0cfcdf06c70fc39e6e6ac8ef07bb69982969
