OSのインストールをしすぎてWindowsからアクセスできなくなったUSBメモリを復活させた話

追記しました(2020/05/20)

原因はパーティションとかフォーマットの問題ではなかったので、追記しました。 追記はこちらとなります


個人的には新しいOSが出てくる古いノートPCやRaspberryPiでインストールしたり色々遊ぶのが好きなのですが、いろいろやっていてUSBメモリにアクセスできなくなる状況が発生しました。正直やりすぎたかなと思いました。

ただ、その後WindowsPCにUSBメモリを挿入しても認識されないし、ディスク管理ツールからも見ることができないのでどうにかならないかなと思ったのでLinuxベースのOSから復帰を試みました。LinuxベースといってもRaspbianなのですが…。

ただ、その方法で過去の自分の経験でやっていることでいろいろ混乱があったのでメモを残しておこうと思います。

今回の解決手段を早く知りたい方は本エントリー下の方にあるアプローチを変えて復帰を御覧ください。

チェック~作業

USBをPCに挿してもディスク管理ツールでも表示されません。

f:id:ueponx:20200314133013p:plain

もちろん、diskpartコマンドからも認識されていません。

f:id:ueponx:20200314133029p:plain

正常なUSBメモリであれば以下のように表示が行われています(使用したものの容量は小さいものを使っています)。

f:id:ueponx:20200314133043p:plain

RaspbianからUSBにアクセスしてみる

ディスク関連の復帰はLinuxベースOSのほうが一日の長があるというイメージなので、まずは認識されるかを試してみます。USBメモリをUSBポートに挿入して以下のコマンドを実行してみると

ディスクの認識状況の確認

~$ dmesg | tail 
[  378.779481] usbcore: registered new interface driver uas
[  379.757735] scsi 0:0:0:0: Direct-Access     SanDisk  Ultra Fit        1.00 PQ: 0 ANSI: 6
[  379.761108] sd 0:0:0:0: [sda] 60062500 512-byte logical blocks: (30.8 GB/28.6 GiB)
[  379.762056] sd 0:0:0:0: [sda] Write Protect is off
[  379.762074] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[  379.762874] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[  379.772853]  sda: sda1 sda2
[  379.776051] sd 0:0:0:0: [sda] Attached SCSI removable disk
[  379.789555] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  380.373915] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)

正常に認識されていたので壊れてはいなかったようです。ということは、何らかのパーティション設定、フォーマットの関係でWindows10からみえなくなっているということになります。となると、現在のパーティションを削除・再作成、フォーマットを行えば認識されるかなと思います。

では実際にやってみようと思います。こういう流れになるかなと思います(これではうまくいきませんw)。

うまく行かなかった作業

認識されているので、マウント情報を確認します。mountコマンドを実行するとこんな感じになっています。

マウント状態の確認

$ mount
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
(略)
/dev/sda1 on /media/pi/system-boot type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
/dev/sda2 on /media/pi/writable type ext4 (rw,nosuid,nodev,relatime,uhelper=udisks2)

USBメモリ/medhia/pi以下にマウントされていることがわかります。また今回のUSBメモリには2つのパーティションがあることもわかりました。 まずはパーティションの操作をするにはアンマウントする必要があるのでアンマウントしておきます。

マウント解除

$ umount /media/pi/writable 
$ umount /media/pi/system-boot
$ mount
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
(略)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)

ではfdsikコマンドを実行してパーティションの操作を行っていきます。fdisk上で【d】コマンドで存在するパーティションを削除します。今回は2つのパーティションがあったので2回行います。その後【n】コマンドで新しいパーティション作成しパーティション情報を書き込みます。

$ sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): d
Partition number (1,2, default 2): 

Partition 2 has been deleted.

Command (m for help): d   
Selected partition 1
Partition 1 has been deleted.

Command (m for help): n 
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 
First sector (2048-60062499, default 2048): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-60062499, default 60062499): 

Created a new partition 1 of type 'Linux' and of size 28.7 GiB.
Partition #1 contains a vfat signature.

Do you want to remove the signature? [Y]es/[N]o: y

The signature will be removed by a write command.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

作成した、今回作成したパーティション/dev/sda1になっています。 このパーティションfsck.vfatコマンドでフォーマットを行います。

$ sudo mkfs.vfat -v -c -F 32 /dev/sda1 
mkfs.fat 4.1 (2017-01-24)
/dev/sda1 has 64 heads and 32 sectors per track,
hidden sectors 0x0800;
logical sector size is 512,
using 0xf8 media descriptor, with 60060452 sectors;
drive number 0x80;
filesystem has 2 32-bit FATs and 32 sectors per cluster.
FAT size is 14688 sectors, and provides 1875970 clusters.
There are 32 reserved sectors.
Volume ID is 863ad85c, no volume label.
Searching for bad blocks 176480... 350304... 523744... 698080... 868192...  
(中略)
29340000... 29509728... 29680224... 29847824... 30018528...

USBメモリを抜き差しするとmount情報が変化しています。マウントポイントは/media/pi/863A-D85Cになっています。アクセスも正常できます。

$ mount
(中略)
/dev/sda1 on /media/pi/863A-D85C type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

X側からも以下の様に参照できます。

f:id:ueponx:20200314132928p:plain

では、WindowsPCへUSBメモリを挿入してみます。でも、Windows側からは認識が行われません。もちろんディスクの管理からも認識はおこなわれません。 なぜだ!

いろいろと調べてみた

Linuxではマウントできるのに、なぜWindowsでは認識できないのかググってみて以下をみつけました。

www.archlinux.site

このなかで

USBメモリをパーティショニングする際のHex codeは0700(Microsoft basic data)となる。MBRパーティショニングで使われるHex codeのb(W95 FAT32 (LBA))は使えない。

という部分がありました。どうもMBR形式ではなくGPT形式で行うのかなとおもいました。そこでGPT形式でfdiskを行う(?)gdiskをつかって作業を行ってみます。

gdiskコマンドを使った作業

先程のUSBメモリを挿入し、アンマウントを行います。

$ mount
(中略)
/dev/sda1 on /media/pi/863A-D85C type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
$ umount /media/pi/863A-D85C

gdiskを起動すると以下のように表示されます。

$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: damaged

Found valid MBR and corrupt GPT. Which do you want to use? (Using the
GPT MAY permit recovery of GPT data.)
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: 

表示をみると…

GPT: damaged

Found valid MBR and corrupt GPT. Which do you want to use? (Using the GPT MAY permit recovery of GPT data.)

お?GPTが破損しているようです。MBRも存在しているようですがこれは先程の作業によるものかなと思います。このUSBはクリアな状態に戻したいのでここでは【3】を入力します。

$ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.3

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: damaged

Found valid MBR and corrupt GPT. Which do you want to use? (Using the
GPT MAY permit recovery of GPT data.)
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer:  3

あとは新しいパーティションテーブルを作成して(【o】を入力)、そこに新しいパーティションを作成(【n】を入力)を行います。

(注意)新しいパーティションの作成時にHex codeの入力を求めれられるのでMicrosoft basic dataのIDである0700を入力します。 省略するとLinux filesystemである8300となるので注意しましょう。

無事に終了したらディスクにパーティションテーブルを書き込みを行います(【w】を入力)

Command (? for help): o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y

Command (? for help): n
Partition number (1-128, default 1): 
First sector (34-60062466, default = 2048) or {+-}size{KMGTP}: 
Last sector (2048-60062466, default = 60062466) or {+-}size{KMGTP}: 
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 0700
Changed type of partition to 'Microsoft basic data'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sda.
The operation has completed successfully.

あとはFAT32でフォーマットをかけます。この処理は先程と同じになります。

$ sudo mkfs.vfat -v -c -F 32 /dev/sda1 
mkfs.fat 4.1 (2017-01-24)
/dev/sda1 has 64 heads and 32 sectors per track,
hidden sectors 0x0800;
logical sector size is 512,
using 0xf8 media descriptor, with 60060419 sectors;
drive number 0x80;
filesystem has 2 32-bit FATs and 32 sectors per cluster.
FAT size is 14688 sectors, and provides 1875969 clusters.
There are 32 reserved sectors.
Volume ID is 07fc44b3, no volume label.
Searching for bad blocks 174432... 353632... 526688... 699744... 873568... 1046880... 
(中略)
29845344... 30014048... 

フォーマットが終わったら、USBを挿入し直してみます。マウント情報を確認します。今回は/media/pi/07FC-44B3としてマウントされています。

~$ mount
(中略)
/dev/sda1 on /media/pi/07FC-44B3 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Xからも認識されています。ここまでは先程と同じです。

f:id:ueponx:20200314151816p:plain

では、挿入してみます…あれ?だめ?

アプローチを変えて復帰

ここまでやっても駄目となると、流石に疲れてしまい、このUSBはLinuxだけで一致時的にデータを交換するものにしようかなと思い1ヶ月以上放置していました。ただ、心の底では、ちょっともったいないなあと思い再度復旧作業にチャレンジしてみました。

今回は、gdiskコマンドで1パーティションMicrosoft basic dataにしておきます。 この状態では、Windows側からは認識されない状態です。

本当にどこかの領域が壊れているのかもしれないかなと思って、fsckコマンドを実行してみました。

手順としては以下のようになります。

  1. USBメモリをアンマウント
  2. fsckコマンドを実行

するとあまり見慣れない以下のようなメッセージが表示されました。

0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.

ダーティビットがセットされているというものです。よくわからなかったのですが以下のエントリを参考に作業しました。

qiita.com

fsckコマンドは-w -rオプションを使用したほうがいいとのことです。

参考

www.raspberrypi.org

操作ログ

$ sudo umount /dev/sda*
umount: /dev/sda: not mounted.

 $ sudo fsck -w -r /dev/sda1
fsck from util-linux 2.33.1
fsck.fat 4.1 (2017-01-24)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Perform changes ? (y/n) y
/dev/sda1: 3 files, 4/1875864 clusters
/dev/sda1: status 1, rss 16352, real 7.745412, user 0.194318, sys 0.116591

ググってみたところ、Dirty bitとは次のようなもののようです。

Dirty bitとは…各ボリュームごとに備えられている特別なstatus bitで、ボリュームのマウント時にセットされ、OSの終了時のアンマウントでクリアされるもの。もしシステムが突然の障害や電源断、リセットなどにより、稼働途中で強制的に終了、再起動したりすると、Dirty bitはセットされたままになる。

障害の原因は突然の抜き差しや電源断のようなところでしょうか。…心当たりなくはない…

fsckコマンドでからの問い合わせで 1) Remove dirty bit を選択したところ、無事Windowsから認識されるようになりました。 Explorerからドライブが認識されている時点でかなり嬉しい!

f:id:ueponx:20200430132612p:plain

もちろんですがディスクの管理からも問題なく見えています。

f:id:ueponx:20200430132602p:plain

めでたしめでたし。

おわりに

fdiskなどでUSBメモリを初期化したら、今回のようなDirty bitも含めてクリアにされるのかなと思っていたのですが、クリアされてなかったのはちょっと驚きました。物理的に破壊している領域は無視できなくなるのかなとは予想していましたが、こんな事があるとは!という印象でした。 あと、fdiskmkfsといったコマンドを過去の知識でなんとなく行っていたりしたところもありましたが、それらの知識を新たにすることができましたのは良かったかなと思います。

/* -----codeの行番号----- */