さまざまな内部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 パーティションが非常に大きい場合、この方法が適している可能性があります。