趣味の電子工作などの記録。時にLinuxへ行ったり、ガジェットに浮気したりするので、なかなかまとまらない。
TAKEさんのLinuxブログをみてみたら、UbuntuがGUIで起動した、という記事がありました。
自分の方は先日失敗しているので、ちょっとみてみたら、BeagleBoard UbuntuのWikiに8月24日付けで新しいarmhfイメージが上がっていて、BeagleBone Blackについては、
BeagleBone/BeagleBone Black: v3.8.13-bone26 kernel ・Lots of hdmi fixes...
という記載が・・・・(^^;
ということで、BeagleBoard UbuntuのWikiに沿って改めて試してみました。
まず、SDイメージをダウンロードしてきます。これは上記Wikiの中の「Raring 13.04 armhf」の項目の少し下にある Prebuilt image のリンクを辿って入手します。
頻繁に見させていただいているTAKEさんのLinuxブログで音声合成の記事を見かけたので試してみました。
LinuxMint13で試してみたのですが、TAKEさんの記事の通りに
という手順で試してみたら、文字通り「あっ」という間に音声を発声してくれました。
漢字仮名まじりの文章でも何ら問題なく発声してくれるのでおもしろいです。（あ、漢字仮名交じりだけではなく、数字やアルファベットのSI単位系なんかもいけましたね）
＜追伸＞
パラメータをイジってみたくなりました。このあたりが参考になるかもしれない。
先日秋葉原に行ったら、SanDiskの新しいUSB3.0メモリを見かけたので買ってきました。しばらく放置してあったのですが、例によってOSインストールに使うとどうなるか、ということで簡単なベンチマークをしてみました。
ブツは、SDCZ48-032G-U46です。型番からわかる通り32GB品です。値段は馬鹿っ早のExtreme SDCZ80-032G-X46より少し安い程度でした。（すみません、具体的な金額忘れました・・・）
サイズはSDCZ80よりも2割くらい短い感じでしょうか。並べてみると２割くらいですが、実物では結構違いを感じます。コンパクトになっているので、このコンパクトさで性能が出ているのであれば・・・・と思って購入したわけです。
ベンチマークの方法は前回と同じです。
読み込みはパッケージの記載（80MB/s）にやや届かず、というところでしょうか。
書き込みの方は例によって625MBのISOファイルを書き込んでみたところ、開放まで約30秒、LEDの点滅が収まるまで約1分なので、開放までで20MB/sくらい、LED点滅が収まるまでで10MB/sくらいで、USB3.0のUSBメモリとしては凡庸な結果となりました。
価格差があまり大きくないことを考えると、やや大きくて嵩張りますが、Extremeを買った方がお得感は高そうです。
しばらく前に秋月でBeagleBone BlackをGetしました。
まずはMicroSDカード上にデスクトップ環境を構築してみました。
こちらのページ
http://www.armhf.com/index.php/download/
のからUbuntu Raring 13.04をダウンロードする。
ubuntu-raring-13.04-armhf-3.8.13-bone20.img.xz (June 9, 2013)
というファイル。
# xz -cd ubuntu-raring-13.04-armhf-3.8.13-bone20.img.xz > /dev/sdb
としてMicroSDカードにイメージを書き込む。
MicroSDカードを取り付けて、BOOTボタンを押しながら電源投入し、MicroSDカードから起動させる。
login: ubuntu / Password: ubuntu にてログインする。
$ sudo apt-get update
$ sudo apt-get upgrade
にてパッケージを更新
イメージを書いた状態だと、u-bootに1MB、システムに約2GBのみなので、MicroSDカードの容量一杯まで使うにはパーティションサイズの変更が必要です。一旦シャットダウンし、別のPCにてパーティションサイズを変更しました。
$ sudo apt-get install ubuntu-desktop
ものすごく時間がかかりますので、ひたすら待ちます。結局1時間以上かかりました。
再起動すると、グラフィカルログイン画面で立ち上がります。
・・・が、何か変です。周期的に画面が乱れます・・・。マウスカーソルの表示をトリガーにしていそうです。
リモートデスクトップ接続のため、xrdpをインストールします。
$ sudo apt-get install xrdp
ホスト側から rdesktop で接続しようとすると、「unable to connect」で蹴られてしまいます。
おそらく、iptables で蹴られているものと思います。
簡単に済ますため、
$ sudo apt-get install ufw
$ sudo ufw disable
として、firewall 機能を無効にしたところ、ホスト側から
$ rdesktop 192.168.1.108
で接続できました・・・・が、ログインすると途中でエラーを吐いて黙りこんでしまいました・・・。
デスクトップ環境のインストールを
$ sudo apt-get install xubuntu-desktop
として、xubuntuにすると、「Failed to load session “gnome”」というエラーでやはりダメでした・・。
引き続いて8.3章のカーネルのインストール以降の作業です。
続いてブートスクリプトの設定です。
前回、最後にpartimageでバックアップをとるために umount しましたので、それを改めて mount するところからです。
第6章「基本的なソフトウェアのインストール」に進みます。
ここまでの作業のバックアップはパーティションイメージとtarで取得済みです。
ここからの作業は5章の最後に書いてある通り、rootで行います。特に問題や気づいた点がない限りはHTML版のLFS BOOKからコピペで進めていきます。
ちょっと治具を簡単に手持ちのPIC12F675で作ろうとしたのですが、ハマってしまいました。
今回の環境はMPLAB-X + XC8を使ってみようと思ったのですが、これがハマりの元凶です。
まずはLチカで環境に問題がないことを確認しようとしていたのですが、そこで引っかかりました。
Lチカプログラムはこんな感じで、何の変哲もありません。
しかし、コンパイルして動かそうとすると動きません。
いろいろ設定を疑ってみたものの、うんともすんとも言いません・・・・。
プログラムメモリの内容をディスアセンブル表示させると、先頭は
というような感じでした。001番地にCALL 0x3FFがありますが、これは確か3FF番地にはRETLW命令が置いてあって、Wレジスタにクロック周波数の補正値を入れて戻ってきて、その後、OSCCALレジスタにWの値を書き込む（上記で言うと、レジスタバンクを１に切り替えてからT1CONのアドレスに書き込む）ことで、周波数を補正していたはずです。
しかし、不安になって、WindowsでPickit2でROMの中身を吸い出して見たところ・・・・・3FF番地の値が0000（NOP）になってました。これでは001番地のCALL命令で無限ループになるので動くわけがありません。
Pickit2にはクロック周波数補正値を回復する機能があるので、それで3FF番地の値を回復させて、改めてMPLAB-Xで書き込んでみるとLチカが動作しました。・・・が、再度コンパイルして書き込んでみると、やっぱり動きません。
Pickit2で見ると、また3FF番地の値が消失しています。この状態をPickit2で吸い出してHEXファイルに保存し、補正値を回復させ、改めて吸い出したHEXファイルを書き込むと、Pickit2は補正値を保存するので、ちゃんと動作しました。
とにかく「MPLAB-XとPIC12F675の組み合わせは使い物にならない」ということがわかりました・・・。
続いて第5章の一時的環境の構築を進めます。
普段、自宅ファイルサーバとして利用しているFreeNASですが、正常系は問題なく動作しているものの、トラブルが起きた場合の処置についてはこれまで調べてきませんでした。
そこで、今回ちょっと調べてみたいと思います。
まず、VMware上にFreeNAS9.1の32bit版をインストールしました。ホストシステムが32bit+PAEカーネルのLinuxMint13なので、FreeNASも32bit版を選択しました。
起動用のHDDは10GB、データ用のHDDはSCSIで10GB×2（それぞれのディスクに1A,1Bという名前を付けました）としました。
インストール自体は特に問題ありません。ホスト名などは適当にvmFreeNASとしました。
インストール後、パスワードを設定し、10GBのディスク2本で暗号化ありのZFSボリュームをミラーで作成しました。
これをCIFSで共有するわけですが、いつものことながら、今ひとつよくわかりません。設定してからLinux側から見えるようになるまで時間がかかるためでしょうか。
まあ、今回の目的は暗号化関連なのでよしとします。
適当なファイルをvmFreeNAS側に置いた状態で、今度は暗号化ZFSボリュームにパスフレーズをつけてみます。これまでは暗号化していてもパスフレーズもなしで運用してきました。
仮想FreeNASサーバを２台動かして、1台目のディスク2台（ミラーなので）をコピーして、そのうちのディスク1台をFreeNASサーバ2台目に付けてみます。
普通にボリュームを作成しようとすると、中身のあるディスクとしては認識されず、初期化しようとします。つまり、ディスクを持ち出しても読み出せそうにありません。
しかし、「ボリュームの自動インポート」を行うと、暗号化ボリュームをインポートするか聞いてきます。
ここでYesを選んでOKを押すと、
暗号化キーを確認してきます。ここで、元のFreeNASサーバからエクスポートした暗号化キーのファイルを指定してやると・・・ボリュームも指定しろ、とエラーがでました。（下記）
とにかく、両方指定してやると、
元のボリューム名を確認してきます。そこでOKを押すと、
無事にインポートされました。シェルで中のファイルを見ると、確かに存在していそうです。ミラーしたディスクの片方しかマウントしていないので、DEGRADEになっていますが、とにかくファイルの救出はできそうな感じです。
なお、ミラーを構成する２つのディスクを接続してからボリュームの自動インポートを行い、ディスクを指定する際に２つとも指定してやるとミラーであることを認識してミラーディスクとしてインポートされました。
一度でも片方だけでインポートすると、一旦ボリュームをデタッチしてもミラーとしてはインポートされなくなるようです。（当然といえば当然な気がしますが・・）
実験１をまとめると、暗号化キーとミラーディスクの片方があればデータは復旧可能。
もう一つ気になっていたことがあります。暗号化キーにパスフレーズをつけた場合に、起動時に入力が必要なのかどうかです。これまでは起動時に入力するのは面倒なので、パスフレーズをつけずに運用していました。
一方で、考えようによってはパスフレーズを入力しなければ決して中身の見えないサーバとして運用することもできるかもしれないわけです。
というわけで、実験してみました。
先に２台のディスクのコピーを持ち込んだらHEALTHYに復帰した２台目の方で、パスフレーズをつけて再起動してみました。
起動後、ボリュームはロックされた状態になりました。
ロックされたボリュームを選択して、下の方のUnlockをクリックします。
パスフレーズを入力して「OK」をクリックします。
無事にアクセスできるようになりました。（正確にはCIFSでアクセスできるかは確認していません。例によって、見えたり見えなかったりが不安定なので。シェルでディレクトリやファイルの存在を確認しただけです。）
実験２のまとめ：パスフレーズを設定すると、起動後にパスフレーズを入力するまではアクセスできない。