CentOS
さくらVPS
glibc
TensorFlow

さくらVPSのCentOSがKernel panicで起動しなくなった場合の復旧方法

表題の状況にそもそも陥る人はあまりいないかもしれません。
もしそうなったらCentOSのRescueModeというので復旧できます。

私の場合、さくらVPSのCentOS6(6.7)で無理矢理glibcの2.17動かそうとしたら、sshログインもsftp接続もできなくなり、OSを落としたらKernel panicで起動しなくなりました。
VNCコンソールでこういう画面になるやつです

Kernel panic - not syncing : Attempted to kill init!
Pid: 1, comm: init Not tainted 2.6.32-504.3.3.el6.x86_64 #1
Call Trace:
[<ffffffff81529277>] ? panic+0xa7/0x16f
[<ffffffff8107a5f2>] ? do_exit+0x862/0x870
[<ffffffff8107a658>] ? dp_group_exit+0x58/0xd0
[<ffffffff8107a6e7>] ? sys_exit_group+0x17/0x20
[<ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b

サポートに問い合わせて「root権限渡しているんで」というテンプレ回答だった場合などは
下記方法を試して頂けると復旧できるかもしれません。

レスキューモードで起動

さくらのコントロールパネルにログイン->各種設定->OSインストール->centos6 x86_64->VNCコンソールを起動->Rescue installed system
->choose language "English" ->Keyboard type "jp106" -> Setup networking "NO"
->Continue -> shell Start shell

これで/mnt/sysimage以下にディスクをマウントした状態になりました。
つまり、/root/は今は/mnt/sysimage/rootになっている状態という事です。
そして、viコマンド等、色々なコマンドが使えるようになってます。

原因箇所を修正

(私の場合はetc/ld.so.confを修正しました
修正上書き

$: vi /mnt/sysimage/etc/ld.so.conf

キャッシュファイルが残っているのを確認

$: ls /mnt/sysimage/etc | grep ld.so.cach

キャッシュファイル削除

$: rm /mnt/sysimage/etc/ld.so.cache

レスキューモードから抜ける

原因箇所を修正したら、ディスクのマウントを解除して、OS再起動します。

$: exit

そして
reboot Reboot -> Boot from local driver

これで正常にOSが起動するはずです

そもそもやろうとした事

https://qiita.com/Wanwannodao/items/42c93686e49498c43529
これのLD_LIBRARY_PATH指定がすごく長くて嫌だったので、http://www.8wave.net/ldconfig.html
このページみたいに/etc/ld.so.confにglibcへのpassを通してldconfig叩いちゃいました。

なので余計なことしないで、pyenv、anaconda環境でこのページ通りにやってみたのですが、下記エラーでtensorflow動きませんでした...

relocation error: /tmp/libc6_2.17/lib64/libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference

どなたかわかる方いらっしゃいましたら教えてくださいmm
基本、CentOS7に上げて使えって話なんですけどね...