Adb client does not use these values, so just ignore it.
Bug: b/158824677
Test: 'adb -H 127.0.0.1 -P 5037 devices' does not crash.
Change-Id: I4dada6e5e1714157bbf1af370510dfa7bfbd6b17
Also generic syntax clean up and removing some unused aspects (sorting
the list and the TODO increasing performance based on this sorting).
Test: logging unit tests
Change-Id: I56bb3866c13cb4c28bd48665bf32ec620cf0278e
Documentation is synchronized to match external, to ease updating.
blacklist is replaced with ignorelist or ignore depending on context.
Test: none
Change-Id: I6db7ad321684759e3c5ac1f66f940b6e8a5709a0
As the EXT4_MAX_BLOCK_SIZE defined as 65536 which reached maxium value
of unsigned int. The superblock value maybe larger than 65536. This is
found by the Integer Overflow Sanitizer.
This patch fixed below boot error when userdata is corrupted:
init: processing action (fs) from
(/vendor/etc/init/hw/init.freescale.rc:221)
init: [libfs_mgr]Invalid ext4 superblock on '/dev/block/by-name/userdata'
init: InitFatalReboot: signal 6 init: #00 pc 00000000000af7e8 /system/bin/init
(android::init::InitFatalReboot(int)+208) init: #01 pc 00000000000afbd0 /system/bin/init
(android::init::InstallRebootSignalHandlers()::$_22::__invoke(int)+32)
init: #02 pc 00000000000006bc [vdso:0000ffff9691b000] (__kernel_rt_sigreturn)
init: #03 pc 000000000004e070 /system/lib64/bootstrap/libc.so (abort+176)
init: #04 pc 000000000003427c /system/lib64/libfs_mgr.so
(read_ext4_superblock(std::__1::basic_string<char, std::__1::char_
traits<char>, std::__1::allocator<char> > const&,
android::fs_mgr::FstabEntry const&, ext4_super_block*, int*)+1804)
Test: boot with corrupted ext4 superblock
Change-Id: I58ed723afa9975d0e93f96fad7c55465e68b3edd
Signed-off-by: Haoran.Wang <elven.wang@nxp.com>
SnapshotUpdateTest uses a relatively small super partition, which
requires a small alignment and 0 alignment offset to work. For the
purpose of this test, hardcode the alignment and offset.
This test isn't about testing liblp or libdm.
Bug: 154355449
Bug: 157437632
Bug: 158718136
Bug: 157633441
Bug: 154646936
Test: atest on devices with alignment of data partition >= 512KiB
Change-Id: I1d0474f028cc824bd4197d0228350395239b3b81
Having mounted apexes with loop back devices backing files on /data
partition will prevent clean unmount of it. Unmounting them and tearing
down loop devices should minimize the risk of that.
Note that it won't fix the issue completely, as there are a few (~2-3)
processes that keep restarting even after SIGKILL is sent. Which means
that they can still hold references to apexes on /data partition. But
in practice probability of this is quite low.
Test: adb reboot
Test: put tzdata apex in /data/apex/active && adb reboot
Bug: 158152940
Change-Id: I4624567b3d0f304dba4c6e37b77abd89e57411de
The in_cdb.length (ALLOCATION_LENGTH) must be set in order to send
SECURITY PROTOCOL IN command.
Bug: 143636526
Test: Trusty storage tests
Change-Id: Ie4252e9b19c05825c895ec07f8c9684ae456f6c9
Initial commit for a SerializedLogBuffer. The intention here is for
the serialized data to be compressed (currently using zlib) to allow
for substantially longer logs in the same memory footprint.
Test: unit tests
Change-Id: I2528e4e1ff1cf3bc91130173a107f371f04d911a
Test that:
1) Logs are cleared
2) More logs can be added after clear
3) Well behaving blocking readers stay connected and can read new logs
after clear.
Test: this unit test
Change-Id: I8497896f5fb068b1e50ff0dcaab1cf79aebae2bb
Clear() and Prune() return a boolean indicating whether or not their
operations failed because the log buffer was 'busy'. This means that
they return false upon success and true upon failure, which is not
intuitive.
This change inverts their return value to simply be true if they were
successful or false otherwise. It also simplifies the return value of
ChattyLogBuffer::Prune() to true if the requested number of rows have
been pruned or if all rows in the log buffer have been pruned, and
otherwise return false.
Test: logging unit tests
Test: clearing works even under logging pressure
Change-Id: I346bb945496ef62bf8e973298f81c5163f49bc57
Regardless of whether a system property is "ro." or not, it can be
overridden by build.prop from the more specific partition. i.e.
foo.bar=true in system/build.prop can be overridden by
foo.bar=false in vendor/build.prop. However, the warning message
was referring the overridden property as "ro." causing confusion
when reading the log. Fix it by not mentioning "ro.".
Bug: 117892318
Test: N/A
Change-Id: I13014522d0c6b507b30c8754e2087fd71cc39971
Init starts ueventd in the default mount namespace to support loading
firmware from APEXes.
Bug: 155023652
Test: devices boots
adb$ nsenter -t (pid of ueventd) -m ls /apex
=> shows all APEXes
Change-Id: Ibb8b33a07eb014752275e3bca4541b8b694dc64b
If the superblock of /data is corrupted, fs_mgr would skip check_fs.
But, e2fsck actually may reference backup superblock to recover
the filesystem. This fix gives fs_mgr second chance to fix corrupted
ext4 /data.
Bug: 156200421
Test: boot with corrupted ext4 superblock
Signed-off-by: Randall Huang <huangrandall@google.com>
Change-Id: Ia39af3340c0e241f62557b7c2cc8b800443342f9
Status() is called with an empty string to handle `fastboot oem`
commands. This currently emits a set of spaces and sets
last_start_time such that the epilog can track the time spent in this
command. Emitting the spaces is problematic however, since it results
in the follow:
$ fastboot oem device-info
(bootloader) Verity mode: false
(bootloader) Device unlocked: true
(bootloader) Device critical unlocked: true
(bootloader) Charger screen enabled: true
OKAY [ 0.000s]
Finished. Total time: 0.000s
If we skip emitting the spaces, then we get the correct result:
$ fastboot oem device-info
(bootloader) Verity mode: false
(bootloader) Device unlocked: true
(bootloader) Device critical unlocked: true
(bootloader) Charger screen enabled: true
OKAY [ 0.001s]
Finished. Total time: 0.001s
There are no other uses of Status() with an empty string, so this
changes won't impact other commands.
Bug: 158310284
Test: fastboot formats this and other commands correctly.
Change-Id: I6294acefc65a8399160c0944b3fbc2f2ace919ed
for a first implementation the cgroup v2 freezer controller will be used in a
way similar to cgroup v1, that is a single child group will hold all frozen
processes. Some adjustments are needed for the new structure.
- Add support for cgroup v2 syntax under procfs.
- Separate creation of a directory with ownership/mode changes to allow changes
after mounting the cgroup kernfs root.
- Allow the creation of sub-groups under a cgroup v2 hierarchy.
Bug: 154548692
Test: manually verified that a proper cgroup v2 hierarchy is created and
accessible
Change-Id: I9af59e8214acaead3f520a94c95e75394c0df948
TARGET module shell_and_utilities_recovery requires non-existent: unzip.recovery
This should be referring to the "ziptool" module. "unzip" is a symlink
installed by "ziptool".
Bug: 7456955
Test: TH; boot/ramdisk/system/bin/ziptool installed in /boot partition
Change-Id: Ib9edf9c17b4dfdebdb8719fb7b9244fca6133f6d
