どうしてこんなことになったのでしょうか？（前回の長い回答）

Question 1

Linux イメージを再インストールすることでマウントの問題を解決できました。

sudo apt-get install --reinstall linux-image-$(uname -r)

ところで、すべては VirtualBox のアップグレードから始まりました。双方向クリップボードが機能しなくなったので、Guest Additions ISO を再挿入しようとしました。これが上記の問題を引き起こしました。現在、Guest Additions はマウントし直されましたが、クリップボードはまだ機能しません...

Answer

Linux イメージを再インストールすることでマウントの問題を解決できました。

sudo apt-get install --reinstall linux-image-$(uname -r)

ところで、すべては VirtualBox のアップグレードから始まりました。双方向クリップボードが機能しなくなったので、Guest Additions ISO を再挿入しようとしました。これが上記の問題を引き起こしました。現在、Guest Additions はマウントし直されましたが、クリップボードはまだ機能しません...

Question 2

要約 これは再起動することですぐに修正できます。apt-getを使用しないでください一番下の「再起動するだけ」を参照してください。

どうしてこんなことになったのでしょうか？（前回の長い回答）

まさにこのような問題は、次のような場合に発生します。

カーネルをアップグレードする（例えば.66から.67へ）
を実行しapt-get autoremoveて何らかの方法で実行中のカーネルを削除するか、手動で「古い」カーネルを削除して、/lib/modules/kernel.66 からすべてのモジュールを削除します。
再起動しないので、「古い」.66カーネルが動作し続けます。ロードされたモジュールはメモリに残り、すべてが機能しますが、新しいモジュールをロードできません.66 モジュールは削除されました。
まだロードされていないモジュールをロードする必要がある操作を実行しようとする

VirtualBox ISO をインストールするには、まさにその作業、つまり ISO9660 サポートモジュールのロードが必要になる場合があります。

実行中のカーネル (.66) が /lib/modules/kernel.66 で何も見つけられないため、要求されたモジュールは自動ロードできなくなりました。モジュールが存在するただし、これは /lib/modules/kernel.67 にあり、現在の .66 カーネルはこれを認識しないため、一致しないモジュールをロードすることは推奨されません。

uname されたカーネルを再インストールすると、実行中のカーネルモジュールも再インストールされるため、../.66/.../isofs.ko が再び使用可能になり、再起動が不要になります。これはインストールされたカーネルのダウングレードであり、アップデートの問題は残ります。（以下を参照してください）。

つまり、追加CDを実行すると、ランニング.66カーネル、ない更新された .67 カーネル (まだ実行されていません)。

このような状況に陥った場合は、確かに再起動して修正します（新しい.67カーネルがモジュールを見つけます）。おそらく新しいカーネルに属するモジュールをロードすることで（isofsかなり安定しており、重要なカーネルアップグレードを行っていない限り、互換性が維持されます（これはまだ推奨されません!):

# mount /dev/cdrom /mnt
mount: unknown filesystem type 'iso9660'

上記は、発生している根本的なエラーです (「不明なファイルシステムタイプ」)。

# uname -a
Linux virtual 3.13.0-66-generic ...

そこで、インストールされているモジュールのバージョンを確認します。.66 である必要があります。

# ls /lib/modules
3.13.0-67-generic

...しかし、ディレクトリは 1 つしかなく、それは .67 です (.66 ディレクトリは存在するかもしれませんが、空です。この場合、du -sh /lib/modules/*さまざまなディレクトリによって占有されるスペースの量がわかり、空のディレクトリといっぱいのディレクトリを区別できます)。

再GRUBなしで古いカーネルイメージを再インストールしても、実際の問題は解決しません。

実行中のカーネルをモジュールとヘッダーとともに再インストールします。これで、grub新しいカーネルをロードするように設定された両方のカーネルが手に入ります。

ISO CD-ROM をマウントできます (モジュールが存在するため)。また、VBox モジュールはコンパイルされます (ヘッダーがインストールされているため)。

実行中の .66 カーネル用のモジュールがコンパイルされ、しばらくの間は動作します。

最初の再起動では、VirtualBox がまったく追加されていない .67 カーネルが使用されていることがわかります。

カーネルを再インストールしても、実際の問題は解決しない。

apt-get install --reinstall linux-image-$(uname -r)

上記のように、最初の再起動では、カーネルがダウングレードされた (または「アップグレードされていない」) 状態になります。すぐに、Ubuntu はカーネルのアップグレードを試行します... すると、開始状態に戻ります (下記「カーネルのダウングレード」を参照)。再起動して、Virtualbox Additions を再度インストールする必要があります。

ISOモジュールにパッチを当てても、実際の問題は解決されない。

カーネル 66 と 67 の間で作業は行われておらず、バイナリは基本的に変更されていないため、ISO9660 モジュールを強制的にロードできる可能性があります。そのため、次のように試します。

# insmod /lib/modules/3.13.0-67-generic/kernel/fs/isofs/isofs.ko

エラーはありません。うまくいきました。カーネル .66 がカーネル .67 からモジュールをロードしました。もう一度 CD-ROM をマウントしてみましょう。

# mount /dev/cdrom /mnt
mount: block device /dev/sr0 is write-protected, mounting read-only

やあ！うまくいったよ！

はい、しかし、これはまだ本当の助けにはなりません。なぜなら、インストールされるCDはVirtualBox Additionsであり、ランニングインストールするカーネルヘッダー。実行中のカーネルがモジュールもうそこにはいない、カーネルヘッダーもおそらくそのため、CD-ROM はマウントされますが、インストーラーは起動時に失敗します。

また、何らかの方法でヘッダーが見つかり、コンパイルが失敗しなかったとしても、.66 モジュールディレクトリがクリーンアップされているため、新しくコンパイルされた Virtualbox モジュールは保存される場所がありません (これが、isofsモジュールがそもそも見つからなかった理由です)。

しかし、以前のカーネルのモジュールとヘッダーディレクトリを復元することで、これらすべてを修正したとします。つまり、実質的には高価な（そして部分的な）カーネルダウングレードを行ったことになり、追加された部分は失った次回の再起動時に、.66 カーネルの残りとともに、新しくインストールされた .67 カーネルが起動します。.66 ヘッダー付きの .66 カーネルから起動された Virtualbox Additions CD は、.67 ではなく .66 カーネルモジュールを忠実にインストールしたためです。

カーネルをダウングレードすると、しばらくは機能します

もし私達取り除く.67 カーネルを削除し、代わりにモジュールを含む .66 カーネルを再インストールすると、しばらくは問題なく動作します。上記の「ISO モジュールの強制」ソリューションのように、再起動は必要ありません。

また、Additions の問題のあるカーネルはインストールされていないため、再起動しても何も失われません。

しかし、この方法ではカーネルは依然として「アップグレード対象」リストに残り、遅かれ早かれ同じ問題が発生することになります (自動更新の頻度に応じて、通常は翌日または翌週)。

付与された、より適切なタイミングでそれを発生させることができます、これはかなり価値があるかもしれません。遅れているプロジェクトのコーディングマラソンの途中での強制アップグレードは悪魔です。

つまり、再起動するだけです! (そして追加 CD を再実行します)。

再起動すると、すでにインストールされている最新の .67 カーネルがアクティブになり、そのすべてのモジュールとヘッダーが存在します。その中には、isofsISO9660 CD ファイルシステムを読み取るためのモジュールも含まれます。

 sudo reboot

再起動後、CD-ROM が動作し、Guest Additions がインストール可能になります。

VirtualBox で Additions を使用してカーネルを更新する「最善の」手順は次のとおりです。

 apt-get update
 apt-get upgrade              (or apt-get dist-upgrade)
 reboot                       
 (re)install VirtualBox Additions on the new kernel that is now running
 apt-get autoremove

(セキュリティ上の理由から、ユーザーが「戻る」ことができるように、最新から 2 番目の古いカーネルは自動的に削除されない可能性があります)。

Answer

要約 これは再起動することですぐに修正できます。apt-getを使用しないでください一番下の「再起動するだけ」を参照してください。

どうしてこんなことになったのでしょうか？（前回の長い回答）

まさにこのような問題は、次のような場合に発生します。

カーネルをアップグレードする（例えば.66から.67へ）
を実行しapt-get autoremoveて何らかの方法で実行中のカーネルを削除するか、手動で「古い」カーネルを削除して、/lib/modules/kernel.66 からすべてのモジュールを削除します。
再起動しないので、「古い」.66カーネルが動作し続けます。ロードされたモジュールはメモリに残り、すべてが機能しますが、新しいモジュールをロードできません.66 モジュールは削除されました。
まだロードされていないモジュールをロードする必要がある操作を実行しようとする

VirtualBox ISO をインストールするには、まさにその作業、つまり ISO9660 サポートモジュールのロードが必要になる場合があります。

実行中のカーネル (.66) が /lib/modules/kernel.66 で何も見つけられないため、要求されたモジュールは自動ロードできなくなりました。モジュールが存在するただし、これは /lib/modules/kernel.67 にあり、現在の .66 カーネルはこれを認識しないため、一致しないモジュールをロードすることは推奨されません。

uname されたカーネルを再インストールすると、実行中のカーネルモジュールも再インストールされるため、../.66/.../isofs.ko が再び使用可能になり、再起動が不要になります。これはインストールされたカーネルのダウングレードであり、アップデートの問題は残ります。（以下を参照してください）。

つまり、追加CDを実行すると、ランニング.66カーネル、ない更新された .67 カーネル (まだ実行されていません)。

このような状況に陥った場合は、確かに再起動して修正します（新しい.67カーネルがモジュールを見つけます）。おそらく新しいカーネルに属するモジュールをロードすることで（isofsかなり安定しており、重要なカーネルアップグレードを行っていない限り、互換性が維持されます（これはまだ推奨されません!):

# mount /dev/cdrom /mnt
mount: unknown filesystem type 'iso9660'

上記は、発生している根本的なエラーです (「不明なファイルシステムタイプ」)。

# uname -a
Linux virtual 3.13.0-66-generic ...

そこで、インストールされているモジュールのバージョンを確認します。.66 である必要があります。

# ls /lib/modules
3.13.0-67-generic

...しかし、ディレクトリは 1 つしかなく、それは .67 です (.66 ディレクトリは存在するかもしれませんが、空です。この場合、du -sh /lib/modules/*さまざまなディレクトリによって占有されるスペースの量がわかり、空のディレクトリといっぱいのディレクトリを区別できます)。

再GRUBなしで古いカーネルイメージを再インストールしても、実際の問題は解決しません。

実行中のカーネルをモジュールとヘッダーとともに再インストールします。これで、grub新しいカーネルをロードするように設定された両方のカーネルが手に入ります。

ISO CD-ROM をマウントできます (モジュールが存在するため)。また、VBox モジュールはコンパイルされます (ヘッダーがインストールされているため)。

実行中の .66 カーネル用のモジュールがコンパイルされ、しばらくの間は動作します。

最初の再起動では、VirtualBox がまったく追加されていない .67 カーネルが使用されていることがわかります。

カーネルを再インストールしても、実際の問題は解決しない。

apt-get install --reinstall linux-image-$(uname -r)

上記のように、最初の再起動では、カーネルがダウングレードされた (または「アップグレードされていない」) 状態になります。すぐに、Ubuntu はカーネルのアップグレードを試行します... すると、開始状態に戻ります (下記「カーネルのダウングレード」を参照)。再起動して、Virtualbox Additions を再度インストールする必要があります。

ISOモジュールにパッチを当てても、実際の問題は解決されない。

カーネル 66 と 67 の間で作業は行われておらず、バイナリは基本的に変更されていないため、ISO9660 モジュールを強制的にロードできる可能性があります。そのため、次のように試します。

# insmod /lib/modules/3.13.0-67-generic/kernel/fs/isofs/isofs.ko

エラーはありません。うまくいきました。カーネル .66 がカーネル .67 からモジュールをロードしました。もう一度 CD-ROM をマウントしてみましょう。

# mount /dev/cdrom /mnt
mount: block device /dev/sr0 is write-protected, mounting read-only

やあ！うまくいったよ！

はい、しかし、これはまだ本当の助けにはなりません。なぜなら、インストールされるCDはVirtualBox Additionsであり、ランニングインストールするカーネルヘッダー。実行中のカーネルがモジュールもうそこにはいない、カーネルヘッダーもおそらくそのため、CD-ROM はマウントされますが、インストーラーは起動時に失敗します。

また、何らかの方法でヘッダーが見つかり、コンパイルが失敗しなかったとしても、.66 モジュールディレクトリがクリーンアップされているため、新しくコンパイルされた Virtualbox モジュールは保存される場所がありません (これが、isofsモジュールがそもそも見つからなかった理由です)。

しかし、以前のカーネルのモジュールとヘッダーディレクトリを復元することで、これらすべてを修正したとします。つまり、実質的には高価な（そして部分的な）カーネルダウングレードを行ったことになり、追加された部分は失った次回の再起動時に、.66 カーネルの残りとともに、新しくインストールされた .67 カーネルが起動します。.66 ヘッダー付きの .66 カーネルから起動された Virtualbox Additions CD は、.67 ではなく .66 カーネルモジュールを忠実にインストールしたためです。

カーネルをダウングレードすると、しばらくは機能します

もし私達取り除く.67 カーネルを削除し、代わりにモジュールを含む .66 カーネルを再インストールすると、しばらくは問題なく動作します。上記の「ISO モジュールの強制」ソリューションのように、再起動は必要ありません。

また、Additions の問題のあるカーネルはインストールされていないため、再起動しても何も失われません。

しかし、この方法ではカーネルは依然として「アップグレード対象」リストに残り、遅かれ早かれ同じ問題が発生することになります (自動更新の頻度に応じて、通常は翌日または翌週)。

付与された、より適切なタイミングでそれを発生させることができます、これはかなり価値があるかもしれません。遅れているプロジェクトのコーディングマラソンの途中での強制アップグレードは悪魔です。

つまり、再起動するだけです! (そして追加 CD を再実行します)。

再起動すると、すでにインストールされている最新の .67 カーネルがアクティブになり、そのすべてのモジュールとヘッダーが存在します。その中には、isofsISO9660 CD ファイルシステムを読み取るためのモジュールも含まれます。

 sudo reboot

再起動後、CD-ROM が動作し、Guest Additions がインストール可能になります。

VirtualBox で Additions を使用してカーネルを更新する「最善の」手順は次のとおりです。

 apt-get update
 apt-get upgrade              (or apt-get dist-upgrade)
 reboot                       
 (re)install VirtualBox Additions on the new kernel that is now running
 apt-get autoremove

(セキュリティ上の理由から、ユーザーが「戻る」ことができるように、最新から 2 番目の古いカーネルは自動的に削除されない可能性があります)。

Question 3

他の人の回答によると、これは通常、再起動することで修正できます。

何らかの理由で「iso9660」モジュールがロードされません。depmodすべてのモジュールをスキャンし、モジュールの依存関係を作成します。

sudo depmod -a
sudo mount /dev/sr0 /mnt
ls -l /mnt

これによって問題は解決します。

Answer

他の人の回答によると、これは通常、再起動することで修正できます。

何らかの理由で「iso9660」モジュールがロードされません。depmodすべてのモジュールをスキャンし、モジュールの依存関係を作成します。

sudo depmod -a
sudo mount /dev/sr0 /mnt
ls -l /mnt

これによって問題は解決します。

Question 4

私はパッケージをアップグレードして再起動することでこれを解決しました（Ubuntu 16.04）。

sudo apt-get update
sudo apt-get upgrade
sudo reboot

Answer

私はパッケージをアップグレードして再起動することでこれを解決しました（Ubuntu 16.04）。

sudo apt-get update
sudo apt-get upgrade
sudo reboot

どうしてこんなことになったのでしょうか？（前回の長い回答）

答え1

答え2

どうしてこんなことになったのでしょうか？（前回の長い回答）

再GRUBなしで古いカーネルイメージを再インストールしても、実際の問題は解決しません。

カーネルを再インストールしても、実際の問題は解決しない。

ISOモジュールにパッチを当てても、実際の問題は解決されない。

カーネルをダウングレードすると、しばらくは機能します

つまり、再起動するだけです! (そして追加 CD を再実行します)。

答え3

答え4

関連情報