So-net無料ブログ作成
プログラム 記事一覧(10件ずつ)
プログラム ブログトップ
前の10件 | -

MSP430 LaunchPadとVirtualBox [プログラム]

MSP430の開発環境(linux版の場合)も64bit専用となりつつあり、非常に困ったものです。
Energiaにしろ、CCS7にしろ、64bitOS専用です。
なので、私はVirtualBoxに64bitOSを入れて、そこにMSP430の開発環境をインストールして使っています。

しかしながら、VirtualBoxだと、USBの問題を片付けなければなりません。
VirtualBoxから、ホストに接続されたUSBデバイスを操作するには
(a) VirtualBoxでUSB2.0,3.0を扱うためには、ホスト側にExtension Packをインストールしなければならない
(b) それが何のデバイスかをホストが知っていなければならない
ということのようです。

CCS7をインストールするとして、
(a)のExtension Packの方は、VirtualBoxのサイトからダウンロードしてインストールすればよいです。
(b)の方は、MSP430のCCS7/etc/udev/rule.d/71-ti-permissions.rulesを追加して、/etc/init.d/udev restartすればよいです(が、実は、それだけではダメでした)。

これらをして、MSP430のサンプルコード(出荷時に書き込まれているもの)をTIのサイトからダウンロードして、CCSでimportしてビルドしました。
ホストに接続したLauchPadを、ホストが認識したことを確認して、VirtualBoxの方でそのUSBデバイスを有効にすると、ゲストの64bitOSが認識しました。
CCSの設定で、デバッガ(ICEの設定)をそれに変更し、ビルドしてダウンロードしてデバッグに入ります。
が、アラートが出て、「LaunchPadの方の『eZ-FET on-board emulator』のファームウェアを更新する必要がある」と言われてしまいました。
なんとなく「update」ボタンを押してしまったら、... 緑と赤のLEDが点灯したまま止まってしまいました。数分待ったでしょうか、エラーメッセージがでました。updateに失敗!!! え? LaunchPadがいきなりゴミになった!?
こんな状態になることは少なからずあることなので、当然回復させるための手段があるはずですが、どうやるのでしょう?

まず、LaunchPadのUSBケーブルを一度抜いて挿し直してみます。当然、デモプログラムも動きません。
ホストもUSBデバイスを正しく認識できていません。USBデバイスとしては認識していますが、71-ti-permissions.rulesにあるデバイスではないので不明なデバイスとなり、(b)ができないため、VirtualBoxで使用できない(ゲストOSで使用できない)、ということです。
LaunchPadのeZ-FET on-board emulatorが初期化されたため、71-ti-permissions.rulesにはない、MSP430の素のUSBデバイスになっているようです。なら、これを71-ti-permissions.rulesに追加してやったらどうでしょうか? dmesgの出力をみて、VendorとProductのIDを追加してやります。
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",
ATTRS{idVendor}=="2047",ATTRS{idProduct}=="0203",MODE:="0666"
udevを再起動して、LaunchPadのUSBケーブルを差し直すと、デバイスとして認識しました。これでVirtualBoxでそのUSBデバイスが見えるようになりましたので、それを有効にしますと、ゲストOSからそのUSBデバイスが見えるようになりました。

そして、CCS7を起動して、デバッグしようとすると、「LaunchPadの方の『eZ-FET on-board emulator』のリカバリが必要」というので、リカバリすると、赤のLEDが不規則に点滅し、しばらくして、デバッガが起動しました。おお、ゴミからLaunchPadに戻ったよ。
続けて、CCSでソースレベルデバッグができることを確認しました。

これでやっと本来のプログラムへ進むことができます。やれやれ。


共通テーマ:パソコン・インターネット

UEFIでの起動 [プログラム]

BIOSの問題で、「3TB(GPT)のHDDからlinuxを起動できないけど、2TBまでのパーティションだけ(MBR)だったら起動できる」ということをやっていたHDDがありまして、今回、UEFIについて調べて、なんとかMBRからGPTへ、UEFIでの起動ができるようになりました。その作業メモです。

注意: ここでの内容の正確さは保証できません。起動できなくなっても自力で解決できる人向けの情報です。

ここでのBIOSの問題とは、おそらく、
gdiskを使って、GPTでパーティションを作成すると、MBRのパーティションがprotective MBRになってしまって、そこにbootableなパーティションがないから、MBRのブートストラップを実行しない
のではないかと思われます。
そんなBIOSでも、時期によっては、
UEFIでの起動がサポートされていて、ちゃんとUEFIの起動の作法に合わせるとGPTを理解して起動できる

ようなものがあります。

以前3TB買ったときは... 面倒だったので、2TBまでのパーティションでMBR onlyとしたのでした。
今回、それをUEFIにして、未使用部分でパーティションを拡張します。
UEFI化するとき、今回は、現在起動中のHDDをそのまま使って行ないます。そのため、慎重に操作しなければなりません。

操作の概要は、次のとおり。なお、swapを止めても動作できる程度のメモリを積んでいることが前提です。linuxのコンソールなら、4GBでも十分でしょう。

まず、EFIのパーティションが必要です。
EFIのパーティションは、数10MBもあれば十分ですので、swapパーティションからもらうことにします。
swapを停止し、fstabのswap行を一時的にコメントアウトしておきます(でないと、再起動のときに90秒も待たされます)
その後、gdiskを使って、MBRからGPTを作り、swapパーティションを削除し、そこにEFIパーティションを作成して、書き込みます。
次にEFIパーティションをFAT32でフォーマットして、/boot/efiのディレクトリを作って、そこにマウントします。
そして、grub-efi-amd64をインストールし、EFI用のgrubをインストール(grub-install --target=x86_64-efi /dev/sda)して、EFI用のブートローダ(/boot/efi/EFI/debian/grubx64.efi)をインストールします。そして、それをEFIでのデフォルトの起動パスの位置(/boot/efi/EFI/boot/bootx64.efi)にコピーします。


# swapoff -a
# vi /etc/fstab   ← swapの行をコメントアウトします。
# gdisk /dev/sda
    rのfで、MBR->GPT(+protected MBR)にします。
    mで戻って、dでswapパーティションを削除し、そこにnで数10MBのパーティションを作ります。tはEF00のEFIパーティションです。
    さらにnで、残りの部分をswapにします。
    vで確認してから、wで書き込みます。
# mkfs.vfat -F32 /dev/sdaX    ← EFIパーティションをFAT32でフォーマットします。
# mkswap /dev/sdaY  ← swapパーティションをフォーマットします。
# mkdir /boot/efi
# mount /dev/sdaX /boot/efi
# vi /etc/fstab   ← /dev/sdaXを/boot/efiにマウントするようにします。(これは行わなくても構いません)
# apt-get install grub-efi-amd64
# grub-install --target=x86_64-efi /dev/sda
# mkdir /boot/efi/EFI/boot
# cp -a /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/boot/bootx64.efi
# sync
# reboot   ← 再起動します。
    再起動では、念のためrecoveryを選んで立ち上げます。再起動に失敗したら、Debianのインストーラのrescueを使って復旧します。
    rootのパスワードを入力して、シェルに入ります。
    EFIで起動したかどうかは、/sys/firmware/efi/があるかどうかで判断できます。
    問題なさそうなら、
# swaplabel /dev/sdaY    ← swapのUUIDが表示されますので、それをfstabに書き込みます。
# vi /etc/fstab  ← swapの行を、そのUUIDを使用して修正します。
# sync
# reboot

未使用だった領域を使えるようにするには、新しいパーティションを作るか、あるいは、gparted liveを使ってパーティションを拡大するか、です。私は、操作が簡単なgparted liveをUSBメモリにべた書きしてそれ使って拡大しました。



共通テーマ:パソコン・インターネット

configureのGTK+のチェックでエラー [プログラム]

ちょっと特殊な問題でしたが、 pkg-config がおかしな挙動をする、ということで、書いておきます。

linuxで、GUIのあるアプリをビルドしようとして、configureすると

      checking for GTK+ - version >= 2.6.0... no
      *** Could not run GTK+ test program, checking why...
      *** The test program failed to compile or link. See the file config.log for the
      *** exact error that occured. This usually means GTK+ is incorrectly installed.
      (以下、GTK 1.2.7も3.0.0もチェックでnoになる)

 で、「GTKがない」と言われてしまいます。
でも、GTK+パッケージは、2.xも3.0もインストール済みなのです。なんで?

前から、このエラーでコンパイルできなかったものがあったし、ということで、今回、解決するまで調査することにしました。

configureをいじって調べていくと、GTK+のチェック部分で、

      pkg-config gtk+-2.0
      pkg-config --uninstalled gtk+-2.0
で、どちらも1 (エラー)が返ってくるという、とんでも仕様。はぁ?
とりあえず、configureがこの先でやることを試そうとして
      pkg-config gtk+-2.0 --cflags
したら、
      libpng 16がインストールされているべきなのにないからエラーだよん
とか表示されてました。

ググって調べてみると
      http://www.linuxquestions.org/questions/slackware-14/fail-to-compile-wireshark-4175510119/
に、libpng14がないと、エラーすることがあるというのを見つけました。
同じ理由かも?

/libや/usr/libを調べてみると、
libpng12はインストールされてたけど、libpng16は入ってません。
なんでかなー...

記憶の彼方を探ると、
libping12でないと動作しない「重要な何か」があったから、固定したような、そうでないような。

とにかく、ま、libpng16をいれましょう。
      sudo apt-get install libpng-dev
で、どこに入れたんですか?
/lib/i386-linux-gnuには、libpng12のままで、16はありません。はて?
/usr/lib/i386-linux-gnuに12と16(1.6)が同居してました。

こんなめちゃくちゃなインストールでいいのでしょうか...

とりあえず、
     pkg-config gtk+-2.0 --cflags
が動くようになりました。
やれやれ、これで、今までどうしてもconfigureできなかったやつらがコンパイルできるようになります。

共通テーマ:パソコン・インターネット

秋月の800x480のHDMIディスプレイにRaspberry PIをつなぐ [プログラム]

秋月の「7インチ TFTカラー液晶モニター NTSC HDMI対応」[SJ-781H]にRaspberry PIをつないでみました。

設定は、
    http://akizukidenshi.com/download/ds/akizuki/raspberry.pdf
にありますが、config.txtに以下を追加せよ、とあります。
hdmi_group=2
hdmi_mode=14
hdmi_cvt = 800 480 60 6 0 0 0
しかしながら、最近のRaspbianだと、この表示ではボケボケで使い物になりません。

結論から先に言うと
hdmi_mode=87
にすればOKです。


ググって調べると、同じようなLCDで別のパラメータを与えているページがあったので、
まず、基本のページ

    https://www.raspberrypi.org/documentation/configuration/config-txt.md

を調べると
hdmi_group=2
hdmi_mode=14
のときは、
 848x480 60Hz
になってしまいます。でも、LCDは800だったはず。
原因はこれですね。横のピクセル数が間違ってる、というわけです。
で、正しい(800x480 60Hz)値は、というと、...

なんと、その表の中にはありません。
はて?

基本のページのhdmi_cvtのところを読むと、
「hdmi_modeの表に合うのがなければ、hdmi_cvtで定義可能」
とあります。なるほど。
hdmi_cvt = 800 480 60 6 0 0 0
は、
800x480 60Hz、アスペクト比 15:9、マージンなし、プログレッシブ(インターレースでない)、ReducedBlankではない
です。

さらに、基本のページのその先には、800x480 60Hzの例がありました。
「group 2 mode 87」で新しいモード(800x480 60Hz、音声付き)を作るには
hdmi_cvt=800 480 60 6
hdmi_group=2
hdmi_mode=87
hdmi_drive=2
と書け、とあります。
なるほど。

以上のことから、
hdmi_mode=87
に設定すれば、正しく表示できることが分かります。これで、ちゃんと表示されるようになりました。


RaspberryPiとBeagleBoneBlackの世界は、アップデートが激しいので、このページの情報も古くなるときがくるでしょうが、そのときは、基本のページ
https://www.raspberrypi.org/documentation/configuration/config-txt.md
を見て、最新の情報を得て修正してください。

タグ:raspberrypi

fsprotect再び [プログラム]

BeagleBoneBlackのDebianで、aufsがサポートされ始めました。ですので、fsprotectが、パッケージをインストールするだけで使えるようになりました。

で、早速使ってみました。SD上のrootfsはext4フォーマットになっています。
    tune2fs -i0 -c0 -m0 /dev/mmcblk0p1
したあと、uEnv.txtのcmdlineに「fsprotect ro」を追加して再起動しました。

ふむ。問題なさそうです。

...と思ったのですが、その後、丸1日、「なぜprotectしてくれずに書き込みやがるのか」という大問題にぶつかることになりました。
そうです、linuxがrootfsに「書き込む」のです。しかしながら、書き込んだ形跡をfindで探しても見つかりません。また書き込んで削除したらディレクトリの日付が変わるはずなので、そういうことでもないようです。

調査対象をファイルシステム全体に広げると、見つかりました。ちょうど1バイトだけ変更されていました。
それは、ファイルシステムの先頭から1401バイトめでした。

何が書き込まれた(変更された)のか? それを知るには、まず、ext4の構造(レイアウト)を知らなければなりません。
ext4の構造は
     https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout
などにあります。
1024バイトまでが Group0 paddingで、次からsuperblockになっています。
1401バイトは、superblockの中です。superblockの1401-1024=377バイトめ、つまり、0x179バイトめは
0x178  __le64  s_kbytes_written  Number of KiB written to this filesystem over its lifetime.
の下位から2バイトめです。
「このファイルシステムへ書き込んだKiB数」だということですから、「間違いなく書き込んでいます」。protectしてくれてません。はて?

なお、このs_kbytes_writtenは、「ext4をマウントした後では」、sysfsから読むことができます。たとえば、
    cat /sys/fs/ext4/mmcblk0p1/lifetime_write_kbytes
とすればわかります。さらに、これを下記のように直接/dev/mmcblk0p1から読むこともできますが、この場合、注意すべき点があります。
    dd if=/dev/mmcblk0p1 bs=1024 count=2 | hexdump -C |grep 0000570
注意点は、「ReadWriteでマウントしているとき」、実際にファイルシステムへ書き込んでも、この値は「変わりません」。アンマウントするときに、ここへ書き込まれるようです。

さて、誰かが書き込んでいるわけですが、それがなかなか分かりませんでした。
まず、書き込みが、起動時なのか終了時なのかについては、他のマシンでSDカード上のrootfsのlifetime_write_kbytesを調べることにより、「起動時」と分かりました。

起動時のどこでしょうか? initramfs内でしょうか? fsprotectの前でしょうか? fsprotect時でしょうか?
initramfs(/boot/initrd.img-*)をgunzip+cpio展開して、中を調べていくと...
ひょっとして!? fsckしてからマウントするようになっています。もっともそれはUN*X時代からの流儀で、突然の電源断などのあとでは、そのfsckが大活躍したものです。/fastboot というファイルがあると、/etc/fstabでfsckするように設定されていもfsckを行いません。ただ、/etc/fstabは、通常rootfs上にありますので、rootfsについては、カーネルの起動パラメータ(fastboot)で指定するようです。

(書き込まない)ReadOnlyのrootfsに対してfsckを実行することが正しいのかどうかについては、NANDのデータ保持期間など議論があるところでしょうが、ともかく、このfsckを「止める」ことにします。

uEnv.txtのcmdlineにfastbootを追加して、結局、「fsprotect ro fastboot」の3つを追加しました。
また、起動時にfsckをしないため、他のPC上でfsck -fをして問題ないのを確認してから、BeagleBoneBlackに差し込んで起動しました。

そして、
    cat /sys/fs/ext4/mmcblk0p1/lifetime_write_kbytes
を見たあと、再起動して、再度
    cat /sys/fs/ext4/mmcblk0p1/lifetime_write_kbytes
したとき、同じ値になっていることを確認しました。



今回の検討点としては、
  • initramfs内のスクリプトで、ReadOnlyのrootfsに対してfsckを実行して書き込みをするのが正しいのかどうか
  • 一般的にReadOnlyのrootfsに対してfsckを実行して書き込みをすることが正しいのかどうか
ということになるでしょう。
個人的には、
  • ReadOnlyのrootfsについては、まず、fsck -nで書き込まずエラーの有無を調べる。
    エラーがあったときは、fsckを行うか、起動中止するか、のいずれかを
    「なんらかの方法で選択して」行うようにする。
のがよいのではないかと思います。まぁ個人的にinitramfs内のスクリプトを書き換えてもよいのですが、本当にReadOnlyで運用開始するのでないかぎり、initramfs関連のパッケージのアップデートがあるたびに対応しなければならないので、非常に手間がかかります。
今回の問題では、「起動するときにだけ」SDに書き込むので、もしも基本24時間稼働であれば、再起動は半年〜1年に1回くらい(経験的な値)なので、書き込む回数としてはまったく問題がない程度でしょう。

共通テーマ:パソコン・インターネット

マザー入れ替えで、シグナルのキャッチに失敗する [プログラム]

省エネのため、i5-4670マザーとFX8350マザーを入れ替えました。やっていることは同じでも、もちろんAMDの方が遅くて電力食いなので、長時間動作の方をi5に入れ替えたのです。そちらは大して問題ないようにみえました。
ところが、入れ替えてFX8350のマザーになったマシンで動いているプログラムが、SIGHUPの受信に失敗して、プログラムが停止してしまいました。なんじゃこりゃ。

はて、なんででしょう... あ、こいつ、ビルドするのに -march=native を使ったんだっけ。
となると、ソースからリビルドです。プログラムをリビルドすると、問題なくSIGHUPを受信できます。

うーむ、プログラムを少しでも速く動かさなければならなかったので、-march=nativeとしたのですが、良し悪しですね。マザーを変えたので、いずれプログラムをリビルドするべきなのはわかっていましたが、「すぐにでも」やらないと、シグナルがちゃんと動かないなんてのは知りませんでした。まさかと思いますが、ひょっとして、計算結果も間違ってたりするのでしょうか... こ、怖い...


共通テーマ:パソコン・インターネット

無線ルータにリフレクタを [プログラム]

前回、「無線ネットワーク不調」のため無線ルータを入れ替えましたが、まだときどき数分間だんまりになってしまう状況でした。

ひょっとして混線?
WiFi ExplorerやinSSIDerとは言わないまでも、何らかの調べるツールが必要だなーと思いました。
無線ルータにその機能はなかったので、昔、買っておいたWiFiのUSBアダプタを引っ張りだしてきました。Ralinkのチップが載っているものですが、これはファームウェアをダウンロードしなくてはならず、以前はlinuxで動かすのに割と手間がかかっていたものです。が、現在のlinuxでは、ファームウェアダウンロードの仕組みが統一的に組み込まれて、non-freeで必要なパッケージをapt-getすれば普通に使えてしまうようになりました。こういう正しい進化は実に望ましい進化ですね。

で、そのWiFiアダプタを使って、WiFi関連のコマンドを調べていると、「ふむ、これは自分で書けそうだ」という気になったので、perlで書いてみました。よくあるGUIでなく、「テキスト画面にグラフを出す」方向で。コンソール上でも使えるので、却って便利かも? (負け惜しみ:-)。

結局のところ、
  iw wlan0 scan
の出力を加工するだけなので、SSIDを出さないステルスAPでの通信は表示されません。ま、いいか。

いくつかのポイントがありました。

  • rfkill unblock 0 などで、ハードやソフトでの使用禁止を解除しなければならない場合がある
    私の使っている別のノート内蔵のWiFiモジュールだと、iwconfig wlan0 txpower offが、rfkill block 0と同様な動作のようでした。
    いつもtxpower offしていたので、これが必要でした。
  • ifconfig wlan0 up したときに、ファームウェアがダウンロードされて、WiFiアダプタが動き出す
    ファームウェアがダウンロードされるまでは、WiFiアダプタは実質的には動作しません。
  • WPA2はRSNと表示されている
    iw wlan0 scanの出力の中に、WPAという表記はあるのに、WPA2という表記がありませんでした。
    代わりにRSNというのがあって、ググってみると、こいつがWPA2のことでした。
  • 同じチャンネルに複数のSSIDがある
    同一のAPから出力されているものだけでなく、別のAPから同一チャンネルで出力されているようです。
    おそらく、その2つ(以上)のAPが離れているために混線していないのでしょう。
  • cursesでなく、tputを使った
    画面を消さずに左上にカーソルを移動するだけですが。tputなんてコマンドがあったんだー。
で、こんな感じの出力が。
Sun Aug 30 00:54:59 JST 2015
Ch: . 8 . 7 . 6 . 5 . 4:SSID;name/E,+APs
 1:+                   :l******user/2,game/E                                    
 2:                                                                             
 3:                                                                             
 4:+++8+++7+           :aterm-******-g;WR8750N/2,-gw/E                          
 5:+                   :auhome_******/2,-W/E                                    
 6:                                                                            
 7:                                                                            
 8:                                                                             
 9:                                                                            
10:                                                                            
11:+++8                :aterm-******-g;WR9500N/2,-gw/E                          
12:                                                                            
13:                                                                            
別に混んでないなー。別のところ(窓際)だと、ほぼ全チャンネルが使用状態だったりしたのですが...
私が使っているのは8チャンネルですが、ここは使われていないようにみえます。

となると、おそらく私と同じようにステルスAPで通信している人がいるのかもしれません。
あるいは、ステルスAPなので、空きチャンネルと思って通信を開始する機器があるのかもしれません。
後者だとすると、SSIDをブロードキャストするようにしてやればよいのですが、それは思案のしどころ。

チャンネルを変えるのもひとつの手ですが... 11a/11acへ移るのも考えましたが、まだ機器が高い。
有線部分の無線置き換えのための無線機器を、最近はイーサネットコンバータと呼ぶらしいです。知らんかったー。

で、リフレクタのページを見つけました。早い話、中華鍋をAPの後ろに置く、というもの。パラボラですな。
円弧のもの、放物線状のもの、鍋など、いろいろとありましたが、まぁ簡単に自作できるもので試してみたとこです。
http://www.freeantennas.com/projects/template2/index.html
これは、ロッドアンテナにぴったりのもので、200円無線ルータにはちょっと合わないのですが、紙なので、ちょっと細工して取り付けました。
で、結果は... 少しマシになったような「気がします」。


もし、これが効果ないのなら、導波管を考えています。
2.4GHzは波長が12.5cmくらいなので、やや大きくなってしまいますが、ダンボールとアルミホイルで作れるでしょう。
通信距離は、直線でコンクリートの壁を挟んで1mくらい。なので、リフレクタよりも導波管のほうがきっとよいでしょう。
他所への漏れ電波も減りますし、逆に入ってくるの(混信)も減るはずですから。

共通テーマ:パソコン・インターネット

無線ネットワーク不調 [プログラム]

以前RaspberryPiやBeagleBoneBlack作ったLANの無線路ですが、不通になりました。
再起動してみたり、RaspberryPiに戻してみたりしましたが、ダメでした。
で、無線ルータを入れ替えたところ、復活しました。
ま、210円の無線ルータですしね。
たくさん予備を買っておいてよかった、というところです。

さて、取り外した(壊れたはずの)無線ルータですが、念のため
何が壊れたのかを確認しようとして、チェックしてみると…
ちゃんとつながります。あれっ?
あ、でも、パケットロスが多すぎのうえ、無線ルータの向きを変えると通信できなくなりました。
ははぁ、どちらかの電波の出力が弱いのでしょうね。でなければ、電波の受信部のアンプが壊れたか。
最近の暑さを考えると、出力段のトランジスタが熱暴走などで壊れた可能性が高そうです。
電波の出力状態を調べれば、多分、どちらが壊れているのか、確認できるでしょう。



共通テーマ:パソコン・インターネット

Xが立ち上がらない [プログラム]

Debianのsidでの出来事です。

apt-get upgrade で保留されているパッケージが多かったので
apt-get dist-upgrade したらXが立ち上がらなくなりました。Oh headache.

xorg-video-abi-18がないと言われます。
でもそんなパッケージありません。

ググって調べてみると、xorg-video-abi-18は、xserver-xorg-coreの中にあるようです。
はて?

なにが起こっているのでしょう?
xorg-video-abiは-18と-19があって、x86版は-18でなければなりません。
しかし、なぜか-19の方しか出てきません。

けっ。xserver-xorg-coreが、-19になっていて、-18を必要とするx86のビデオドライバが全滅ということのようです。
xserver-xorg-coreを古いものに戻せば直るでしょうが…。
どうすんだよ、これ!?


前回、Xが立ち上がらなくなったときは、Debian snapshotからパッケージを拾ってきて dpkg -i しましたが、今回は、apt で直してみます。
というのも、何とか直らないかと、testingを入れてみたり、X関連パッケージを削除したりと、多くのパッケージがわけの分からない状態になってしまったからです(笑)。

では、順番に。
  1. 混乱してしまったパッケージを削除する
    snapshotからaptで入れ直すので、まず、Xサーバ関連を削除します。なお、設定は残しておいたほうが良さそうなので、purgeはしません。
      # apt-get remove xserver-xorg xserver-xorg-core xserver-xorg-video-all fglrx
  2. いつの時点まで戻ればよいかを探す
    upgradeした後でもちゃんと動いていたと記憶にある日の数日前くらいを考えます。
    正確には、snapshotのページの左ペインの「binary packages:」の一覧から、リンクをたどって個々のパッケージのページまでいけば、バージョン一覧が出てきますので、それをたどれば、アーキテクチャ、日付などが表示されます。
    今回は、5月1日でよさそうです。
  3. レポジトリの切り替え
    /etc/apt/sources.list と /etc/apt/sources.list.d/ を横へ避けます。
    以下の内容の/etc/apt/sources.listを作成します。5月1日なので、20150501です。
      deb http://snapshot.debian.org/archive/debian/20150501/ unstable main contrib non-free
  4. オプションをつけて update
    snapshotのページにあるように、オプションをつけてupdateします。
      # apt-get -o Acquire::Check-Valid-Until=false update
  5. 削除したパッケージを入れる
      # apt-get install xserver-xorg xserver-xorg-core xserver-xorg-video-all
  6. 再起動してチェック
    再起動してチェックします。
      # reboot
  7. 問題なければ、レポジトリを戻す
    横へ避けた /etc/apt/sources.list と /etc/apt/sources.list.d/ を元に戻します。


以上で直りました。
ここまで3日かかりました…。はぁ。



共通テーマ:パソコン・インターネット

RaspberryPiをBeagleBoneBlackに置き換える [プログラム]

BeagleBoneBlackはRev.A6のころに買っていて、あれこれと予定していたのですが、設置までは至りませんでした。
BeagleBonleBlackのCPUには、ハードウェアの暗号化エンジンが載っており、これがデフォルトで使えそうなので、試してみました。
以前、RaspberryPiで、無線LAN間をOpenVPNのサーバ・クライアントで結ぶものを作りました。残念ながら非力なRaspberryPiでは、10Mbps程度の速度しか出ませんでしたが、ハードウェアの暗号化エンジンを使ってどれだけ速くなるでしょうか?

…と思ったのですが,結論からいいますと、ハードウェアの暗号化エンジンを使っているのかどうかも分からないような結果となりました。これは、元々opensslのスピード測定部分にバグがあり、測定時間が3秒どころか0.0何秒になってしまい、測定結果が不正確すぎる値しかでてこない、と言う問題がありました(現在は直っています)。ネット上にある多くの測定結果は、そのときのバグありバージョンで測定されているものですから、元々の「本当の速度」が分からないのでした。


では、順番に。
まず、予備調査として、openssl speedコマンドでそれぞれ速度を測ってみました。

BeagleBoneBlackのwheezyのプレビルドのSDイメージ(stable; console版)を使いました。BegleBoardDebian(http://elinux.org/BeagleBoardDebian)からです。
カーネルは、Linux 3.8.13-bone67 #1 でした。
openssl speed aes-256-cbc は以下の値です。
$ openssl speed aes-256-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 4933445 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 64 size blocks: 1425060 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 256 size blocks: 373241 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 94438 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 8192 size blocks: 11855 aes-256 cbc's in 3.00s
OpenSSL 1.0.1e 11 Feb 2013
built on: Wed Oct 15 18:31:51 UTC 2014
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      26311.71k    30502.96k    31849.90k    32342.65k    32372.05k
RaspberryPiのときは、以下の値で、BBBは2倍速いです。
# openssl speed aes-256-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 2262500 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 64 size blocks: 682967 aes-256 cbc's in 2.98s
Doing aes-256 cbc for 3s on 256 size blocks: 179207 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 45360 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 8192 size blocks: 5680 aes-256 cbc's in 2.98s
OpenSSL 1.0.1c 10 May 2012
built on: Thu Nov  8 03:42:28 UTC 2012
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      12066.67k    14667.75k    15292.33k    15534.66k    15614.28k
さて、BBBの、この約30000kという値、ハードウェアの暗号化エンジンを使っているのでしょうか? ここで、opensslのスピード測定のバグの問題にぶつかってしまうのです。たとえば、次のページ
  http://processors.wiki.ti.com/index.php/Sitara_Device_Crypto_Performance_Comparison
なら、ハードウェアの暗号化エンジンなしで約8000kですが、実はRaspberryPi(15000k)よりも遅いです。半分の速度しか出ていません。これはどうしたことでしょう? CPUのクロック差からして、これはgccやOSのバージョンによる差と考えなければなりません。となると、gccやOSのバージョンが上がると、2〜4倍程度は速くなる可能性がある、ということでしょうか? それも十分考えられます。
ハードウェアの暗号化エンジンを使った場合は、opensslのスピード測定のバグの問題のため、不正確な値しかでていません。なので、実際の速度がどれだけなのか、まったく分かりません。困ったものです。

しかしながら、現行のRaspberryPiの2倍の速度というのは、それなりに魅力的です。なので、ともかく一度BeagleBoneBlackで置き換えてしまいましょう。昨年大問題となったopensslのheartbleed脆弱性のこともありますし。(ただ、このopenvpnTLS-Authを使っていますので問題ありませんでした。攻撃者にTLS-Authキーが知られない限りheartbleedバグを利用することができませんので。)

基本的な方針はRaspberryPiのときと同じです。そして、発生した問題も同じでした(他にもありますが)。

rootfsをROM化するために、fsprotectをapt-getしましたが、相変わらずaufsが使えないため、fsprotectが動作しません。x86版ならサポートされているのに、armはダメです。でも、「必要性」から言えば,PCのx86よりも、小型組込み用のarmのほうが比べ物にならないくらい「必要」としているのですがね。
fsprotectを諦めて、やはり、unionfsを使うことになります。

それから、USB-Etherアダプタが"ethX"じゃなくて、"rename3"になっていました。これはASIXのチップを使ったものです。
"rename3"のまま使用しても構わなかったのですが、まぁ、ちょっと直しましょう。
/etc/udev/rules.d/70-...が悪いのは分かっていますが、どう書くのでしたっけか?
ググってみますと(rename3 ASIX)と同じ目にあわされている人が何人かいて、結局、MACアドレスでeth1にするように記述しました。
# USB device ASIX (AX88x72A)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:yy:zz:uu:vv:ww", NAME="eth1"
その他、openvpnなどの設定は、RaspberryPiでの設定をコピーしてインストールします。これらは変更なしです。

さて、準備はできましたので、前回と同じくunionfsの起動スクリプトを入れて起動しました。…ハングアップしました。
調べると、bin〜をbindマウントして、古いのをunmountしたあたりです。

問題を順に対処していきましょう。
  • ifconfig -aしても、ethが出てきません
    他に何かしたら、D-Busかなにかがないというエラーがでました。
    /sysや/procを「新たにmount」するのはもはやダメらしいです。以前mountしたfsと関係なく、その時点で新しいfsがマウントされてしまうようです。セキュリティのためではないかと思います。よって、以前のものをbindマウントする必要があります。
      mount -t proc proc /proc -> mount --bind 以前 /proc など

  • シリアルコンソールからログアウトすると、シリアルがハングアップします(正確には,gettyが再実行されません)
    明らかに、rootfsを移動したことに問題があるわけですが、どこに問題があったのかわかりませんでした。
    でも、kill -1 1すればgettyが動くことがわかったのですが、…
    結局,直せませんでした。systemdの設定や構造は未だ理解不能です。(/etc/inittabはsystemdでも解釈されるのか?、とか)
    とりあえず、rootの.bash_logoutに
      ( sleep 3; kill -1 1 ) &
    を追加。…、嫌になるくらいひどすぎる回避策ですが、この場合は、動くことが大事であって、無理にでも動けばOKです。

  • カーネル起動パラメータからquietを削除すると、コンソールがハングします
    これもひょっとするとkill -1 1で直るのかもしれません(試していません)が、いずれにしても原因が不明です。messagesの出力のためにconsoleがオープンされたままrootが移動するから?でしょうか。
ともあれ、これでなんとか動き始めました。が、さらに調整が必要でした。
  • もし、sshサーバを動かしているなら、一度再起動したあと、元々のrootfsの /etc/ssh/ssh.regenerate を削除しましょう。
    でないと、毎回起動時にhostkeyが再生成されて、「前回と違うhostkeyだ」と言われてしまいます。
      /bin/rm -f etc/ssh/ssh.regenerate
SDが出来上がったので,PCにSDをもってきて、PCのgpartedでパーティションサイズを変更します。保存やコピーのサイズや時間の節約のためです。
rootfsは400MB未満というコンパクトさ。rootfsとして、1GBもあれば十分でしょう。

イメージファイルとして、バックアップをとっておきましょう。
dd if=/dev/sdX of=SD.img count=YYYYY
YYYYYは、fdiskなどを用いて、(使用しているパーティションの最後のセクタ番号+100)程度を指定します。

BeagleBoneBlackは、eMMCがついています。SDの内容をeMMCに書き込みます。rootfsをROM化してあるので、SD同様、心配無用です。
このバージョンのBBBのDebianでは、eMMCへの書き込みはuEnv.txtを1行修正するだけです。それで起動すると、書き込まれます。終了は、コンソールで確認するか、LED4つが全部点灯するかでわかります。SDを抜いて、電源を入れ直します。電源を入れ直さなければならない理由はCPUがそうなっているからです。BBBのCPUは、リセットではsysconfig(起動デバイス順序)を読み直しません。電源on時のみsysconfigを読み直すので、リセットすると、SDから起動しようとしてSDがないのでコンソールからの起動になり、eMMCを読みにいきません。

で、今まで設置していたRaspberryPiと入れ替えました(相手側はRaspberryPiのままです)。起動したら、そのまま問題なく動作しました。
あとは、同様にして無線ルータの相手側もBeagleBoneBlackに入れ替えます。

これで、当初の目的は達成できました。
実際に、openvpnと無線LANを通してファイル転送速度を調べると、
RaspberryPi        1.1MB/s (以前の結果)
BeagleBoneBlack    2.5MB/s
となり、約2.3倍の速度が出ていました。


さて、opensslのスピードの続きです。
  http://datko.net/2014/03/21/bbb_upgrade_3_13/
の情報によると、kernel 3.13以降はHW暗号エンジンがデフォルトらしいです。…さっきインストールした3.8.18って何? 古すぎっ。
で、そこにあるようにkernel updateを、ついでに、RCじゃない最新版まで引き上げましょう。
wget https://rcn-ee.net/deb/wheezy-armhf/v3.18.2-bone1/install-me.sh
chmod +x install-me.sh
./install-me.sh
したら、
Error: this script is no longer supported for [repos.rcn-ee.net]
Please use:
cd /opt/script/tools/
git pull
sudo ./update_kernel.sh
or:
sudo ./update_kernel.sh --kernel v3.x.x-x
ですと。BeagleBoneBlackの情報はあまりにも早く、むしろ早すぎるくらいに、情報が古くなります。私がここに書いたものも、もう既に古くなっていることでしょう。
さて、正しいkernelのアップデートはどうするかというと、DebianなんだからDebian流にやればよいのです。
apt-cache search linux-image
ここに3.19のRCまでありました。でも、念のため、3.18.2を入れます。
apt-get install linux-image-3.18.2-bone1
再起動して、早速測定。
openssl speed aes-256-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 4963187 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 64 size blocks: 1432710 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 256 size blocks: 375715 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 95073 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 8192 size blocks: 11910 aes-256 cbc's in 3.00s
OpenSSL 1.0.1e 11 Feb 2013
built on: Thu Jan  8 22:02:29 UTC 2015
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa, --noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      26470.33k    30564.48k    32061.01k    32560.12k    32522.24k
全然変わってません。
なので、結局、ハードウェアの暗号化エンジンを使っているのかどうかわかりませんでした。

共通テーマ:パソコン・インターネット
前の10件 | - プログラム ブログトップ