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
Print logs necessary to understand why apexd isn't shutting
down when this test fails, due to a rare flake.
Bug: 285458033
Test: init_kill_services_test (and cause this error to be hit)
Change-Id: Ic9cbf7b2b9fa89504e4a53597065e94c32233e12
This CL allows restart_period to be set to a value shorter than 5s.
Previously this was prohibited to rate limit crashing services. That
behavior is considered to be a bit too conservative because some
services don't crash, but exit deliverately.
adbd is the motivating example. When adb root or adb unroot is
requested, it changes its mode of operation (via sysprop), exits itself,
and restarts (by init) to enter into the mode. However, due to the 5s
delay, the mode change can complete no earlier than 5 seconds after adbd
was started last time. This can slow the mode change when it is
requested right after the boot.
With this CL, restart_period can be set to a value smaller than 5. And
services like adbd can make use of it. However, in ordef to rate limit
crashing service, the default is enforced if the service was crashed
last time. In addition, such intended restart is not counted as crashes
when monitoring successive crashes during booting.
Bug: 286061817
Test: /packages/modules/Virtualization/vm/vm_shell.sh start-microdroid \
--auto-connect -- --protected
* with this change: within 2s
* without this change: over 6s
Change-Id: I1b3f0c92d349e8c8760821cf50fb69997b67b242
apexd restarts the device, so it causes flakes here,
especially in presubmit.
Bug: 280514080
Test: init_kill_services_test
Change-Id: I4455704795961f3ae94e29bdf098eca739130973
It can be difficult to figure out where this test
is while it's executing, so I've added logs.
Bug: 280514080
Test: init_kill_services_test (w/o tradefed to avoid reboot), then:
:) adb logcat -d | grep init_kill_services_test
... I init_kill_services_test: hello lmkd!
... I init_kill_services_test: okay, now goodbye lmkd
... I init_kill_services_test: I said goodbye lmkd!
... I init_kill_services_test: are you still there lmkd?
... I init_kill_services_test: I'm done with lmkd
... I init_kill_services_test: hello ueventd!
... I init_kill_services_test: okay, now goodbye ueventd
... I init_kill_services_test: I said goodbye ueventd!
... I init_kill_services_test: are you still there ueventd?
... I init_kill_services_test: I'm done with ueventd
... I init_kill_services_test: hello hwservicemanager!
... I init_kill_services_test: okay, now goodbye hwservicemanager
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: I said goodbye hwservicemanager!
... I init_kill_services_test: are you still there hwservicemanager?
... I init_kill_services_test: I'm done with hwservicemanager
... I init_kill_services_test: hello servicemanager!
... I init_kill_services_test: okay, now goodbye servicemanager
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: I said goodbye servicemanager!
... I init_kill_services_test: are you still there servicemanager?
... I init_kill_services_test: I'm done with servicemanager
Change-Id: I2466f574fc06cdf1b01db82f89649f39b0f34345
We've had flake in libdm_test for a long time, with no clear cause.
Lately however it has become particularly reproducible when running
the UeventAfterLoadTable test in isolation, and thus we've identified
the root cause.
uevents for device-mapper are fired when the sysfs node is added, but at
that time, the "dm" subnode has not yet been added. The root node and dm
node are added very close together, so usually it works, but sometimes
ueventd is too fast.
Instead of relying on sysfs, query the uuid/name node directly from
device-mapper.
Bug: 270183812
Test: libdm_test
Change-Id: I258de5de05d813c3cb7f129e82e56dbfe8bf3117
The prop can be consumed by init scripts to do customized setup:
on property:ro.gsid.dsu_slot=oemtest
# Do setup for test
on property:ro.gsid.dsu_slot=oemdemo
# Do setup for demo
Bug: 277691885
Test: m
Change-Id: I7bd78b9ba31021b27d57c6f092dad5d7ebf6e59b
When booting up, Android can boot into one of three modes: normal,
recovery, and charger mode. The set of modules that should be loaded
during first stage init in each mode can differ, which is why init
reads the list of modules to load from modules.load.recovery when
booting into recovery, and modules.load otherwise.
This means that init will read the list of modules to load during first
stage init from modules.load even when booting into charger mode. This
is not ideal, as it causes modules that need to be loaded during
first stage init only when booting into charger mode to also be loaded
during first stage init of normal boot, which can degrade boot time.
Thus, add support for reading modules.load.charger, which contains the
list of modules that need to be loaded during first stage init when
booting into charger mode.
Bug: 266752750
Change-Id: Ib9178bdfe5a6aac57b86b6d453b03625e95d5b48
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
This also specifies user on an adbd service
declaration which was missing before. It seems
that certain services are declared mulitple
times.
Fixes: 276813155
Test: boot (on CF, the only V device in the tree)
Test: remove 'user' specification and see error
Change-Id: I138f3ace72d46f221551ad61e75ba4c01632da59
NOTE: in master, but should be submitted in AOSP.
Waiting to hear from security folks. Also might
need cleanup.
Not currently done. Seems errorprone.
Bug: 276813155
Test: boot, check logs
Change-Id: I7cbc39b282889dd582f06a8eedc38ae637c8edec
Set the user explicitly.
For boringssl self-test, changed to 'nobody' since
this test doesn't require permissions.
Bug: 276813155
Test: boot, check can 'nobody' can still write to kmesg.
Change-Id: I32f7134e83183bd054bffbb22d412d7a2dc0ad09
