The parameter "androidboot.hardware" has been removed from bootconfig
and replaced by "hardware" parameter.
Test: launch_cvd with 4.19 and 5.10 kernels
Test: atest CtsFsMgrTestCases
Bug: 173815685
Change-Id: I627426ae1bd0a165b70b8f2584ec184abfb4236f
The androidboot.selinux property is loaded in a special way, because it
happens in the "selinux_setup" stage, and not the true second stage.
Allow it to be passed through bootconfig instead of only via the kernel
cmdline.
Bug: 173815685
Test: launch_cvd -extra_kernel_cmdline androidboot.selinux=permissive
Test: launch_cvd -guest_enforce_security=false [bootconfig method]
[..]
init: Permissive SELinux boot, forcing sys.init.perf_lsm_hooks to 1.
[..]
Change-Id: I92003c7a2dac5d6e7d0e0f4ee2757f86cc0087c7
The androidboot.android_dt_dir property is special, because it is loaded
to find out where to get the other DT properties from, and those DT
properties are supposed to override the cmdline/bootconfig ones. So, it
need special casing, and that special case lacked bootconfig support.
Bug: 173815685
Test: launch_cvd -extra_kernel_cmdline androidboot.android_dt_dir=/tmp
[..]
init: Using Android DT directory /tmp
[..]
Change-Id: Ie0958dd0a96394d65f6568653b754ea6f885212e
As parameters are moved from kernel cmdline to bootconfig,
first_stage_init needs to be updated to handle the new
location.
/proc/bootconfig should be checked first, if not present, then check
/proc/cmdline.
Test: launch_cvd
Test: launch_cvd with 4.19 kernel artifacts that do not support
bootconfig
Test: Both of the above configurations with --num_instances 0 or 4
Test: Both configurations with androidboot.boot_devices or
androidboot.boot_device set
Bug: 173815685
Change-Id: I03743f922351d58375e8b9a903899b8bc54bd71e
Any service which is executed when Runtime apex is mounted, but
linkerconfig is not updated can fail to be executed due to missing
information in ld.config.txt. This change updates init to have a status
variable which contains if current mount namespace is default
and APEX is not ready from ld.config.txt, and use bootstrap namespace if
it is not ready.
Bug: 181348374
Test: cuttlefish boot succeeded
Change-Id: Ia574b1fad2110d4e68586680dacbe6137186546e
This is a follow-up of I828ce999be6d786bf46dd5655dfda81d046906ab. The
change introduced a behavioral change that fstab is read twice: before
root is changed to /first_stage_ramdisk, and once again after that.
Previously, that happend only after the root is switched. That change
caused a problem when there is no fstab in DT and fstab is provided via
a file. The fstab file has been at
/first_stage_ramdisk/fstab.<hardware> because that file was supposed to
be read after the root switch.
With the change, init fails to read the fstab during the first attempt
because there is no /fstab.<hardware> at the moment. Here comes the
problem. Although it failed to read fstab, DoCreateService() is invoked
because ReadFirstStageFstab() doesn't report the failure; it returns an
empty fstab object. As a result, DoCreateDevices() is called but it
doesn't create the dm linear device because it couldn't find an fstab
entry having `logical` option.
Then after /first_stage_ramdisk becomes the root, the fstab file is
correctly read. But since the prior run of DoCreateDevices() is recorded
as 'done', init doesn't try to do that again; dm linear device is never
created. Then we fail to mount any of the logical partitions.
This change fixes the problem by modifying ReadFirstStageFstab()
function so that the failure is correctly reported back to the caller.
When it fails, DoCreateDevices() is not called.
Bug: N/A
Test: Watch TH
Change-Id: Idf2dbc6c0fb6c311ab3f5ff1f28315f7daa2b4ce
Androidboot parameters are being moved from the kernel commandline to
bootconfig.
fs_mgr looks for these parameters in properties and falls back to
reading directly from /proc/cmdline. So both of these sources are
updated for bootconfig.
The androidboot parameters from /proc/bootconfig
are added as ro.boot properties, and fs_mgr will fall back to searching
/proc/bootconfig if it is too early.
Test: boot cuttlefish with androidboot.fstab_suffix and
androidboot.hardware in bootconfig and not in cmdline.
Test: atest CtsFsMgrTestCases
Bug: 173815685
Change-Id: Iea36a0da94c26e1aa37d97c576725e0ad77cd3ad
The action reads a file with individual `export` actions declared on
each line, and calls `setenv` for each.
See go/updatable-classpath for details on how this is going to be used.
Bug: 180105615
Test: manual
Change-Id: I5390e52cf8ffd9c3babf31ed854eeecc727351eb
Add a property ro.boottime.init.modules to provide kernel modules
loading time in milliseconds. Also add corresponding log to show in init
log along with loaded module count.
Test: boot test
Bug: 178143513
Change-Id: I77e3939c2a271da6841350a8c2a34ad32f637377
The first-stage init has been built in Make due to some requirements
(like placing it directly under the root directory rather than bin/, and
creating mountpoints like /proc, etc.) that are not supported in Soong.
However, Ie06dc5a93635ea8b1e18be517ed8615b6c82fee6 will make it possible
to satisfy the requirements in Soong. The build of the boot image is
done in Soong and we can create mount points using the `dirs` property
and create a symlink /init that points to /bin/init_vendor using the
`symlinks` property.
To complete the picture of build everying in Soong, this change adds a
Soong-version of the first-stage init.
Note that the Soong-based boot image creation is currently only for the
microdroid usecase. Therefore, the Android.mk-based first-stage init
still remains and will be removed later.
Bug: 178562516
Test: m init_first_stage_soong
Change-Id: I278cb60a11d94fb48341fd3592be0652a25bdbfb
When there is a transition of daemon from selinux stage, we observe
intermittent hangs during OTA. This is a workaround wherein
we don't do the transition and allow the daemon to continue which
was spawned during selinux stage.
Bug: 179331261
Test: Incremental OTA, full OTA on pixel
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I622a0ed8afcd404bac4919b1de00728de2c12eaf
This has been something the kernel does automatically since 2014, so
there's no obvious reason to add extra work during boot to duplicate
that effort.
Bug: http://b/179086242
Test: treehugger
Change-Id: I44cce99a892e4f2a6a303c2126bd29f955f5fb23
None of them are necessary, and it's more intention-revealing to say
`c++2a` or whatever anyway.
Test: treehugger
Change-Id: Ie1df26499d160d6fc757d17fcb0121997bda14f9
Revert submission 1563392-remove_art_from_bootstrap
Reason for revert: Bug: 179002105
Reverted Changes:
I65e2a2089:Remove ART APEX from the bootstrap apexes
Ic20df80e2:Remove ART APEX from the bootstrap apexes
Change-Id: I474ab95805c5ca28e0bba91f3d226e8db5a7a9ea
During device bringup, dynamic partitions may not be properly
configured by some sort of build or load misconfiguration. Diagnosing
such issues can be difficult without being able to see which partitions
are available and what they contain.
Aditionally, making logical partitions available to first stage console
permits early mounting of vendor partition and allows primitive
validation of vendor scripts without requiring full Android
environment. For instance, vendor_dlkm partition and modules can be
probed needing to have a full Android bootup.
Creation of logical partitions is done only when first_stage_console is
requested in order to have minimal impact on normal boot. Thus, only a
small refactor is required to split CreateLogicalPartitions out of
MountPartitions.
Bug: 174685384
Bug: 173732805
Change-Id: I828ce999be6d786bf46dd5655dfda81d046906ab
Signed-off-by: Elliot Berman <eberman@quicinc.com>
ueventd.rc scripts belong in the /etc/ directory of their given
partition, not the root of the partition. This can cause problems,
especially since Android.bp cannot write to the root directly, forcing
vendors to use Android.mk for these files. Note that
/system/etc/ueventd.rc moved long ago.
Test: Tree-hugger
Change-Id: I2dcaafc3c3f687f76ab6bc38af979c8b43346db0
During device bringup, dynamic partitions may not be properly
configured by some sort of build or load misconfiguration. Diagnosing
such issues can be difficult without being able to see which partitions
are available and what they contain.
Aditionally, making logical partitions available to first stage console
permits early mounting of vendor partition and allows primitive
validation of vendor scripts without requiring full Android
environment. For instance, vendor_dlkm partition and modules can be
probed needing to have a full Android bootup.
Creation of logical partitions is done only when first_stage_console is
requested in order to have minimal impact on normal boot. Thus, only a
small refactor is required to split CreateLogicalPartitions out of
MountPartitions.
Bug: 174685384
Bug: 173732805
Change-Id: I82b7d77b9dc75af59b5e18b574e3eb99c8aff9e2
Signed-off-by: Elliot Berman <eberman@quicinc.com>
microdroid is the base image for on-device VMs. We will use Android
components (init, adbd, servicemanager, ...) on the VM as much as
possible.
Bug: 177630284
Test: m microdroid
Change-Id: I36890644baaaf8f441698411dd869ddb220734fb
For user who would like to retain the crash symptom and avoid device
from power cycle for live debugging, set
init.svc_debug.no_fatal.<svc_name> to "true" to skip FATAL reboot.
Bug: 177593855
Change-Id: I0bdb6191e5963c08e1ea301a60060acf916dd49b
This is used in cts tests to verify that algorithms in blocklist aren't
used to build the hashtree. The system properties are required to perform
the check on unrooted devices.
Bug: 175236047
Test: flash, getprop; atest CtsNativeVerifiedBootTestCases
Change-Id: I2dcfdb06f85dbe92cde45e836dd68e7bd835020f
This change will help non-user builds with keeping debugfs
disabled during run time. Instead, debugfs will be mounted by init
to enable boot time initializations to set up vendor debug data
collection and unmounted after boot. It will be also be mounted by
dumpstate for bug report generation and unmounted after.
This change is only intended to help vendors (who depend on debugfs to
collect debug information from userdebug/eng builds) keep debugfs
disabled during runtime. Platform code must not depend on debugfs at all.
Test: manual
Bug: 176936478
Change-Id: I2e89d5b9540e3de094976563682d4b8c5c125876
After Treblized, AOSP do not handle /factory folder. Also, AOSP
does not mount any partition to /factory. /factory has no possibility
to have any content. For factory purpose, it can be implemented in
vendor.
Bug: 177280838
Test: na
Change-Id: I0a2537336c2ef1efbad3e4f9e876aeaa607bc737
With compressed VAB updates, it is not possible to mount /system without
first running snapuserd, which is the userspace component to the dm-user
kernel module. This poses a problem because as soon as selinux
enforcement is enabled, snapuserd (running in a kernel context) does not
have access to read and decompress the underlying system partition.
To account for this, we split SelinuxInitialize into multiple steps:
First, sepolicy is read into an in-memory string.
Second, the device-mapper tables for all snapshots are rebuilt. This
flushes any pending reads and creates new dm-user devices. The original
kernel-privileged snapuserd is then killed.
Third, sepolicy is loaded from the in-memory string.
Fourth, we re-launch snapuserd and connect it to the newly created
dm-user devices. As part of this step we restorecon device-mapper
devices and /dev/block/by-name/super, since the new snapuserd is in a
limited context.
Finally, we set enforcing mode.
This sequence ensures that snapuserd has appropriate privileges with a
minimal number of permissive audits.
Bug: 173476209
Test: full OTA with VABC applies and boots
Change-Id: Ie4e0f5166b01c31a6f337afc26fc58b96217604e
