260

インスタンスが正常に起動しない時には他のインスタンスでディスク修復：GCP

サーバー

Google Cloud Platform上の コンピュートエンジンのインスタンス、LinuxサーバーをWebmin から、約60のソフトウェアのアップデートをしようとしたら、新カーネルのインストールに失敗。

理由は、/boot のディスク容量不足。

そこでSSHでログインし、 /boot にあったファイルを一覧する。

 

dr-xr-xr-x.  6 root root     4096  5月  8 11:20 .
dr-xr-xr-x. 20 root root     4096  4月 22 21:39 ..
-rw-r--r--   1 root root      171  8月 15  2018 .vmlinuz-3.10.0-862.11.6.el7.x86_64.hmac
-rw-r--r--   1 root root      171  9月 26  2018 .vmlinuz-3.10.0-862.14.4.el7.x86_64.hmac
-rw-r--r--   1 root root      170  6月 26  2018 .vmlinuz-3.10.0-862.6.3.el7.x86_64.hmac
-rw-r--r--   1 root root      170  7月 16  2018 .vmlinuz-3.10.0-862.9.1.el7.x86_64.hmac
-rw-r--r--   1 root root      170  2月  1 21:58 .vmlinuz-3.10.0-957.5.1.el7.x86_64.hmac
-rw-------   1 root root 20029603  4月 16 21:38 CloudEndure-Migration-initramfs-0-rescue-347d59c6807f4fdbb0a47726d8396d96.img
-rw-------   1 root root 20030387  4月 16 21:41 CloudEndure-Migration-initramfs-0-rescue-6eed10dce8a4469390fb949a6f350aa6.img
-rw-------   1 root root 21051488  4月 16 21:40 CloudEndure-Migration-initramfs-3.10.0-862.11.6.el7.x86_64.img
-rw-------   1 root root 21050593  4月 16 21:38 CloudEndure-Migration-initramfs-3.10.0-862.14.4.el7.x86_64.img
-rw-------   1 root root 21055275  4月 16 21:39 CloudEndure-Migration-initramfs-3.10.0-862.6.3.el7.x86_64.img
-rw-------   1 root root 21051537  4月 16 21:40 CloudEndure-Migration-initramfs-3.10.0-862.9.1.el7.x86_64.img
-rw-------   1 root root 21053329  4月 16 22:01 CloudEndure-Migration-initramfs-3.10.0-957.5.1.el7.x86_64.img
-rw-------   1 root root  3414344  8月 15  2018 System.map-3.10.0-862.11.6.el7.x86_64
-rw-------   1 root root  3414754  9月 26  2018 System.map-3.10.0-862.14.4.el7.x86_64
-rw-------   1 root root  3412056  6月 26  2018 System.map-3.10.0-862.6.3.el7.x86_64
-rw-------   1 root root  3412056  7月 16  2018 System.map-3.10.0-862.9.1.el7.x86_64
-rw-------   1 root root  3544044  2月  1 21:58 System.map-3.10.0-957.5.1.el7.x86_64
drwxr-xr-x   2 root root      148 10月 19  2018 ce_conversion
-rw-r--r--   1 root root   147859  8月 15  2018 config-3.10.0-862.11.6.el7.x86_64
-rw-r--r--   1 root root   147859  9月 26  2018 config-3.10.0-862.14.4.el7.x86_64
-rw-r--r--   1 root root   147837  6月 26  2018 config-3.10.0-862.6.3.el7.x86_64
-rw-r--r--   1 root root   147837  7月 16  2018 config-3.10.0-862.9.1.el7.x86_64
-rw-r--r--   1 root root   151922  2月  1 21:58 config-3.10.0-957.5.1.el7.x86_64
drwxr-xr-x   3 root root       16 11月 30  2017 efi
drwxr-xr-x.  2 root root       26 10月 10  2015 grub
drwx------.  5 root root     4096  4月 16 21:21 grub2
-rw-------   1 root root 20029497  4月 16 18:51 initramfs-0-rescue-347d59c6807f4fdbb0a47726d8396d96.img
-rw-------   1 root root 20029721  4月 16 18:57 initramfs-0-rescue-6eed10dce8a4469390fb949a6f350aa6.img
-rw-------   1 root root 20421090  1月 10  2018 initramfs-3.10.0-514.26.1.el7.x86_64.img
-rw-------   1 root root 20420723  1月 10  2018 initramfs-3.10.0-514.26.2.el7.x86_64.img
-rw-------   1 root root 20190848  1月 10  2018 initramfs-3.10.0-693.11.1.el7.x86_64.img
-rw-------   1 root root 20189513  1月 10  2018 initramfs-3.10.0-693.5.2.el7.x86_64.img
-rw-------   1 root root 21051104  4月 16 18:55 initramfs-3.10.0-862.11.6.el7.x86_64.img
-rw-------   1 root root 21050403  4月 16 18:51 initramfs-3.10.0-862.14.4.el7.x86_64.img
-rw-------   1 root root 13095125  2月  9 17:30 initramfs-3.10.0-862.14.4.el7.x86_64kdump.img
-rw-------   1 root root 21053641  4月 16 18:53 initramfs-3.10.0-862.6.3.el7.x86_64.img
-rw-------   1 root root 21052426  4月 16 18:57 initramfs-3.10.0-862.9.1.el7.x86_64.img
-rw-------   1 root root 12990853  7月 29  2018 initramfs-3.10.0-862.9.1.el7.x86_64kdump.img
-rw-------   1 root root 21053446  4月 16 21:05 initramfs-3.10.0-957.5.1.el7.x86_64.img
-rw-------   1 root root 13099782  4月 16 21:27 initramfs-3.10.0-957.5.1.el7.x86_64kdump.img
-rw-r--r--.  1 root root   611544 11月 30  2017 initrd-plymouth.img
-rwxr-xr-x   1 root root  6398144 10月 19  2018 vmlinuz-0-rescue-6eed10dce8a4469390fb949a6f350aa6
-rwxr-xr-x   1 root root  6398144  9月 26  2018 vmlinuz-3.10.0-862.14.4.el7.x86_64
-rwxr-xr-x   1 root root  6234048  7月 16  2018 vmlinuz-3.10.0-862.9.1.el7.x86_64
-rwxr-xr-x   1 root root  6643904  2月  1 21:58 vmlinuz-3.10.0-957.5.1.el7.x86_64

溜まっていた古いバージョンのファイルを削除しようとしたら、誤って全部削除してしまった。

CloudEndure* 関連を全部削除するつもりで、

rm -rf  CloudEndure*

とコマンドするつもりが、 CloudEndure と ＊の間に空白が空いてしまい、

rm -rf CloudEndure *

とやってしまった。

痛恨の一撃であった。

一瞬で全てのファイルが消えてしまった。

とりあえずそこに存在していたファイル名一覧のコピーメモをしておいた。

どうせ今から新しいカーネルをインストールするのだから、それでいいのかも、とアップデートを進めてみた。

無事に全てのアップデートが終わって、カーネルも最新バージョンがインストールされていた。

/boot はこんな状態になった。

dr-xr-xr-x.  2 root root     4096 May  8 04:32 .
drwxr-xr-x  23 root root     4096 May  8 08:33 ..
-rw-r--r--   1 root root   151923 Apr 29 15:03 config-3.10.0-957.12.1.el7.x86_64
-rw-------   1 root root 59103128 May  8 04:32 initramfs-0-rescue-6eed10dce8a4469390fb949a6f350aa6.img
-rw-------   1 root root 20791748 May  8 04:30 initramfs-3.10.0-957.12.1.el7.x86_64.img
-rw-r--r--   1 root root   314089 Apr 29 15:03 symvers-3.10.0-957.12.1.el7.x86_64.gz
-rw-------   1 root root  3544552 Apr 29 15:03 System.map-3.10.0-957.12.1.el7.x86_64
-rwxr-xr-x   1 root root  6643904 May  8 04:32 vmlinuz-0-rescue-6eed10dce8a4469390fb949a6f350aa6
-rw-r--r--   1 root root      171 Aug 14  2018 .vmlinuz-3.10.0-862.11.6.el7.x86_64.hmac
-rw-r--r--   1 root root      171 Sep 26  2018 .vmlinuz-3.10.0-862.14.4.el7.x86_64.hmac
-rw-r--r--   1 root root      170 Jul 16  2018 .vmlinuz-3.10.0-862.9.1.el7.x86_64.hmac
-rwxr-xr-x   1 root root  6643904 Apr 29 15:03 vmlinuz-3.10.0-957.12.1.el7.x86_64
-rw-r--r--   1 root root      171 Apr 29 15:03 .vmlinuz-3.10.0-957.12.1.el7.x86_64.hmac
-rw-r--r--   1 root root      170 Feb  1 14:58 .vmlinuz-3.10.0-957.5.1.el7.x86_64.hmac

しかし、しばらくして、ウェブサイトにアクセスできない、SSHでもアクセスできない、GCPのWEBコンソールからもアクセスできないという状態に陥ってしまった。

再起動しても同じ。

コンソール上では起動している状態になっているが、SSHでもアクセスできない。

Ping も届かない、反応しない。

 

やはり /boot 内の必要ファイルが紛失してしまっていて、正常に起動していないものと推測された。

よくみると、もともとあった、

drwxr-xr-x   3 root root       16 11月 30  2017 efi
drwxr-xr-x.  2 root root       26 10月 10  2015 grub
drwx------.  5 root root     4096  4月 16 21:21 grub2

のフォルダーが足りない。

そこで、移転して20日ばかりの旧サーバーを起動して、同じようにアップデートして最新状態にして比較する。

更新日付順に一覧すると、grub2 フォルダーが最新カーネルファイルと同じく日付更新されていたから、これだけが必要だとわかる。

 

これを如何にしてコピーし、SSHでは接続できないインスタンスの起動ディスクの/boot にコピーすればよいのか？

 

他のLinux インスタンスを起動させて、トラブル中のインスタンスのディスクをマウントして読み込み、書き込めればよいのだ。

 

そのためにはまず、トラブル中のインスタンスからディスクを接続解除する。

そして、Google に用意されている debug-instance を起動する。

そしてdebug-instance にトラブル中のディスクを接続マウントすれば良い。

General tips for using Compute Engine  |  Compute Engine Documentation  |  Google Cloud
Google Cloud
 
https://cloud.google.com/compute/docs/troubleshooting

または、「ディスクを新しいインスタンスで使用する」でもよいだろう。

 

GCP のWEBコンソール上で debug-instance にSSH接続するのだが、

ファイルの転送、アップロードができなかった。できたように見えるがどこを探しても見つからなかった。

そこで、旧サーバーにSSH接続ログインできるようにした後、SCPで目的の圧縮ファイル grub2.tar.gz をコピー移植することに成功した。

 

後はまた、この修復したディスクから新しいインスタンスを作成し、起動すると復活できた。

あらためてファイヤーウォール等を再設定し直す必要だある。

登録していた固定IPは、そのまま残っていたので、IPアドレスの変更はなかった。

 

ダウン時間は5時間ぐらいだった。

 

無料 Google Compute Engine に ConoHa から丸ごと移転する方法
チャージ不足でサーバー停止50時間ConoHa のチャージ残高が尽きていて、サーバーを止められていたのに気づいたのが1月5日の夜中だった。300円チャージしたのが6日の朝7時で復活した。停止したのは4日の0時過ぎだから、50時間以上のダウンタイムとなった。4日の0時といえば、Poon Hill トレッキング中で、ゴレパニの宿で深い睡眠中であった。ポカラに着いた夜に気づいた。丁度WiFiがなかった。止められたらメールで通知が来るが、見落としていた。このサイトはモニターされていて、ダウンするとメール通知が届くが、ダウンした直後と、...
信旅
 
https://makotoiwasaki.com/google-compute-engine-from-conoha.html

 

 

  • 311
    2680年6月24日
    サーバー

    VM インスタンスを他のGCPアカウントに移転コピーする方法

    GCPからGCPへの移転方法AWS, Azure 等の他のクラウドサーバーからGCP（Google Cloud Platform）に移転する方法はよく論じられているが、GCPのAアカウントからBアカウントに移転するにはどうしたらよいのだろうか？ Compute Engine のVMインスタンスを、他のGCP アカウントのCompute Engine に移転又はコピーするにはどうしたらよいのだろうか？ プロジェクトの共有 試行錯誤の上、たどり着いたのがプロジェクトの共有であった。GCPのトップページ、ダッシュボードの最初にプロジェクト情報のカードがあり、其の中に「このプロジェクトにユーザーを追加」という項目がある。そこをクリックして、他のGCPアカウントのGma...
    ... >> つづき
  • 112
    2679年11月5日
    WordPress

    Let’s Encrypt SSL証明書の期限切れ対策 certbot を使う

    またまたこのサイトのSSL証明書が期限切れになった。 Kusanagi の自動更新ができていない。 それで手動であれこれしてみても、こんなエラーが出る。＃ kusanagi update cert Challenge failed for domain makotoiwasaki.com Challenge failed for domain www.makotoiwasaki.com Attempting to renew cert (makotoiwasaki.com) from /etc/letsencrypt/renewal/makotoiwasaki.com.conf produced an unexpected error: Some challenges hav...
    ... >> つづき
  • 223
    2679年9月3日
    WordPress

    Google Indexing API プラグイン WordPress by Rank Math

    Google の Indexing API を使うと、新しい投稿記事を瞬時にGoogleの検索エンジンに登録できる。 WordPress のプラグインとしてインデックスAPIが利用できる。使い方は英語だが、この通り： ⏱️ Get Google To Index Your Website Instantly Using the Indexing API ⚡Take a look at how you can use Google's new indexing API & to get your website's pages and content crawled instantly instead of waiting for Google to...
    ... >> つづき
  • 15
    2679年9月3日
    WordPress

    検索結果スニペット、抜粋 get_the_excerpt の設定

    Yoast SEO を停止して、Rank Math SEO プラグインを使ってみたらGoogle の検索結果に表示される記事抜粋スニペットの文字数が短過ぎに見えてびっくりした。#1 Yoast Alternative You Deserve - Rank Math SEO vs. Yoast SEORank Math SEO plugin for WordPress is hands down the best Yoast alternative WordPress plugin. And the best thing is, Rank Math is completely FREE!Rank Math
    ... >> つづき
  • 11
    2679年8月29日
    WordPress

    WP_CRON を停止して Linux crontab で自動バックアップする方法

    WP_CRON を停止して、Linux の crontab に移行する設定をこれまでに何度も試みたがうまくいかなかった。 毎日バックアップされるはずの、UpdraftPlus プラグインのクロンが動いていない。やっと成功した設定方法を記録しておく。wp-config.php に次の行を追加する。define('DISABLE_WP_CRON', true);/var/spool/cron  に、  httpd という名前のファイルを作成し、次の1行を追加する。 所有者を httpd.www など、httpd nginx サーバーの稼働ユーザー名と同じにする。nginx.conf に書いてある。root@s4:/v...
    ... >> つづき
  • 109
    2679年8月29日
    WordPress

    Nginx の Fcache が効いていない時に効かせる方法

    Kusanagi WordPress プラットフォームでは Fcache とBcache がある。 Fcache とはNginx ヱブサーバーのキャッシュ機能であり、Kusanagi の独自機能ではない。Nginx のアクセスログを眺めていると、  BYPASS MISS EXPIRED のみで、HITが殆どない。 トップ頁、アーカイブリストの頁ではHIT、 個別投稿頁では、BYPASS MISS EXPIRED ばかりでHITがない。Kusanagi fcache on とすると、fcache は有効になったかのように思えるが、本当にキャッシュが効いているのかどうかはログで確認しないとわからない。まず、Wordpressの編集画面にログインし...
    ... >> つづき
  • 287
    2679年8月25日
    WordPress

    httpdアクセスログを日本語デコードする方法

    HTTPD アクセスログの日本語化 Nginx,  Apache ヱブサーバーのアクセスログを見ると、日本語URLはエンコードされていて読めない。 そこで、デコードして表示させる。 ログのファイル名が ssl_access.log だとすると、tail -f ssl_access.log| perl -ne 'use URI::Escape; print uri_unescape($_);' tail -f access.log | php -R 'echo urldecode($argn)."\n";'で、日本語URlが読める状態で出力される。 Apacheのログをデコードする方法 - Life with ITプログラマ x ...
    ... >> つづき
  • 16
    2679年8月25日
    WordPress

    リロードなしにスタイルシートの更新を反映させる方法

    ヱブサイトの再構築中には、スタイルシート、style.css を頻繁に調整更新する。 CSSを追加、編集する度に再読み込みを繰り返して、変更の反映を確認していた。 これで編集者は反映を確認できるのだが、一般閲覧者はわざわざ再読み込みしたり、キャッシュを削除したりするはずはないので、変更が反映されていない崩れたデザインを見ているかもしれない。わざわざリロードしたりキャッシュを削除したりしなくても変更が確実に反映されるような設定方法を発見した。wp_enqueue_scripts で CSS、JS の読み込みを管理している場合には、次のようにfunctions.php に記述する。// 子テーマのstyle.cssを最後に読み込む add_acti...
    ... >> つづき

サーバー カテゴリ人気記事 Views most

タグ関連記事

閲覧履歴