Always create ramdisk/first_stage_ramdisk directory at build time.
Generic boot image always need this directory to work on devices
w/ and w/o a dedicated recovery partition. By default, the ramdisk is
mounted as readonly, unless on x86 platforms. If the ramdisk is mounted as
readonly, the directory cannot be created at runtime.
Note that devices with a dedicated recovery partition will never
switch root into the first_stage_ramdisk directory in first stage init.
Bug: 156098440
Test: manual by disabling init to mkdir first_stage_ramdisk
Change-Id: Ie272f4eedccc0b008fb538c1e0f3985ff70696cf
This requires a few other changes to support building libutils
properly. It does appear the windows versions of libutils is
referencing CallStack code, but it doesn't seem to cause any problems.
However, I removed those references completely for the windows build.
Also removed a few extra spaces that seem to have accumulated in the
RefBase.cpp.
Bug: 170465278
Test: Builds and libutils unit tests pass.
Change-Id: Ibeee7791b13636b34bdd592c5420fd91620f752a
When a device-mapper table contains a "user" entry, a corresponding
dm-user misc control device is created. The devices are put into a
separate folder by default, which currently confuses ueventd, and we
wind up with paths like:
/dev/dm-user!blah
Special case these devices so they wind up as:
/dev/dm-user/blah
Test: dmctl create blah user 0 100 test-device
/dev/dm-user/test-device exists
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Change-Id: I313db07c3400f14f3ed0ffa20fdac2ac3e34b6d3
In many cases, it's a common practice to use the name of the
domain type of a process or the type of the usage category
instead of using ambiguous terms like sys, system, etc.
Update the property name with net. prefix for better naming to
fit the usage of the system property.
Bug: 170917042
Test: 1. m -j10
2. Check if /proc/sys/net/ipv4/tcp_default_init_rwnd is
updated as expected
Change-Id: I0267880d62cc504a419827732780d2db97b2dfef
Allocating the entire address space is sufficiently unreasonable that
hwasan blows you out of the water if you try to do that. Half the
address space feels like it's large enough to be guaranteed to fail
(which is all I think this intended to test) without being quite so
obviously incorrect that tools like hwasan are going to object...
...except hwasan actually has a 2GiB limit. So let's keep the cleanup,
but also just disable these tests if they're running under hwasan for
now.
Bug: https://issuetracker.google.com/171054277
Test: treehugger
Change-Id: I41f3def5c3a43aa7f9ca3a130b4306ebed659d6a
Instead of assuming a module with the .llndk suffix exists, add an
llndk_stubs property to every cc_library module that has a
corresponding llndk_library. Also rename the llndk_library to have
an explicit .llndk suffix.
Bug: 170784825
Test: no changes to build.ninja (excluding comments) or Android-${TARGET_PRODUCT}.mk
Change-Id: Ifba79a1ae64a67a9d7393dac2fb012cd8af8e149
The first argument in a modules.dep line must end with a colon so fail
if that condition is not met.
Test: libmodprobe_tests
Change-Id: I6f3a22758302f16b924e5a16f7af9bf35f1a56f3
Adding new path to visibility rule, as b/170958306 prevents adding
new changes to a project being introduced in the same topic. We need to
do this ahead of the migration and then cleanup after the migration is
complete.
BUG: 167963357
Test: TH
Change-Id: Id02e4ea3a6d387bad7b2dbd5d0a38f662d0254fc
As we change to a more resumable format, flush mostly writes the final
parts of the file that are needed, which would write extra data that is
not needed to continue writing, and would immediately be overwritten.
Additionally, in the next patch we will fsync the file after adding an
op, making the flush built in, and the Finalize name more appropriate.
Change-Id: I1db48315dec097b0620a0dfe7e7fd0098610d482
Bug: 168829493
Test: builds
Rather than using some implicit naming scheme, we've decided to just let
userspace pick whatever control device naming scheme it wants. This requires
an additional argument to be passed to the kernel.
Test: cow_snapuserd_test
Bug: 168259959
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Change-Id: Ibf7f378b67abb6ca7457a9fdc9b8739e3d31bee3
Signed-off-by: Akilesh Kailash <akailash@google.com>
A recent change moved creating /data/vendor/tombstone earlier than
/data/vendor was created, which would cause /data/vendor/tombstone to
not be created until the second time a device boots, instead of the
first.
This change moves the creation of /data/vendor* earlier, allowing
/data/vendor/tombstone to be created on the first boot.
Bug: 169659307
Test: boot CF for the first time and see /data/vendor/tombstone is
created
Change-Id: I53ee8fbc282bc533d50756ebb4cc65a5ca582088
These projects have moved to a different location.
platform/system/core [libprocinfo] -> platform/system/libprocinfo
platform/system/core [libbacktrace] -> platform/system/unwinding [libbacktrace]
platform/system/core [libunwindstack] -> platform/system/unwinding [libunwindstack]
BUG: 163786882
Test: Local build + TH
Change-Id: Id6d278d917236df0ffd40b5c32593856e112cb5b
When running tests against cuttlefish, `adb root` sometimes flakes
because of a 6 second timeout in wait_for_device, which can get
triggered when adbd's restart gets throttled by init. The adb client
would notice that the socket went down, try to reconnect and fail
because adbd still hasn't started yet, and then wait up to 10 seconds to
reconnect, before which the `adb root` invocation would have failed due
to timeout. Increase the timeout to be long enough to handle this, and
also reduce the interval of reconnections to speed things up when we're
in this scenario.
Bug: http://b/170707786
Test: while true; do adb root; adb wait-for-device; adb unroot; adb wait-for-device; done
Change-Id: I140d721dfcfd635d45813a55990684a25e32228c
