28113cf3f6
Right now there is a bug in second-stage-init that screws up the overlayfs overrides. This happens because: 1. second-stage-init mount_all might be executed in the "bootstrap" mount namespace. 2. In order to move (MS_MOVE) submounts in fs_mgr_overlayfs_mount_all(), we change the mount propagation type of overridden filesystems to MS_PRIVATE. 3. This means that the "default" mount namespace would not receive the mount events of the overlayfs overrides. 4. After /data is mounted, init would switch to the "default" namespace. This means any new processes spawned after this period would not be able to see the overlayfs overrides. We fix this by changing the mount order of second-stage-init mount_all to mount the overlayfs override of a partition immediately after the partition is mounted. This way we don't need to move any submounts as there can't be any, thus we don't need to set any mountpoint to MS_PRIVATE so the mount event of the overlayfs would be propagated to the "default" mount namespace, too. Bug: 309407859 Bug: 306124139 Test: adb-remount-test Test: verify that overlayfs tookover successfully from second-stage-init Change-Id: If2ff4852516292ccbc7abdeebe0e9a7c1c7ba606 |
||
|---|---|---|
| .. | ||
| fs_mgr | ||
| fs_mgr.h | ||
| fs_mgr_dm_linear.h | ||
| fs_mgr_overlayfs.h | ||
| fs_mgr_vendor_overlay.h | ||