DOSブートディスクをWindows64bit環境で作成する

BIOSアップデートがDOSプログラムしかないサーバ用マザーボードで、BIOSアップデートを実施する必要が出た。
そんなわけで、DOSブート環境が必要になったわけだが、USB FDDを使うのではなく、USBメモリを使用したい、ということで調査した。

しばらく前の定番。
hpのUSB-keyメモリからのブート作成ツール
HP Drive Key Boot Utility
  cp006049.exe (45 MB) v7.41.3790.0 (8 Nov 2005)
USB-keyメモリからのシステムブートに関して
  cp004916.exe (28 MB) v7.10.3790.0

こいつをVista 64bit環境で実行したら、管理者権限+互換モードを必要とする、というのはまだいいのだが、
「フォーマット中、プログラムから応答がなくなる」
とか
「フォーマット後、ファイルが見付からない、というエラー出力」
とか
「作成できたもので結局のところブートできない」
とか発生した。
(なお、実行ファイルが日本語ディレクトリとか長いとかかな、と短い場所に置いても同現象)

代替を探したところ「RMPreUSB」がうまいこと動作した。

これの利点
・Portableエディションという、インストール不要バージョンもある
・USBメモリの認識のさせ方を3種類(FDD認識/ZIPドライブ認識/HDD認識)から選ぶことができる
・Free DOSが同梱されていてライセンスを気にしないでDOSブートできる
・DOSブート以外も作成できる

1. RMPreUSBを起動すると以下のような画面が現れる。
001

2. 以下のように、USBメモリが表示されていることを確認する。

ここで選択されているUSBメモリの内容が全て削除、フォーマットされ、DOSブートメモリとなります。

3. 「3 Bootloader Options」にて「FREEDOS bootable」を選択します。

4. 「4 Filesystem and Overrides」は「FAT16」「Boot as HDD」でひとまずやってみてください。

うまくブートしなかった場合は「Boot as FDD」とか「Boot as ZIP」を試してみてください。

5. 「6 Prepare Drive」をクリックするとフォーマット開始です。

使わなかったボタンがいろいろありますが、Free DOSのブートディスクを作るくらいであれば、これだけで問題ありませんでした。

ECCエラー多発してるエラーが取れたのでメモ

CentOS6サーバに、2GBメモリが2枚刺さってる。
久々に起動したら、ECC関連のエラーメッセージを吐きまくってるのでメモ書き。

Feb  8 16:42:15 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:16 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:17 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:18 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:19 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:20 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:21 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:22 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:23 cent6server kernel: EDAC MC0: CE page 0xfb802, offset 0x200, grain 128, syndrome 0x64, row 1, channel 1, label "": i3000 CE
Feb  8 16:42:24 cent6server kernel: EDAC MC0: CE page 0xfab1b, offset 0xa00, grain 128, syndrome 0x64, row 1, channel 1, label "": i3000 CE
Feb  8 16:42:25 cent6server kernel: EDAC MC0: CE page 0xfb8ac, offset 0x780, grain 128, syndrome 0x64, row 1, channel 1, label "": i3000 CE

ちなみに、読み込まれているドライバは以下でした。

# lsmod|grep edac
i3000_edac              3471  0
edac_core              46581  3 i3000_edac
#

ちなみに「rmmod edac」を実行すると、エラーログを出力させなくすることもできます。
(もちろん、エラーがなくなるわけではない)

Proxmox上のOpenVZ仮想マシンをCLIでlive motion

Proxmox 2.xでは、共有ディスク無しでのホストサーバ移行(Live Motion/vMotion)みたいなことができる。
Web GUIでの方法はわかったが、CLIでのやり方についてのドキュメントが見つけにくく難航した。

使用するコマンド「pvectl」

ただし、このコマンドは、自サーバ上のみのコントロールを担当する。

「pvectl list」で、サーバ上にある仮想マシンリストを表示

root@pve1:~# pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       101 server1.osakana.net  running    1024       8.00
       102 server2.osakana.net  running    1280       30.00
#

他にもサーバがある場合は以下の様な形で他サーバに対してssh経由でコマンドを発行して状態を取得する。

root@pve1:~# ssh root@pve2 pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       103 server3.osakana.net  stopped    1024       10.00
       104 server4.osakana.net  stopped    1024       8.00
# 

移動させる時は「pvectl migrate VMID サーバ名 -online」

root@ns5:~# pvectl migrate 101 pve2 -online
Jan 31 15:56:51 starting migration of CT 101 to node 'pve2' (192.168.1.102)
Jan 31 15:56:51 container is running - using online migration
Jan 31 15:56:51 starting rsync phase 1
Jan 31 15:56:51 # /usr/bin/rsync -aHAX --delete --numeric-ids --sparse /var/lib/vz/private/101 root@192.168.1.102:/var/lib/vz/private
Jan 31 15:57:31 start live migration - suspending container
Jan 31 15:57:31 dump container state
Jan 31 15:57:32 copy dump file to target node
Jan 31 15:57:32 starting rsync (2nd pass)
Jan 31 15:57:32 # /usr/bin/rsync -aHAX --delete --numeric-ids /var/lib/vz/private/101 root@192.168.1.102:/var/lib/vz/private
Jan 31 15:57:35 dump 2nd level quota
Jan 31 15:57:35 copy 2nd level quota to target node
Jan 31 15:57:36 initialize container on remote node 'pve2'
Jan 31 15:57:36 initializing remote quota
Jan 31 15:57:37 turn on remote quota
Jan 31 15:57:38 load 2nd level quota
Jan 31 15:57:38 starting container on remote node 'pve2'
Jan 31 15:57:38 restore container state
Jan 31 15:57:39 removing container files on local node
Jan 31 15:57:40 start final cleanup
Jan 31 15:57:40 migration finished successfuly (duration 00:00:49)
root@pve1:~ #

で、うちの環境だと、CPUがpve1はIntel, pve2がAMDなので、移行後の起動に失敗する。
なので、別途、起動させる必要がある。

root@pve1:~# ssh root@pve2 pvectl start 101
Starting container ...
Container is mounted
Adding IP address(es): 192.168.1.201
Setting CPU units: 1000
Setting CPUs: 1
Container start in progress...
root@pve1:~#

これで、以下のような感じで移行が完了する。

root@pve1:~# pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       102 server2.osakana.net  running    1280       30.00
root@pve1:~# ssh root@pve2 pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       101 server1.osakana.net  running    1024       8.00
       103 server3.osakana.net  stopped    1024       10.00
       104 server4.osakana.net  stopped    1024       8.00
# 

さて、この処理を自動化すると・・・

#!/usr/bin/bash

SERVER=pve2
for vid in `pvectl list 2>&1 |grep running | awk '{ print $1 }'`
do
  echo === $vid ===
  echo pvectl migrate $vid $SERVER -online
  pvectl migrate $vid $SERVER -online
  ssh root@$SERVER pvectl list 2>&1 |grep  stop | grep $vid
  echo ssh root@$SERVER pvectl start $vid
  ssh root@$SERVER pvectl start $vid
done

ほんとは、移行後に起動しているか確認した上で、pvectl startを実行させるべきなんだろうけど、起動状態でpvectl startを実行しても影響がないので、無視している。

Firefox OSをビルド中

Firefox OSの開発機「Otoro」「Unagi」ってのは、どうもあまりスペックが高くない端末らしい、という話は把握していたものの、実体がよく分からないなぁ、と放置していました。

で、このたび、「Announcing the Firefox OS Developer Preview Phone!」ということで、Geekphone取り扱いで「Keon」と「Peak」の2機種が入手可能になるということがアナウンスされた。

外見とかスペック(Snapdragon S1 1GHz, HVGA, RAM 512MB)とかを考えると、ZTE V788D(MSM7225A)や、Xperia E(MSM7227A)あたりが該当しそうだなぁ、と

そして、先日手に入れたK-Touch W619も同じQualcommのMSM7225A系統。
もしかしたら動くかなぁ?とビルドしてみることにしました。

とりあえず、ソースファイル群を取得し、確認したところ、otoroとunagiの構成に関するファイルは、「B2G/device/qcom/」ディレクトリにありました。
CPUはどちらもMSM7627A、と予想よりはちょっとだけ上でした。
無線LANはunagiは、NL80211とath6kl_sdio(SDIO接続)
otoroは、ar6000という違いがありそうな感じ。
まぁ、見方が間違っているような気もしますけど・・・

とりあえず、otoro想定で、buildを開始してみてます。

まだ、Build途中ですが、すでにはまった点があるので公開しておきます。

・Ubuntu 12.10にしてたらはまった。
すでにUbuntu 12.10 32bit環境があったので、そこに構築したらビルドが早々にエラーになった。
公式の「Firefox OS ビルドの必要条件」にあるように「デフォルトホストコンパイラの変更方法」をおこなう必要があったようだ。
まぁ、64bit環境にかえた方がよさそう、というのもあったので、Ubuntu 12.04 64bit環境で作り直しました。

Firefox OS側の手順Android側の手順とでパッケージ選択に差異がある
同じAndroid開発環境をベースとしているわりに、差異があった。
とりあえず、両方に書かれているパッケージ選択をそのままやっておいた。

また、javaについては「openjdk-6-jdk」を選択しておいた。

・build.sh実行時に「-j2」を指定したら失敗した
オプションなしで実行したら進んだ。

・割り当てメモリが少ないと失敗しやすい?

make[7]: *** [TabChild.o] エラー 1
make[7]: *** 未完了のジョブを待っています....
arm-linux-androideabi-g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

In the directory  /work/firefox/B2G/objdir-gecko/dom/ipc
The following command failed to execute properly:

こんな感じのエラーがでます。
公式の「Boot to Gecko のビルド」に空きメモリがないから、と書いてあります。

まぁ、仮想マシンで1.2GBの割り当てで構成しているからですね。
もう1回、build.shを実行すると先に進む程度の失敗のようです。

そんなわけで、終わるのにはまだまだ時間がかかりそうです。

USB温度計 TEMPerV1.2は計測ミスが多い

(注意: TEMPer V1.2のドライバは→「ここ」にあります)
USB温度計TEMPer V1.2で温度取得をおこなっていると、以下の様な形で、エラーとなることがある。

 $ ./pcsensor
USB interrupt read: Resource temporarily unavailable
Fatal error> USB read failed
$

しかも、これが発生すると該当デバイスは一度offlineとなり、別のデバイスとして認識されてしまいます。

どれくらいの確率で発生するのかを、スクリプト組んで確かめてみました。

作成したスクリプト

#!/bin/bash

SUCCESS=0
FAILED=0
I=0
while [ $I -lt 1000 ]
do
        echo -n "$I "
        ./pcsensor > /dev/null 2>&1
        if [ $? -eq 0 ];
        then
                SUCCESS=`expr $SUCCESS + 1`
        else
                FAILED=`expr $FAILED + 1`
        fi
        sleep 5
        I=`expr $I + 1`
done
echo ""
echo "successed: $SUCCESS"
echo "failed:    $FAILED"

pcsensorを実行して5秒待つ、というのを繰り返すという、まぁ、素直なものですね。

USB温度計を2つつなげて、1000回の測定を開始!

$ ./test.sh
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 
<略>
7 988 989 990 991 992 993 994 995 996 997 998 999
successed: 879
failed:    121
$

2個のうちどちらか片方こけただけでも、両方アウトになるので、失敗確率が結構いってしまいます。

また、エラーが発生すると、offlineになるので、ログには以下の様な記録がずらずらっと・・・

# tail /var/log/messages
Jan 17 15:02:27 temperserver kernel: usb 2-2: configuration #1 chosen from 1 choice
Jan 17 15:02:27 temperserver kernel: input: RDing TEMPerV1.2 as /class/input/input174
Jan 17 15:02:27 temperserver kernel: input,hidraw0: USB HID v1.10 Keyboard [RDing TEMPerV1.2] on usb-0000:00:1d.0-2
Jan 17 15:02:27 temperserver kernel: hiddev96,hidraw96: USB HID v1.10 Device [RDing TEMPerV1.2] on usb-0000:00:1d.0-2
Jan 17 15:03:02 temperserver kernel: usb 3-1: USB disconnect, address 90
Jan 17 15:03:03 temperserver kernel: usb 3-1: new low speed USB device using uhci_hcd and address 91
Jan 17 15:03:03 temperserver kernel: usb 3-1: configuration #1 chosen from 1 choice
Jan 17 15:03:03 temperserver kernel: input: RDing TEMPerV1.2 as /class/input/input175
Jan 17 15:03:03 temperserver kernel: input,hidraw0: USB HID v1.10 Keyboard [RDing TEMPerV1.2] on usb-0000:00:1d.1-1
Jan 17 15:03:03 temperserver kernel: hiddev96,hidraw96: USB HID v1.10 Device [RDing TEMPerV1.2] on usb-0000:00:1d.1-1

そして、lsusbを実行すると、以下のように、デバイス番号がすごいことに・・・

# lsusb
Protocol spec without prior Class and Subclass spec at line 4297
Bus 003 Device 091: ID 0c45:7401 Microdia
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 084: ID 0c45:7401 Microdia
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

(1000回スクリプト実行前にも、テストとかをおこなっているので・・・)

運用に当たっては、いろいろ配慮が必要なようです。

モバイルバージョンを終了