NBM2

natural born minority

about

「PCのハードウェアクロックが狂ってるとしっちゃかめっちゃかになる」話

技術的検証も、ハードコピーも、なーにも出来てないんですけど…

ともかく！ 「こんな事象になるんだ…」という「トラブった時疑うべき点」となる「貴重な体験」をしたっぽいので、あわててブログ書きました。

現象

ハードウェアクロック(マザーボード中にある時計)が、とてつもない未来(今回遭遇した例では”2172年”)に設定された状態では、 コンピュータの動作に著しい支障をきたす。

遭遇した環境

  • Linux(UbuntuLinux)
    • たまたまそうだが、事象から考えるにOSを問わなそう(未検証)
  • ノートPC(例のChromebock “Asus C300MA”)

遭遇した問題

  • DHCPサーバから、IPを取得できない
  • DHCPサーバから、プライマリDNSが取れない
  • 手動でIP、DNSサーバを設定しても名前解決が出来ない
  • 証明書が役立たず(HTTPS/SSL通信が出来ない)
  • NTPサーバを設定していたとしても「ネット繋がらない」ので自動補正効かず解決に向かわない
  • 電源切ると「ハードクロック側」を最初に参照するのでシステムクロックを補正してもまたおかしくなる
  • Linux的には
    • パッケージ管理がズタボロ(出来たり出来なかったりするので依存性がむちゃくちゃに)
    • Ubuntuのディストリインストーラが途中でこける

おそらくは「TTL(Time to live)のような”発行時間”と”有効期間(寿命)”のような概念」があるものが軒並みやられる感じ。

経緯

しばらく電源をつけてなかったマシンで、電源をつけるとハードウェアクロックが超絶未来になっていた。

設定も変えてない上「まさか時計の狂いぐらいで挙動に著しい支障をきたす」と思っていないため、原因をそこに見いだせず、ドハマリ。

(その間、めっちゃ時間をかけてインストールしたり、ディストリのバージョンを3つくらい行き来してみたり…の試行錯誤。)

対処(解決策)

インストーラが動かないせいで「内部ディスクのOSは当てにならない」状態となってしまったため、 USBメモリブータブルUbuntuLinuxを起動させ、そこで作業を行いました。

最初の時点で、どうやら日付がおかしい…。

date
2172年 10月 21日 水曜日 06:26:37 JST

DNSの名前解決をすると、以下のような状態になり、名前が引けません。

host google.co.jp
timer.c:811: fatal error: RUNTIME_CHECK(isc_time_now((&now)) == 0) failed
中止 (コアダンプ)

ここで「timer.c … ?」という疑いから、原因に辿りつけたのですけど…。

まず、システムクロック(ソフトウェア上の時間)を、「出来る限り現在の時間」に寄せて、補正しました。

sudo date --set '2015-11-04 23:15:00' # 正確でなくても良いです。ある程度寄ってれば…

この時点で、DHCPでのIP取得とDNSでの名前解決が復活します。

host google.co.jp
google.co.jp has address 216.58.221.3
google.co.jp mail is handled by 30 alt2.aspmx.l.google.com.
google.co.jp mail is handled by 40 alt3.aspmx.l.google.com.
...

よし、復活！…なのですが、インターネット参照が復活していることから、 NTPでの「時間合わせ」も復活してることをGUIで確認します。

NTPが上手く行った様子

うんうん、上手く行ってる。

最後に、元凶となった「ハードウェアクロック」を「システムクロック」から、上書きするコマンド発行して終了です。

sudo hwclock --systohc
# 確認
sudo hwclock --show
2015年11月04日 23時34分25秒  -0.845570 秒

小並感

いやー、今考えると「先ず最初に疑えよ」な感じなのですが…なまじ「Linuxの出来の良さに期待」している俺なので、解決にて間取りました。

もっとフラットな脳みそで問題解決には望まないとな、と反省した貴重な出来事でした。

blog comments powered by Disqus