The exit of init panics the system *after* process context (mm, stack,
...etc.) are recycled, according to Linux kernel's 'do_exit'
implementation. To preserve most init process context for debugging,
triggers the panic via proc-sysrq explicitly.
Note: after this change, there will be no "Attempt to kill init" panic
when androidboot.init_fatal_panic is set.
Test: Insert data abort fault in init, the full process context is
preserved in memory dump captured after panic.
Bug: 155940351
Change-Id: I3393bd00f99b8cb432cfa19a105b7d636b411764
Extend androidboot.first_stage_console cmdline property to enable
skipping module load failures without stopping at a serial console. This
is useful for GKI development.
Set androidboot.first_stage_console=2 for this behavior.
Bug: 155296582
Test: verify behavior for values 0, 1, and 2
Change-Id: I068c631a22c848e45a421b297b1acae1b3deb3c1
Introduce new command to allow setting task profiles from inside .rc
script. This is to replace usage of writepid when a service is trying
to join a cgroup. Usage example from a .rc file:
service surfaceflinger /system/bin/surfaceflinger
task_profiles HighPerformance
Bug: 155419956
Test: change .rc file and confirm task profile is applied
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I0add9c3b363a7cb1ea89778780896cae1c8a303c
There are devices stuck waiting for vendor_init to finish a command,
without giving much more information. Instead of setting aside the
last run command, it's more valuable to store and dump the last 30
logs seen.
Bug: 155203339
Test: these logs appear during hung reboots
Test: normal reboots have no difference.
Change-Id: I99cae248eb81eaf34ef66b910fa653a9fa135f68
When the subcontext code was redone to allow only one subcontext
(vendor_init), the code for restarting it and for terminating it
during shutdown was not updated, resulting in it not working.
Bug: 155203339
Test: kill subcontext init and notice it restart
Test: subcontext init stops during shutdown
Change-Id: Ib77f59d1e7be0ffcfd3f31c8450dc022c20bb322
Bug: 153540919
Test: Able to boot without errors
Change-Id: If206e5e3d76a7919b7468bc2d9666b3aff296b3b
Merged-In: If206e5e3d76a7919b7468bc2d9666b3aff296b3b
Since this function is used in userspace reboot, we need to be more
diligent with error handling, e.g.:
* If init fails to read /sys/block/zram0/backing_dev, then fail and
fallback to hard reboot.
* Always call swapoff.
* Always reset zram.
* Tear down loop device only if zram is backed by a loop device.
Test: adb reboot userspace
Bug: 153917129
Change-Id: I4709da1d08cf427ad9c898cfb2506b6a29f1d680
Merged-In: I4709da1d08cf427ad9c898cfb2506b6a29f1d680
(cherry picked from commit a840d405eb)
libsnapshot* uses update_metadata-protos. This
used to be optimized out, but now that SnapshotManager is
virtual, CreateUpdateSnapshots can no longer be optimized out.
Bug: 148956645
Test: compiles
Change-Id: Ib67cafd156308bf5a477996ec32eb786f8e896db
If the first stage console is being used, attempt to run /first_stage.sh
immediately before the console is created.
Bug: 154126020
Change-Id: I8b7431e7b8219afea295b120d7ea91751804bda6
tl,dr;
Increase the attempts to 50 to reduce the chances of failing
to load the serial console. This will only happen if the cmdline
parameter "androidboot.first_stage_console=1" is enabled.
Details:
10 attempts only amounts to about 1 second of trying to open the serial
console. I tested booting an ACK GKI image 5x with 20 vendor modules and
found the serial console loaded on attempt 17 for all five boot
tests.
Bug: 153354917
Test: boot ACK image 5x and verify serial console comes up
Change-Id: I161a4176b2c6cf7b0bc1eefe072ff38b894add5d
Merged-In: I161a4176b2c6cf7b0bc1eefe072ff38b894add5d
Some of the test cases in CtsInitTestCases and CtsFsMgrTestCases require
root. This CL makes it possible to run such tests cases on userdebug
builds, which in turn means that they will be run on presubmit.
New option was implemented in
https://android-review.googlesource.com/c/platform/tools/tradefederation/+/1283834
Test: atest CtsInitTestCases
Test: atest CtsFsMgrTestCases
Change-Id: I3d29789ddd7ac549e40ac193c58d986670c49285
Similarly to other recovery mechanisms, timeout is controlled by a
read-only property that can be configured per-device.
Test: adb root
Test: adb shell setprop init.userspace_reboot.started.timeoutmillis 2
Test: adb reboot userspace
Bug: 152803929
Change-Id: Id70710b46da798945ac5422ef7d69265911ea5ef
1) There's no reason or way to support boot_clock for waiting for
property changes, since the underlying futex_wait uses
CLOCK_MONOTONIC. We probably wouldn't want boot_clock even if it
did, since it doesn't make sense to consider the time a device was
suspending in the timeout for waiting for a property to change.
2) The init tokenizer has been essentially unchanged for a decade,
there's no motivation to 'fix' it to not require a trailing
newline.
3) The ueventd TODO regarding moving vendor specific ueventd.rc
entries out of rootdir has been fixed.
Test: n/a
Change-Id: I3b68e3d2f25cbd539f9f8ff526669b8af04d833d
Structured bindings with templated containers work now, so no need for
the workaround or TODO.
Test: init unit tests
Change-Id: I6a286de9859d8a97df480a7ac2862a3a10bd9fb3
There was an email thread about this recently, and I've been asked many
times.
For instance, if this error wasn't attributed, denials a service is
hitting would be attributed to init, and that's a recipe for disaster.
Secondarily, thinking about SELinux whenever you write a new service is
good.
Bug: N/A
Test: N/A
Change-Id: Ib9d2c5d8947375a0d4c33ecf3d075caef6b41f70
This test is killing critical device services, and if it runs
repeatedly or some of the critical services have already died, it'll
force the device to reboot again and potentially consider the test a
failure.
This forces the test to reboot first, so that it is in a fresh state and
we can avoid this type of flake on the device.
Bug: 153444614
Test: atest init_kill_services_test
Change-Id: Ia81a319af1d209f58e70f824bb8eb7f11973637c
In recovery mode, load modules from modules.load.recovery if it
exists. Otherwise load from modules.load as usual.
Change-Id: I7636bb5958ed10ae9a66015f04f168129618272f
Previously, after `adb reboot userspace` is called on a device that
doesn't suppor it, init would've logged an error and quietly exit the
shutdown sequence. This was leaving adb handing forever.
With this approach, init will fail setprop
"sys.powerctl=reboot,userspace" in case userspace reboot is not
supported.
Test: adb root
Test: adb setprop init.userspace_reboot.is_supported 0
Test: adb reboot userspace
Test: atest CtsInitTestCases
Bug: 146639622
Change-Id: I1264078f53ed3ff54638c7f3b6846b7437f98ee5
Devices in the lab are hitting an issue where they're getting stuck
likely in the sync() call in DoReboot() before we start the reboot
monitor thread and before we shut down services.
It's possible that concurrent writing to RW file systems is causing
this sync() call to take essentially forever. To protect against
this, we need to remove this sync(). Note that we will still call
sync() after shutting down services.
Note that the service shutdown code has a timeout and there is a
reboot monitor thread that will shutdown the device if more than 30
seconds pass above that timeout. This change increases that timeout
to 300 seconds to give the final sync() calls explicitly more time to
finish.
Bug: 150863651
Test: reboot functions normally
Test: put an infinite loop in DoReboot and the the reboot monitor thread
triggers and shuts down the device appropriately
Change-Id: I6fd7d3a25d3225081388e39a14c9fdab21b592ba
Userspace reboot resets sys.powerctl to an empty string once it
starts, which was inadvertently triggering the backtrace of the main
init thread.
Test: no more unexpected backtraces
Change-Id: I35d6f1b37aa31a46ae9266647f41a709f28b6099
General recommendation is to avoid read-only properties, and instead control
"read-onlines" by only allowing init/vendor_init to set the property.
Since ro.init.userspace_reboot.is_supported was added in this release, and
nobody outside of the platform is querying it directly, it should be fine to
simply rename it.
Test: adb shell getprop init.userspace_reboot.is_supported
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 152803929
Change-Id: I7552d5ccc6e9b750a6081947eef8fcb027be13e1
This reverts commit d30c51157e.
This test wasn't flaky, it was failing when not run as root, but that
has been fixed.
Bug: 152630580
Bug: 152637928
Test: this test is okay now
Change-Id: I3b20be2839dae90ffc6a8eeea68f36e532060af1
Bug: 152630580
Bug: 152637928
Bug: 152662041
Bug: 152662652
Test: this test is skipped when run as non-root
Change-Id: I7118025cc20081a200000bf484a08c9ed0b0d3ec
Bug: 150863651
Test: add delays during critical parts of shutdown and see the
expected debug information
Change-Id: Ida586903fd3eefc32ca9ee34ea2db037896ed9f4
We already stop queue'ing new control messages, but we forgot to stop
handling those control messages that are already queued. This CL
fixes that.
Bug: 150863651
Test: CF reboots appropriately
Change-Id: Ifea07a30b868de23eb735db10d8bae410e1b98bb
Apparently relying on bootanim to restart or not is too flaky.
Bug: 152630580
Bug: 152637928
Test: this test no longer runs
Change-Id: If61b31bad276560a9f0db9811724bbc9efc51d28
The tests are only needed in vts10 suite.
Bug: 151896491
Test: local build
Exempt-From-Owner-Approval: This CL removes vts10 tests from vts suite.
It won't change test logic or behavior.
Change-Id: I4d468be075b54213b56c7e1aa94af94f2bdce9ff
Particularly in the case of the device failing to reboot. Some test
devices are showing that they've received the reboot message but
without rebooting.
Bug: 150863651
Test: prevent init from handling reboot and see a stacktrace
Test: reboot works normally
Change-Id: Ide001dadbb9e9cd235ea509066e6ae6664bb429b
