fs_mgr supports 'nofail' flag, which is used if we do not want to
error-out incase the mounting/setup fails for a partition tagged with
nofail flag in fstab.
Recently added code in vold misses this handling, i.e. it aborts even
for a nofail partition upon encountering an expected failure.
Test: Add a non-existing logical partition fstab entry with 'nofail'
flag. Init's first stage mount acks this and doesn't crash.
Vold aborts (as it doesn't handle it), and device doesn't boot.
With this change, device boots up.
Change-Id: I2b1904a9c648c31bcc05b2e7e77480db236ff66e
When we're mounting a private volume, we create stacked emulated volumes
on top of it. Due to the ordering there, we would broadcast the emulated
volumes being created *before* the "mounted" status update. This in turn
could cause us to try and mount these emulated volumes before the
underlying private volume is really mounted. This is problematic in
particular on devices that support a filesystem keyring, where we need
to do some additional setup before the devices can be used.
While we could modify StorageManagerService to delay the mount, a safer
fix at this stage of the release is to just fix the ordering of these
events. To achieve that, add a simple postMount() helper, that is called
after a succesful mount. This allows us to setup the volume properly
before trying to mount any stacked volumes.
Bug: 151079464
Test: atest AdoptableHostTest
Change-Id: I2cc4113d4d71d89aa629bb9c0fa9be441355c079
This patch fixes missing entry in the below commit.
Fixes: c52f6724ed ("vold: clean up configuration set")
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: Ia39a427d4747b29a7af42633f34daab63204bbf9
Vold needs to pass / accept IncFs control via Binder, so it
neeeds to get and put its internal FDs in and out. Using the new
release() function it works without extra fd duping
Bug: 153704006
Test: builds & boots
Change-Id: I64bc5b1ca9f2c69e34c3a860ed3edbe58bd9ea29
am skip reason: Change-Id I562df49deffdccdb2cfd657130fc05b24d40a6a6 with SHA-1 78f806198f is in history
Change-Id: I8cdb012f5976e3c964e16dff9da9541831442734
am skip reason: Change-Id I562df49deffdccdb2cfd657130fc05b24d40a6a6 with SHA-1 78f806198f is in history
Change-Id: Ib183a53d8b49427ddf243d22db5df1f4b2b9815e
To improvement performance, and also making them able to list
the dirs.
This should also be fine under b/151055432, as the whole obb
directory is mounted, renameTo() from installer to apps should be
a move not copy.
Bug: 153422990
Bug: 153540919
Test: atest AdoptableHostTest
Change-Id: Ia18fd4393db14a0f11d6e5b947dd716515bdeeef
While looking at some emulator logs, I noticed that we fail to create
dirs like /Android/data/com.foo/cache on public volumes, because we try
to chmod it; public volumes go completely through FUSE, even for
Android/, and so these operations will fail, because the underlying
UID/GID is not setup correctly.
Really the only thing we really have to do on public volumes is create
the dirs, like we used to do.
Bug: 152618535
Test: manually verify cache dirs can be created successfully
Change-Id: I66e5d0873f1198123787943b17b468eadf0a853d
am skip reason: Change-Id Iaebff2a835288839a2faf0edbe0e47ceb96b4458 with SHA-1 97ff0845e2 is in history
Change-Id: Ieb4f5184e6428db1023a78bd2f492bc2827b8170
am skip reason: Change-Id Iaebff2a835288839a2faf0edbe0e47ceb96b4458 with SHA-1 97ff0845e2 is in history
Change-Id: I3e1e7c803956c895d976368b64481f42dfcf3c5c
am skip reason: Change-Id Iaebff2a835288839a2faf0edbe0e47ceb96b4458 with SHA-1 97ff0845e2 is in history
Change-Id: If48e613ce1fba64f6bf9bf8613ce93d76cf8b31f
