蝉は、やがて死ぬる午後に気づいた。ああ、私たち、もっと仕合せになってよかったのだ。:2019年11月分

2019/11/05(Tue)

[チラシの裏] オレオレN6とKVM VirtIOで障害

(追記) サポートから直近で障害メンテは無かったという回答ががが、じゃあなんでVirtIO死んだのやら…

さくらVPSで事前予告なしのKVMライブマイグレーションが発生したようなのだが、困ったことに移行先のKVMのバージョンが違うのかN6のvirtioドライバが対応してないようでvioif(4)が生きたまま死んどってネットワーク反応無しで警告が飛んできた。

ワイも最近頭ぶっ壊れつつあるので不用意にもとりあえずビールならぬ再起動(脳死)を実行してしまい、カーネルがld(4)認識できずに起動不能に陥って更に事態悪化という痛恨のミス、ログすら回収してねえ!

この時点でVPSコンソールで起動/シャットダウン/コンソールと操作がなんもできん状態になってしもうたのでKVMホスト側の障害かと、サポートも連休中は休みなのでメールだけ投げて放置。

とりあえずDNSいじってwwwのCNAMEを昔取得した無料ホームページサービスに飛ばすかーとも考えたんだけど、nginxにHSTS設定してたので証明書用意しhttpsの設定せんとブラウザエラーになるから手間なので止めた、どうせ誰も読んでねえわこんなチラシの裏。

そんで本日ようやっとサポートから返答あって

とのこと。 あれ頭に「ストレージが初期化されます」とあるので既存のディスクイメージ破棄されるのかと思って躊躇してたんだが、ISOインストールを選択した場合はストレージの内容は保持されるのね。

ということでN8.1のinstall CDで起動しkernel-GENERIC.tgzとmodules.tgzだけ手動展開し再起動かけて仮復旧。 そのうちオレオレN6のソースツリーにvirtioドライバの変更を反映したいところである。

つーか今後も同じようなトラブル起きる可能性あるわけで、コンサバ(スズキ目サバ科サバ属)にVirtIO無効でwm(4)とwd(4)使う方がええかもね…

2019/11/11(Mon)

[オレオレN6] 続・チラシの裏障害対応

先日のトラブル対応、そっちにちょいと追記しておいたけど、さくらのサポートは直近でメンテも障害も確認しておりませんゆう回答がきた。

前回の再起動時のdmesgは

Jul 22 02:15:54 tk2-219-19156 /netbsd: NetBSD 6.1_STABLE (GENERIC) #1: Thu Mar  1 11:15:04 JST 2018
Jul 22 02:15:54 tk2-219-19156 /netbsd:  root@tk2-219-19156.vs.sakura.ne.jp:/usr/obj.amd64/sys/arch/amd64/compile/GENERIC
Jul 22 02:15:54 tk2-219-19156 /netbsd: total memory = 1023 MB
Jul 22 02:15:54 tk2-219-19156 /netbsd: avail memory = 978 MB
Jul 22 02:15:54 tk2-219-19156 /netbsd: timecounter: Timecounters tick every 10.000 msec
Jul 22 02:15:54 tk2-219-19156 /netbsd: timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
Jul 22 02:15:54 tk2-219-19156 /netbsd: Red Hat KVM (RHEL 7.0.0 PC (i440FX + PIIX, 1996))
Jul 22 02:15:54 tk2-219-19156 /netbsd: mainbus0 (root)
Jul 22 02:15:54 tk2-219-19156 /netbsd: cpu0 at mainbus0 apid 0: Intel Core Processor (Broadwell), id 0x306d2
Jul 22 02:15:54 tk2-219-19156 /netbsd: cpu1 at mainbus0 apid 1: Intel Core Processor (Broadwell), id 0x306d2

そんで今回のdmesgだと

Nov  5 23:56:40 tk2-219-19156 /netbsd: NetBSD 8.1 (GENERIC) #0: Fri May 31 08:43:59 UTC 2019
Nov  5 23:56:40 tk2-219-19156 /netbsd:  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC
...
Nov  5 23:56:40 tk2-219-19156 /netbsd: Red Hat KVM (RHEL 7.0.0 PC (i440FX + PIIX, 1996))
Nov  5 23:56:40 tk2-219-19156 /netbsd: mainbus0 (root)
...
Nov  5 23:56:40 tk2-219-19156 /netbsd: cpu0 at mainbus0 apid 0
Nov  5 23:56:40 tk2-219-19156 /netbsd: cpu0: Intel Core Processor (Broadwell), id 0x306d2
Nov  5 23:56:40 tk2-219-19156 /netbsd: cpu0: package 0, core 0, smt 0
Nov  5 23:56:40 tk2-219-19156 /netbsd: cpu1 at mainbus0 apid 1
Nov  5 23:56:40 tk2-219-19156 /netbsd: cpu1: Intel Core Processor (Broadwell), id 0x306d2
Nov  5 23:56:40 tk2-219-19156 /netbsd: cpu1: package 1, core 0, smt 0

ちゅーことで変わってないのでマジっぽい、じゃあなんで今認識しないのやら。

でも障害が起きたら事前通告なくフェールオーバーは発生する方が当たり前だし、ライブマイグレーションじゃなきゃ仮想マシンの移動先はまったく同一構成であることすら保証されんちゅーことまで留意して運用せなならんのは確かやな。 でも対応策としてKVMのバージョンに依存しないようVirtIO無効にしただけでは不十分で、OSが存じ上げないCPUだった場合に発生する障害には対応のしようがねえよな、ほら最近も systemdがAMD Zen2のRDRAND命令が続けて-1返すので起動しねえとかあったわけでな。 ということで止まると困るなら自分でちゃんと冗長化しておけってことだ罠。

そんで仮復旧にカーネルだけ8.1に入れ替えた後、syslogに

Nov 10 23:45:56 tk2-219-19156 /netbsd: in_cksum: out of data

が大量出力されとるのと、IPv6でのNTPの時刻同期に失敗してるのにたった今気づいたのだが、以前 pf(4)のバグ踏んだ件のうちv6パケットをv4としてチェックサムとって死ぬ件のfixがTNF本家だともう干支一回りするくらいにメンテ滞ってるので取り込まれてない件やなこれ。

この差分はオレオレN6にはマージしてあったんだけど、結局そもそもの発端である IPv6で自分自身に接続しようとすると謎ブロックされる現象までの解決には至っていないので困ったもんである、風の噂だとN10でpf(4)ごと消滅の予定だそうだから直るはずもねえかこれ。

[SCM] gitに欲しい新機能

ゲーム全くやらん人なのでネットの評判ちら見しただけなんだけどDeath Strandingってゲームのいいねシステムおもろいね、オープンソース界もgit favoriteとか実装してcommit単位で *1いいねつけられると少しは燃え尽きた作業者も息吹き返すのかなぁと思った、つかgit favoriteでなくgit thanksとかかな。 顔本ヒウイッヒーあたりのいいねは承認欲求丸出しのはた迷惑な妄言奇行に注ぐガソリンで世の害悪なんだけど、実際に手を動かした行為にありがとうを送れるのはプロジェクトも円滑になる。 ということで水にもありがとう以下略

ちなみにgit prise(blame)という機能は既にあるけどこれはエンバグさせた犯人を捜し出す責任追及機能なのでちょっと違う、またお前か(クソデカ溜息)。

でもgitの主要開発者がLinusだから実装されるとしたら👍(U+1F44D Thumbs Up Sign)でなく🖕(U+1F595 Reversed Hand With Middle Finger Extended)の方か、commitしたらLinusから即Fuck飛んでくるのはそれはそれで楽しそうではある(ぉ

*1:githubのプロジェクト単位にいいねとか芝生とか意味ねえしな。

2019/11/21(Thu)

[旅行] 昇仙峡

今年も昇仙峡に紅葉見物行ってきたよ。

今回は大波乱で、あたりに注意を払わずフラフラ歩き回ってるどっかのbarさんが、ワイのカメラを三脚ごと落差数十メートルの崖っぷちに叩き落としやがったので、ノーザイルで拾いに行くというミッションが発生し危うく死ぬところであった。

なんとか崖のギリギリのとこに三脚が引っかかってるのを這い寄って近づき、落ちてた木の枝をカメラのネックストラップにひっかけて拾い上げることが出来てワイもカメラも無事生還したんだが、滑落して肉片になってても残当レベルだったので決して真似はしてはならない(戒め)。 谷底へ誘う分厚いツルッツルの落ち葉のおかげでカメラに傷一つ故障ひとつもなかったのは幸いであった、昔日光東照宮の石畳と城ケ島の岩場で落っことしたレンズはそりゃもうポッキリとマウント逝ったんだけどな。

ちなみに生還してきた時にはbarさんとっくに逃亡済であったクソが、教訓としてはザイル買うんですかねいやそんなん装備しても谷川岳みたいにワイの死体がぶらーんとなっとるのを自衛隊が射撃して回収するような羽目になっても困るんだけどね… まぁ即諦めてBBA小一時間問い詰めて弁償させるのが最適解なんだろう、どうせワイの師匠みたいにEOS-1Dsと赤鉢巻レンズを崖から落としたわけでもねえしせいぜい中古で数万で揃うショボショボの装備やしな…

それにしても柵から結構な安全マージンとって設置したはずの三脚、これbarさん持ち上げて投げ捨てたんじゃねーかくらいに谷底へと舞ってく光景は「人間の証明」の麦藁帽子を思い出しましたね… carさん、僕のあのカメラどうしたんでしょうね? ええ、秋、夢の松島から覚円峰へゆくみちで、 谷底へ落としたあのカメラですよ…

2019/11/27(Wed)

[写真] DNGファイルのEXIFの編集にExif Pilotという商用アプリを使うとタグが壊れてその後のRAW現像ができなくなる

デジカメの日付情報がバッテリ切れでトンだまま撮影したりするとEXIF情報の日付が数年前にワープするわけですが、ワイ普段は exiftoolというツールで修正するのだけど、コマンドラインいつも忘れるので今回 Exif Pilotという商用GUIツールの機能制限版を使ってみたんだけどこれが失敗であった。 こいつでDNGの日付をいじると余計なことにサムネールデータまでも更新され、その際に一部のタグが破壊され復元不可能になるんですわこいつ。

技術的な説明をすると、DNG(TIFFのサブセット)というのは画像コンテナフォーマットでイメージファイルディレクトリ(IDF)という仮想ファイルシステムみたいな概念がある。

そんでDNGでは通常

(root)
  |
  +---- IFD0 ... Thumbnail(160x120)
  |       |
  |       +---- SubIFD ... RAW Image
  |       |
  |       +---- SubIFD1 ... Preview Image(640x480)
  |
  +---- ExifIFD ... EXIF Metadata
  |
  +---- MakerNotes ... Vendor Specific Metadata

という配置をするんだけど、こいつをサムネール更新時に

(root)
  |
  +---- IFD0 ... Old Thumbnail(160x120)
  |       |
  |       +---- SubIFD ... RAW Image
  |       |
  |       +---- SubIFD1 ... Preview Image(640x480)
  |
  +---- ExifIFD ... EXIF Metadata
  |
  +---- IFD1 ... New Thumbnail

と書換えてサムネールをIFD1に勝手に移しちゃうんだよな。

おそらくIFD0上のサムネを上書きするには現在確保済の領域が新しいサムネのサイズ足らん場合に、拡張する必要あるけどオフセットの再計算やらがめんどくさい的なプログラミング上の手抜きやろうねこれ。

サムネをIFD1として新規に追加したよつってもビューアがそれに対応してなきゃ意味がないわけで、その結果エクスプローラーでアイコンのサムネ表示ができなくなっとる。

そんでですね更に悪いことにサムネが表示できないだけではないんですわ、IFD1を追加する際にExifIFDに続くMakerNotesというカメラベンダの私的メタデータ領域を考慮せずに上書き破壊しとるのだ。

この私的領域について、編集前のファイルは

---- MakerNotes ----
Maker Note Type                 : Rdc
Firmware Version                : 1.51
Serial Number                   : (20130000)0010XXXX
Ricoh Image Width               : 3776
Ricoh Image Height              : 2832
Ricoh Date                      : 2000:01:02 08:54:45
...

となってるんだけど、これが編集後は

---- MakerNotes ----
Maker Note Type                 : Rdc
Firmware Version                : v0151
Internal Serial Number          : 31333030303030303130363739390000
Ricoh Image Width               : 2832
Ricoh Image Height              : 0
Ricoh Date                      : 0102:08:54 41:00:01
...

とIFD1を追記した結果上書きされてしまい中身ブッ壊れてしまっとる、よってこの部分に記録されてるカメラ独自の撮影時情報は失われてしまうので、正しいRAW現像ができなくなるという不具合が生じるわけです。 まぁカメラ固有パラメーターが弄れなくなるだけで完全にRAW現像ができなくなるわけでもないんだけど。

結論としては素性の知れんツールを使う前にはファイルのバックアップを忘れずに、という至極当たり前のお話。

なおバックアップしとらん粗忽者で被害を受けた人はご愁傷様だけど、RAW現像できなくなるだけでRAW Imageそのものは残ってるから拡張子を.dng → .tifに変換してそこからSubIFDにあるRAW Imageをぶっこ抜けるツール探せばとりあえず元画像は救出できるから頑張って。 もしかするとスクリプト言語とTIFFイメージ操作ライブラリでゴリゴリやる必要はあるかもしれんけど、大切な写真を諦めず頑張ってください(他人事)。

(追記) 一応名無しでバグ報告しておいた、直るかもしれないし直らないかもしれない。

2019/11/30(Sat)

[写真] SONY NEX/ICLE系ミラーレスカメラで頻発するカメラエラー問題

先日書いた SONY PlayMemory Camera Appsサイトの二段階認証の話、長い事放置されとったのに今見たらお知らせに「現在対応方法を協議中」なんて書かれてとるんだが、誰かここ読んで通報したんですかねいやまさか。

なのでおまけとしてSONYのNEX/ICLE系ミラーレスカメラの 悪口直して欲しいとこをひとつ書いておこうかと思う、こいつらシャッターを切ると

カメラエラー、電源を入れ直してください(Camera error. Turn power off then on)

というメッセージを表示し操作不能になる持病があって、この世の地獄である価格COM爺やゲハのゴキアン@カメラ分所のエサとなっとる。

このエラーが発生するのはいくつかのパターンがあるようで

  1. SD/MSへの書込エラー
  2. 手振れ補正センサーのスタック
  3. シャッターのスタック

が原因となっとるっぽい、つーかエラーメッセージくらいわけーや。

んで原因の切り分けとして

で直るのであれば1。

設定画面から手振れ補正を切にして解消するのなら2、センサーにつまったゴミの清掃あるいは軽くチョップ入れると直ったりもするらしいけど基本はASSY交換。

シャッター幕が下がりっぱなしであれば確実に3、ゴミが原因なら清掃で直る可能性もあるけどたいていはどっか変形してるだろうからこれもASSY交換。

まあここまではカメラは精密機械なので故障はつきものだから特に文句をいう筋合いはない、SONYは工賃も部品代も良心的な方やと思う。

ところがですね、どうもこの3つ以外にもソフトウェアのバグっぽいケースがあるのよね。

ワイのNEX-5Rが正にその症状で

という現象がでとって他にもワイと同様の問題抱えてる人が結構おるのだ、 このへんとかね。

これ問題発生時の挙動を観察してると

のだよね、シャッター音2回ってのはフォーカルプレーンシャッターの構造からして先幕に続いて後幕が作動しとる音、そしてプレビューまでされてるので撮影自体は成功してるのだ。 なので機械的に問題はないはずなんだよな。

そしてなによりソフトウェアのバグを疑う理由は、そもそもNEX/ICLE系ミラーレスは先幕はメカニカルでなく電子で行うのがデフォルトなので、わざわざメニューから設定変更しなければ先幕は動作しないはずなのだ。 なのでシャッター音は1回のみのはずで、本来であれば動作しないはずの先幕が何らかの理由で暴走してエラーになっとるっぽいのだこいつ。

まぁハードウェアを疑うのであれば、コールドブート時のみ発生するちゅーことでどっかのコンデンサの劣化で電力足りとらん可能性もある。 そんならASSY交換止む無しとは思うんだけど、ただ電源入れて暫く待ってチャージができたであろう時間が経過してもエラー出るので違うんじゃねえかな。

そんで他の人の報告みても新品を買って2ヶ月で発生したとか、サポートに修理出してシャッター交換が必要といわれ、新しいカメラ買える修理代払ったけど直らなかったぞクソがなんて話も海外フォーラムに書かれてるのよな。 そのへんからしてハードの劣化磨耗の問題じゃなく、ソフトウェアのバグじゃねーのかなぁこれ。

そもそもNEX-5無印(2010年6月)と5N(2011年9月)もシャッターユニットやらCOPAL製の共通部品なんだけどこっちは発売すぐに新品買って8~9年ヘビーに使ってきたけどこういう症状とは無縁だったのでな。

ついでにいうならNEX-5Rと同時期のAマウント機(α65やα57なんか)も同一のCOPALシャッターだけど、こっちはNEX-5Rとは別系統のOSを採用してるので問題は発生してないのもバグじゃねーのという疑念の裏付けとなっている、どうでもいいけどα57買いましたさすがにα200はもう限界だ。

対症療法としてはさっきのリンク先にもあるけど、設定画面から電子先幕シャッター(EFCS)を切にして常時メカニカルな先幕を使用するようにすればいい。 そもそも電子先幕って

というメリットはあるけど、実は高速シャッター時にシンクロの問題でボケが欠けたり露出不足になったりするデメリットもあるのよな。 ワイはEマウントレンズよりこの問題の起きやすいAマウントレンズをLA-EA2経由で使うのがメインなのでもう常時切でええんよね。なんかシャッター音が非常にダサいという問題はあるが。

まぁワイの推測どおりソフトウェアの問題だとしても、何年も前に販売終了しとる機種だからファームアップなんて期待できんのがアレなんやな。