自動化されたVM作成システムの一部として、ブロックデバイスが一時フォルダー(/ tmp/whatever)にマウントされます。さまざまなスクリプトがVM最初の実行です。
最近何かが変更され、一時的なマウントがビジーで、アンマウントを拒否しています。ファイルを開いたままにしている可能性があるものを特定するために、私はチェックしました:
ルートとして実行されるテスト
上記のどのテストでもファイルシステムの使用を示す結果はありませんが、umount -fは「デバイスまたはリソースがビジーです」/「デバイスはビジーです」とまだ文句を言います。
真の根本原因に到達し、うまくいけば現在しばらく再起動できないシステムで再起動せずにスタックマウントを修正し、これが再発しないようにするには、他にどのようなテストを試すべきですか?
一時マウントにはホストが実行しているものとは異なるバージョンのLinuxがインストールされているため、一時マウントからのカーネルモジュールがロードされていることも/ doubtful /です(ただし、確認方法はわかりません)。
編集
ビルドプロセスの一部である場合は、いずれにしても再起動する必要があると思います。 「レイジー」アンマウントをプロセスに挿入してみてください。使用する umount -l /tmp
そして、それがプロセスのこの障壁を乗り越えるのに役立つかどうかを確認してください。
まったく同じ問題が発生しましたが、仮想マシンのルートファイルシステムがext4である場合にのみ発生するようです。 ext3は正しく動作します。奇妙に聞こえるかもしれませんが、 http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ で説明されているカーネルのバグかもしれません
その場合は、カーネルパッチを待つ必要がありますOR新しいvmをメインマシンにインストールしないでください。仮想マシンとして実行されている一時的なlinuxからのインストールは、マシンを再起動せずに再起動するため、正しく動作します。メインマシン。
Ext3を試しましたか?そうでない場合は、ext3にインストールしてみてください。ext4の使用が重要な場合は、後でext4に変換できます(そして、それは http://www.debian-administration.org/article/643/Migrating_a_live_system_from_ext3_to_ext4_filesystem で説明されています)。
umount
が失敗する理由の1つは、リモートデバイスの基になるIPアドレスが変更された場合です。
これは、デスクトップサーバーからラップトップをリモートマウントしたときに発生します。最初のマウントはIPアドレスAで行われます。ラップトップを再起動するとアドレスBが与えられますが、デスクトップでは引き続きアドレスAをラップトップのアドレスとして記録しています。これは、mount
コマンドによって返されたIPアドレスを調べて、ラップトップの現在のアドレスと比較するとわかります。
umount -l
を使用してマウントを解除できました