web-dev-qa-db-ja.com

パーティションなしのSDカードのマウント

GNU/LinuxでSDHCカードをマウントしようとしています。通常起こることとは異なり、/var/log/syslogは言及していませんsdb1、ただ：

Jul 26 16:07:53 xvii kernel: [  159.404842] scsi 6:0:0:0: Direct-Access     Singim   SD Card   MMC/SD 1.4F PQ: 0 ANSI: 0 CCS
Jul 26 16:07:53 xvii kernel: [  159.405115] sd 6:0:0:0: Attached scsi generic sg2 type 0
Jul 26 16:08:01 xvii kernel: [  168.239600] sd 6:0:0:0: [sdb] Attached SCSI removable disk

さらにfdisk -l /dev/sdb何も出力しません。私は何をすべきか？

編集（2014-07-27）:このSDカードをもう一度入手できましたが、故障しているようです。昨日、USBカードリーダーで試していました。今日、ラップトップのSDスロットに挿入して直接試しましたが、何千ものI/Oエラーが発生しました。

Jul 27 11:56:35 xvii kernel: [ 8091.317234] mmc0: new high speed SDHC card at address 1234
Jul 27 11:56:35 xvii kernel: [ 8091.317477] mmcblk0: mmc0:1234 SA04G 3.68 GiB
Jul 27 11:56:35 xvii kernel: [ 8091.320119] mmc0: Got data interrupt 0x00200000 even though no data operation was in progress.
Jul 27 11:56:35 xvii kernel: [ 8091.322277] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00
Jul 27 11:56:35 xvii kernel: [ 8091.322289] mmcblk0: retrying using single block read
Jul 27 11:56:35 xvii kernel: [ 8091.324862] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
Jul 27 11:56:35 xvii kernel: [ 8091.324872] end_request: I/O error, dev mmcblk0, sector 0
Jul 27 11:56:35 xvii kernel: [ 8091.326398] mmcblk0: error -84 transferring data, sector 1, nr 7, cmd response 0x900, card status 0x0
Jul 27 11:56:35 xvii kernel: [ 8091.326405] end_request: I/O error, dev mmcblk0, sector 1
Jul 27 11:56:35 xvii kernel: [ 8091.329056] mmcblk0: error -84 transferring data, sector 2, nr 6, cmd response 0x900, card status 0x0
[...]

およびgdisk -lはパーティションテーブルを検出できませんでした。カードに関するlsblk出力：

mmcblk0                  179:0    0   3.7G  0 disk

少ししてからもう一度試してみたところ、カードが認識されました。

Jul 27 12:08:00 xvii kernel: [ 8776.617712] mmc0: new high speed SDHC card at address 1234
Jul 27 12:08:00 xvii kernel: [ 8776.618117] mmcblk0: mmc0:1234 SA04G 3.68 GiB
Jul 27 12:08:00 xvii kernel: [ 8776.620324]  mmcblk0: p1

それをマウントすることができます：/ dev/mmcblk0p1/media/mmcタイプvfat（rw、nosuid、nodev、noexec、noatime、uid = 1000、gid = 1000、fmask = 0022、dmask = 0022、codepage = 437、iocharset = utf8、shortname = mixed、errors = remount-ro、user = vinc17）

gdisk -l /dev/mmcblk0 MBRパーティションテーブルのみが見つかりましたが、2番目のパーティションテーブルが最後のパーティションと重複しています。

linuxmountsd-card
5
vinc17

リンク/dev/$diskはブロックデバイス全体を指しますが、未割り当て領域のないパーティションディスクでは、/dev/$disk[num]にも表されない唯一の部分は最初の2kb-4mb程度です- $diskのパーティションテーブル。これは、ファームウェアやOSが読み取ることができる形式でrawデバイスに書き込まれた情報の一部です。さまざまなシステムがさまざまな方法でさまざまな理由でそれを解釈します。 3つカバーします。

  • BIOSシステムでは、このテーブルはMBRマスターブートレコードの形式で書き込まれるため、ファームウェアは起動可能な実行可能ファイルの場所を見つけることができます。 BIOSを起動するために、パーティションの最初の512バイトを読み取り、テーブルがbootableフラグでマークして実行するため、パーティションテーブルを読み取ります。これらの512バイトには通常ブートローダーが含まれています（多くのLinuxシステムではgrubまたはliloのように）次に別の実行可能ファイルをチェーンロードします（Linuxなど） kernel）ローダーが理解するファイルシステムでフォーマットされたパーティションにあります。

  • 新しいカーネルを備えたEFIシステムおよび/またはBIOSシステムでは、このパーティションテーブルはGPTGUIDパーティションテーブル形式にすることができます。 EFIファームウェアは[〜＃〜] fat [〜＃〜]ファイルシステムを理解しているため、テーブルがEFIシステムパーティションフラグで記述しているパーティションを探し、次のようにマウントします。 FAT、およびそのBoot0000- {GUID} NVRAM変数に格納されているパスの実行を試みます。これは基本的にBIOSブートローダーが実行するように設計されているタスクと同じであり、ロードする実行可能ファイルがファームウェアによって解釈できる限り（v。3.3以降のほとんどのLinuxカーネルなど）それらの使用を不要にします。 EFIファームウェアはもう少し洗練されています。

起動後、パーティションテーブルが存在し、カーネルがそれを理解している場合、/dev/${disk}1は4mb+オフセットにマップされ、パーティションテーブルが示す場所で終了します。パーティションは、実際には次のような任意の論理分割子です。

start of disk | partition table | partition 1 | ... and so on | end of disk

それは次のようにもなると思いますが：

s.o.d. | p.t. | --- unallocated raw space --- | partition 1 | ... | e.o.d.

それはすべて、パーティションテーブルで定義したレイアウトに依存します。これは、fdisk形式のMBRまたはgdisk形式のGPTなどのツールで実行できます。

  • ファームウェアにはブートデバイス用のパーティションテーブルが必要ですが、カーネルには、ファイルシステムを認識させたい細分化されたブロックデバイス用のパーティションテーブルが必要です。ディスクがパーティション化されている場合、テーブルがないと、カーネルはディスクスキャンでsuperblocksを見つけられません。パーティションテーブルを読み取り、それらのオフセットを/dev/$disk[num]のリンクにマップします。各パーティションの開始時に、スーパーブロックを探します。それはほんの数kbのデータです（もしそうなら）カーネルにそれがどんなタイプのファイルシステムであるかを伝えます。堅牢なファイルシステムは、パーティション全体にsuperblockのバックアップを配布します。パーティションに読み取り可能なsuperblockが含まれていない場合、カーネルはそれを理解しますが、カーネルはファイルシステムをまったく認識しません。

いずれにせよ、重要なのは、ファームウェアによって解釈される必要のないディスク（起動しないディスクなど）では、これらのテーブルは実際には必要ないということです（これは唯一の実行可能なGPT +でもあります） BIOSの場合）-単一のファイルシステムのみが必要な場合。 /dev/$diskは、任意のファイルシステムで全体をフォーマットできます。必要に応じて、一日中mkfs.fat /dev/$diskできます。おそらく、Windowsは、removableフラグでマークされたデバイスタイプの場合と同様に、とにかくそうします。

言い換えると、ファイルシステムsuperblockをパーティションテーブルではなくディスクの先頭に配置することは完全に可能です。その場合、カーネルがファイルシステムを理解していれば、次のことができます。

mount /dev/$disk /path/to/mount/point

ただし、パーティションが必要で、まだ存在していない場合は、それらを作成する必要があります。つまり、前述のようにfdiskまたはgdiskなどのツールを使用して、パーティションの場所をディスクのヘッドにマッピングするテーブルを作成します。 。

これらすべてを合わせると、あなたの問題は次の3つのうちの1つであることがわかります。

  • ディスクにはパーティションテーブルもファイルシステムもありません

    • 最近ワイプされたか、使用されなかったか、その他の方法で破損しています。

  • ディスクのパーティションテーブルがOSカーネルに認識されない

    • BIOSとEFIだけがファームウェアタイプではありません。これは、SDHCカードが特に役立つ可能性があるモバイル/組み込み領域に特に当てはまりますが、そのようなデバイスの多くは、ファイルシステムとパーティションテーブルの間の境界線を曖昧にするあまり洗練されていないファイルシステムのレイヤーを使用します。

  • ディスクにはパーティションテーブルがなく、OSカーネルで認識されないファイルシステムでフォーマットされています

上記のコメントを読み直した後、私はそれが後者の場合であるとかなり確信しています。そのテレビでマニュアルを入手することをお勧めします。デスクトップLinuxのカーネルモジュールとしてロードされているファイルシステムをロードして、そこにディスクをマウントできるかどうかを確認してください。

4
mikeserv