passive log strage

バイク、ガジェット、ゲーム、ツール・・・等。

DM200 ver1.4でRTC関連が変更?

取り急ぎ。

2017/04/16追記:本家にて対応版kernelがリリースされています。
そこらへんをうちでまとめた記事がこちら

今回の状況について

  • DM200で「Linux on Pomera DM200 (人柱版その2)」をメインに使っており、通常のPomeraとして使っていない人は影響を受けない。
  • DM200のファームウェアがVer.1.3までの人(Ver1.4にアップデートしていない人)は影響を受けない。
  • もちろんLinux on Pomera DM200を使わずに通常のPomeraとして使っているだけの人も無関係。
  • PomeraLinux on Pomera を行き来するたびに毎回時刻合わせをする」という運用が苦にならない人も問題ないだろう。

影響をうけるのは、自分のように通常のPomeraを使いつつ時々Linux on Pomeraを起動する人。

念のため再度注意

あくまでDM200 ファームウェアVer1.4で普通にPOMERAとして使う分にはなんの問題も発生しない。
間違っても本件についてキングジムに問い合わせたりすることの無いようくれぐれもよろしくお願いします。
また、今回の現象について Linux on Pomera 提供者の @ichinomoto さんにはなんの責任も無いことを改めて記します。
今更書く必要はないと思うが、「Linux on Pomera」 は我々の自己責任っていうのはみんな判ってるよね?
俺たちは自己責任で遊んでるってこと、みんな判ってるもんね?

状況

DM200 Ver.1.4から、内部的な時刻の取り扱いが大幅に変わっている?ように見えた。

@obally

  1. Pomera側で時刻設定 例「2018/4/6(金) 14:00」
  2. Linux on Pomeraで起動。(起動時にはWiFi自動接続しない→NTP時刻合わせせず
  3. sudo timedatectlでHWクロック(RTC)の時刻確認
  4. 結果→RTCの時刻が「2018/04/5(木) 14:03」

JSTでも+−9時間でもなく、-24時間。

なぜ今更気がついたかというと、tmuxを導入してstats-lineに時刻を表示するカスタムを加えていて「あれ?」と。

この件について(たまたまこのタイミングでうちの記事をtweetしてくださった) @ytakeda さんに追試していただいた(なんか巻き込んでしまってすみません)

@obally →

@ytakeda ←

@obally →

@ytakeda ←

ということで、確定。

Pomeraだけ使う人やLinuxだけを使う人には問題ないんだろうけど、Pomera側とLinux側を行き来する自分にはやっかいな状態になってしまった。

対処法を考えてみたが・・・

  1. なんとか頑張ってみるよ派
    1. [素人の思いつき案]:TimeZone関連をゴニョゴニョして無理矢理「+24時間」で動作させる。
      • TimeZone定義として「UTC+24:00」という『オレオレTimezone』をでっち上げるという力業。
      • TimeZone関連をちょっと調べてみたけど、前提として範囲が「UTC-12時間〜UTC+12時間」であって「24時間」ってのはTimeZoneの想定範囲外になるはず。
      • 「オレオレTimeZone」定義が作れて、これを適用できたとしても、他の時刻関連ライブラリに与える影響が未知数。
      • WebAPIを呼ぶスクリプトなども微妙に怖い。
    2. [もっと知識が深ければできそう案]
      • Linux on Pomera側で、時刻周りの管理(timedatectlとか)よりもっと下層レベルで「RTC+24時間の下駄履かせる」処理を噛ませる。
      • すんません俺にはどこから覗けばいいのかすらわかんねぇです。
  2. もう諦めるよ派
    1. [アップデートなんていらんかったんや案]
      • DM200ファームウェアをVer1.3に戻す。
        • 一応、あくまで「基本はPOMERAとして使う」という立ち位置なので、そこまでネガティブにはなれないのよね・・・。
    2. [Linux側寄り妥協案]:POMERA上では「RTC=時刻はつねに+24時間」として諦める。
      • POMERA上では一日速い」を許容する運用。
      • 今まで通りの設定でNTPでの時刻合わせが使えるのが利点。
      • DM200の標準機能「ポメラSync」が多分怪しくなる(タイムスタンプ基準で判定してるようなので)。
    3. [POMERA側寄り妥協案]:Linux上では「RTC=時刻はつねに-24時間」として諦める。
      • 逆に「Linux上では一日遅れ」を許容する運用。
      • NTP時刻合わせが使えない(RTCを書き換えてしまうから)。
      • タイムスタンプを判定に利用するようなWebAPIを呼ぶスクリプトも使えないだろうと思われる。

正直、現状でこれぐらいしか思いつかない。

とりあえず「2-3. [POMERA寄り妥協案]」で、意図せずRTCが変更されないようにntp同期外しておいた。

それにしても・・・

なぜに24時間なんだ?

  • JST(+9:00)なら「ああ、TimeZone=Asia/Tokyo準拠にしたんだ」となる。むしろありがたい。
  • (-9:00)なら「ああ、TimeZone=Asia/Tokyo準拠にしようとしてどっかミスったんだ」となる。
  • それ以外の+-12時間以内のズレなら「ああ、TimeZone準拠にしようとして間違えて全然別のTimeZone適用しちゃったんだ」となる。

↑ソースは俺(全部自分でやらかしたことがあるからw)。

意図的にずらしているにしては24時間ずらす意味が見いだせないので不具合かと思ったのだが、POMERAのシステム上ではつじつまが合っている(ファイルの書き込み時間なども問題なくPOMERAで設定した時刻で書き込まれている)ので、本来の使い方(DM200をPOMERAとして使う場合には)不具合とまでは言うことはできない。

引用:本家 Linux on Pomera DM200 人柱版 – 記録 :「聞かれそうな質問と回答」より。

Q. 内蔵のATOKは使えるのか
A. DM200標準のソフトは、よく使われるコマンド以外は画面描画処理も含めて基本的に1つのプロセスで動作しているようです。ATOKもそのプロセス内部で動いている(個別のプロセスとして存在しない)ようなので外から使うのは難しそうです。(以下略)

  • DM200上でLinuxOSが走り、その上層で1プロセスとして、ATOK等も含めた「POMERAアプリ(仮称)」が走っている。
  • POMERAアプリ(仮称)」ではすべて "RTC+24時間"で動作・完結している。
  • なので通常どおりPOMERAの動作としてはつじつまが合っている(ようにみえる)。
  • 前回の記事の通り、Ver1.3→Ver1.4では素のkernelやinitramfs周りでの変更は無かった。
  • ということは、もっとアプケーション寄りのところで何かしらの変更があった、と考えられる。

オリジナルのファームウェアのうち、kernelと「POMERAアプリ(仮称)」の間の層で何かが変わっているが解れば、こうなった理由がわかるのだろうか?

うーん・・・

まとめ

前回、「Ver1.4で問題無し!どや!」などと大手を振って公開してしまった手前非常にばつが悪いのだけど、ここにきてこんな状況だとは。まさか時刻関連でこんな変更があるなんて思ってもいなかった。
現状で解決策が思いつかない以上、Ver1.3 → Ver1.4へのアップデートを気軽にお勧めできなくなってしまった(いや、そもそも明確にお勧めしてたわけじゃないけども)。

なにかブレイクスルーが見つかるまでは保留とする。


謝辞: @ytakedaさんご協力ありがとうございました。