突然消失するかもしれないブログ

”とつきえブログ”

カテゴリーアーカイブ: Linux

玄箱ProでDebian squeeze/wheezyのアップデートする際の注意点

2011/03/11の震災で1台目の玄箱Proが故障してしまい、1年近く自宅にサーバーのない生活をしてきましたが、あまりに不便なため、2台目の玄箱Proを引っ張り出すことにしました。

2台目の玄箱ProにはDebian wheezyを自前でインストールしていたのですが、aptitude update; aptitude full-upgradeを実行して最新の状態にアップデートしたところ、悲しいことに正常に起動できなくなってしまいました。。

ブート時のエラーメッセージを見ると、udevが延々とエラーメッセージを吐いており、原因を調べてみたところ、Linuxカーネルが古く、カーネルのコンフィグが足らないせいのようです。

非公式のDebianインストーラを使用している限り、またこのような悲劇が起こるので、何か他の良い方法がないか探してみたところ、Debian本家が正式に玄箱Proに対応していることが判明しました。

玄箱ProでDebianをインストールする公式ガイドがあり、以下のサイトに従ってDebian公式インストーラでDebianをインストールすれば良いようです。

http://www.cyrius.com/debian/orion/buffalo/kuroboxpro/

非公式のDebianインストーラで玄箱ProにDebianをインストールしてしまうと、Debian本家のバージョンアップに追従するのが辛くて挫折しがちになりますが、Debian公式のインストーラでDebianをインストールすれば、安心して最新の状態にバージョンアップすることができるかもしれません。

ということで、近いうちに時間を見つけてセットアップしようと思います。(つづく)

 

広告

1つのユーザープロセスが搭載している物理メモリを使い切るとLinuxカーネルが落ちる件

昨年の夏、DevQuizのパズル問題を解くために、OS XとLinuxを酷使したのですが、

OS Xは高負荷時(メモリを使い切る)でもシステムが落ちないのに、Linuxは落ちる。

という症状に悩まされました。

計算プログラムを朝、しかけて、夜、結果を確認すると、OS Xの方は、Macがファンをぶんぶん回しながら計算を続けていましたが、VMware vSphereの仮想マシン上で動作するDebian6のLinuxの方は、確実にLinuxカーネルごと落ちてしまうのです。

(仮想マシン、ハイパーバイザ自体は生きている状態です。ハイパーバイザの仕組み上、仮想マシンに割り当てた以上の物理メモリが使われてしまうことはありません。)

自分が作っている計算プログラム、つまり、1つのプロセスで搭載している物理メモリを使い切ってしまうことが原因だということは想像がつくのですが、スワップも設定しているのに、なぜLinuxカーネルが落ちてしまうのか原因がわかりません。

(スワップ領域がSANのストレージ上にあるのでそれが原因とか、VMware vSphereが原因とか??)

今、流行の ”ビッグデータ” などを処理しようとすると、ある程度安定した分散環境が必要になるのですが、原因がつかめないとLinuxベースで安定した分散環境を構築できるのか、この先、不安です。

 

追記:2012/02/19 14:27

Linuxカーネルがフリーズする原因は以下のようにいくつかあるらしいので、切り分けしたいと思います。

(1)Linuxカーネル、ドライバ等にバグがある。

(2)ハードウェアに不具合がある。(メモリモジュールにエラーがあるなど)

(3)仮想実行環境に不具合がある。

 

(2)(3)に問題がないことがわかれば、kexec+kdumpで(1)Linuxカーネル、ドライバ等の不具合を探っていくことになります。

 

※参考

第2回 減り続ける利用可能メモリ……そしてついにリブート!

http://www.atmarkit.co.jp/flinux/rensai/tantei02/bangai02c.html

「Linuxが落ちる原因,遅い理由はこうして突き止める」――VA Linux Systems Japan 高橋浩和氏

http://itpro.nikkeibp.co.jp/members/ITPro/oss/20040427/1/

Linuxでクラッシュダンプを採取(1) ~ kexec + kdump を使ってみる ~

http://dsas.blog.klab.org/archives/50558228.html

 

ThinkPadT42でDebian:Debian 6の電源管理の謎について

Linuxでの電源管理は、伝統的に、acpid, acpi-support-base, acpi-supportで行われているようですが、Debian 6のグラフィカルログイン環境では、gnome-power-managerによって電源管理が行われるようです。

つまり、acpiの設定をいくら行っても、gnome-power-managerの設定を行わないと反映されないというわけです。

Debian/etch で Gnome Power Managerをつかってサスペンドする の情報によると、

従来の場合は、すべてacpidで電源管理の処理が行われます。

(acpiのイベント)

=> acpid でフック

=> イベント種別から /etc/acpid/events 以下の設定でスクリプトを選択

しかし、グラフィカルログイン環境では、acpidで処理された後、gnome-power-managerで電源管理の処理が行われるようです。

(acpiのイベント)

=> acpid でフック

=> acpi-support パッケージにより、キーイベントに変換され、/dev/inputXに渡される。

=> Xサーバ君がキーイベントを受ける

=> gnome-power-manager がキーイベントを受け取り?、    ディスクトップのユーザ設定に応じて処理を決めて、    サスペンド/ハイバネーションの要求を〜する。

ということで、Debian 6でgnomeのグラフィカルログイン環境での電源管理は、acpidだけではなく、gnome-power-managerでも管理されているということを理解する必要があります。

詳しくは以下をご覧下さい。

ThinkPadT42でDebian:リッドクローズドモードで使う

 

ThinkPadT42でDebian:リッドクローズドモードで使う

Debian 6をインストールしたThinkPad T42はサーバとして使用したいので、液晶画面は閉じた状態でも電源がONの状態で使える、リッドクローズドモードの設定を行います。

Debian 6のグラフィカルログインには落とし穴がある。

Debian 6をグラフィカルログイン環境でインストールすると、ログイン後の状態では液晶画面を閉じてもサスペンドしないのに、ログイン前の状態のログイン画面で液晶画面を閉じるとサスペンドしてしまう、という現象が起きます。

原因は、gnome-power-managerというプロセスです。

ログイン前の状態では、gdm3のユーザIDである、Debian-gdm(UID=106)でgnome-power-managerが実行されますが、ログイン後の状態ですは、ログイン時のユーザIDで実行されます。

gnome-power-managerは、”電源管理の設定”というアプリケーションで設定した設定ファイルを参照しますが、Debian-gdm(UID=106)には、その設定が反映されていないのが原因です。

では、どうすれば、Debian-gdm(UID=106)にも電源管理の設定を反映させることができるのかと言うと、”電源管理の設定”のウィンドウの下に「デフォルト値」にする」というボタンがありますので、これをクリックします。

”デフォルト値にする”のボタンの意味は、システム全体で共通の設定値を設定するということです。

NewImage

”電源管理の設定”は、gconfによって設定ファイルを保存しており、システム全体で共通の設定値として保存した場合は、以下のファイルに設定値が保存されます。

○デフォルト値が保存される場所

/etc/gconf/gconf.xml.defaults/%gconf-tree.xml

ちなみに、各ユーザの個別の設定値は、ログインしたユーザIDのホームディレクトリ配下の ~/.gconf/apps/gnome-power-manager/%gconf.xml に保存されます。

NewImage

すると上記のように、”lid_ac”が”blank”、つまり、液晶画面が閉じられた時は、サスペンドせずに液晶画面をブランク(液晶画面の電源をOFFにして真っ暗)にするという設定になります。

これで、ログイン前の状態のログイン画面で液晶画面を閉じてもサスペンドしなくなります。

めでたし、めでたし。

 

 

ThinkPadT42でDebian:Debian 6のインストール

ThinkPad T42に最後の一働きをしてもらうため、Debian 6 squeezeをインストールしてみました。

Pentium-M 1.8GHz、メモリ2GBなのでできることは限られますが、それでも玄箱Pro(ARM9 400MHz, メモリ128MB)に比べれば快適です。

(1)Debian 6のインストールCDイメージ(isoイメージ)をDLする。

ThinkPad T42はUSBメモリからブートすることができないので、Debian 6のインストールCDイメージ(isoイメージ)をDLし、CD-R、ないしは、DVD-Rに焼いて、そのメディアからブートします。

http://www.debian.org/distrib/netinst#smallcd

今回は、上記のネットワークから必要なファイルを適宜DLしながらインストールする”小さなCD”というイメージを使いました。

これならCD-R、あるいは、DVD-R一枚で済みます。焼いたメディアは緊急用のメンテナンスディスクとしても使えるので、インストールが終わったら大事にとっておきましょう。

最近のLinuxのディストリビューションは64bit版がメインになっているため、DLするときは、64bit版(amd64)ではなく、32bit版(i386)のイメージが必要です。(ThinkPad T42のPentium-Mは、32bit CPUです。)

※ちなみに、ThinkPad T42で間違って64bit版(amd64)のイメージでブートしてみたところ、途中まではブートしますが、ハングアップしてしまいます。。

ThinkPad T42のCD/DVDドライブがへたっている場合は、外付けのUSB CD/DVD-ROMドライブからでもブートできます。

(2)光学メディアからブートする。

ThinkPad T42のBIOSの設定で、起動順が、HDDよりも先に、内蔵のCD/DVD-ROMドライブ、外付けUSB CD/DVD-ROMドライブが来ていることを確認して、いよいよインストールを開始します。

(3)インストールする。

ネットワークから必要なファイルを適宜DLしながらインストールするので、通信状況やサーバの状況によって変わってきますが、インストールが完了するのに結構時間がかかるので、気長に待ちましょう。

P.S

玄箱Proでは、開発版の次期Debian 7 wheezyを使用していましたが、アップデートが頻繁に行われるため、追従するのが大変なので、今回はおとなしくリリース版のDebian 6にしています。(^_^;)

 

Debianで「入手不可能なパッケージは修正できません」と表示された場合の対処方法

Debian 6 squeezeのVMwareの仮想マシンイメージを8ヶ月ぶりぐらいに起動して、aptitude full-upgradeもsafe-upgradeを実行したら「入手不可能なパッケージは修正できません」と表示されてアップデートできない状態に陥っていました。


先に進みますか? [Y/n/?] y
拡張状態情報を書き込んでいます… 完了
エラー http://ftp.us.debian.org squeeze/main openssl 0.9.8o-4
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main cups-ppdc 1.4.4-7
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main libcups2 1.4.4-7
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main python 2.6.6-3+squeeze4
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main notification-daemon 0.5.0-2
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main whois 5.0.10
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main libxmuu1 2:1.0.5-2
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main acpi-support 0.137-5
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main alsa-utils 1.0.23-3
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main libesd0 0.2.41-8
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main ijsgutenprint 5.2.6-1
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main python-imaging 1.1.7-2
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main libhpmud0 3.10.6-1.1
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main libapr1 1.4.2-6
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main libaprutil1 1.3.9+dfsg-5
  403  Forbidden
E: http://ftp.us.debian.org/debian/pool/main/o/openssl/openssl_0.9.8o-4_i386.deb を取得で きませんでした: 403  Forbidden
E: 入手不可能なパッケージは修正できません
パッケージリストを読み込んでいます… 完了
依存関係ツリーを作成しています
状態情報を読み取っています… 完了
拡張状態情報を読み込んでいます… 完了
パッケージの状態を初期化しています… 完了
拡張状態情報を書き込んでいます… 完了
タスクの記述を読み込んでいます… 完了

すでにインストール済みのパッケージが、依存するパッケージもアップデートしようとしているが、最新のパッケージでは不要になったため、リポジトリからそれらの依存するパッケージが削除されたのが原因のようです。

では、解決法はというと、上の太い青字の部分を手がかりにしてパッケージ毎に個別にアップデートしながら問題が解決されるまで試行錯誤を繰り返します。

aptitude install libaprutil1
aptitude install libapr1
aptitude install libhpmud0

今回は、上記のようにインストール済みのパッケージの個別のアップデートを繰り返していき、いつの間にかaptitude full-upgrade、safe-upgradeが正常に実行できるようになりました。

ちなみに、Debian 7.0 wheezyのテスト版はリリースされていないみたいですね。

BeagleBoard:(11)Debianインストール2

BeagleBoard上にDebianをインストールする方法についてです。

(1)主な情報源
BeagleBoardDebian – eLinux.org

こちらの手順に従い、ネットインストールでDebianをインストールします。

(2)シリアルコンソールの準備

開発用PCとBeagleBoardをシリアルのクロスケーブルで接続して、BeagleBoardを操作します。

ここでは、開発用PCとしてDebian5、通信用ソフトとしてkermitを使用します。

<kermitの通信設定>

kermitを起動して、以下のコマンドを実行して通信設定を行います。

都度、入力するのは大変なので、~/.kermrcに以下を記述しておけば自動設定されます。

尚、BeagleBoardのシリアルではフロー制御が行われないので、通信データを取りこぼさないように適度にディレイを入れる必要があります。

set line /dev/ttyUSB0
set speed 115200
set flow-control none
set carrier-watch off
set delay 1

上記の通信設定をした後、connectコマンドを実行して、何回かリターンキーを押すと、開発用PCとBeagleBoardの間で同期がとられて、正常に通信できるようになります。

connect

kermitを抜けたい場合は、以下のキーを入力します。

ctrl ¥ c

(3)BeagleBoard用のuImage(Linuxカーネルイメージ)、Debianインストール用のinitrdを取得してmicroSDに書き込む。

microSD上に最低でも3つのパーティションが必要になります。

パーティション1(/dev/mmcblk0p1):VFAT(uImage, initrd)
パーティション2(/dev/mmcblk0p2):Linux swap
パーティション3(/dev/mmcblk0p3):Linux(rootファイルシステム)

インストール時はパーティション1だけ作成すれば、あとはDebianのインストーラが作成してくれます。

ブートローダは、BeagleBoardのNANDに書き込まれているものをそのまま使いますので、microSDに書き込む必要はありません。

パーティション1のルートディレクトリにuImageとuInitrdを書き込みます。

# BeagleBoardにDebianをインストール際に利用できるuImageは若干古いバージョンのLinuxカーネルになりますが、Debianをインストールした後、自由にバージョンアップすることができます。
wget http://rcn-ee.net/deb/kernel/CC-beagle-v2.6.29-58cf2f1-oer44.1.uImage
mv CC-beagle-v2.6.29-58cf2f1-oer44.1.uImage uImage

# Debianは安定版のlennyをインストールして、lennyをインストールした後、Squeezeなどにバージョンアップすることができます。
wget http://ftp.debian.org/debian/dists/lenny/main/installer-armel/current/images/versatile/netboot/initrd.gz
gzip -d initrd.gz
dd if=initrd of=uInitrd ibs=8388608 conv=sync

(4)BeagleBoardのu-Bootを設定する。

Debianインストール時は、u-Bootの画面で以下のように設定、実行します。

setenv bootcmd ‘mmc init; fatload mmc 0:1 0x80300000 uImage; fatload mmc 0:1 0x81600000 uInitrd; bootm 0x80300000’
setenv bootargs ‘console=ttyS2,115200n8 ramdisk_size=8192 root=/dev/ram0 rw rootfstype=ext2 initrd=0x81600000,8M’
saveenv
boot

Debianインストール後は、上記の設定のうち以下のように変更します。

setenv bootargs ‘console=ttyS2,115200n8 root=/dev/mmcblk0p3 rootwait rootfstype=ext3 ro’
saveenv

Debianインストール後に、BeagleBoardのHDMI端子経由でHDMI/DVI出力したい場合は、上記の設定のうち、以下のように変更します。

<解像度が1280×720、色深度が16bitの場合>
setenv bootargs ‘console=ttyS2,115200n8 root=/dev/mmcblk0p3 rootwait rootfstype=ext3 ro omapfb.mode=dvi:1280x720MR-16@60’

<解像度が1280×720、色深度が24bitの場合>
setenv bootargs ‘console=ttyS2,115200n8 root=/dev/mmcblk0p3 rootwait rootfstype=ext3 ro omapfb.mode=dvi:1280x720MR-24@60’

<解像度が1440×900、色深度が16bitの場合>
setenv bootargs ‘console=ttyS2,115200n8 root=/dev/mmcblk0p3 rootwait rootfstype=ext3 ro omapfb.mode=dvi:1440x900MR-16@60’

<解像度が1440×900、色深度が24bitの場合>
setenv bootargs ‘console=ttyS2,115200n8 root=/dev/mmcblk0p3 rootwait rootfstype=ext3 ro omapfb.mode=dvi:1440x900MR-24@60’

(5)Debianインストーラを起動する。

上記で用意したmicroSDをBeagleBoardにセットしてリセットするだけで、Debianインストーラが起動し、画面の指示に従って行けば、必要最小限のDebianがインストールされます。

尚、DHCPでUSBイーサネットアダプタにIPアドレスが割り振られるはずなのですが、なぜかうまくいかないので手動で設定する必要があるようです。

<参考:BeagleBoardのu-Bootの工場出荷時の設定>

bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi; fi; else run nandboot; fi
bootdelay=10
baudrate=115200
loadaddr=0x82000000
console=ttyS2,115200n8
vram=12M
dvimode=1024x768MR-16@60
defaultdisplay=dvi
mmcroot=/dev/mmcblk0p2 rw
mmcrootfstype=ext3 rootwait
nandroot=/dev/mtdblock4 rw
nandrootfstype=jffs2
mmcargs=setenv bootargs console=${console} vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${mmcroot} rootfstype=${mmcrootfstype}
nandargs=setenv bootargs console=${console} vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${nandroot} rootfstype=${nandrootfstype}
loadbootscript=fatload mmc 0 ${loadaddr} boot.scr
bootscript=echo Running bootscript from mmc …; source ${loadaddr}
loaduimage=fatload mmc 0 ${loadaddr} uImage
mmcboot=echo Booting from mmc …; run mmcargs; bootm ${loadaddr}
nandboot=echo Booting from nand …; run nandargs; nand read ${loadaddr} 280000 400000; bootm ${loadaddr}
stdin=serial
stdout=serial
stderr=serial
bootargs=console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mtdblock4 rw rootfstype=jffs2

Environment size: 1310/131068 bytes

Debian Squeezeの最新状況(2010/05/16)

数日ほど前にDebian Squeezeが大幅にアップデートされました。

今回のアップデート内容から、Debian Squeezeの正式リリース時は、IPv6がデフォルトで有効になるのかもしれません。

確認できた大きなアップデート内容は以下の通りです。

(1)netatalk2.1

netatalkが2.1にバージョンアップされました。

ii  netatalk                          2.1-1                      AppleTalk user binaries

netatalk 2.1 (安定版) 対応状況:HAT:So-net blog

Snow Leopardのバグにより、netatalk 2.0.xに接続すると問題が発生するので、2.1をおすすめします。

詳細は、HATさんのエントリーを参照していただくとして、Snow Leopardからnetatalk2.1の共有フォルダへのアクセス速度がかなり改善されたような気がします。

アップデート後に注意が必要なのが、Mac OS X Snow Leopardでafpdサーバに接続できない(解決編) « 突然消失するかもしれないブログの「(2-2).AppleDBディレクトリ以下をすべて削除する。」の作業が必要です。でないと、Snow LeopardからアクセスするとFinderがフリーズしてしまいます。

・共有フォルダの「.AppleDB」以下を削除する。

# find “afpdの公開フォルダとして指定しているディレクトリ” –name “.AppleDB” –print –exec rm –rf {} \;

・/etc/netatalk/AppleVolumes.defaultを再設定する。

:DEFAULT: maccharset:MAC_JAPANESE volcharset:UTF8 options:usedots,upriv dperm:0700 fperm:0600 cnidscheme:dbd

 

(2)squid3.1.1

squid3が3.1.1にバージョンアップされましたが、IPv6が有効になっていない環境ではsquid3.1.1が正常に動作しません。

原因は、Debian Squeezeのデフォルトの設定ではIPv6が無効にされているのに対して、squid3.1.1のパッケージがIPv6のオプションを有効にしてビルドされているためです。

当面、squid2.xかsquid3.0を使用することをオススメします。

具体的には、

Re: [squid-users] Squid-3.1: comm_open: socket failure : (97) Address fa

You have IPv6 disabled in your system somehow.

Squid opens IPv4/IPv6 hybrid sockets to receive and send both v4 and v6
traffic in one socket for simplicity and ease of transition. If that fails
like in your case it falls back to IPv4-only sockets.

I recommend re-enabling IPv6 socket capability in your OS.

squid3.1からIPv6がサポートされるようになり、IPv4/IPv6のハイブリッドソケットにより、IPv4とIPv6の通信を送受信するようになりました。

squid3.1はデフォルトではIPv6サポートが有効になった状態でビルドされるため、IPv6サポートを無効にするには、ビルド時のconfigureのオプションで、以下のオプションを指定する必要があります。

–disable-ipv6          Disable IPv6 support

BeagleBoard:(10)USBが不安定な原因が判明

以前、BeagleBoard Rev C4のUSBが不安定だと書きましたが、電力供給不足が原因だったようです。HighSpeed USB2.0 EHCIポートは不安定ですが、mini-USBポートであれば安定して使用できることがわかりました。

BeagleBoard:(8)USBが不安定? « 突然消失するかもしれないブログ

BeagleBoardのACコネクタに5V/1Aの電源を供給してみたところ、嘘のようにmini-USBポート、HighSpeed USB2.0 EHCIともにを使用してみたところ、USBが安定して使用できるようになり、快適にDebian Squeezeが動作するようになりました。

BeagleBoardは、mini-USBからの電力供給だけでは電力が不足するらしく、セルフパワーのUSB-HUBを使用していてもUSB機器を安定して使用することができないようです。

BeagleBoardは、状況によって1Aくらいの電流を要求するのかもしれません。

遠回りしましたが、ようやく安定してBeagleBoardが使用できるようになりました。大きな山を1つ越えたかなという感じです。

<追記:2010/05/01

半日ほど負荷試験を兼ねてHighSpeed USB 2.0 EHCIのポートを使ってみたのですが残念ながら死んでしまいました。シールド対策が不十分なのが原因なのでしょうか。。。

一応、連続して安定して使用できる時間が数分から数時間に伸びたので若干改善したことにはなるのですが。

現在、mini-USBのポートに切り替えて負荷試験中です。

ハードの問題なのか、ソフト(Linuxカーネル)の問題なのかよくわからなくなってきました。

追記:2010/05/01>

<追記:2010/05/02

apache benchを使用して、BeagleBoardに接続されたUSB-Ethernetのネットワーク負荷試験を数時間しかけてみましたが、mini-USBのポートが死ぬことはありませんでした。

BeagleBoardのHighSpeed USB2.0 EHCIポート周りは、やはり設計不良があるのかもしれません。

追記:2010/05/02>

 

BeagleBoard:(9)USBホストケーブルでBeagleBoard本体に給電できない(当たり前?)

BeagleBoardのHighSpeed USB2.0 EHCIポートが不安定なので、BeagleBoardのmini-USB(OTG)ポートをUSBホストとしてUSB機器(クライアント)を使用するためのmini-USBホストケーブルを購入しました。

BeagleBoardにmini-USBホストケーブルを以下のように接続してみたところ、mini-USB端子からBeagleBoardへ給電が行われないことがわかりました。

BeagleBoard→mini-USB(タイプA)→mini-USB(タイプB)→セルフパワーのUSB-HUB

なぜ!?なぜなの?

PCの場合だと、PCのUSBポート(タイプA=USBホスト)からUSB機器(タイプB=クライアント)へ給電する、つまり、USBホストからUSBクライアントに対して給電することはあるけど、その逆はない。

ということは、BeagleBoardのmini-USB(OTG)ポート(タイプA=USBホスト)からUSB機器(タイプB=USBクライアント)へ給電することはあっても、その逆はないというのは、当たり前なんですね。

ということで、BeagleBoardのmini-USB端子を使用するには、電源ジャックから電源供給をしてやるしかなさそうです。電源ケーブルを買わなきゃ。。。

心が折れそう。。。

%d人のブロガーが「いいね」をつけました。