ラベル Raspberry Pi 3 Model B の投稿を表示しています。 すべての投稿を表示
ラベル Raspberry Pi 3 Model B の投稿を表示しています。 すべての投稿を表示

2018年9月18日火曜日

Raspbianのlatest firmware (4.14.70-v7+ #1143)がshutdown時にkernel panic

*** このページの不具合は修正済み (2018-09-22更新) ***

shutdown / reboot時にkernel panicする不具合は4.14.70-v7+ #1144で著者の環境では再現せず、修正された模様。

なお、2018-09-22現在の最新版は4.14.71-v7+ #1145である。

*** 以上 ***


Raspberry Pi 3 model B (RasPi3B)をRaspbianで運用しているが、rpi-updateでupdateした最近のfirmware (4.14.69あたりから? 2018-09-18現在最新の4.14.70-v7+でも)だと、shutdown時にkernel panicを起こしてrestartしない。

普段RasPi3Bをheadless (displayに繋がずに)運用しているため、なぜrebootしないのか原因が分からなかったが、試しにHDMIにLCDを繋いでみたところ判明した。

Raspberry Pi Forumsによると、

* Bluetoothのon/offによる → BTがoffだとkernel panicする
* USBからのbootだとこのbugがaffectする?

などの書き込みがある。

workaroundとしては、8月中旬ごろのfirmwareにdowngradeする手がある。

cf.

* [Is this a stable kernel? - Raspberry Pi Forums](https://www.raspberrypi.org/forums/viewtopic.php?t=222448)
* [After last updates RPI 3+ hangs on shurdown/reboot if bluetooth off - Page 2 - Raspberry Pi Forums](https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=222475&start=25)

2018年6月15日金曜日

watchdogを導入したRaspbianでsudoが使えなくなったのでfork bombでrebootさせた話

Raspberry Pi 3 model BにRaspbian (armv7l)を入れて有線routerとして利用しているが、sudoがsegmentation faultを吐いて使えなくなる状況に陥った。

どうやらsudoのpermissionがおかしくなったことが要因らしいが、理由はどうあれRaspbianでsudoが使えないのは致命的である。普通にinstallして特に設定しない場合、Raspbianではrootとしてloginできない。一般userが必要に応じてsudoする運用が前提だからだ。

こうなると、aptでsystem updateも、rpi-updateでfirmware upgradeも、shutdownもできない。最終手段として強制的に電源を切る (=microUSBのcableを引っこ抜く)ぐらいしか思い付かないが、NAND flashのstorageではあまりやりたくない (HDDでも嫌だが)。

そこで、watchdogをinstallしていることを思い出し、fork bombでsystemをdownさせてrebootさせようと思い付いた。つまり:

* fork bombを発動
* watchdogが発動 → reboot
* boot processでfsckが実行される → filesystemが修復されpermissionが回復
* sudoが使えるようになる (はず)

fork bombにはshell scriptで実行する方法と、Cあたりでprogramを書いて実行する方法がある。今回はshell scriptより速く効きそうなCでprogramを書いて実行した。

#include <unistd.h>

int main(void){
  while(1){
    fork();
  }
}
これをforkbomb.cとして保存し、gcc -o forkbomb forkbomb.cでcompile。実行前に気休めとして一応syncを発行しておく。

./forkbombを実行。systemがfreeze → watchdogによりrebootがかかるのを待つ。

無事rebootし、fsckが実行されたのか、sudoは何事もなく使えるようになった。


2017年8月2日水曜日

Raspbianで起動時にscriptを自動実行させる

Raspberry Pi 3 Model B (RasPi3)で部屋のLED照明とか、RasPi3自身の冷却ファンのPWM制御とか、室温の計測&loggingをさせている。それらのscriptを起動時に自動実行させたくなったので調べてみた所、以下のwebpageがとても参考になった (というかそのものズバリ)。

* [Raspberry Piでプログラムを自動起動する5種類の方法を比較・解説](http://hendigi.karaage.xyz/2016/11/auto-boot/)

採用した方法と理由


題にもあるように5つの方法が紹介されているが、個人的な用途やpros/consを考えると
cronのjobとして登録する方法が一番のお勧め。

* 登録と削除がcrontab -eで出来て楽
* 起動するscriptはuser権限で起動する

cronを使う時の問題点 (2017-08-25追記)


RasPi3はRTCを持たないので再起動時した直後など暫く時刻がズレていることがある。室温・湿度などをCSV fileに記録する際にはこれが問題となり、本来時系列順であるべき所がいきなり時間が戻ったりする。

19:01:03 ...
19:01:04 ...
18:30:33 ... <--- ここから...
...
18:30:52 ... <--- ここまでおかしい
19:03:12 ... <--- NTPで補正された
19:03:13 ...

cron側でNTPで時刻が補正される迄実行しないようにできれば一番良い。試してはいないが、systemdを使っているのだから依存関係を適切に設定すればNTPの実行後にcronを立ち上げられるような気もする。

取り敢えずsensorから値を取得するscriptの冒頭で、現在時刻とlog fileのmtimeとを比較して、現在時刻がmtimeよりも前 (eg. 現在=16:30でmtime=17:00)なら異常と判断してNTPによるsyncを待つようにした。

発展


もしこれで足りなければ (super userで動かしたいとか)、/etc/rc.localに細工 (exit 0の前あたりに追記)する方法を取る。

正当なやり方はsystemdのserviceとして登録する方法なんだろうけど、たかが小さなscriptを自動実行させたいってだけであんな長ったらしい設定fileを書くのは面倒すぎる。

補足


検索時に気になったのは、あちこちに残っている古い情報が検索の上位に出て来ること。例えばRaspbianのdefault init systemがsystemdに移行したとかの事前情報が無いと、上手く起動しないとか、設定fileが無いとか、無駄に混乱する原因になりそう。