さまざまな内部SATAドライブを使用してUbuntu 18.04をインストールしました。そんなある日、単純停電が発生しました。問題ありません。私たちは前にこのようなことを経験しました。電源が再投入された後、サーバーはSSHに応答しませんでした。時には地下室に行き、箱のボタンを押して再びオンにする必要がありました。これをしましたが、数分経ってもまだSSHを介してアクセスできません。
今私はボックスに接続された小さなモニターとキーボードを持って地下室にいます。再起動後、長い間Ubuntuのロゴが表示され、キーを押して⬆ブートローダを表示するとタイムアウトしたようです。時間はこんな感じです。
A start job is running for dev-disk-by\x2duuid-914d3b77\x2d06c4\x2d4514\x2d8fee\x2d1fc6eb81bbd9.device (51s / 1min 30s)
実際、序盤に2つのエラーがありましたが、どちらも1分30秒が経過するとタイムアウトになるようです。別のタイムアウトブート操作がUUID=a158e6ec-1433-454c-9cd2-10f7306fde82。/etc/fstab
1時30分後にEnterキーを押してrootコマンドプロンプトに入り、実行し、vim /etc/fstab2つのエラーに対応する行をコメントアウトしたので、ファイルは次のようになります。
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda2 during installation
UUID=6f90b496-401e-475f-add0-3c6d3bcae7a0 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=BFE0-55D4 /boot/efi vfat umask=0077 0 1
/swapfile none swap sw 0 0
UUID=bc731122-7e4e-47d9-b6a5-db1f703f96a8 /media/Tre ext4 defaults 0 0
UUID=6c7b175d-b80b-4069-bbbe-f82aeb302200 /media/Sam ext4 defaults 0 0
#UUID=a158e6ec-1433-454c-9cd2-10f7306fde82 /media/Hex ext4 defaults 0 0
#UUID=914d3b77-06c4-4514-8fee-1fc6eb81bbd9 /media/Wes ext4 defaults 0 0
ファイルを保存した後、rebootUbuntuを実行してすぐに再起動しました。表示されずにログイン画面に移動します。私は暗い地下室のサーバーのクローゼットから這い、ソファからSSHを介して戻ってきました。
blkid私はWesと呼ばれるドライブのUUIDが私が持っていたUUIDとは異なるように見えることを使用して発見しました/etc/fstab。そのため、バックアップを作成し、UUIDをその行のUUIDとして編集し、その行blkidのコメントを削除しました。もう一つreboot、今Wesが戻ってきました。今、私はHexと呼ばれる大きな6TBドライブがなくなりました。私の/etc/fstab外観は次のとおりです。
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda2 during installation
UUID=6f90b496-401e-475f-add0-3c6d3bcae7a0 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=BFE0-55D4 /boot/efi vfat umask=0077 0 1
/swapfile none swap sw 0 0
UUID=bc731122-7e4e-47d9-b6a5-db1f703f96a8 /media/Tre ext4 defaults 0 0
UUID=6c7b175d-b80b-4069-bbbe-f82aeb302200 /media/Sam ext4 defaults 0 0
#UUID=a158e6ec-1433-454c-9cd2-10f7306fde82 /media/Hex ext4 defaults 0 0
UUID=bc731122-7e4e-47d9-b6a5-db1f703f96a8 /media/Wes ext4 defaults 0 0
Hex行のコメントを外すと、同じ操作が1:30にタイムアウトするのを待つ無限ループに陥ります。ログを見てjournalctl -xe問題があると思われる場所に移動すると、次の赤いエラーが表示されます。
zen systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-a158e6ec\x2d1433\x2d454c\x2d9cd2\x2d10f7306fde82.device
これは同じ16進ドライブに対応しているようです。
ドライブが破損するのではないかと心配して、ワードローブから箱を取り出して開いて、特定のハードドライブを取り外しました。私はそれを机に持ってきて、SATA-USBポートに接続して電源を供給しました。ドライブが回転し始め、それをMacノートブックに接続しました。ディスクユーティリティを開くと、ハードドライブが表示されますが、容量は1.8TBにすぎず、パーティションも表示できません。
6TBドライブをフォーマットするために特別な措置を取らなければならなかった記憶があるようで、この部分が正しいかもしれませんが、もしかしてMacが見えないかもしれませんか？とにかく、私はドライブを見てインスピレーションを得てサーバーに戻すことにしました。
もっと読んでもっと検索しましたが、このサイクルに閉じ込められました。エントリをコメントアウトし、/etc/fstabシステムにSSHを適用するか、コメントを解除して中断を再開できます。入ると最上位フォルダとファイルがいくつか見えますがcd、/media/Hex広いほとんどのファイル構造が消えたり見えないようです。
Hexを通常に戻す方法は？
答え1
defaultsオプションをnoauto,x-systemd.automount次に置き換えます/etc/fstab。
UUID=a158e6ec-1433-454c-9cd2-10f7306fde82 /media/Hex ext4 noauto,x-systemd.automount 0 0
Archlinux Wikiから：systemdを使用した自動マウント
パーティションが大きい場合、fsck が確認するときにそれに依存しないサービスを開始できるようにする方が効率的です。これは、パーティションの/etc/fstabエントリに次のオプションを追加することで実現できます。
noauto,x-systemd.automountこれは最初のアクセス時にパーティションをfsckしてマウントし、カーネルは準備ができるまですべてのファイルアクセスをバッファリングします。たとえば、/home パーティションが非常に大きい場合、この方法が適している可能性があります。
答え2
最良のシナリオ：システムは単にファイルシステムに対してログ回復および/またはファイルシステムチェックを実行しようとしますが、ファイルHexシステムが大きすぎるため、1分30秒以上かかります。この場合、システムの残りの部分が起動した後にファイルシステムチェックを手動で実行するのが最善です。以下の指示を参照してください。
最悪のシナリオ：ハードウェアレベルでディスクエラーが発生する可能性があります。
注釈付きの行を含む一部のファイルとフォルダが/media/Hex表示され、/etc/fstab手動でマウントされていない場合は、一部のプログラムがマウントポイントと見なされる空のディレクトリに書き込まれ、Hex実際のHexファイルシステムが削除されました。これは物理ファイルシステムのファイル状態とは何の関係もありませんが、ファイルシステムの現在の問題が解決されると、Hex物理ファイルシステムに再マージするのは少し難しいかもしれません。Hex
今、その行をコメントアウトしてください/etc/fstab。Hexシステムが稼働してHexシステムに接続したら、blkid以前のようにコマンドを使用してHex現在のデバイス名を識別します。これを知ったら、さらに診断を開始できます。
ファイルシステムを含むデバイス（ここでHexの名前は、ファイルシステムがディスクデバイス全体に直接存在することを報告します。）/dev/sdX1/dev/sdXblkid/dev/sdX
良い最初のステップは実行することですsudo smartctl -H -a -f brief -l error /dev/sdX。つまり、ディスクの全体的な状態、SMART属性、およびディスク自体によって書き込まれた可能性があるハードウェアレベルのエラーを報告する必要があります。ハードウェアレベルでディスクが正常であることを示す場合は、続行できます。 （結果を解釈する方法がわからない場合は、元の質問を編集して結果を追加してください。）
ディスクにハードウェア障害が表示された場合は、決定を下す必要があります。エラーが発生したディスクに機密データが含まれている場合は、自分で修理しようとするのをやめ、ディスクをデータ復旧の専門家に送信することをお勧めします。プロフェッショナルな回復には多少の費用がかかりますが、データを正常に回復する可能性は最も高いです。このタスクを実行することを選択した場合は、ディスクに追加のタスクを直接実行しないでください。ディスクに物理的に障害が発生した場合、ディスクの電源を入れると問題が悪化し、回復が困難になる可能性があります。
ハードウェアレベルでディスクに問題がない場合、またはディスク上のデータが「プロフェッショナルなリカバリコストを要する価値はありませんが、持っていればよいでしょう」の場合、次のステップはパーティションに何が起こっているのかを理解することです。 6TBディスクと言われたので、おそらくGPTパーティショニングを使用しているでしょう。次のいずれかのコマンドでパーティションのレイアウトを表示する必要があります。
sudo parted /dev/sdX print
sudo gdisk -l /dev/sdX
sudo fdisk -l /dev/sdX
（私はUbuntu 18.04がGPTパーティションを理解するのに十分新しいものだと思いますfdiskが、他のコマンドが6TB全体を表示している間に1.8TBパーティションのようなものを報告した場合、それはおそらく実際の問題ではありません。）
このパーティション情報を追加するには、元の質問を編集します。次のステップは、これらの検査の結果によって異なります。
ddrescueディスクにSMARTエラーマークがある場合は、次のステップは同じサイズまたはより大きいサイズの新しいディスクを購入し、同様のツールを使用してできるだけ早く内容全体を新しいディスクにコピーすることです。これが完了すると、データは悪化しなくなります。
ディスクのSMART診断が正常であり、ファイルシステムが認識された場合は、準備を続ける前にディスクを新しいディスクに複製することをお勧めします。その後、ファイルシステムに次の内容が含まれていると報告するデバイスでファイルシステムチェックを実行できますsudo fsck.ext4 -f -C0 /dev/sdX1。大容量ディスクでは、これにはかなり時間がかかることがあります。この-C0オプションは、ファイルシステムチェッカーが実行中に完了率を提供するように指示します。
ファイルシステムの検査が成功した場合、次のステップは手動でマウントを試みることです。たとえば、ファイルがビジーであるとマークされsudo mount /dev/sdX1 /media/Hexている場合は、インストールを実行するときにそのマウントポイントを使用している可能性があるすべてのサービスを停止する必要があります。/media/Hex/media/Hex
インストール後に正常に見える場合は、安堵の/media/Hexため息をつき、手動で削除し（sudo umount /media/Hex）、その行のコメントを/etc/fstab外した後、システムを再起動できます。これでファイルシステムがスキャンされ、完全にアンマウントされたため、正常に再起動する必要があります。
実際のファイルシステム（現在は実際のファイルシステム「下」に隠されています）をマウントした後、マウントポイントディレクトリに残っているすべてのファイルをクリーンアップするには、次のようにしますHex。Hex
sudo mkdir /mnt/Hex_oops
sudo mount --bind / /mnt/Hex_oops
cd /mnt/Hex_oops/media/Hex
...その後、その中のファイルとディレクトリが/mnt/Hex_oops/media/Hex重要であることを確認してください。その場合は、Hex実際のファイルシステムの正しい場所に移動できます。一部のアプリケーションで自動的に作成された空のディレクトリの場合は、削除できます（ルートファイルシステムで無駄にスペースを取るため）。次に、この一時配列を削除します。
cd /
sudo umount /mnt/Hex_oops
sudo rmdir /mnt/Hex_oops