Rstream A1のroot取得 失敗編1 GoRoot.bat

root取得なんですが・・・
まず、adb接続してみてびっくりですよ。

$ mount
mount
rootfs / rootfs rw 0 0
tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
/dev/block/mtdblock7 /system yaffs2 rw 0 0
/dev/block/mtdblock10 /data yaffs2 rw,nosuid,nodev 0 0
tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0
/dev/block/mtdblock9 /cache yaffs2 rw,nosuid,nodev 0 0
/dev/block/mtdblock5 /hidden yaffs2 rw,nosuid,nodev 0 0
/dev/block/mtdblock1 /misc yaffs2 rw,nosuid,nodev 0 0
/dev/block/mtdblock8 /misc2 yaffs2 rw,nosuid,nodev 0 0
DxDrmServerIpc /data/DxDrm/fuse fuse.DxDrmServerIpc rw,nosuid,nodev,user_id=0,group_id=0,allow_other 0 0
$ 

/systemパーテーションがrwでマウントされてるし。

調べてみるとGoRoot.batというのがあって、それでrootがとれるらしい。
内容的にはすごく簡単なので、手動でやってみる。

c:\android>\android\platform-tools\adb shell
$ mkdir /data/work
$ exit
c:\android>\android\platform-tools\adb push su /data/work
1877 KB/s (34612 bytes in 0.018s)

c:\android>\android\platform-tools\adb push Superuser.apk /sdcard/
1506 KB/s (16967 bytes in 0.011s)

c:\android>

まず、必要なsuとSuperuser.apkを転送。
あと、cpが使えなかったり/sdcard/だとsuに権限が与えられないので、/data/workに作業用ディレクトリを作成した。

で、次の手順。

c:\android>\android\platform-tools\adb shell
$ cd /data/work
$ ls -l
-rw-rw-rw- shell    shell       34612 2011-12-15 22:50 su
$ chmod 4755 su
$ ls -l
-rwsr-xr-x shell    shell       34612 2011-12-15 22:50 su
$

/data/workにコピーしたsuに対して、権限を与えてあげます。

$ ./su -
./su -
Permission denied
here1here2here3$

$

あれ?駄目?
あ、/dataはnosuid,nodevでマウントしてるからか、と/sqlite_stmt_journalsにコピーしなおしても、同じ結果に・・・

Rstream A1でこの手法はうまくいかないようです。

— 2011/12/19 追記 —
なぜCommtiva z71派生モデルで一般的なGoRoot.batがうまくいかなかったかを調べたところ、Rstream A1以外の大半のCommtiva z71派生モデルでは、adb接続時はrootユーザで入れてしまうらしい。
Rstream A1では、一般ユーザで入るように設定されてしまっているので、同じ手法が使えない、ということだったようだ。

なお、MUCHTEL A1のAndroid 2.2を書き込むと、rootユーザが簡単に取得できるようになるが、日本語設定がないので設定画面とかが英語になる、というのと、R-stream A1のIP電話アプリが消える、という問題がある。

R-Stream / MUCHTEL A1を買った

ソフマップで7980円、とか言うので、つい買ってしまいました。

あまり裏側の写真を見なかったので、あえて裏側を

2011年3月製造の機体でした。
で、最初バッテリーは30%の充電状態でした。

パソコンにつなぐとドライバインストール用の内蔵ストレージが開くのでそれに従ってセットアップすると、ADB接続用のドライバもインストールされます。

C:\android>platform-tools\adb devices
List of devices attached
FSTMAUS0006869  device
C:\android>

で、とりあえず、スクリーンキャプチャをいくつか・・・


よくある画面キャプチャはこんなもんですが、ここにあるR-Phoneをクリックすると・・・

番号を取得していないので、エラーとなります。

インストールされているアプリは・・・


といったところ。

キーボードを開くと・・・

「Touch Pal」という英数入力のみのソフトが入っている状態。

そういえば、Androidのバージョンはっと・・・

Android 2.1-update1
ベースバンド: MP1_850
カーネルバージョン: Apps_2.6.29
ビルド番号: 5022_2_360

そうそう、フォントは中華フォントですよ

ASUS Eee Note EA800の日本語マニュアルが来た!

ASUS Eee Note EA800の日本語マニュアルが某所に来た!

日付が2011年9月と入ってるけど、まぁ気にしないで内容チェック!

・・・・とてもやるきがかんじられるすばらしいまにゅあるですね

ま、本文はちゃんと日本語になってますよ!
って、あ・・・

下の画面キャプチャのところ「スナップショット」の表示が切れてるよ・・・
うちの翻訳版が「画面取得」となってるのは、こういった表示しきれないという事態を防ぐためだったりしたんだけど、それを無視している模様

マニュアルの所々に赤字で書かれている記述があります。
これらは初期firmwareにはなく、途中のアップデートで追加されていったところです。

マニュアルの作成ベースとなったfirmwareは V1.0.16.128 の模様。

台湾版の最新が「V1.0.14.118TW」(2011/05/30)、ロシア版が「V1.0.16.139」(2011/10/11)であることを考えると、マニュアル表紙に書かれていた日付2011年9月というのは妥当なあたり。

果たして、発売されてくるEA800のfirmware versionは何になっていることやら・・・
購入した方によればV1.0.16.142だそうです。

って・・・・「戻る」のフォントが中華フォントしてるよ
「規定のノートの背景」なんて謎表記もあるし・・・「既定のノートの背景」の間違いだろうけどさ

参考までにうちの日本語版の設定画面

ReadyNAS NV+ v2が日本でも発売

なんかReadyNAS NV+2で検索してくる人が多いなぁ、と思ったら、今日、発表されたんですね。
NETGEAR ReadyNAS Duov2 / ReadyNAS NV+v2 製品紹介ページ

詳しいあたりは、アメリカで発表になった時に作成した記事を参照してください→「ReadyNASのCPUがMarvell Kirkwoodに

それにしても、2005年11月末にディスクが4本させるReadyNAS 600を買った時は84000円だったわけですが、ずっと値段が下がって、同じ4本モデルのReadyNAS NV+v2が34800円になっている、というのは、時の流れを感じるなぁ、と言ったところです。

それにしても、プレスリリースを含めて、いままでの製品とCPUアーキテクチャが変更になった、という点に触れていないんですね。
結構、大きな違いだと思うんですが・・・

VMware仮想マシンのバックアップに関する解説

VMwareで仮想マシンのバックアップを行う際に出てくる用語について、簡単にまとめてみた。

キーワード
・VMware Consolidated Backup (VCB)
・VMware vStorage APIs for Data Protection (VADP)
・VMware Virtual Disk Development Kit (VDDK)
・File-level Restore(FLR)

VMwareで仮想化を行っている場合、仮想マシンを丸ごと、動作させたままの状態でバックアップすることができる。
その際は、仮想マシン内のOS上で動作しているvmware-toolsと連携し、ファイルシステムに対してある程度の静止点を作成させ、その後にバックアップを行う、といったことが出来るようになっている。

バックアップ・リストアを行う仕組みとして、VMware Consolidated Backup(VCB)と、VMware vStorage APIs for Data Protection (VADP)の2種類がある。
VADPはvSphere4から登場した新しい仕組みで、基本的にはこっちの方が高機能である。
詳細についてはVMware KB1021175:vStorage APIs for Data Protection (VADP) FAQ に掲載されている。

VCBの場合はWindowsのみ、VADPの場合はWindows/Linuxのみであるが、仮想マシン丸ごとでバックアップしても、仮想マシン上のOS内のファイル単位でリストアすることができる。
この手法をFile-Level Restore(FLR)と呼んでいる。

FLRはどのように実現されているか、というあたりだが、実は結構アレなつくりをしている。
仮想ディスクとしてリストアした後、仮想ディスクを内部的にマウントしてリストアする。
というようなイメージでリストアが行われる。

こんな処理をまともに実装してたら、バックアップソフトベンダが死んでしまうので、VMware側で簡単にできるような開発向けのソフトウェアライブラリを用意している。
それが、VMware Virtual Disk Development Kit (VDDK)である。

VDDKは、いくつかバージョンが出ている。
VDDK 5.0
VDDK 1.2.1
VDDK 1.2
VDDK 1.1
VDDK 1.0.1

VDDKのバージョンが異なると何が変わってくるか、という点だが、基本的には新しいバージョンほど機能が増えている、ということになる。

vSphere5と共にリリースされたのがVDDK5.0ではあるが、これを使用したバックアップソフトウェアがvSphere4のバックアップに使用できないといったことは無い。

しかし、逆のVDDK 1.2.1を使用したバックアップソフトウェアをvSphere5環境で利用する場合には、いろいろ注意が必要な点が発生する。
この例の場合、VMFS-5が非サポートであるため、vSphere5環境ではSANストレージを旧来のVMFS-3(vSphere4仕様)で利用する必要が出てくる。

VDDKはバックアップソフトウェアの開発時に内部に組み込まれて使用される。
このため、あとからVDDKだけをバージョンアップするということはできず、バックアップソフトウェアベンダが新しいバージョンを開発するまで新機能は使用できない。
このため、VDDKおよび新しいvSphereリリース時は、バックアップソフトウェアによってできる機能が異なってくるという事態が発生する。

各バックアップソフトの対応については別途調べてください。