☰

仮想ボックス上の Ubuntu 10.04 でエラーが発生します: ターゲット ファイルシステムに /sbin/init がありません \ init が見つかりません。init= bootarg を渡してみてください。

tag-icon • tag-icon linux ubuntu virtualbox
仮想ボックス上の Ubuntu 10.04 でエラーが発生します: ターゲット ファイルシステムに /sbin/init がありません \ init が見つかりません。init= bootarg を渡してみてください。

私は Linux 初心者ですが、これをインストールした唯一の理由は、Ruby on Rails との Windows 非互換性の問題を回避するためです。そうは言っても、これは確かに便利で、はるかに高速なので、当分の間 Winrails 関連の作業は行わないと思います。

そこで、VirtualBox を使用して仮想マシンを作成し、過去 3 週間、Ubuntu をインストールしました。最近、Ubuntu がいくつかの項目を更新できるかどうか尋ねてきたので、「OK」をクリックしました。

今は起動せず、次のエラーが表示されます: *mount: /dev を /root/dev にマウントできませんでした: そのようなファイルまたはディレクトリはありません mount: /sys を /root/sys にマウントできませんでした: そのようなファイルまたはディレクトリはありません ... ターゲット ファイルシステムに /sbin/init がありません。init が見つかりません。init= bootarg を渡してみてください

BusyBox v1.13.3...

(initramfs) _ *

そこでフォーラムを巡回したところ、さまざまな解決策がありましたが、それらはすべてライブ CD からの起動に関係していました。(これは、最初に Ubuntu をインストールするために使用した ISO イメージだと思います)。しかし、その CD から起動すると、Ubuntu 画面でハングし、小さなドットが白から赤に切り替わり続けますが、1 時間そこに留まったので、スタックしたと思います。何ができるのかわかりません。busybox シェル (またはそれ) から何かを実行して、問題を解決できますか?

問題は、すべての宝石などを使って必要なものをすべて揃えるのに約 10 時間かかったことです。また、調整した内容を書き留めていなかったし、私は中年なので、その情報はすべて漏れてしまっていて、もう一度やりたくありません。既存のインストールを修復したいです。

おそらく、ISO に何か問題があるのではないかという疑問が湧くでしょう。私は新しい仮想マシンを作成し、同じ ISO ファイルを使用して新しい Ubuntu をインストールしたので、そうではないと思います。

ご協力いただければ幸いです。

フィル

答え1

ブートローダーのプロンプトではすべて正常に見えます。そのため、ファイルシステムが破損しているのではないかと心配しています。

以下のプロセスを提案します。

  1. 新しい仮想マシンを作成し、Ubuntu を新規インストールします。
  2. パッケージをインストールしetckeeper、 を実行しますetckeeper init。これにより、 がバージョン管理下に置かれます/etc。Bazaar、Darcs、Git、Mercury の中でお気に入りのバージョン管理ツールがある場合は、 を/etc/etckeeper/etckeeper.conf実行する前にでそれを選択しますetckeeper commit。
  3. 変更内容は、/etcパッケージ管理タスクの前後、および 1 日に 1 回自動的にコミットされます。etckeeper commit基盤となるバージョン管理ツールを直接実行または呼び出すことで、手動でコミットできます。
  4. ここで、古い VM を保存してみましょう。新しい VM をシャットダウンし、古い VM のディスクを新しい VM に追加して、新しい VM を起動します。
  5. をマウントしてみてください/dev/sdb2。 を実行するように求められたらfsck、実行してください。
  6. 古い VM から可能なものを回復します。
  7. バックアップ設定には、のリポジトリ/etcと、VM内/usr/localおよびVM 内で実行するすべての操作を必ず含めてください。/home

答え2

私も似たような状況に遭遇しました。Ubuntu 10.10 ホストと Ubuntu 10.10 ゲストです。

ゲスト FS が破損し、上記と同じエラーが発生しました。

この問題は、vdi ファイルからパーティションをマウントし、これらに対してファイル チェックを実行することで解決されました。

sudo vdfuse -g -f /media/ssdext4/UbuntuGuest.vdi /mnt/

これで、「sudo ls -l /mnt/」を使用して、vdi ファイルからパーティションを一覧表示できるようになります。

次に、フルパスで FS チェックを実行します。sudo fsck.ext4 /mnt/Partition1

vdfuse はデフォルトのインストールの一部であるべきだと思います。vdfuse がなければ、これらの問題を解決する方法がわかりません。

答え3

最も複雑ではありませんが、おそらく最も迅速なアプローチです。壊れた VM のディスク イメージを新しくインストールした VM に追加し、そこからマウントし、$HOME、/etc、場合によっては /var/{lib,db, ...} から何かをコピーします (または少なくともコピーを保持します)。これで 1 時間以内に元の状態に戻ります。

実際の問題は、初期の RAM ディスクが仮想ディスク デバイスを適切に検出してマウントできないことによって引き起こされていると思います。そのため、壊れた VM のファイル システムに何らかの方法でアクセスできる場合は、次のようなことも試すことができます。

mount /dev/sdbroken1 /mnt/brokendisk
for i in dev dev/pts proc sys; do
  mount --bind /$i /mnt/brokendisk/$i
done
chroot /mnt/brokendisk
update-initramfs -u -k all # regenerate initial ramdisk - look for errors
^D
reboot

答え4

私もまったく同じ問題を抱えています。ライブ ISO での奇妙な動作も含まれます。

結局、問題はGRUBが何らかの理由でおかしくなっていることにあるようです。おそらくホストシステムがスリープ状態になっていることが原因でしょう。[Christis Bergelesさんが私と同じホスト（Mac OSX）で同じ問題を説明しているので、こう言います。[http://christos.bergeles.net/blog/files/tag-grub.html]

問題のある仮想 HD を別の動作中の Ubuntu VM に接続します。

そのVMを起動する

(次の 2 行は、この VM に問題のディスクが /dev/sdb にあることを前提としています)

sudo マウント /dev/sdb1 /mnt

sudo grub-install --root-directory=/mnt/ /dev/sda

私の場合は、この問題の 2 つの別々のインスタンスで機能しました。

ティム。

関連情報