从android中的adb shell手动挂载SD卡

Mount an SD card manually from adb shell in android

提问by Merc

I have an android 4.1 phone (Lenovo 820). After some changes aimed at partitioning the internal SD ram (which changed , the phone will no longer mount the externalSD card. I am good-ish at Linux, but I have never seen the Android shell before today.

我有一部安卓 4.1 手机（联想 820）。经过一些旨在对内部SD ram进行分区的更改（更改后，手机将不再挂载外部SD卡。我对Linux很好，但在今天之前我从未见过Android shell。

I would love to know the steps to:

我很想知道以下步骤：

• Get the list of available devices representing SD cards
• Manually mount the SD card -- the mount command won't work as it says can't read /etc/fstab-- how do you mount things?
• Get the SDcard to mount at boot time

• 获取代表 SD 卡的可用设备列表
• 手动挂载 SD 卡——挂载命令不会像它说的那样工作can't read /etc/fstab——你如何挂载东西？
• 在启动时获取要挂载的 SD 卡

My /etc/system/vold.fstab has:

我的 /etc/system/vold.fstab 有：

dev_mount sdcard /storage/sdcard0 emmc@fat /devices/platform/goldfish_mmc.0 /devices/platform/mtk-msdc.0/mmc_host
dev_mount sdcard2 /storage/sdcard1 auto /devices/platform/goldfish_mmc.1 /devices/platform/mtk-msdc.1/mmc_host

Mount is now:

坐骑现在是：

rootfs on / type rootfs (ro,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/secure type tmpfs (rw,relatime,mode=700)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/emmc@android on /system type ext4 (ro,relatime,nobarrier,noauto_da_alloc,commit=1)
/emmc@usrdata on /data type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,nobarrier,noauto_da_alloc)
/emmc@cache on /cache type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,nobarrier,noauto_da_alloc)
/emmc@protect_f on /protect_f type ext4 (rw,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)
/emmc@protect_s on /protect_s type ext4 (rw,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)

回答by Jarmez

I can't believe no one has responded to you in 2 months? Wow...how slack!

我不敢相信 2 个月内没有人回复您？哇……好闲啊！

Well anyway I spose I should fill you in on some info as well as ask some questions. 1). Have you got root access or did you pull the system vold from a release image/firmware? Like Linux SuperUser rights? 2). If you have root access/super user rights how did you obtain it? I mean what method did you use to gain root access? Was it via some scripts/binaries and a known exploit? Or was it flashed by the means of a rooted kernel? The reason I ask is that root access isn't just root access as most people are lead to believe; there are varying levels of root access. For instance you may have full root access as a user on the device, but come time when you want to manipulate your system remotely say from command line of your favorite Linux distro then you may find that root access isn't all it's cracked up to be. If you used an exploit and not a kernel then chances are that you only have system level root access, and ADB (android debug bridge) to your PC will be faced with various messages like "access denied", "unable to obtain superuser privileges" or "adb cannot run as root in production builds" or something similar to this. The reason this happens is because unlike some specialised developer kernels root via an exploit doesn't make the kernel insecure. I would recommend you do a bit of reading on what an insecure kernel is and if it is suitable for what you are hoping to achieve. The reason I say that is because on some devices having an insecure kernel is not ideal as it can trigger some unwanted system flags (some permanent and irreversible according to some manufacturers) and are used against developers to not honor warranty or as a means of extracting money for premium repair services to devices (regardless of if you the developer hoping to make some break through discoveries...caused the damage to the device or not? which sux). I think your device should be ok...? But I'm not 100% sure so do some research.

好吧，无论如何，我认为我应该向您提供一些信息并提出一些问题。1）。您是否获得了 root 访问权限，或者您是否从发布映像/固件中提取了系统卷？像 Linux 超级用户权限？2）。如果您拥有 root 访问权限/超级用户权限，您是如何获得它的？我的意思是你用什么方法来获得 root 访问权限？是通过一些脚本/二进制文件和已知的漏洞利用吗？或者它是通过有根内核的方式闪现的？我问的原因是 root 访问权限不仅仅是大多数人认为的 root 访问权限；有不同级别的根访问权限。例如，您可能以设备上的用户身份拥有完全的 root 访问权限，但是当您想从您最喜欢的 Linux 发行版的命令行远程操作您的系统时，您可能会发现 root 访问权限并不是它破解的全部内容是。如果您使用的是漏洞而不是内核，那么您可能只有系统级别的 root 访问权限，并且 ADB（android 调试桥）到您的 PC 将面临各种消息，例如“访问被拒绝”、“无法获得超级用户权限”或“adb不能在生产版本中以root身份运行”或类似的东西。发生这种情况的原因是因为与某些专门的开发人员内核不同，通过漏洞利用的 root 不会使内核不安全。我建议您阅读一下什么是不安全的内核以及它是否适合您希望实现的目标。我之所以这么说是因为在某些具有不安全内核的设备上并不理想，因为它会触发一些不需要的系统标志（根据某些制造商的说法，一些是永久性的和不可逆转的）并且被用于反对开发人员以不履行保修或作为提取的手段用于设备高级维修服务的资金（无论您的开发人员是否希望取得突破性发现...是否对设备造成损坏？哪个 sux）。我认为你的设备应该没问题......？但我不是 100% 确定所以做一些研究。

If you find that you cannot run an insecure kernel it is not the end of the world, it just requires a little bit more work to get what you want, which I will elaborate with examples in a moment.

如果你发现你不能运行一个不安全的内核，这并不是世界末日，它只需要多做一点工作就能得到你想要的东西，我稍后会用例子来详细说明。

Next thing you should probably consider is what you are hoping to do when you get where you want in/on the device? Have you thought that far? If so you may realise that the standard Android console/shell is rather dismal and ill equiped for tools to do all the great things you have been able to do with a blink of an eye on your Linux computer; that means you are going to need some support tools like "busybox" as well as possibly some others as well, like for instance if you are working on some databases you'd probably want sqlite3, you probably need the actual bash binary to extend your shell a bit. You would also want to look at not only just obtaining these binaries but possibly where they should be located on your system for ease of access otherwise you are going to get rather tired of typing huge long paths in the console to reach certain areas of your device like your sdcard. You will be familiar with symlinks having used Linux, well Android is no different only that a lot of the system of Android uses container like environment for applications. When dealing with this there can be some hurdles to overcome as the system has security checks in place to try stop intrusion by unwanted 3rd parties. That is what keeps most developers safe knowing that their (and your) personal data is protected, however when this is you and you want to go in to these areas of the device you need to have your tools setup correctly. Most Android tinkerers use a modified recovery image (or a custom one - not too dissimilar to the custom kernel concept) that allows them to modify the system while it is offline through the means of mostly a simple zip file with embedded instructional script, binary and a manifest (research signed and unsigned zips for Android custom recoverys - I won't go in to detail about that but it is important). You could essentially package up all of your tools into a single zip and "flash" install the components into the areas of the system you require and symlink the same files to various other locations as well.

您可能应该考虑的下一件事是，当您在设备中/上到达您想要的位置时，您希望做什么？你有没有想过这么远？如果是这样，您可能会意识到标准的 Android 控制台/shell 相当令人沮丧，并且没有配备工具来完成您在 Linux 计算机上眨眼间就能完成的所有伟大事情；这意味着您将需要一些支持工具，如“busybox”以及其他一些支持工具，例如，如果您正在处理一些您可能需要 sqlite3 的数据库，您可能需要实际的 bash 二进制文件来扩展您的壳一点。您不仅要查看获取这些二进制文件，还要查看它们应该位于系统上的哪个位置以便于访问，否则您会厌倦在控制台中输入长长的路径以到达设备的某些区域就像你的 SD 卡一样。你会熟悉使用 Linux 的符号链接，Android 没有什么不同，只是很多 Android 系统使用容器一样的应用程序环境。在处理这个问题时，可能会有一些障碍需要克服，因为系统有适当的安全检查来尝试阻止不需要的第 3 方的入侵。这就是让大多数开发人员知道他们（和您的）个人数据受到保护的原因，但是当您这样做并且您想要进入设备的这些区域时，您需要正确设置工具。大多数 Android 修补程序使用修改后的恢复映像（或自定义的 - 与自定义内核概念不太相似），允许他们在系统脱机时通过大多数带有嵌入式指令脚本、二进制和清单（研究用于 Android 自定义恢复的签名和未签名 zip - 我不会详细介绍，但它很重要）。您基本上可以将所有工具打包到一个 zip 文件中，然后将组件“闪存”安装到您需要的系统区域中，并将相同的文件符号链接到其他各种位置。二进制文件和清单（研究用于 Android 自定义恢复的已签名和未签名 zip 文件 - 我不会详细介绍，但这很重要）。您基本上可以将所有工具打包到一个 zip 文件中，然后将组件“闪存”安装到您需要的系统区域中，并将相同的文件符号链接到其他各种位置。二进制文件和清单（研究用于 Android 自定义恢复的已签名和未签名 zip 文件 - 我不会详细介绍，但这很重要）。您基本上可以将所有工具打包到一个 zip 文件中，然后将组件“闪存”安装到您需要的系统区域中，并将相同的文件符号链接到其他各种位置。

Lets look at some examples now shall we - say you have root access cause you used an exploit on your device but have secured kernel still note: secured kernel = ro.debugable=0within your system default.prop file (generated at boot time and not found or located within most firmware packages). If you want to allow adb to have root access you are going to need to change that file and in particular the line I mentioned above. There may also be other requirements so you should look into what your device needs e.g. The Galaxy Tab I am repairing at the moment is older so uses mass storage instead of media transfer protocol, so I need to tell adb to keep the connection open and solid (not time out and disconnect) when engaged with the device; this happens to be done through the default.prop file as well. The difficulty comes when you want to change this file; most people decompile the kernel and the ramdisk and edit it directly and recompile and then reflash it to the device mainly because adb obviously doesn't have root access at the moment. You can pull the file from the system like so:

现在让我们看一些例子 - 假设你有 root 访问权限，因为你在你的设备上使用了漏洞，但有安全内核仍然注意：安全内核 =ro.debugable=0在您的系统 default.prop 文件中（在启动时生成并且在大多数固件包中找不到或位于）。如果您想允许 adb 具有 root 访问权限，您将需要更改该文件，特别是我上面提到的那一行。可能还有其他要求，因此您应该查看您的设备需要什么，例如我目前正在修复的 Galaxy Tab 较旧，因此使用大容量存储而不是媒体传输协议，因此我需要告诉 adb 保持连接打开和稳固（不超时并断开连接）与设备接合时；这恰好也是通过 default.prop 文件完成的。当您想更改此文件时，困难就来了；大多数人反编译内核和ramdisk并直接编辑并重新编译然后将其重新刷新到设备，主要是因为adb显然没有' 目前没有root访问权限。您可以像这样从系统中提取文件：

adb pull default.prop default.prop

(Thats if you have adb on your PC distro environment path)

（如果您的 PC 发行版环境路径上有 adb）

This will bring the straight you, only the problem is when you want to put it back after changing it can be rather difficult. Various solutions are about, I hear a lot of pushing it to SDcard /emmc/storage/sdcard0/default.prop or /tmp/default.prop and then requiring you as "SuperUser" on the device using something like terminal emulator, script manager or root explorer to put the file back in place and give it the correct permissions.

这将使您保持正直，唯一的问题是当您想在更改后将其放回原处时可能会相当困难。关于各种解决方案，我听到很多将它推送到 SDcard /emmc/storage/sdcard0/default.prop 或 /tmp/default.prop 然后要求您使用终端模拟器、脚本管理器等设备上的“超级用户”或根资源管理器将文件放回原位并为其授予正确的权限。

typing adb remount on a device with secure kernel will allow you to remount the whole system as read-write and you can do as you please. If insecure though you may end up doing something like

在具有安全内核的设备上键入 adb remount 将允许您以读写方式重新安装整个系统，您可以随心所欲。如果不安全，尽管您最终可能会做类似的事情

adb root
remount

or you might end up finding that your whole console has no superuser rights what so ever, so you would be required to adb shell into the device shell (where it or you has superuser rights) and then executing the commands you want to try.

或者您最终可能会发现您的整个控制台没有超级用户权限，因此您需要将 adb shell 加入设备外壳程序（它或您拥有超级用户权限的位置），然后执行您想要尝试的命令。

adb shell
su
mount -o rw /system
remount /system

I have discovered recently that you can obtain the same level of access through a single line at the adb console and single return key like so:

我最近发现您可以通过 adb 控制台上的一行和单个返回键获得相同级别的访问权限，如下所示：

adb shell su -c mount -o rw,remount /system

This passes the arguments in single string adb shell -> superuser access -> pass command -> mount as read-write -> remount command -> to the system partition.

这将单个字符串 adb shell -> 超级用户访问 -> 传递命令 -> 以读写方式挂载 -> 重新挂载命令 -> 中的参数传递到系统分区。

You could if you like use the above command to gain superuser rights from the console and echo strings into the default.prop file without the need of decompiling the kernel.

如果您愿意，可以使用上述命令从控制台获得超级用户权限并将字符串回显到 default.prop 文件中，而无需反编译内核。

In my case I just repeated the same commands a few times and overwrote the default.prop with the same content only adjusting specific variables to my liking like so: note the first line only uses 1 > so this effectively wipes or overwrites the default.prop file, hence the rest of the lines need to also follow. I use 2 > like >> because this appends to the following line of the file.

在我的例子中，我只是重复了几次相同的命令，并用相同的内容覆盖了 default.prop，只是根据我的喜好调整了特定的变量，如下所示：注意第一行只使用 1 > 所以这有效地擦除或覆盖了 default.prop文件，因此其余的行也需要遵循。我使用 2 > like >> 因为这会附加到文件的以下行。

adb shell su -c echo ro.secure=1>default.prop
adb shell su -c echo ro.allow.mock.location=0>>default.prop
adb shell su -c echo ro.debuggable=1>>default.prop
adb shell su -c echo persist.sys.usb.config=mass_storage,adb>>default.prop
adb shell su -c echo persist.service.adb.enable=0>>default.prop

This is rather fast and effective for 4 or 5 lines of code, but this is not practical when you are rewriting a large file with many lines of test. You may want to look at things like grep with looping functions in a bash script to filter specific lines of the large text/script/config file, however for this example and probably for your system vold file this should be sufficient.

这对于 4 或 5 行代码来说是相当快速和有效的，但是当您重写包含多行测试的大文件时，这并不实用。您可能希望在 bash 脚本中查看带有循环函数的 grep 之类的内容，以过滤大型文本/脚本/配置文件的特定行，但是对于此示例以及可能对于您的系统 vold 文件，这应该足够了。

I think this should be enough to (excuse the pun) ARM you with enough info to be dangerous :) On that note, please make sure you have got a backup of your device, before you go messing with the system. They are very similar to linux but they are also very different too! Heed this warning, MAKE SURE YOU BACK UP YOUR EFS PARTITION STRAIGHT AWAY!! Efs contains the device IMEI number and this is something you really don't want corrupted or lost. I have seen first hand what can happen; you don't even need to call the EFS partition by accident to break it....you only need make an error calling an explicit path to the incorrect partition and it can obliterate your IMEI!

我认为这应该足以（请原谅双关语）用足够的信息武装你，以免造成危险:) 在这一点上，请确保在你搞乱系统之前备份了你的设备。它们与 linux 非常相似，但它们也非常不同！注意这个警告，确保你立即备份你的 EFS 分区！！Efs 包含设备 IMEI 号码，这是您真正不希望损坏或丢失的东西。我亲眼目睹了可能发生的事情；您甚至不需要意外调用 EFS 分区来破坏它....您只需要在调用不正确分区的显式路径时出错，它就可以消除您的 IMEI！