以前Raspberry Piを使って部屋の温度を定期的に取得するデータロガーのようなものを作りました。

結構長い期間データが溜まってきているので、データを分析してみたくなりました。SQLiteはそのままだとまさにデータベースなので、表計算ソフトなどで簡単に扱いにくく感じます。一応ODBC接続をすればデータ読み込みができるらしいのですが、それも面倒なので今回はSQLiteからCSVデータを書き出してみることにしました。

この作業はデータベースそのものをWindowsにコピーして実行するよりも、Raspberry Pi上でSQLiteの機能を使ってエクスポートするのが簡単です。

手順としては以下の画像の通りです。箇条書きにすると、

1. 事前にデータベースファイルのあるディレクトリにcdコマンドで移動する
2. SQLiteを起動し、目的のデータベースを開く
3. .headers on で出力するファイルのヘッダー行を表示するように設定する
4. .mode csv でCSVファイル出力をオンにする
5. .output [任意のファイル名].csv で出力するファイル名称を設定する
6. SQL文を入力すると設定の通りにcsvファイルが発行される
7. .quit でSQLiteを抜ける

このような手順になります。あとはcsvファイルを任意の環境に移動させて利用します。

今回メインのPCが故障した際の代替機としてRaspberry Pi 4Bを使いました。
これは以前室温センサーを組み立てたときの開発機として購入したものです。
本番のハードウェアは別途購入したRaspberry Pi Zero WHなので、開発機は開発完了後使っていませんでした。

一応スマートフォンもあるとは言え、できればキーボードと大きい画面が使える端末が代替機としては望ましいので、検証も兼ねてミニPCとして利用可能かどうか試してみました。

以前開発に使っていた時はやはり動作が緩慢な感じがしたので遅いのは仕方ないかと思っていましたが、今回試してみたところパフォーマンス面は大幅に改善しているように感じられました。OSがアップデートされて64bitARMに対応したことにより、以前より高速に動作するようになったそうです。

特に助かったのが動画の再生で、動画配信サービスで提供されている720p以上の高解像度の動画であっても特にカクカクすることもなく問題なく再生ができました。とりあえずWebブラウズと動画の再生だけでもできれば予備機としては合格点ではないかと思います。

少々気になったのはChromiumで日本語入力ができなかったことです。同時に入っていたFirefoxは問題なかったのでChromium側に原因がありそうですが、その点だけが不足でした。

デスクトップPC比で消費電力も非常に少なく、騒音もほとんどゼロに近いので、緊急時だけでなく普段使いもできそうな可能性を感じました。

データが読み出せなくなってしまったというHDDをダメ元で良いので復旧できるか試してみてほしいということでお預かりしました。確かにWindowsで読み込もうとするとデバイスマネージャーでは認識するのですが、未フォーマットのボリュームとして認識され、データにはアクセスできないようでした。

一応認識はするのでUbuntuを搭載したPCに接続し、Gpartedというパーティション管理ツールで修復ができないか試してみました。

GNOME Partition Editor

[gparted.org]

GpartedはGUIツールなのでLinuxに慣れていない場合でも使いやすく、”Attempting Data Rescue”というデータ救出の機能があるので、これが手軽に使えます。

試してみたところ最初はUbuntuでもマウントできなかったHDDが無事にマウントできるようになりました。一部データに破損があったので100%完全にデータを救えませんでしたが、大部分は回収して別のストレージに移すことができました。

Windows環境ではどうしようもなさそうに感じるストレージの故障も、Linuxを使うと意外にどうにかなることがあります。困った時には結構助けられています。

室温のロギングに使っているRaspberry Piのメンテをしようと思い、Windows付属のリモートデスクトップを使用してログインを試行しました。しかし、ID・パスワードとも正しいもののはずなのになぜかログインができず困りました。

通常使用のユーザーではなくrootであればログインできたので、rootでログインしてターミナルで sudo passwd [ユーザー名] と入力してパスワードを再設定して解決となりました。

非管理者のユーザーでpasswdコマンドを使うと現在のパスワードを入力した上で新しいパスワードの設定を行うことになりますが、管理者権限のあるユーザーであればそこからのsudo passwdで新しいパスワードのみを再設定できるので、こういう困った場面では便利です。

ファイルサーバ機が壊れてしまったので家からLinuxマシンがなくなってしまいました。
たまに操作を思い出す意味でも触りたくなるので、仮想環境を作ってみることにしました。

仮想環境のFedoraで表示した当blogの様子です。

Linuxはフォントの感じが優しくてそこが好みです。
常々「Linuxを常用したらどこが問題になるかな？」というのは心配しますが、こればっかりは実際に運用してみないと問題点も出てこないかも知れないですね。

天気も悪かったので久々にバックアップに使っているNASのフォルダ構成を見直しました。
この手の作業は悪天候の休日に限ります。

やはりどうしてもファイルは自分好みの方法で整頓しておかないとなんだか居心地が悪く感じてしまいます。

最初NASにアクセスできなかったのでRPから製品版になって何か変化があったかとしばらく悩みましたが、NAS側でsambaのサービスが動いていないだけでした。

せっかくのHyper-VだしLinuxの対応はどうかなと思ったら結構入れられるものもあるようです。

REHLとCentOSについてはLinux向けの統合サービスが提供されているので、おすすめはこの2種ということなのでしょうか。

一応ファイル置き場にFedoraが入っているのでLinuxを触りたいときはそれでもいいんですが、たまにはちょっと違うのを試してみたいなと思うこともありますんで…

Hyper-V自体は非常に優秀のようですので、Win8に入っているのはなかなか心強いです。

いろいろありましたがOSの入れ替えが完了しました。

Fedora14以前ではSambaのサービスを動かす時に、

/etc/rc.d/init.d smb start

とかこんなコマンドで起動していたのですが、Fedora16から?（この辺ちょっと不確実ですが）サービスの起動はsystemctlで行われているんだそうです。

なのでコマンドは

systemctl start smb.service

という風に変わっています。

後今回もSELinuxの設定を忘れてしばらく苦しみました。

なぜかUSBメモリからLiveインストールできない問題ですが、どうもGnomeデスクトップ版が原因のようでした。
エラー自体はFedoraのインストールプロセス中に

there was an error installing the live image to your hard drive.
this could be due to bad media.please verify your installation media.

という「インストールメディアが壊れてるのでは?」というエラーでした。
エラーメッセージで検索するとやはり「ファイルが壊れてるかもしれないからISOを検証してみては?」というまっとうな回答が出てくるのですが、Live起動した際にGnomeがエラーを表示するのが気になっていたのでLXDE版を試したところこちらは普通にインストールできました。

Gnomeの何が良くなかったのかは謎のままですが、とりあえず原因がデスクトップ環境の種別にあったのは間違いないようです。

16も出たのでいつも通りLive USB Creatorで起動USBを作ってインストール…と思っていたのですが、
インストールプロセス中に「インストールメディアが壊れている」云々というエラーが。

USBメモリに入れたisoファイルそのものは破損していないようなのですが再現性がありちょっと困っています。
とは言え、大至急の話でも無いのでまたネットで調べつつ頑張ろうと思います。
しかしまあ毎度ながらスルッとは行きませんね。