This property will hold the major.minor part of the kernel version (e.g. "5.4"), allowing init scripts to act depending on that version, enabling and disabling certain features.
Bug: 194156700
Test: manual on a Pixel device
Signed-off-by: Alexander Potapenko <glider@google.com>
Merged-In: Icec640b8a7150b344d9aa3bc0bdbcdae050c7c45
Change-Id: I5af411e39da600e5e0f6703f3a2a4930d509e29d
This reverts commit 1c51525f66 because it
accidentally made reboot_on_failure be a no-op for all services. This
is because Reap() itself calls KillProcessGroup() on devices with a
vendor level >= R, which in turn sets SVC_STOPPING. I had overlooked
this somehow, probably because I didn't consider that a service can
consist of multiple processes.
It turns out that real FDE devices don't actually need the above commit
because FDE devices aren't allowed to have updatable apexes enabled, and
without updatable apexes enabled, apexd exits automatically and
therefore doesn't have to be stopped. This can be verified by using the
aosp_cf_x86_phone_noapex build target, rather than aosp_cf_x86_phone
which I had used for testing before. So just revert it for now.
Bug: 194370048
Change-Id: I90eddf2a87397449b241e5acaaa8d4a4241d73a9
(cherry picked from commit d14a178d01fd1690cf8c9f69dd8672b29f946a10)
Merged-In: I90eddf2a87397449b241e5acaaa8d4a4241d73a9
If a bootconfig argument has a list of values, it has a space between
them in /proc/bootconfig.
Example:
BOARD_BOOTCONFIG := parameter=value1,value2,value3
In /proc/bootconfig, it looks like:
parameter = "value1", "value2", "value3"
Before this CL, that example would end up with the value string of:
"value1, value2, value3"
To keep consistent behavior with kernel cmdline the value string should be:
"value1,value2,value3"
Test: Boot cuttlefish with test bootconfig params and verify ro.boot.*
Bug: 192257482
Merged-In: Iccdec451f53330162fa2c9ad2b7c2630f32b4168
Change-Id: Iccdec451f53330162fa2c9ad2b7c2630f32b4168
This test requires running test services, which causes test to crash
(and still incorrectly be reported as passing) when running on
non-rooted device.
Ignore-AOSP-First: reboot_test is not in AOSP yet
Bug: 190958734
Test: atest CtsInitTestCases
Change-Id: I3c5c9917d0a787d66272ccf4aefc57e6573841bc
This reverts commit 0a799bdfd6.
Now that the kernel bootconfig feature has been to updated to handle
mixed subkeys and values, androidboot.hardware parameter is supported.
Test: build and boot Cuttlefish with "androidboot.hardware=cutf_vm"
Bug: 191502832
Merged-In: I0e436a27730d20689bc6974562c3e88d744385db
Change-Id: I0e436a27730d20689bc6974562c3e88d744385db
Androidboot parameters have moved from /proc/cmdline to /proc/bootconfig
so we need to check both places in reboot_utils.
"ro.boot.*" properties can not be used because this is initialized
before the properties are set.
Test: boot Cuttlefish with init_fatal_panic and
init_fatal_reboot_target in bootconfig and in cmdline
Bug: 191494101
Merged-In: I6c230496ec1c3632470d20ff4a31f28db96ea71b
Change-Id: I6c230496ec1c3632470d20ff4a31f28db96ea71b
adb_debug.prop is migrated too. And ramdisk_available is added to all
dependencies.
Bug: 187196593
Test: boot
Change-Id: I59cd149e0021211b8fd59c44b93bbf18dc8637bf
Merged-In: I59cd149e0021211b8fd59c44b93bbf18dc8637bf
Ban weird paths such as /../system or //vendor in first stage mount.
Add utility function fs_mgr_create_canonical_mount_point() that:
* mkdir(mount_point) to ensure mount_point's existence
* Test that realpath(mount_point) =?= mount_point
Bug: 188898525
Test: Presubmit
Test: Boot CF
Change-Id: Iaf2ec52701277f26cc81f3e15a47b6083a788334
Merged-In: Iaf2ec52701277f26cc81f3e15a47b6083a788334
(cherry picked from commit 3431d52675f25020b279c9fbcda6b8648f9cf67b)
Rename fs_mgr_overlayfs_mount_fstab_entry() to
fs_mgr_mount_overlayfs_fstab_entry() and move it out of
fs_mgr_overlayfs.cpp to make it available for user builds.
Add checks to unsure overlayfs mount point doesn't contain symbolic
link or /../.
Check the mount point with an allowlist if user build. The mount point
should either be /vendor, /product ... or their submounts, or strict
submounts of /mnt/vendor and /mnt/product.
Bug: 188862155
Test: Boot test with overlayfs mount entries on user build
Change-Id: I3b60dfa4b63cf2ae0754f53d1d08365aa7be1ee0
Merged-In: I3b60dfa4b63cf2ae0754f53d1d08365aa7be1ee0
(cherry picked from commit 23816e84ca8821f303d9a3e753d7c050881bacd5)
* Add logs.
* Append "override_creds=off" overlayfs mount flag only if
fs_mgr_overlayfs_valid() returns kOverrideCredsRequired.
Pre-4.6 kernels or kernels without the override_creds patch don't
need or don't recognize the override_creds mount flag.
(Background: I832c8ca3fce0269bdef4ce988541adb7ba9662ed)
* mkdir(mount_point) before mount() to ensure the mount point exists.
This could happen if the mount point is in a tmpfs, such as /mnt.
Bug: 188862155
Test: Boot to normal with overlayfs mount entries in first stage fstab
Change-Id: I1a05696346610d7fd61de6d25c379520fd58ca9b
Merged-In: I1a05696346610d7fd61de6d25c379520fd58ca9b
(cherry picked from commit dcf1c1f46235637a6d1057c88e6d1fed88e1b90a)
GetDmVerityDevices() should filter out overlayfs fstab entries in the
first place, so InitRequiredDevices() don't need to filter out overlayfs
pseudo device names.
Bug: 188862155
Test: Boot to normal with overlayfs mount entries in first stage fstab
Change-Id: I0ac8b7ac0f21daa0c191580d9349adf217854864
Merged-In: I0ac8b7ac0f21daa0c191580d9349adf217854864
(cherry picked from commit 87290f8e9bb11b919e049e3662819af81e2a35c9)
Add a test to check the build fingerprint when the dynamic build
id is in use.
Bug: 186786987
Test: th
Change-Id: I44d6be0c18552f319bcb8d19cca5659ce580d26c
Background in http://go/compatible-build-fingerprint. To uniquely
identify the mixed build, we plan to append the unique vbmeta digest
to ro.build.id.
If BOARD_USE_VBMETA_DIGTEST_IN_FINGERPRINT is true, the build system
will not set ro.build.id. Instead, init will set it at runtime, by
appending the digest to the legacy build id.
Bug: 186786987
Test: build and boot a device with new build id
Change-Id: Idea57df599bfd6eede760671e2555541f7dc3f21
emulator migrated to bootconfig, we don't use
the kernel command line to pass userspace properties.
Bug: 182291166
Test: boot
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Iff2f627aec64b7ba2240444639acedc76a1aa806
This reverts commit 6cb4311f4d.
Reason for revert: no need to keep the compatibility now
Bug: 186485355
Change-Id: Iffdf3abebc17f32e36f3b3fe2b4f9c2592da9653
Test: TreeHugger
Add a new service flag SVC_STOPPING which tracks whether a service is
being manually stopped by init, and make the "reboot_on_failure" service
setting not apply when SVC_STOPPING is set.
This is needed for devices that use FDE, because otherwise the device
reboots during the following init script fragment:
on property:vold.decrypt=trigger_shutdown_framework
class_reset late_start
class_reset main
class_reset_post_data core
class_reset_post_data hal
... because that stops all services, including apexd which has been
marked with reboot_on_failure since
https://android-review.googlesource.com/c/platform/system/apex/+/1325212.
So init was killing apexd, then rebooting the device because apexd
"failed" due to having been killed. Making reboot_on_failure not apply
when init stops a service itself fixes the problem.
This is one of a set of changes that is needed to get FDE working again
so that devices that launched with FDE can be upgraded to Android 12.
Bug: 186165644
Test: Tested FDE on Cuttlefish
Change-Id: I599f7ba107e6c126e8f31d0ae659f0ae672a25e4
If precompiled vendor policy has system_ext hash, system_ext also has to
have its hash, to use precompiled sepolicy.
Bug: 186727553
Test: remove system_ext's hash and see sepolicy compiled in runtime
Change-Id: I4af3418d614156b5e9cd0b0116c2814ba994ee81
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
Alexander Potapenko