Android与/ etc / fstab等效吗？

#1 楼

不要将Android视为经过大量修改的Linux发行版。因为不是。 Android与Linux发行版共享的几乎唯一东西是内核。甚至这个组件也被修改了。其他核心组件（如libc）也有所不同。

Android没有/etc/fstab

您不需要/etc/fstab即可安装分区。但是也没有IIRC mount命令。 dev_mount应该可以工作（需要root用户）。回答您的问题的标题：所有启动系统的安装均使用/etc/vold.fstab帮助程序脚本完成。

#2 楼

fstab文件位于/中。

它称为/fstab.$systemname.rc，其中$systemname基于手机的指纹属性，可以识别为芯片组类别还是手机本身。

#3 楼

我看到有冲突的信息。一种资源说它是硬编码的，因此不能更改用户端：

在device / system / init中找到特定于Android的初始化程序。添加LOG消息以帮助您调试device / system / init / init.c中定义的LOG宏的潜在问题。
init程序使用硬编码文件名或由生成的设备名直接挂载所有文件系统和设备。探测sysfs文件系统（从而消除了Android中对/ etc / fstab文件的需要）。

在其他地方提到了/etc/vold.fstab和/etc/vold.conf。我将它们安装在CM 7.1下的设备上，但不确定如何使用。

#4 楼

您可以通过运行

mount -o remount, rw /mnt/sdcard

将外部存储重新安装为可执行文件，这将删除noexec，nosuid和nodev标志，但仍为vfat fs。您可以链接到此fs，但不能从内部链接。重新安装无法在重新启动后继续存在，因为将读取vold.fstab文件，并在重新启动时使用noexec标志将其重新安装。

如果将外部存储中的任何一个重新格式化为vfat以外的任何格式，则它们将不会在重新引导时重新挂载，并且您移至任何外部存储器的任何应用程序将无法使用。如果您不打算为应用程序使用外部存储，则可以卸载外部存储并使用busybox mke2fs DEVICE使其成为ext2。使用busybox newfs_msdos DEVICE将其返回到vfat并再次可用。

注意busybox mkfs.vfat损坏，您将得到类似


lseek的信息：值太大，无法定义数据类型


所以不要浪费时间。所有这些都假设您已经扎根，并且拥有一个工作中的busybox二进制文件。

#5 楼

我意识到这是一个古老的话题，但是这里的一些答案实际上阻碍了我学习fstab和Android的努力，因为它们强烈暗示着Android中的fstab情况与其他Linux发行版完全不同。据我所知，不是。

但是，在这里读取不同的响应使我感到奇怪：我的设备上有什么fstab-等效文件？

步进回到片刻，注意“ Android没有/ etc / fstab”可能对OP没有帮助，因为他们必须已经知道这一点。如果这是不正确的，那么他们的问题（询问与/etc/fstab等效的Android是什么）将毫无意义。另一方面，我们知道@Flow并不是要暗示Android上没有等效功能，因为他们提到了其中一个名为/etc/vold.fstab的“帮助脚本”。

总之，我认为@Flow发布的内容是，在某些系统上，存在一个名为/etc/vold.fstab的文件（可能是“帮助脚本”，我无法在手机上验证该文件），在那些系统上，此文件与/etc/fstab。

回到我自己的设备的好奇之处，尽管有OP的年龄，我还是出于以下几个原因将我的发现发表在这里：


首先，我想记录一下我在手机Pixel 2XL上可以找到的所有fstab样式文件。
其次，我想向人们展示，尤其是Linux / Android新手，这很容易在您自己的设备上找到这些文件（“教他们钓鱼”）。
第三，对我写出我的发现很有帮助（奖金：我将始终可以在StackExchange上再次找到它！）。
最后，Google仍然是Stil我会将此页面提供服务，这样有机会为我以外的人提供帮助。

所以让我尝试总结一下我从所有这些中学到的一切：

Android或至少可以访问的其变体确实使用了fstab -style文件。但是，这些文件的确切名称，位置和功能会因发行版本而有所不同-含义取决于Android版本和设备，如果使用自定义ROM，也取决于ROM。

要在系统上找到这些文件，请打开终端仿真器，例如tmux或adb shell，然后运行类似这样的命令：find / -type f -iname '*fstab*' 2>/dev/null。将文件2（stderr）重定向到/dev/null将使您的输出更整洁，因为即使您是find，您也可以忽略从root收到的错误消息的冲击。

我的系统（Pixel 2XL，代号“ taimen”），我发现了三个候选文件：

taimen:/ # find / -type f -iname '*fstab*' 2>/dev/null

/sbin/.core/mirror/vendor/etc/fstab.taimen
/vendor/etc/fstab.taimen
/data/data/com.android.omadm.service/files/dm/dmt_data/fstab

前两个是单独的文件，既不是硬文件也不是符号文件链接到另一个，但是如果您对它们进行链接，则会发现它们是相同的。再深入一点，如果在文件上运行diff，您会发现它们具有相同的Device和Inode值：

taimen:/ # stat /sbin/.core/mirror/vendor/etc/fstab.taimen /vendor/etc/fstab.taimen

  File: `/sbin/.core/mirror/vendor/etc/fstab.taimen'
  Size: 1326     Blocks: 16      IO Blocks: 512 regular file
Device: fc00h/64512d     Inode: 925      Links: 1
Access: (644/-rw-r--r--)        Uid: (    0/    root)   Gid: (    0/    root)
Access: 2009-01-01 02:00:00.000000000
Modify: 2009-01-01 02:00:00.000000000
Change: 2009-01-01 02:00:00.000000000

  File: `/vendor/etc/fstab.taimen'
  Size: 1326     Blocks: 16      IO Blocks: 512 regular file
Device: fc00h/64512d     Inode: 925      Links: 1
Access: (644/-rw-r--r--)        Uid: (    0/    root)   Gid: (    0/    root)
Access: 2009-01-01 02:00:00.000000000
Modify: 2009-01-01 02:00:00.000000000
Change: 2009-01-01 02:00:00.000000000

stat会定期报告这两个文件名每个文件只有一个链接（因此不涉及硬链接或符号链接）。我不是文件系统专家，但是这里发生的是同一设备已挂载两次。您可以在以下命令的输出中看到这一点，其中输入的两行之间的唯一区别是安装点（紧接在“ on”之后的部分）：

taimen:/ $ mount | grep vendor

/dev/block/dm-0 on /vendor type ext4 (ro,seclabel,relatime,block_validity,delalloc,barrier,user_xattr)
/dev/block/dm-0 on /sbin/.core/mirror/vendor type ext4 (ro,seclabel,relatime,block_validity,delalloc,barrier,user_xattr)

仅当我以root用户身份登录时，我才能看到第三个文件，因此，如果您拥有与我的设备相同的设备，除非您的手机已扎根，否则您仍然找不到或无法访问此文件。该文件与一项称为“开放移动联盟设备管理”的服务有关，但这是我所知甚少的服务，因此，我将在这里仅提及它，如果愿意，您可以向Google寻求详细信息。