suでルートにログインできない。共有ライブラリを一部削除したため

Question

###前提・実現したいこと

• suコマンドでルートにログインできるようにする方法を捜しています。
• 直前に共有ライブラリを削除してしまっていました。
• 気づかずにrootからログアウトしてしまいました。
• 削除したのはたぶん/lib64/libc.so.6です。
• ルートでログインしてしまえば、ldconfigコマンドで共有ライブラリの修正もできる認識です。

###発生している問題・エラーメッセージ

su -
su: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

###対応してみた内容

cp /lib64/libc-2.12.so /var/tmp/
cp /var/tmp/libc-2.12.so libc.so.6

export=LD_LIBRARY_PATH=/var/tmp/:/var/tmp/:/bin/:/lib64/:/usr/local/lib64/:/usr/lib64/:/usr/local/lib:/usr/lib:$LD_LIBRARY_PATH

export LD_PRELOAD=/var/tmp/libc.so.6:/lib64/libpam_misc.so.0:/lib64/ld-linux-x86-64.so.2:/lib64/libaudit.so.1:/lib64/libdl.so.2:/lib64/libcrypt.so.1:/lib64/libfreebl3.so:$LD_PRELOAD

※ これでlsコマンドやdirコマンドなどが復活しました。

※ しかし下記のように、問題は解決されませんでした。

su -
su: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

###補足情報(言語/FW/ツール等のバージョンなど)

• CentOS 5
• Red Hat 4.4.7-11

###追記事項（すみません書き漏れてました）

• Google Compute Engineを利用しています。
• sshの設定で、直接rootでログインできないように設定してあります。

Answer 1

su 出来ない事への回答ではありません。

＞一つ目のVMのドライブにchroot
これはKVMなどの仮想環境で使われるテクニックで、
(何でも良いので)仮想イメージを作成し、起動しなくなったイメージファイルをマウントさせます。
その後、chrootでマウントさせたパスを/として動作させ復旧させる方法です。

chroot は(端折った説明をすれば)特定のパスを/として動作させるときなどに使用出来ます。

例えば、壊れたイメージが /mnt/broken_image などにマウントされれているとします。
このとき
$ chroot /mnt/broken_image
とすれば、/mnt/broken_image のパスが / として表示され、
その後の編集が楽になります。
(例えば壊れたイメージの /etc/sysconfig/network-scripts/ifcfg-eth0を編集したい場合、
本来であれば /mnt/broken_image/etc/sysconfig/network-scripts/ifcfg-eth0 ですが
chroot すれば、そのまま/etc/sysconfig/network-scripts/ifcfg-eth0を編集すればいいのです)

ところで、sudo も駄目なのでしょうか？
sudo bash
ですとか。

Answer 2

シングルユーザーモードで起動できないんでしょうか？

手元の32bit版CentOS 5だと、/lib/libc.so.6 は /lib/libc-2.5.so のシンボリックリンクです。

---

追記です。
ググって見ましたが、こんなのが出てました。

If you ever mess up your VM and you can't access the machine anymore you would
create a second VM and attach the drives of your first VM to the second
and chroot into the drives of your first VM.

（意訳）
もし、VMを台無しにしてどこからもアクセスできなくなったら、二つ目のVMを作って、一つ目のVMのドライブを二つ目にアタッチし、一つ目のVMのドライブにchrootすればいい。

これは、ネットワークが起動しなくなっちゃった人へのアドバイスとして書かれてましたが、同じような状況ではないでしょうか。

Comments

[shimeru]

すみません、記載するべきだったのですが、
Google Compute Engineを使っているため、
シングルユーザモードでは起動できないのではないかと思います。

[shimeru]

すみません

＞一つ目のVMのドライブにchroot

というのは、どういうことでしょうか？

[shi_ue]

原文にそう書いてある、というだけで、どういう意味だかは…
cd、って意味ですかね？

[mint.cherry]

かなり自信はないですm(__)m汗
> 手元の32bit版CentOS 5だと、/lib/libc.so.6 は /lib/libc-2.5.so のシンボリックリンクです。
シンボリックリンクならシンボリックリンクでそのまま作ってあげればいいと思いますが…

googleさんのクラウドですよね。
VMを私はgoogleさんの仮想インスタンスと捉えます。
shi_ueさんの投稿してくれた英文を見ました。
英語文は得意ではないですが私からしてみると以下のように解釈します。
VM（インスタンス（以降、新VMと呼びます））をもう一台契約して、もとからあるインスタンス（以降、旧VMと呼びます。）を新VMに加える。（新VMのどこかのディレクトリが旧VMのrootディレクトリ以下すべてまんまコピーされる状態です。）
chrootとは特定のディレクトリをrootディレクトリとして扱えるようにできる機能です。簡単に言うと新VMと旧VMを合体させて、旧VMのほうをchrootとして扱えばいいということです。たぶんもう一つインスタンスを立てるにはお金が必須になってきます。googleさんの仕様によりますが…

お金もかかるし、そんなことしなくても、まだいい方法があると思います。
スナップショットとかとっていないのでしょうか？

追記＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
` 簡単に言うと新VMと旧VMを合体させて、旧VMのほうをchrootとして扱えばいいということです。 `
と言いましたが、chrootの仕様を少し詳しく知る必要があります。私はあまり知りませんm(__)m汗
/lib/libc.so.6 など新VMではなく旧VMのほうを参照されてしまったらまた同じエラーが出てきて変わりません。