Androidの/ etc / fstabと同等のものは何ですか？

時々、私は彼らがLinuxをあまりいじっていないことを本当に望んでいます！/etc/fstabどこかにそこにあることを知っていますが、どこに？

代替ファイルシステムでいくつかのパーティションをマウントしたいです（FAT32が好きではないため）。

Androidを大幅に変更されたLinuxディストリビューションと考えないでください。そうではないからです。AndroidがLinuxディストリビューションと共有するほぼ唯一のものはカーネルです。そして、このコンポーネントも変更されます。また、libcなどの他のコアコンポーネントも異なります。

Androidにはありません /etc/fstab

/etc/fstabパーティションをマウントする必要はありません。しかし、IIRCにはmountコマンドもありません。dev_mount動作するはずです（ルートが必要です）。質問のタイトルに答えるには：スタートアップシステムのマウントはすべて、/etc/vold.fstabヘルパースクリプトを使用して行われます。

fstabファイルはにあり/ます。

チップセットのカテゴリまたはハンドセット自体として識別される、ハンドセットの指紋特性に基づいた/fstab.$systemname.rc場所$systemnameと呼ばれます。

矛盾する情報が表示されています。 あるリソースはハードコードされていると言っているので、ユーザー側で変更できるものではありません：

Android固有の初期化プログラムは、device / system / initにあります。LOGメッセージを追加して、device / system / init / init.cで定義されたLOGマクロの潜在的な問題をデバッグします。

initプログラムは、ハードコーディングされたファイル名またはsysfsファイルシステムをプローブして生成されたデバイス名を使用して、すべてのファイルシステムとデバイスを直接マウントします（これにより、Androidの/ etc / fstabファイルが不要になります）。

他の場所/etc/vold.fstabで/etc/vold.conf言及されています。CM 7.1のデバイスにそれらがありますが、どのように使用されているのかわかりません。

実行することにより、外部ストレージを再マウントして実行可能にすることができます

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バイナリを持っていることを前提としています。

これは古いトピックであることを理解していますが、ここでの回答のいくつかは、fstabAndroidのfstab状況が他のLinuxディストリビューションとは非常に異なることを強く示唆しているため、AndroidとAndroid について学ぶ努力を実際に妨げました。私が言えることから、そうではありません。

しかし、ここでは異なる回答を読んで、私は疑問に思う作った：何fstabに換算つまたは複数のファイルです、私のデバイス？

「Androidには/ etc / fstabがありません」ということは、OPには既に知っているはずなので、OPにとってはおそらく役に立たないことに注意して、少し前に戻ります。これが真実でない場合、彼らの質問（Androidの同等のものを尋ねる/etc/fstab）は意味をなさないでしょう。一方、@ FlowはAndroidに同等のものが存在しないことを暗示しようとしていないことを知ってい/etc/vold.fstabます。

全体として、@ Flowの投稿の要点は、一部のシステムにはファイル（おそらく「ヘルパースクリプト」-電話では確認できない）/etc/vold.fstabがあり、これらのシステムではこのファイルがに最も近い等価物/etc/fstab。

自分のデバイスについて疑問に思うことに戻り、OPの年齢にもかかわらず、いくつかの理由でここに私の発見を投稿します。

• まず、携帯電話で見つけることができるすべてのfstabスタイルのファイル、Pixel 2XL を文書化します。
• 第二に、私は人々、特にLinux / Android初心者に、自分のデバイスでこれらのファイルを見つけるのがかなり簡単であることを示したいと思います（「魚に教える」）。
• 第三に、調査結果を書くことは役に立ちます（ボーナス：StackExchangeでいつでも再び見つけることができます！）。
• 最後に、Googleはまだこのページを提供しているので、これは私以外の誰かに役立つ可能性があります。

それで、これから学んだことすべてをまとめてみましょう。

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」）で、3つの候補ファイルが見つかりました。

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

最初の2つは別々のファイルであり、どちらももう一方へのハードリンクでもシンボリックリンクでもありませんが、それらのファイルdiffは同一であることがわかります。もう少しstat詳しく見てみると、ファイルを実行すると、同じデバイスとiノードの値があることがわかります。

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これらのファイル名の両方を、それぞれ1つのリンクのみを持つ通常のファイルとして報告します（したがって、ハードリンクまたはシンボリックリンクは含まれません）。私はファイルシステムの専門家ではありませんが、ここで起こったことは、同じデバイスが2回マウントされたことです。これは、次のコマンドの出力で確認できます。出力の2行の違いは、マウントポイント（「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)

3番目のファイルは、rootとしてログインした場合にのみ表示されるため、私のデバイスと同じデバイスを使用している場合、電話がルート化されない限り、このファイルを見つけることもアクセスすることもできません。このファイルはOpen Mobile Alliance Device Managementと呼ばれるサービスに関係していますが、それは私がほとんど知らないサービスです。したがって、ここでそれについて言及するだけで、必要に応じてGoogleで詳細を確認できます。