The existing code has a lot of references to the
`ro.boot.qemu` and `ro.boot.qemu.something` properties
which is not supported by the bootconfig if we place
everything under `androidboot.qemu`.
Bug: 182291166
Test: getprop | grep qemu
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Icb9d29c8dc39e1fa52a6f2ce43b4f42182b7995d
Currently the gki_4_19_pixel5 presubmit test uses an old
vendor_boot-debug.img from a release branch. Adding fallback
paths to load debug resources from /first_stage_ramdisk dir to
pass the presubmit.
This CL should be reverted later once the vendor_boot-debug.img
gets updated to store the debug resources on the root dir.
Bug: 186082603
Test: boot a device with boot-debug.img
Test: boot a device with vendor_boot-debug.img
Change-Id: I9fcd77fc5a60a15cff254e432e05f1c9122ad80d
Currently the debug resources might under /first_stage_ramdisk/*
of the ramdisk, if there is androidboot.force_normal_boot=1 in the
kernel cmdline to request init chroot into /first_stage_ramdisk dir.
To make a generic boot-debug.img works on devices with and without
this chroot, moving the debug resources to the root of the ramdisk.
And copy them for later use before the chroot.
Bug: 186082603
Test: boot a device with boot-debug.img
Test: boot a device with vendor_boot-debug.img
Change-Id: I052a92b2d26c7fdf749991fc55015ff68743efc2
init starts services in "bootstrap" mount namespace until the "default"
mount namespace is ready even when init's current mount namespace is
"default".
apexd and linkerconfig are those processes to set up the mount
namespaces: apexd activates apexes and linkerconfig generates linker
configs.
Previously apexd is allowed to be started in the "current" namespace by
checking its "service name"(it should be "apexd"). But there can be a
certain environment apexd is started in a different way. For example, in
microdroid, apexd is started using "exec -- /system/bin/apexd --vm"
because it wants to run in a different execution mode.
So, instead of checking the service name, its executable's path is
checked against to allow apexd to be started in the current mount
namespace.
Bug: 179342589
Test: MicrodroidTestCase (microdroid boots)
Test: cuttlefish boots
Change-Id: I7c2490e15d481c28ddf382d2d3fdf58a78e467ec
Only the exact same devpath uevent can launch external handler specified
in ueventd.rc. So, you should specify all possible devpaths, even
firmware with different filenames on the same device. Pattern mactching
can be used to simplify this.
Test: atest CtsInitTestCases
Signed-off-by: Suchang Woo <suchang.woo@samsung.com>
Change-Id: If3b7a2cabb8055bf4b768d928f0fc0012da3c177
'/sys/block/zram0/backing_dev' will exist even if zram is not swapped on in some devices. And there is no reason to ensure that zram is swapped on if '/sys/block/zram0/backing_dev' exists. So, if we want to kill backing_dev during userspace reboot, we should check if zram is swapped on first.
TEST: as follow
- adb root
- adb shell swapoff /dev/block/zram0
- adb shell echo 1 > /sys/block/zram0/reset
- adb shell setprop test.userspace.reboot.flag 1
- adb reboot userspace
- (wait reboot ending) adb shell getprop test.userspace.reboot.flag (1 will be show if successful)
Signed-off-by: luwei9 <luwei9@xiaomi.com>
Change-Id: Icca569cf8d64bc024b867dae2ab789fc9e76445a
emulator passes `android.checkjni` in the kernel
command which we want to use in
frameworks/base/core/jni/AndroidRuntime.cpp
Bug: 182291166
Test: getprop ro.boot.dalvik.vm.checkjni
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: If9473aa9492fa09d8de7cc8fb08614380e4e15f3
emulator passes `android.bootanim=0` in the kernel
command line to disable boot animation.
Bug: 182336906
Test: boot emulator with -np-boot-anim
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Id89a6c92dd4724cac414ffbf8ee731b2bfcc7195
args[2](user name to run as) is used instead of args[1](devpath).
Test: atest CtsInitTestCases
Signed-off-by: Suchang Woo <suchang.woo@samsung.com>
Change-Id: Id271755993d55e332bad54d0414e2232071e5e8e
restrictions
Use the property ro.product.enforce_debugfs_restrictions to enable
debugfs restrictions instead of checking the launch API level. Vendors
can enable build-time as well as run-time debugfs restrictions by
setting the build flag PRODUCT_SET_DEBUGFS_RESTRICTIONS true which in
turn sets ro.product.enforce_debugfs_restrictions true as well enables
sepolicy neverallow restrictions that prevent debugfs access. The
intention of the build flag is to prevent debugfs dependencies from
creeping in during development on userdebug/eng builds.
Test: build and boot
Bug: 184381659
Change-Id: If555037f973e6e4f35eb7312637f58e8360c3013
Minor refactoring and renaming, goal is to make the follow-up patch
easier to read.
Bug: 184132970
Test: Presubmit
Change-Id: I66416161b30ac310934d901cbaf11bc926e2cbf7
So we can extend platform policies with target specific compat rules.
This use case surface in the context of system only upgrade, when the
vendor policy cannot be updated, then the system_ext partition can
contain target specific compat policies.
Bug: 183362912
Test: Presubmit
Change-Id: Ic6436eb8a269f07f932331dedf7dbaa629538ade
The emulator migrated to `ro.boot.qemu`.
Bug: 182291166
Test: presubmit
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Iaa3bdff5cc1efa79c21ae2dc2bdf7ec74731f66c
Since recovery mode doesn't switch root to /first_stage_ramdisk, we need
to update the debuggable file paths for recovery mode. Without this,
adb needs to be authorized in recovery mode even with a debug
vendor_ramdisk.
Bug: 182612208
Test: verify adb is authorized on pixel 5
Signed-off-by: Will McVicker <willmcvicker@google.com>
Change-Id: I557429e1834efcdd92ba0e135377055ffa677137
Some devices might not have system_ext or product partitions. But init
has been refusing to use precompiled sepolicy because init always checks
system / system_ext / product hashes, regardless of existence. This
makes system_ext and product optional, so hash check can be skipped for
non-existing partitions. Of course system is always checked.
Bug: 181640066
Test: boot microdroid and cuttlefish, see precompiled sepolicy works
Change-Id: I32c296fffd894c27097e8b4e10ade977a21d61ab
`ro.kernel.` is an emulator specific prefix.
Bug: 182291166
Test: presubmit
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Ie4a19127f05f3074ccb02bd055711e9b70702ba6
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
This check in export_oem_lock_status happens after PropertyInit() so
all of the ro.boot.* properties will be set. There is no need to import
the kernel cmdline again.
Test: build and boot cuttlefish
Bug: 173815685
Change-Id: I5df7c0105566d4617442dbb8e77eb26e465775f1
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
Basically, ro.product.cpu.abilist* are defined by
ro.vendor.cpu.abilist*. And they can be overried by
ro.odm.cpu.abilist* and ro.product.cpu.abilist*.
ro.system.cpu.abilist* are for fallback if others are no defined.
Bug: 176520383
Test: check the result by flashing aosp_arm64-userdebug on
Test: aosp_blueline-user and aosp_blueline-user hacked by
Test: 64-bits-only
Change-Id: I01ae01af099a4ec8fe3d4525edecc233a477ff60
* In 'ActivateFlattenedApexesFrom', the 'readdir' detects
the APEX folders in a random way that depends on filesystems,
built packages and order of the build chain
* In normal cases, this is not an issue, however when building
with Go configurations, we have a case where the package
'com.android.tethering.inprocess' is built along the
'com.android.tethering' overriden binary, and depending on
the 'readdir' output, the mounts break the Tethering service
Change-Id: I8ac4a0284d8d885f732c71e846933869cf16a0bd
Signed-off-by: Adrian DC <radian.dc@gmail.com>
The firmware_handler.HandleAbort and subcontext.RecoverAfterAbort
tests intentionally abort in the child process to ensure that
ueventd/init can recover if their child processes die. This generates
a tombstone which causes confusion. This change resets SIGABRT to
SIG_DFL right before the abort(), so that the child processes will
exit normally without generating a tombstone or writing a crash to
logcat.
Bug: 169771958
Bug: 175383788
Test: run the above tests and verify no stack traces are printed to
logcat and no tombstones are generated.
Change-Id: Ica09548d1c7a766bf5d9ff2e26c9fd558e85c7c1
This makes it easier to associate logs written during the test with the
test case that was running.
Test: atest CtsInitTestCases
Change-Id: I832f1c9ba8358341c934fdd91a65f5739bc98e37
This test spawns several services backed by /system/bin/yes executable,
and then stops them either while SIGTERM or SIGKILL.
Ideally we want to unit test more of reboot logic, but that requires a
bigger refactoring.
Test: atest CtsInitTestCases
Bug: 170315126
Bug: 174335499
Change-Id: Ife48b1636c6ca2d0aac73f4eb6f4737343a88e7a
This hasn't helped investigating the issue, and the issue itself isn't
a problem anymore, so we remove these logs.
Bug: 155203339
Test: reboot
Change-Id: I20e51d8fcad5572906a8d556bec8a8dee4522834
* changes:
Add /metadata to ramdisk.
Also create dirs under /first_stage_ramdisk for GKI.
Refactor the list of empty dirs in ramdisk in its own list.
Revert "Move e2fsck into /first_stage_ramdisk."
