Explicitly call restorecon_recursive on /metadata/apex
On some devices we see a weird in which /metadata/apex will have a wrong selinux label. This will effectively prevent such devices from getting any apex updates. Since we haven't figured out a root cause for this bug, it's safer to explicitly call restorecon on /metadata/apex to make sure it's correct. This change shouldn't affect a normal boot flow, since /metadata/apex will already have a correct label and restorecon_recursive will be a no-op. Test: rm -Rf /metadata/apex && \ mkdir /metadata/apex && mkdir /metadata/apex/sessions Bug: 149317789 Change-Id: I971ffe35c93bb79d9e71106c24515ec0ee70333a
This commit is contained in:
parent
20d78e3323
commit
cf7b6bad55
|
@ -517,6 +517,12 @@ on post-fs
|
|||
|
||||
mkdir /metadata/apex 0700 root system
|
||||
mkdir /metadata/apex/sessions 0700 root system
|
||||
# On some devices we see a weird behaviour in which /metadata/apex doesn't
|
||||
# have a correct label. To workaround this bug, explicitly call restorecon
|
||||
# on /metadata/apex. For most of the boot sequences /metadata/apex will
|
||||
# already have a correct selinux label, meaning that this call will be a
|
||||
# no-op.
|
||||
restorecon_recursive /metadata/apex
|
||||
|
||||
mkdir /metadata/staged-install 0770 root system
|
||||
on late-fs
|
||||
|
|
Loading…
Reference in New Issue