カテゴリー別アーカイブ: Deep Shit

徳樹庵 前橋店 − A Very Different With On The Menu.

先週は、平成30(2018)年初秋の連休を利用して群馬県にある城攻めへ。今回の初日のターゲットは以前から気になっていた城跡であったのだけれど、公共機関によるアクセスが不明だったので敬遠していた「崖端城(がけばたじょう)」と云う類の城で、周囲の三方が急崖になった全国的にも珍しい山城。越後の軍神・上杉謙信が整備した城で、のちに武田家重臣・真田昌幸によって攻略されるなど知る人ぞ知る城址。

どうやらJRの最寄り駅から少し歩いた昭和村なるところから関越バスで城の入口まで行けるらしいという情報をインターネットで発見して初日に攻略することに。ついでに二日目は上毛電鉄上毛線の沿線付近にある小粒な城がいくつか未攻略だったので一気に攻めてきた。
ありがたいことに、この連休の群馬県は晴天の上、夏日の予報だったので迷うことなく[a]本当の話、この三連休が秋の行楽シーズンであり、自らの出遅れもあって群馬県以外では宿を取れなかっただけだけど。 😥 宿を予約した :)

午前中のうちに移動を済ませて、たっぷり攻めた後、宿近くのチェイン店ながら好物の唐揚げを堪能できるレストランで城攻めの疲れを落とすといった予定だったので、時間的にはかなり無理したところがあった。
実は、これがあとで災難を呼ぶことになるのだが :$

この日は陽が昇る前に起床して朝6時過ぎの電車で移動を開始、4時間かけて初日の最寄りであるJR上越線・岩本駅に到着。そこからバス停まで歩いて、バスに乗って、城址入口前で下車。そこから30分ほど上り坂を歩き、城跡に到着したのが昼少し前。ここまでで意外と疲れた。それから帰りのバスの時刻まで、晴天で夏日の中をたっぷり3時間ほど歩き回ってきた。
そういうこともあり、今晩は熱々の唐揚げをツマミに生ビールを飲んでまったりと疲れを癒やし、明日の城攻めに臨みたいなぁと勝手に想像していた。

そして城攻めを終えてバスに乗りJR岩本駅まで歩いて、次の電車がくるまでの小一時間を駅舎で休み、宿があるJR前橋駅に着いたのが夕方5時過ぎ。で、そのまま予定していたレストランの徳樹庵前橋店へ:

手作り料理とお酒処の徳樹庵(本当か?)

勝手にファミレス系の建物を想像していたのだけど、実際のお店は料亭風の建物で個室に案内された。おおぉ、これは期待できそうな雰囲気 :)。そして席につくやメニューから生中と唐揚げやつまみを選択して注文した:

IMG_6367.resized

個室でまったり

それから一杯目のジョッキが無くなりそうな頃に、楽しみにしていたお店「自慢の逸品・一本唐揚げ」(4本)が登場。大きな唐揚げみたいだから量は小サイズにしたのだけれど:

鶏もも一本唐揚げ4本(490円+税)

あれぇ? 実物を見ると何かメチャクチャ小さい。メニューを見直しても全然小さいぞ :O。こんなに小さいなら8本の方を頼めばよかったけど、それはそれで何か違うよなぁ:|。でレモンを絞って食べたけど、なんだこれ、普通の唐揚げ。油臭いし。

まぁ最初はこんなものなのかなぁと自分を納得させつつ他のツマミを頂くことに。
勘八の刺し身は、なぜかワサビが付いていなかったから別途もらう羽目に :$。おまけに活〆にしてはメチャクチャ堅い身で、脂はほとんどなかった:$。:

勘八のお造り(690円+税)

つけ忘れのワサビ

そこでローストビーフと胡瓜の漬物を頼んでおいて良かった〜と思った:

カルパッチョ(690円+税)と胡瓜の一本漬け(390円+税)

あと洋風トマトサラダも:

IMG_6371.resized

洋風トマトサラダ(290円+税)

なんだかなぁ、値段がチープな品はそれなりの味。特に記憶に残らなかった:|。ここで唐揚げは全く納得がいかなかったのでもう一度、注文。あと勘八も。

しかし相変わらずメニューとは全然別物の品物が出てきた :(。最初の方がマシかも。左がメニュー、右が実物:

IMG_6374.resized

メニューの写真

IMG_6373.resized

実物(490円+税)

ここまできたら詐欺だね :X。それでいて価格[b]いいかげん内税表示にしろよ、食品業界。は首都圏レベル。ド田舎の群馬県前橋は、この程度なのかと呆れて何も言えなくなった。

最後は何も注文する気になれず、梅酒ロックと勘八刺しを食べて早々に退店した。最初の期待が完全に裏切られた上に、会計ではたいそうな金額を払う目になったこともあってイラッとしてしまった:

IMG_6375.resized

勘八のお造り(690円+税)

IMG_6377.resized

梅酒ロック(490円+税)

そんなこんなで知らずに酔っぱらっていたようで、店を出た後にちょっとした災難が。と言っても、これは徳樹庵は関係なく自業自得なのだけど。
まったく電灯のない暗闇の歩道をスマフォでコンビニを探しながらウロウロしていた際に、フラっと躓いて転倒しそうになり、持っていたスマフォを庇う形で利き腕一本で道路に手をついたら、手の甲の一部が削れてしまった :$。この時は、すかさず持参していた絆創膏でなんとか出血を抑えることができたものの、どうも利き腕に力が入らなくなっていた。それでも宿泊先では疲れを癒やすための風呂には注意しながら入ることができたし、寝ている最中も酷い傷みで起こされることは無かった。さらに翌日は、予定どおり城攻めもできたのは(痛かったけど)不幸中の幸いだった 0:)

振り返ってみると、今回は寝不足からか、うっかりしたりイライラすることが多く、悪いことが重なったこともあって、ホント何か群馬県前橋とはつくづく縁がないと痛感した[c]二年前には前橋公園で警察沙汰(自分は無関係だけど)があったりして、ここは嫌な街の一つ。。ということで、もう二度と来たくない街だねぇ、ここ前橋は :O

徳樹庵 前橋店
群馬県前橋市本町3-15-10


気を取り直して、ここからはオマケ。

こちらが初日の城攻めで利用したJR上越線4両編成の211系と岩本駅の駅舎(無人駅):

IMG_6353.resized

JR上越線の211系

IMG_6365.resized

JR岩本駅

ここから長井坂城跡の入口まで連れて行ってくれる関越バスのバス停まで歩いた時に観た風景を。まずは利根川を渡って昭和村へ:

IMGP1178.resized

利根川に架かる橋

IMGP1179

橋の上から利根川の風景(拡大版)

橋を挟んだ反対側も:

IMGP1180

橋の上から利根川の風景(拡大版)

IMGP1182.resized

昭和村

今回の城攻めツアーの戦勝祈願のため、途中にあった川額八幡宮なる神社に立ち寄った:

IMGP1186.resized

川額八幡宮

バス停のある入沢部落あたりで見た木の実(詳細不明):

IMGP1187.resized

木の実

あと畑を介して沼田方面の眺望:

IMGP1424

沼田方面の眺望(拡大版)

関越バスは入沢部落あたりから乗車し、下車したのは関越自動車道の真下あたりのバス停:

IMGP1193

バス停から見上げた関越自動車道(拡大版)

この長井坂城跡の地下には関越道が貫通しているということで、それはとどのつまり、この高架の上まで登る必要があるということである。ということで関越道を見上げながら坂道を延々と登った:O

IMGP1194.resized

関越自動車道

IMGP1201.resized

関越自動車道

こうやって見ていると建築物としては芸術レベルではある:

IMGP1202

芸術的な橋脚(拡大版)

IMGP1208.resized

関越自動車道

で、これが関越自動車道の上にある城址から見下ろした眺め(沼田方面):

IMGP1409

関越自動車道(拡大版)

城跡は大部分が畑ではあったが保存レベルが良く、周囲三方の断崖の他、空堀や土塁など土の城を堪能できた。但し、この時期にしては蜘蛛や藪蚊が多かったが:

IMGP1259.resized

馬出跡

こちらは城内の展望箇所から沼田方面の眺望:

IMGP1379

初日は晴天だった(拡大版)

関越バスの下永井停留所近くには円乗院の宝篋印塔(ほうきょういんとう)なる名跡があった。バスを待つ間、喉が渇いて水を探していた時に見つけた。おかげで冷たい水道水にありつけた。ありがたいことだった。寛政5(1793)年に建立された高さ2.5mの彫刻が大変に美しい石塔で、県指定の重要文化財:

IMG_6362.resized

円乗院の宝篋印塔

最終日は上毛電鉄沿線にある城跡を4つ攻めてきた。ただ天気予報が外れて晴天どころか小雨が降るといった悪天候になってしまったのが残念。
でも運良くワンデーフリーパスの存在を発見。この日は1,000円(大人/当時)で乗り放題:

IMG_6379.resized

城攻めで利用したワンデーフリーパス

乗車した車両[d]ちなみに、上毛鉄道の車両は京王井の頭線の中古車両を使用している。はハロウィーン仕様だった:

IMG_6381.resized

728編成

IMG_6387.resized

車内もハロウィーン仕様だった

これは膳(ぜん)城址公園にあった模擬天守風の遊具:

IMGP1484.resized

膳城址公園の滑り台

膳城は蜘蛛の巣と藪蚊が多かったけど、予想外に見どころが多かった城跡。城マニアの中には改変しすぎとか云ってた野郎がいたけど、宅地化の波が激しい古城ならばこの程度は全然許容できるけどな :/

IMGP1494.resized

膳城の外堀跡

IMGP1542.resized

膳城の外堀跡

上毛線沿線最後の城攻めは大胡駅近くの大胡城。こちらも意外と見どころが多かったが、見学者が全くいなかった[e]そう言えば途中、群馬ナンバーの家族連れを見かけたが「何にもないぞ、この城は。」と言って、さっさといなくなっていた。こいつらは何を期待していたのだろうか。

IMGP1616.resized

本丸虎口跡

本丸を囲む空堀とか:

IMGP1647.resized

全石垣が残った枡形など見どころは大いにあった。

この古そうで閉鎖になった幼稚園へ渡る木橋なんか趣あり:

IMGP1636.resized

城跡の幼稚園は閉鎖されていた

こちらは大胡駅と付属の車両基地。上毛鉄道も無人駅が多いが、大胡駅には車両基地があった:

IMG_6391.resized

大胡駅(線路側)

IMG_6392.resized

大胡駅(ホームと車両基地)

こんな模型も:

IMG_6393.resized

大胡駅構内にあったジオラマ模型

全ての城攻めを終え大胡駅をあとにして終点の中央前橋駅まで乗ってから、上毛電鉄の中央前橋駅とJR前橋駅との間を結ぶシャトルバス(100円)に乗車した。来た時と同様に歩いても良かったけど、疲れたし前日の負傷もあったので :)

IMG_6380.resized

初めて乗ったシャトルバス

帰りは高崎まで行って始発となる湘南新宿ライン快速に普通車グリーン席で。しかし連休で、最後は満席だったけど。お菓子やらビールやらを持って、埼玉県に入るまでは悠々とした電車旅だった。こちらは前橋駅構内のお土産屋で購入した群馬県渋川銘菓の「こがねいも」(108円)。味は普通。残念ながら北海道のわかさいもの方が旨い:p:

IMG_6394.resized

群馬県渋川銘菓の「こがねいも」(108円)

ということで、この時のフォト集はこちら:

See Also長井坂城攻め (フォト集)
See Also山上城攻め (フォト集)
See Also膳城攻め (フォト集)
See Also女渕城攻め (フォト集)
See Also大胡城攻め (フォト集)

参照   [ + ]

a. 本当の話、この三連休が秋の行楽シーズンであり、自らの出遅れもあって群馬県以外では宿を取れなかっただけだけど。 😥
b. いいかげん内税表示にしろよ、食品業界。
c. 二年前には前橋公園で警察沙汰(自分は無関係だけど)があったりして、ここは嫌な街の一つ。
d. ちなみに、上毛鉄道の車両は京王井の頭線の中古車両を使用している。
e. そう言えば途中、群馬ナンバーの家族連れを見かけたが「何にもないぞ、この城は。」と言って、さっさといなくなっていた。こいつらは何を期待していたのだろうか。

Mikeforce server downed again.

今月初めは平成30(2018)年9月1日に発生したサーバ障害は、その週明けにはなんとか復旧できたのだけれど、残念ながら未だ「致命的な問題」が残っていたようで再びダウンしてしまった。正確にはHDD故障で重要なパーティションをマウントできなくなり、ウェブサービスは勿論、システムサービスの類が軒並み停止してしまったという次第 :$

最初の障害でサーバが強制Shutdownした際、HDD内のLVMである /var パーティションで何か処理していたのだろうか。リモートからサーバにログインできないことに気づいた時はなんとなく嫌な予感がしたが :|
で帰宅して調べてみると、案の定、朝まで動いていたサーバは最後にアクセスしてから数時間後に突然、次のようなHDD読み取りエラーが発生していた:

[711805.660457] sd 25:0:0:0: [sdh] FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[711805.660465] sd 25:0:0:0: [sdh] Sense Key : Hardware Error [current]
[711805.660468] sd 25:0:0:0: [sdh] Add. Sense: No additional sense information
[711805.660471] sd 25:0:0:0: [sdh] CDB: 
[711805.660473] Read(10): 28 00 0f a9 6b 10 00 00 10 00
[711805.660484] blk_update_request: I/O error, dev sdh, sector 262761232
[711822.460908] sd 25:0:0:0: [sdh] FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[711822.460916] sd 25:0:0:0: [sdh] Sense Key : Hardware Error [current]
[711822.460919] sd 25:0:0:0: [sdh] Add. Sense: No additional sense information
[711822.460922] sd 25:0:0:0: [sdh] CDB: 
[711822.460924] Read(10): 28 00 0f a9 6b 10 00 00 10 00
[711822.460936] blk_update_request: I/O error, dev sdh, sector 262761232
[711822.460982] XFS (dm-0): metadata I/O error: block 0xfa1bb10 ("xlog_recover_do..(read#2)") error 5 numblks 16
[711822.478620] XFS (dm-0): log mount/recovery failed: error -5
[711822.478680] XFS (dm-0): log mount failed
[711827.723684] XFS (dm-0): Mounting V4 Filesystem
[711827.866409] XFS (dm-0): Starting recovery (logdev: internal)
[711830.994951] sd 25:0:0:0: [sdh] FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[711830.994959] sd 25:0:0:0: [sdh] Sense Key : Hardware Error [current]
[711830.994962] sd 25:0:0:0: [sdh] Add. Sense: No additional sense information
[711830.994965] sd 25:0:0:0: [sdh] CDB: 
[711830.994967] Read(10): 28 00 0f a9 6b 10 00 00 10 00
[711830.994979] blk_update_request: I/O error, dev sdh, sector 262761232
[711847.817378] sd 25:0:0:0: [sdh] FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[711847.817386] sd 25:0:0:0: [sdh] Sense Key : Hardware Error [current]
[711847.817390] sd 25:0:0:0: [sdh] Add. Sense: No additional sense information
[711847.817393] sd 25:0:0:0: [sdh] CDB: 
[711847.817395] Read(10): 28 00 0f a9 6b 10 00 00 10 00
[711847.817406] blk_update_request: I/O error, dev sdh, sector 262761232
[711847.817480] XFS (dm-0): metadata I/O error: block 0xfa1bb10 ("xlog_recover_do..(read#2)") error 5 numblks 16
[711847.839055] XFS (dm-0): log mount/recovery failed: error -5
[711847.839111] XFS (dm-0): log mount 

このI/OエラーによってLVMの /var パーティションが読み込めなくなった。このパーティションが読み込めなくなるのはシステムとして致命的である :$。例えばゲートウェイ+ルータ機能、ブログなどのDBシステム、SSHなどランタイムサービスの他、apt パッケージシステムが動かない等、かなり厳しい状況だった。
特にHDD内にあるブログやウェブのデータが逝ってしまったことで、最初は心が折れそうになってしまった ;(

1日ほど塞ぎこんでしまったが、ゲートウェイ機能を復旧させないと、いつまでたってもインターネットに接続できないので、ひとまずHDDを新調してシステムの全復旧を行うことにした。それに、かなり古いけどブログのDBのバックアップが残っていた ;) ので、時間はかかるけどブログの方は再び書いていけば、いつか元に戻るであろうと前向きに考えることにした :D

ということで、まずは新規のSSD(120GB)とHDD(3TB)を注文、到着するまでの間は既存のHDDからデータの吸い上げ。この時、I/OエラーがでていたHDDについては重要なデータがストアされており、色々試すことで結局は負荷をかけてハードウェアの寿命が縮んでしまいそうなので、GNU Ddrescue なるツールでddイメージを安全かつ堅実に抜き出すことにした。これは本当に素晴らしいツール

  • 不良セクタをスキップして、良好データをまず先に復旧する
  • これによりHDDに不必要な負荷をかけることがないため、最終的に復旧できるデータ量が大きい
  • 不良セクタはログに記録できる
  • 別ツールであるddrescureviewを使うとGTK+ベースの GUI 上にセクタのマップを表示することができる

I/OエラーがでたパーティションはLVMボリュームで容量は 500GB であったが、Ddrescue は特に問題なかった。このサイズのrawイメージを保存できる空きHDDを用意して、玄人志向のHDDスタンド経由でDdrescureを実行した:

$ sudo ddrescue -n -v /dev/mikeforce-vg/vgroup-var_lv ./back-vgroup-var_lv.img back-vgroup-var_lv.log 
GNU ddrescue 1.19
About to copy 536870 MBytes from /dev/mikeforce-vg/vgroup-var_lv to ./back-vgroup-var_lv.img.
 Starting positions: infile = 0 B, outfile = 0 B
 Copy block size: 128 sectors Initial skip size: 128 sectors
Sector size: 512 Bytes

Press Ctrl-C to interrupt
rescued: 536870 MB, errsize: 12288 B, current rate: 1686 B/s
 ipos: 268691 MB, errors: 3, average rate: 16525 kB/s
 opos: 268691 MB, run time: 9.02 h, successful read: 0 s ago
Finished 

500GBのrawイメージを9時間ほどかけて取得、不良セクタは12KBと予想外に少なかった ;)。この後、XFSのfschkであるxfs_repairでファイルシステムを補修してからloopbackでマウントしてみたら、見事にパーティションを読み込むことができた:

$ sudo xfs_repair -L -f /opt/back-vgroup-var_lv.img
Phase 1 - find and verify superblock...
Cannot get host filesystem geometry.
Repair may fail if there is a sector size mismatch between
the image and the host filesystem.
Phase 2 - using internal log
 - zero log...
ALERT: The filesystem has valuable metadata changes in a log which is being
destroyed because the -L option was used.
 - scan filesystem freespace and inode maps...
out-of-order bno btree record 46 (98638 1) block 1/4
block (1,98638-98638) multiply claimed by bno space tree, state - 1
out-of-order bno btree record 47 (225432 1) block 1/4
block (1,225432-225432) multiply claimed by bno space tree, state - 1
out-of-order bno btree record 48 (292435 2) block 1/4
block (1,292435-292435) multiply claimed by bno space tree, state - 1
out-of-order bno btree record 174 (324055 3) block 1/4
block (1,324055-324055) multiply claimed by bno space tree, state - 1
out-of-order bno btree record 175 (324059 2) block 1/4
block (1,324059-324059) multiply claimed by bno space tree, state - 1
out-of-order bno btree record 176 (324096 5) block 1/4
block (1,324096-324096) multiply claimed by bno space tree, state - 1
agf_freeblks 27730912, counted 27730884 in ag 1
agf_freeblks 28437926, counted 28437911 in ag 3
block (2,5220537-5220537) multiply claimed by cnt space tree, state - 2
agf_freeblks 26476336, counted 26476369 in ag 2
agi_freecount 51, counted 52 in ag 3
agi_freecount 64, counted 65 in ag 2
agi_freecount 139, counted 142 in ag 0
sb_ifree 368, counted 335
sb_fdblocks 106740156, counted 106773627
 - found root inode chunk
Phase 3 - for each AG...
 - scan and clear agi unlinked lists...
 - process known inodes and perform inode discovery...
 - agno = 0
data fork in ino 137948 claims free block 4822
data fork in ino 137948 claims free block 4823
correcting nblocks for inode 10686304, was 1 - counted 0
 - agno = 1
Metadata corruption detected at block 0xfa1bb10/0x2000
(...)
Metadata corruption detected at block 0xfa1bb10/0x2000
Metadata corruption detected at block 0xfa1bb10/0x2000
data fork in ino 536882165 claims free block 33555077
Metadata corruption detected at block 0xfa03108/0x1000
corrupt block 0 in directory inode 536896076
 will junk block
no . entry for directory 536896076
no .. entry for directory 536896076
problem with directory contents in inode 536896076
cleared inode 536896076
bad magic number 0x0 on inode 537097760
bad version number 0x0 on inode 537097760
(...)
Phase 4 - check for duplicate blocks...
 - setting up duplicate extent list...
 - check for inodes claiming duplicate blocks...
 - agno = 0
 - agno = 1
 - agno = 2
 - agno = 3
(...)
Phase 5 - rebuild AG headers and trees...
 - reset superblock...
Phase 6 - check inode connectivity...
 - resetting contents of realtime bitmap and summary inodes
 - traversing filesystem ...
(...)
Phase 7 - verify and correct link counts...
resetting inode 61515 nlinks from 20 to 19
resetting inode 512221 nlinks from 16 to 15
Metadata corruption detected at block 0x8058/0x1000
libxfs_writebufr: write verifer failed on bno 0x8058/0x1000
Metadata corruption detected at block 0x3fe90/0x1000
libxfs_writebufr: write verifer failed on bno 0x3fe90/0x1000
Metadata corruption detected at block 0x3fe90/0x1000
libxfs_writebufr: write verifer failed on bno 0x3fe90/0x1000
Metadata corruption detected at block 0x8058/0x1000
libxfs_writebufr: write verifer failed on bno 0x8058/0x1000
done
$ sudo mount -o loop /opt/back-vgroup-var_lv.img ./mnt
$ 

こちらがddrescueviewで表示させたもの。赤色が不良セクタ:

ddrescueviewの結果

不良セクタのサイズが少なかったことが不幸中の幸いだった。これらのセクタはMySQLのデータであったけどブログには影響が無くて安心した 0:)

思えば、今夏の酷暑がHDDに与えていた影響は少なくない[a]加えて、筐体も普通のPCのタワー型だし。として、HDD間の配置を変更し、RootfsはSSDにして発熱を抑えることにした。そして、今さらながらHDDの寿命と故障率について身にしみたのでバックアップを励行することにした。

ということで、全復旧までお金と一週間ほどの時間を要したけど、素晴らしいツールと教訓を得ることができて良しとする。

この後は、自動バックアップシステムを構築し、S.M.A.R.Tで温度を監視しつつサーバを運用することにする。

参照   [ + ]

a. 加えて、筐体も普通のPCのタワー型だし。

Mikeforce server downed.

この記事をアップできている現在は復旧済みで、ことの顛末は次のような次第:

先週は平成30(2018)年9月1日[a]週末の土曜日で仏滅だった。朝、歯医者に行くために少し早めに起きて天気予報を確認しようと Web を開いたら「インターネットに接続できません」なるメッセージが表示された。日頃、常時接続な環境なので、モデムかハブか何かが落ちたかと思って見てみたが特に問題はない。あれ!?っとPCを見てみるとケースにある青色の電源ランプが点いていなかった :|。う〜m。
たしか昨晩寝る前、部屋の照明を消した時に扇風機の電源ランプ[b]これも青い色。暗い部屋では赤色と共に最も視認しやすく目につく色である。が消えていることを確認したが、同時にその背後にPCの電源ランプが見えていたのを記憶していたので、その時までは確かに動いていた。

で、ケースの電源ボタンを押してみたが全く動かない。何もしていないのに電源が落ち、さらに電源が入らないということで、まず最初に昨年春に取り替えた電源ユニットのCoolerMaster V650 Semi-Modular[c]昨年、突然 PC の電源モジュールからカラカラ音が鳴り出したので、調べたらファンの羽が折れ曲がっていた。最初は叩いたら収まっていたが、段々と音も大きくなってきたので電源ユニット本体を取り替えたと云う次第。を疑った。

ケースを開けて、歯医者に出かけるギリギリまで調べてみたが、ハードウェアが故障したような「臭い」は無く、特に電源ユニット回りに至っては焦げた跡など異常は見当たらず。加えて電源ユニットを ON するとマザーボードのP9X79上にあるStandby Power LEDが点灯するので電源ユニットからマザーボードへは通電しているっぽい。しかしケースの電源ボタンを押してもマザーボード上のChassis LEDやCPUファンは動かないし、何より電源ユニットが動いていない :$

今まで見たことの無い症状。
その昔、Windows系OSが載ったPCが立ち上がらなかった時があったが、その時はCMOSの電池切れだったり、DIMMがキチンと差さっておらず少し浮いていたのが原因だった。一応、今回は起動中に落ちているぽいので関係は無いとは思うが、念の為、予備の電池のCR2032に交換したり、メモリを挿し直したが特に変化なし:

グラフィックスボードを外したところ

これにあまり時間を割いていられないし、外(インターネット)に気安く出られないのも不便[d]このサーバはWifiなどの自宅内ネットワークのGWでもある。だし、なにより電源ユニットが問題ということであれば5年保証を要求するところだけど、そこまで原因が確定できていない。メーカーとやりとりしていたら復旧が来週一杯までかかってしまいそう。なので、ここは翌日までに入手できそうな電源ユニットをスマフォから Amazon で注文。いろいろ迷ったが昨年購入したユニットの廉価版っぽいCoolerMaster MW Semi-Modular 650Wにした。値段は半額ほど。まぁ買い捨て覚悟。

そして翌朝の日曜日、ありがたいことに午前中の早い時間に受け取ることができたので、早速マザーボードと電源ユニットを接続してみたが、一回目はケースや CPU ファンが少しだけ動いたものの、結果は同じで電源は立ち上がらない :|。 う〜m。いやはや困った。もしかしてマザーボードか!?なんて、思わず最悪な状況を想像してしまった :(

ここでPCI Expressに装着していたグラフィックスボードの陰に隠れていたLEDを確認しようと、一旦取り外して電源を入れてみると、ピポッと音がなるやいなやCPUファンが回りだして、POSTまで動き出した :O
なんと原因はグラフィックスボードだった:

これが問題の NVIDIA GeForce GTX 660Ti (2GB)

この二枚差しDuallボード、てっきりボード上部に付いていたPCI Expressコネクタに電源ケーブルを指していなければ電源は供給されないものと思っていたが、どうやら間違い。マザーボードからも電源は供給されているようだ(二枚差しだから)。以前はデスクトップとして使っていたPCを今はサーバとして使っている。なので2枚差しのグラフィックスパワーを使う機会は全く無い :D

ということで、今の時間から Amazon を利用しても無駄なので、単にVGAとして利用できる安価なグラフィックスボードを電車に乗ってヨドバシで購入して挿してみたら、あっけなく起動した:

NVIDIA GEFORCE GT710 (2GB)

購入したのはNVIDIA GEFORCE GT710(5,510円/当時)。サーバならば、この程度で十分すぎるスペック。原則的にリモート操作で、どうせ起動時のログを確認する程度にしか使わないし。

ということで、あとでsyslogのログを確認してみたら、PCが落ちたのは9月1日 05:39:16だった。早朝のクロン・ルーチン中に落ちたっぽいがKernelログには異常は無いのでハードウェア故障だ。復旧までに24時間くらいかかってしまった。初動調査で電源が怪しいと見てしまったのが原因だけど、まさかグラフィックスボードが原因で起動しないなって。だって、なくても起動するし :/

ということで不要な電源が一つできてしまった。欲しい方がいれば譲ります =)

参照   [ + ]

a. 週末の土曜日で仏滅だった。
b. これも青い色。暗い部屋では赤色と共に最も視認しやすく目につく色である。
c. 昨年、突然 PC の電源モジュールからカラカラ音が鳴り出したので、調べたらファンの羽が折れ曲がっていた。最初は叩いたら収まっていたが、段々と音も大きくなってきたので電源ユニット本体を取り替えたと云う次第。
d. このサーバはWifiなどの自宅内ネットワークのGWでもある。

Upgrade to Xenial Xerus.

サイトのHTTPS化が完了した勢いで、この間アップグレードしたばかりだけれど、16.04.01 LTSにアップグレードした。一番の強敵はPHP5からPHP7.0にアップグレードされることなので、HTTP回り(Apache2.4/PHP/MySQL)の設定は丸々バックアップを取るも、MySQLのDBは特にバックアップせず。WordPressのDBは先のHTTPS化で既に作成済。まずは既存のシステムを最新にしてから、お決まりのコマンドでアップグレードを開始した;

$ sudo apt update
$ sudo apt upgrade
$ sudo systemctl reboot
(...)
$ sudo do-release-upgrade

途中、設定ファイルの適用可否を聞かれることがあったがアップグレード自体は20分位で終了した:)。と言っても正常終了ではなく、こんな感じでMySQLサーバの起動に失敗していたけど:$

Errors were encountered while processing:
mysql-server-5.7
mysql-server
Error in function:
(...)
Could not install the upgrades

The upgrade has aborted. Your system could be in an unstable state. 
A recovery will run now (dpkg --configure -a).

Setting up mysql-server-5.7 (5.7.13-0ubuntu0.16.04.2) ...
invoke-rc.d: Unit mysql.service is masked
Renaming removed key_buffer and myisam-recover optoins (if present)
ERROR: Unable to start MySQL server:
2016-09-04T01:20:22.230428Z 0 [ERROR] unknown variable 'myisam-recover=BACKUP'
2016-09-04T01:20:22.234640Z 0 [ERROR] Aborting
(....)

こちらはMySQL-5.7になってオプション名が変更になり、mysqld.cnfを修正する必要があったことが原因。アップグレード中の設定ファイル適用可否の質問には全て(N)で答えていたのが影響したようで、MySQLは下位バージョンとは互換性がないようだ(という情報をリリースノートに期待しているんだけど・・・)。ということで、設定ファイルを修正したらあっさり起動した。ここで再びaptコマンドからupgradeを実行して、やっと16.04.01 LTSの環境になった:)

で、ここからが重要で、ウェブサービスを一つ一つ確認してくと、いろいろ問題がでてきたが代表的なものはこんな感じ。全てPHP7.0になったことが原因:

  1. MediaWikiが例外発生で起動しない
    [b6d53246] 2016-09-04 02:45:20: Fatal exception of type MWException
  2. 城攻め訪問記フォト集として使っていたO.r.i.g.i.n.a.l.が何も表示されなくなった

正直、PHPなんて「守備範囲外」なのでよくわからない。そのため最初はPHP5.6にダウングレードしようかと思ったけど、結局はいつか解決しないといけないので今やることにした。

1.の問題はデバッグログを出力するようにして実行時のバックトレースを見ると、どうやらキャッシュタイプが問題のようだった。PHP7.0になってphp-xcacheが提供されないことが原因。ということで、ここはキャッシュを無効することで解決した。

2.の問題は、error.logとPHP7.0への移植の際の注意点を見ながらDEPRECATEDなコードを一つ一つ修正した。まぁ、もともとが相当古いコードということもあって、PHP5時代からいろいろNOTICES(Warnings)が出ていたのだけれど。そういうこともあり、併せて他にも危なそうなコードを修正しておいた。

ということで半日がかりの作業になってしまったけれど、LTS+HTTPS環境の構築が完了で、やっと肩の荷が下りたといったところ:D:

 $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial