NetBSDあれこれ

新品ノートでNetBSDの様子がおかしいのは、なぜ？

　ACPIに起因するらしき症状でメインのノートが正常起動不能、サブのデスクトップは電源管理を使うとえらいことになる電力食いマシンになり、致し方なく新品ノートを調達。

　今時、当たり前のように64ビットCPU、UEFI(BIOSも対応)、ノートで15.6型だと解像度1366x768だったりするが、これまで使っていた32ビットCPUマシンで使っていたSSDを調達した64bit CPUマシンのHDDと換装したら、NetBSDもマルチブートしているDebianもBIOSモードで起動したが、Debianは、ほぼ順調な一方、NetBSDはXが起動せず、ネットワークもつながらない...。

　Xの方は、Linuxは問題ないこともあり、解像度が未対応で何らかの追加作業が必要なのかもしれないが、ネットワークについては、Debianは有線LANは何もしなくても、無線LANはファームウェアをインストールすれば、ともにつながるのにNetBSDが繋がらないのは、なぜ？手動でやるにしてもdmesgを眺めてもネットワークインタフェースがないような気がする...。

　調達したマシンには、LANポートがあるが、LANポート直でも、従前使っていたUSB接続LANアダプタを挿して、これにLANケーブルをつないでもDebianは、今まで通り、あっさり、つながるが、NetBSDだと、やはり、つながらないし、LANアダプタの電源は入らないし、dmesgにも現れず、sudo usbdevsにリストアップされず、認識されていない模様なのは、なぜ...？

　ちなみに当該マシンTOSHIBA dynabook B45/Bの有線LANは、Linuxで認識される情報を見るとIntel PRO/1000(一方、dynabook.comにはIntel LAN Driver IN204C00040BAW1Cとある)、内蔵無線LANは、Intel(R) Dual Band Wireless AC 3165。

　64bitマシンで32bit OSを使うことは珍しいことじゃないと思うが、NetBSDの場合は、amd64あたりを使わないとダメってこと...なのかな？

　それとも先日ここに書いたACPI絡みなのか、標準ブートできなくなった謎の現象に起因している？

　どっちにしてもインストールし直してみないとダメ？

　と思って、まず、NetBSDのLiveUSBを起動、やはり、ネットワーク検出、自動接続はせず、ダメ元でインストーラを起動しても同様、ここでパーティションをいじってしまい、マウントはできるが、システムがなくなり、起動できなくなってしまった...。

　SSDをサブマシンにでもUSB接続するなりしてインストールし直すにしてもネットワークインタフェースは...？i386じゃなくてamd64じゃないとダメ？

　500GBの付属HDDに入ったWindows 10 Pro 64bitダウングレード行使権付きWindows 7 Professional 32/64bitは使わないつもりだったが、ついでに70GB以上とってたNetBSD用を分けてWindowsも入れるかな...ただ、ウィルス入ると厄介だし、常用するつもりもなく、そうなるとアップデート溜まって面倒か...んー...。

　というわけでNetBSD/amd64のboot.isoをダウンロード、GRUB2でisoをloopbackしてknetbsd (loop)/netbsdとしたらroot deviceを問われ、改めてnetbsd-INSTALL.gzをダウンロード、knetbsd /netbsd-INSTALL.gzとしたらsysinstは起動したが、[configure network]を選択しても[I can not find network interfaces for use NetBSD]とか言われてネットワークにつながらないし、何か間違えたのかディスクラベル設定もうまくできずじまい...。

　Intel PRO/1000には、wm、igphy(phy？)とかのドライバが該当しそうなんだけど、もしかしてbuild.shの出番？オプション有効にしてカーネル構築しないとダメ？そこまでしなくてもmodprobe？これLinuxだっけ？よくわかんないけどバイナリでなんかできたっけ？それとも実は、Intel LAN Driver IN204C00040BAW1Cで別の話になってくる？

Arduino IDE/sigrok/PulseView対応してくれるといいのにな

　以前、Arduinoに夢中になっていると書いてから早5ヶ月。

　まだ使い方はよく知らないのだが、PC併用前提のUSB接続の激安ロジックアナライザを買い、これにも対応しているというsigrok/PulseViewをDebianで(は古いからソースからインストールして)環境を整えてみた、これらソフトは、NetBSDでも対応とあった気がしたので少し安心していたのだが、いざ確認してみるとバイナリのリポジトリにもpkgsrcにもない模様、sigrok公式サイトを見るとlibsigrokやsigrok-cliなどはNetBSDにもソースからインストールできそうだが、PulseViewは対応していなさそうだ。

　また、シリアルポートの話(シンボリックリンクを張る手もあるかもしれないが、複数パターンとなるとちょっと...)もあってNetBSDのLinuxエミュレーションでデスクトップ版もWeb版もArduino IDEを使うのは難しそうだ。

　Arduinoや電子工作という視点ではなく、IoTという視点から、ラズパイだけでなく、ラズパイ登場(2012年)よりもずっと以前からあったArduino(2005年登場)についてもNetBSDでも対応しておいた方がよい気がするんだけど。。。っていうか対応してくれたらNetBSDに戻ってこられるんだけど。。。そんな日はやってくるのかな？こないのかな？

アップデートしたらNetBSDをBoot normarlyで起動できなくなったのはなぜ？

　先日、サブマシンであるPavilion上のNetBSDでpkgin fugしたあと、今日、電源入れてみたら、[2.Boot single user]や[3.Disable ACPI]などでは起動できたが、[1.Boot normarly]では起動しなくなった。

　ACPIだけの問題なのかな？

　というか、リポジトリにないよと言われたパッケージを結果的に4〜5個、pkg_tarupしておき、pkg_delete -fしたあと、pkgin fugによるフルアップグレードで多数のワーニングとエラーが報告された。

　さらっとエラーログを見たところ、報告数の割に特にたいしたことなさそうと思ったのだが、見間違いか。。。

　あ、この件、放置してて、すっかり忘れてた。。。今も素直には起動できない(画面左上に点灯カーソル、中央にX印がある状態でマウスもキーボードも効かない)が、[Ctrl]+[Alt]+[F*]で起動できる窓？(あれ、なんていうんだっけ？)があることがわかった(PolicyKit系のエラーのポップアップは出るが)。

　とりあえず、起動できることはわかったが、一体どうしてだろう？これってX Window system関連だっけ？

Firefox 52.2.0がクラッシュ

　先日バージョンアップ前もそうだったが、Firefox 50あたりから？、クラッシュ多発、今回アップグレードしたFirefox 52.2.0も何かの拍子になんの前触れも表示もなく、Firefoxが落ちる。

　なぜ？

　i386 シングルコアCPUには、今のFirefoxは厳しいってことかなとも思ったが、i386 デュアルコアのNetBSDでも同様であることからi386には厳しい。。。と思いきや、同マシンにはFedoraやDebianも入っており、Linuxでもそれなりにクラッシュするにはするが、もっとマシな状況であるとはいえ、バージョンが違うことからするとFirefoxに起因するものなのか？

NetBSD 7.1アップグレード

　11日にNetBSD 7.1リリースされてたのか、お、Raspberry Pi Zeroサポート、Linuxエミュレーション強化？でFlash Player 24とかも使えるようになったと。。。Flashどうなるんだろ？サポート終了は今月いっぱいじゃなくなったのかな？

　というわけでLive USBのsysinstでアップグレード。

Arduinoに夢中

　今更ながら、以前、発注していたArduino互換機等々が届き始め、電子工作・IoTデビューしたばかり(まだデビューしてないか？)の超初心者。

　NetBSDでブレッドボード図/回路図/基板図作成のみならずArduino含めシミュレーションもできるAutodesk Circuitsが使えた。

　よっしゃNetBSDで。。。と思ったものの、Arduino IDEのダウンロード版やウェブ版のプラグインは、NetBSDのLinuxエミュレーションで使えるのかな？

　超初心者だから、そこまで考える余裕もなく、そのあたりの脳の大半をArduinoが占めている今は、もっぱらArduino IDEがリポジトリにあったDebianを使ってしまっているのだが。。。

Firefox webrtcオプション〜今はまだ使えないということで待ち？

　あ、そういうこと・・・？下記リンク先によれば、後述の件に関しては、NetBSDでは、まだ、SCTP/Stream Control Transmission Protocol/ストリーム制御転送プロトコルの実装が完全でないことに起因するようで、これが解決するまではNetBSDのFirefoxでwebrtcオプションは有効にできないというのが現状の模様。

• firefox 45 + webrtc: configure stage fails
• pkg/51515: www/firefox fails to build with webrtc option enabled

　Firefoxにwebrtcオプション付けてmake install/updateすると、まさにwebrtcの辺りでエラーになって通らないのはなんで？(ちなみにpkgsrc-currentでもpkgsrc-2016Q4でも通らない。)

　もしかしてJitsiがwip止まりになっているのと関係ある？

　というのも先日買ったUSBカメラをNetBSDだけでもEkiga、Cheese、コマンド実行でMPlayer、mpv...などで検証、Debianでは、これらの他、Guvcview、Jitsi、Motion、コマンド実行でVLCなどを試し、Jitsiに至ってはFedoraでも試してみた。

　当初、オンライン登録不要で使えるRTCソフトを探してEkigaに行き着いたものの、ちょっとバグっぽい挙動もある。。。当のGNOMEプロジェクトもIM・RTCソフトにEmpathyを標準としている今となってはそれ以前のEkigaより、別途、試してみた開発継続中のJitsiが検証するにもよいかと思うに至る。

　NetBSDにおいてJitsiは、Jitsi側ではなく、NetBSD側で移植を進めているようでwipにもあるにはあるが、バイナリを使って動作しているものの、当のバイナリを生成する手段がないから解決するまではpkgsrcに移植しちゃダメみたいなところで約1年前から止まっている？模様。

　ただ、これってデスクトップ版の話？それともWebRTCベースのJitsi VideoBridgeやJitsi Meetも？ということでJitsiサイトにあったVideoBrideのテストページをNetBSD/Firefoxで試してみると[Your browser does not support WebRTC.]というポップアップが表示される。。。

　え？なんで？Firefox 50.1.0じゃ古い？いやDebianのFirefoxもっと古いけどできてるし、少なくともFirefox Hello!が登場したバージョン38だか39辺りからWebRTCには対応はしているはずだからブラウザバージョンによるものではないか。。。先のエラーをキーに検索してみるもなさげ。。。しばらくして、あ、もしやpkgsrcでオプション扱いなってる？と思い、www/firefoxでmake show-optionsしてしてみるとデフォルトではwebrtcオプションが無効になっている。。。

　そこで/etc/mk.confにPKG_OPTIONS.firefox+=webrtc行を追加してmake updateしてみたら、そのwebrtc部分でエラーになったという話。(エラー内容は、よく眺めていないし、エラー箇所もコピーしていないが。。。)

　なぜ？

Ekiga・CheeseとUSBカメラ

　sipアドレスによる送受信自体は可能だが、Ekiga(ekiga-3.2.6nb52)が、ちょっとおかしい気がする。

　1つめは、音声コーデックが2つ、動画コーデックはゼロだが、Ekigaのプラグインパッケージらしきものはなさ気だし、何かパッケージを入れれば、選択肢が出てくるのか、それはどれなのかが不明。。。(後述のUCAMでは動画コーデックがなくてもローカル映像が表示されたが。。。ここで指定するコーデックは何に使うものなのか。。。それともホントはあるのに表示されないだけなのか？)

　というのも一昨日の夜、AmazonでLogicool C270とElecom UCAM-C0220FEWHという2つのUSBカメラを買ってみた(ら昨日の夜届いた。。。相変わらず早いな。。)。

　当然、事前にNetBSDやLinuxで使えそうか確認したが、NetBSDについては情報がなさそうだったこと、ラズパイでIoTに使おうと思っており、ついでにやってみるビデオ通話については、Linuxで使えればまぁよしとすることにし、いろいろ調べたり、試してみたりした結果、ソフトウェアにはEkigaを使うことにした。

　昨日届いたところで早速、シングルコアCPU:1.60GHz/RAM:2GBマシン上のDebian、NetBSD、デュアルコアCPU:180GHz/RAM:2GBマシン上のDebian、Fedora、NetBSDで試したところ、Debian＋Ekigaでは何れのUSBカメラも利用できることを確認でき、Fedoraはリポジトリの関係でEkigaをインストールできない、NetBSDは、見落としたのかバイナリが見当たらない気がした為、make installしてみたら失敗。。。今日になって、なんだバイナリあるじゃん。。。ということでインストールしてみた次第。

　結果、デュアルコアマシンのNetBSDにおいては、何れのカメラもdmesg、usbdevs、Ekiga設定ウィザード、Ekiga設定パネルなどでも認識され、UCAM-C0220FEもC270もEkiga設定のデバイスに製品名＋GStreamerを選べばUCAMは正常に機能し、C270は映像が表示されないまま、そこで製品名＋PTLIB/V4L2を選択するとUCAMもC270もクラッシュ、シングルコアマシンでは何れのカメラもデバイス選択時にクラッシュ。([追記:2017/02/12]シングルコアマシン＋NetBSDでもmpv、MPlayerだとC270もUCAM-C0220FEも映像が表示されることがわかった。)

　ただ、シングルコアマシンのDebianでは何れのカメラも1度は使えたものの、その後、UCAMは認識すらされず、C270は認識こそされるものの映像が表示されない、両カメラの要求スペックからするとUCAMは厳しいにしてもC270はいけるはずだが、なぜかという話もあるが、どうもUCAMが怪しい気もしなくもないが、そうでなくてもマシンが要因となっている可能性も多分にある為、さておく。([追記:2017/02/15]管理者権限でEkigaを実行(sudo ekiga)すれば、C270だけでなくUCAMも共にシングルコアマシン＋DebianでもEkigaを起動できたので一般ユーザー権限においては、他のアプリやデーモンとリソース使用にあたって干渉している模様。)

　2つめとして、なぜ、PTLIBを選ぶと落ちるのか。。。そもそもPTLIBって何？と思い調べた結果、ライブラリを確認すると入っている模様、また、なぜ、PTLIBとGStreamerと2種類検出されるのか？

　3つめとして、なぜ、デュアルコアマシンのNetBSDで何れのカメラも同様にdmesg、usbdevs、Ekiga設定ウィザード、Ekiga設定パネル上でも認識されるのにUCAMが使えて、C270は使えないのか。。。

　4つめとして他に確認方法はないものか。。。と探した結果、Cheeseなら。。。とやってみるとデュアルコアマシン＋NetBSD＋CheeseでもUCAMは映像表示、画像、動画撮影ができる状態もC270はデバイスを選択すると認識はされるようで一瞬電源ランプも点灯するが、すぐ消灯、解像度がグレー反転して選択不能、値表示もされない状態でテスト・サンプルしか表示されない。

　自身としては、UCAMだけでもNetBSD＋Ekiga or Cheeseで対応できたことに満足気味も、C270も極めて惜しいところまでいっているだけに、どうにも気になる。。。

　5つめ、これまた謎なのだが、同じカメラをUSBポートに挿した際、デバイスの選択肢にあった[...(GStreamer/)]がなくなることがある(この時、不思議なことにekigaではなくlibv4lをpkgin rm libv4lし、pkgin in ekiga cheeseとすると全く同じ一連のパッケージがインストールされ、Ekigaで[デバイスの検出(D)]をクリックすると[...(GStreamer/)]が復活する・・・と思いきや、少なくともカメラ1台のみの場合、NetBSD起動後、先にUSBカメラをUSBポートに挿してからEkigaを起動すると自動認識により映像が表示され、設定リストでも[...(GStreamer/)]があり選択された状態になったりもするが、常にそうとも限らない模様)

　6つめ、テキストチャットでNetBSD＋Ekigaからメッセージ送信してもエラーになり、Debian＋Ekigaから受信した場合に対しては返信でき、Debian＋Ekigaにも届く。

　7つめ、Ekiga-3.2.6nb52は、国際化に対応していないのか？NetBSD＋Ekigaからのメッセージ入力時、日本語入力はできるが、確定できず、実質半角文字しか送信できず、相手からの半角文字は受信できるが、日本語文字は受信できない。

　8つめ、Ekiga-3.2.6nb52の仕様なのか、有効な『仲間』のリストの中から相手をダブルクリックしても反応がないが、少なくとも相手を選択、右クリックして『発信』としても反応がないのはおかしい。(Debianだが、Ekiga 4.0.1では、呼び出し・発信される。)

　9つめ、音声デバイスは、dmesg上で[audio1]だったとしても[出力]で[/dev/audio]とした時のみ相手からの音声が聞こえるが、一音一音途切れる。

Firefox 50.0.1で[NS_ERROR_NET_INADEQUATE_SECURITY]〜解決済み

　滅多にないことだが、たまたま、直前にとあるバイナリパッケージをインストールしたら依存関係上のバージョン不一致があり、エラーになったことに起因するものと思われるが、Firefox(Firefox 49)を起動できなくなり、エラー確認の為、端末から起動させてみるとライブラリのバージョン不一致(少し古いバージョンを要求され)、複数、コピーしていったものの、途中、単なるコピーでは解決できそうもないエラーに遭遇、念のため、リポジトリを確認すると幸いにもFirefox 50.1.0があったのでインストール、何事もなくインストールでき、起動できたのは良かったが、その後、時間にして数分程度とはいえ、以下2点でハマった。

　1つめは、Firefoxが起動したはよいが、ネットワークはつながっている(pingなどで確認済みな)のにGoogleやYahoo!に接続しようとすると[エラーコード: NS_ERROR_NET_INADEQUATE_SECURITY]と表示され、接続できず。。。Seamonkeyで試すと先のFirefox同様のライブラリ関係の理解不能なエラーでひっかかり、リポジトリにはより新しいバージョンがあった為、アップデートしようかとも思ったが、とりあえず、やめておくことにし、mozillaのSSL証明書関係のコマンド(mozilla-rootcerts/mozilla-rootcerts-openssl-2)の実行が必要なのかな？とも思ったが、mozilla系の問題なのかどうかを切り分ける意味でも他のブラウザで試してみようとMidoriをインストールし確認してみるとGoogleやYahoo!も難なく、あっさり開くことができる。。。やっぱり、mozilla系か、とするとSSLかなと思いつつも、せっかくつながったことだし、素直にMidoriを使って先のエラー識別子をキーにググってみることに。

　検索結果の1つであるmozillaサポートフォーラムの、このページによると、どうやら現在、HTTPプロトコルがHTTP1.1から最新のHTTP/2への移行の過渡期にあるようでFirefox(Mozilla系ブラウザ)がこれに未対応であることに起因する模様、暫定措置としてURL入力欄でabout:config、警告を確認の上、編集画面を表示、そこにある検索バーで[http2]を検索するなりして[network.http.spdy.enabled.http2]行をダブルクリック、[true]から[false]に切り替えればよいとあり、やってみると確かにこれで解決した。

　2つめは、LXDE上でFirefoxがメインメニューや端末からは起動するようにはなったが、タスクバー(lxpanel)上のアイコンをクリックしても起動させることができず、Application Launcher Bar上では、ブラウザアイコンも表示されているし、一覧にもあるが、選択して追加ボタンを押してもブラウザアイコンを追加できなくなっていることに気づいた。

　そこでメインメニューやデスクトップアイコンの参照パスの1つである~/Desktopからlxpanelの探索パスの1つでユーザー用の~/.local/share/applicationsに(なぜかFirefox0.desktopとなってはいたが)Firefox.desktopのシンボリックリンクを張ってApplication Launch Barで前に登録したブラウザアイコンを削除、新たに追加することでパネル上からもFirefoxを起動できるようになった。

　これらとは別に、なぜか、Yahoo!のトップページを開き、ニュースの(ajaxによる)タブの内、[国内]タブをクリックすると何度やってもFirefoxがクラッシュする現象に遭遇。(他のリンクやタブではクラッシュしないし、他のサイトでもクラッシュしない。)

　クラッシュする度に何度も起動してYahoo!を表示、[国内]タブをクリックしてみた結果、ポップアップが出たので、勢いで、なんらかのクリアボタンをクリックしたところ、既に日本語対応できていたのに英語表記になってしまうもAdd-onsの[Language]やabout:configを確認すると何れも日本語が有効になっている。。。メニューだけだし、別にどっちでもよいとは思いつつも、[Language]で一度、Disableし、再度、EnableとしてFirefoxを再起動してみたら日本語表示になった。

　これはYahoo!の問題なのか？と思い、マルチブートしている今時点最新のDebian 8.7 JessieのFirefox 45.7.0で試してみたら[国内]タブをクリックしても大丈夫、NetBSD上のFirefoxでもアップデート前までは起きていなかったことからFirefox 50.1.0に起因すると考えてよさそう。

　ちなみにFirefoxも先日51.0がリリースされたとはいえ、Debianが安定重視で枯れたバージョンを使うディストロとは言え、また、ここのところNetBSDが頑張って前バージョンまでは追従しているとはいえ、NetBSDのFirefoxの方が、Linuxより遥かに新しいというのは、古株でない自身でさえ、なんとなく感慨深いものがある。

　Firefox 50.1.0に起因していると考えてよさそうだが、念のため、リポジトリにあるfirefox45.5.1(言語パックなし)を入れて確認してみたところ、やはり、当該事象はなく、正常に機能することがわかった。

　ただ、Firefox 50.1.0の問題なのか、これとNetBSDが絡む問題なのか気になったことから、『"netbsd" "firefox 50.1.0"』でググるとNetBSD/i386 7.1_RC1 ておくれLive Imageに「firefox 50.1.0 が segmentation fault で落ちることがある」、NetBSD上のFirefoxからVMware ESXi 6.0u2または6.5のウェブクライアントを使うに「firefox 50.1.0で異常なキーリピートが発生。。。English (US)に変えて試してみたところ、キーリピートの問題は解決した」旨の情報がある。。。

　今回はクラッシュしたのだから前者かと思いきや後者の「English (US)に変えて試してみた」が、どうにも気になりつつ、マシンの電源を一度OFFにしたが、別件で再度、起動、その際、言語パックFirefox-l10n(50.1.0用)を削除、firefox 50.1.0も一度削除し、再インストールしてみたところ、Yahoo!トップページの『国内』タブをクリックしてもクラッシュしなくなった。。。

　再び、Firefox-l10n(50.1.0用)をインストールしたところ、Add-onsにLanguageタブがない。。。Firefoxを再起動してみたらタブが表示されたが、あえて何もせずにFirefoxを起動、Yahoo!を開いて・・・とやってみたところ、 クラッシュ。。。端末から起動していたのだが、何やら以下のようにABORT、WARNING、ERRORが。。。

　ここで再び、Firefox-l10n(50.1.0用)をアンインストールしてみたものの、同症状が再現する。。。やはり、Firefoxの再インストールかマシンの再起動、もしくは、それら両方を要するのか。。。？

　まずは、Firefox-50.1.0をアンインストールし、再インストールして確認、端末から起動、同様にやってみると、やはり、クラッシュし、Segmentation fault。

　マシンを再起動してFirefox-50.1.0を端末から起動、同様にやってみるとクラッシュすることなく、[国内]タブを開くことができるようになった。

　言語パックも適用していたFirefox 49以前には同症状は起きたことはないが、念の為、検証用に入れたFirefox45.5.1用の言語パックFirefox45-l10n-45.5.1を入れて確認してみたところ、相変わらず、素直にAdd-onsにLanguageが表示されないが、同様にやってみると何事もなく[国内]タブを開くことができる。

　というわけで少なくとも自身の遭遇した問題については、言語パックFirefox-l10n(50.1.0用)に起因する模様。

　ただ、send-prはしづらいな。。。Yahoo!Japanのトップページでしか、この症状に遭遇しないし。。。言語パックが原因だとすると英語圏では問題ないわけだし。。。

　と思ったのも束の間、今朝、言語パックなしのFirefox-50.1.0でもYahoo!Japanトップページの[国内]タブをクリックするとクラッシュ。

　言語パックに起因するものではなかった。。。

　クラッシュする前に一瞬のタメ(間)があることから、ギリギリまで耐えてみたけど、やっぱり無理！っていう状態に見える。

　[国内]タブは、初期表示時には全体が表示されていない為、Ajaxといえど、画面を読み込み、更新されるタイミングにあたると思われ、その際に何らかの余計な負荷がかかっているような気がする。

　が、WindowsやLinuxに同じバージョンのFirefoxを入れてみるというのは億劫で検証はしていないこともあり、Firefoxの特定のバージョンに起因するのか、OSに起因するのかすらわからない。

　ここのところArduinoで電子工作、IoTにハマってもっぱらDebianを使っているが、安定志向のStable版は未だにFirefox 45.8.0だが、Firefoxが落ちまくるのはDebianも同じだ。。。よってクラッシュは、OSではなく、Firefoxに起因するものと考えてよさそう、ただ、近年求められるブラウザ性能に対してマシンスペックが追いついていないからという可能性は残るが。

NetBSDにおけるLXDEの初期設定で(たぶん一時的に)注意すべきこと

　NetBSDでもLXDEをインストールできるようになって久しい、そんな折、一時的であることを期待するも公開された当初や多くのLinuxに比べ、現時点では、必要な初期設定がちょっと増えている。

　バグというほどでもない為、change-requestとしてsend-prしてみたから、そのうち何らかの反応・成果があるかと思う(そう期待している)。

　基本的には、NetBSDリポジトリに収録されたLXDE/MATEを追加インストールの通りで良いのだが、現時点では、これに加えて以下が必要。

1. [/usr/pkg/etc/xdg/lxsession/LXDE/autostart]に[@openbox-lxde]行を追加
2. ~/.xinitrcのLXDE起動に関する記述は[ck-launch-session dbus-launch startlxde]などとし、依存するdbusを明示的に実行する(startx[or xinit]＋~/.xinitrcを使う場合)
3. [~/.xinitrc]などに[export XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS}:/usr/pkg/etc/xdg]を追加
4. [~/.xinitrc]などに[export XDG_DATA_DIRS=${XDG_DATA_DIRS}:/usr/pkg/share]を追加

　当然、/etc/rc.d/dbusも起動させておく。もちろんリンク先の各種設定も必要。

　これらの内、2項以外は、自動設定されるか、何らかの対処により、何れもあえてインストール後にやる必要はないはずだが、現時点では、これらを別途設定しておかないと次のような現象に見舞われることになる。

• LXDEが起動しない
• メインメニューを含むlxpanelが表示されない
• メインメニューではRunとLogout以外は空、Application Launcher Barの中身も空になる(それぞれ別の対処方法もあるが妥当とは言い難い)
• 起動するパッケージソフトウェアのウィンドウバー(本来、最大化/最小化・閉じるボタンなどがある領域)がなく、そのほとんどは、左上に固定となり、ウィンドウバーがないため、移動できない
• [GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed...]といったエラーメッセージのポップアップが出る
• 等々

　2項についてもgdmを使う場合は自動でやってくれるようで、これに関する能動的な設定は不要。

　あ、send-pr、ウィンドウバーじゃなくてメニューバーって書いちゃった。。。修正もできそうな気配だけど、ま、いいか。。。(と言いつつ、修正してみたが、末尾に履歴として追記されるだけなのか。。。)

今やNetBSDはデスクトップ環境としても十二分に堪能できる

　NetBSDを使い始めて約3年、ターゲットマシンの内、今更ながら、最も低スペック(シングルコアCPU:500MHz/RAM:128MB)なマシンでもデスクトップとして使えるOSはあるのかという視点から、結果、NetBSDとOpenBSDにたどり着き、OpenBSDの元は、NetBSDかということでこれを選択するに至った。

　その後、シングルコアCPU:1.6GHz/RAM:512MB/HDD:80GB、デュアルコアCPU:1.8GHz/RAM:1GB/HDD:160GBにもNetBSDを入れ、後に、2台共RAMを2GBに増強、前者のHDDをSSD:128GB、後者のHDDをHDD:2TBに換装、何れもデスクトップ用途で、検証・補完にDebian、Fedora(、つい最近1.2がリリースされた模様もFreeDOS 1.1)などをマルチブートさせているが、途中からメインOSは、NetBSDとすることにした。

　その最大のポイントは、複数台マシンがあってその全てに同じOSを入れる場合、NetBSDのpkgsrcとパッケージ管理システムはソースコードからコンパイルするにしてもバイナリを使うにしても最も効率的で合理的に一貫して、しかも比較的容易に利用できるという点。

　ソースコードを扱うことができる、ソースコードを扱うコマンドが比較的充実している、ソースコードの管理システムがあるというのと、それはもちろん、バイナリも含めて一貫して管理でき、それを容易に利用できるというのとでは大きな違いがある。

　FreeBSDやOpenBSDなど*BSDは総じて同様な利便性があるが、当時検証した際、前者は前述の最も低スペックなマシンには厳しかった、後者はセキュリティ面で有名もオリジナルである点を優先してNetBSDを選択した一方、先日、気まぐれからFreeBSD、OpenBSD共にインストール、すぐに利用環境を整えられる手軽さはあったが、やはり、NetBSDの方が良いという結論に至った。

　NetBSD上で自身が実現できていない点を強いて挙げるとすれば、公式サイトなどにもできるとするWikiがあったりもするが、自身にはできないCUPSの利用と以前はFirefoxで視聴できていたが仕様がコロコロ変わり、のちに常にFlashの最新を求めるようになり、今はできないGyao!の視聴の2点くらい。

(同じFlashベースでもTVer、radiko、らじるらじる等はユーザーエージェント変更の必要もなく視聴可能、また、ユーザーエージェントを変更すればYahoo!映像ニュースも視聴できるし、当然、HTML5ベースのYouTubeも視聴可能。)

　何れも滅多に利用することはない為、NetBSDをデスクトップ用途で使うにあたり、全くと言って良いほど不便はない(し、仮にあったとしてもその時はマルチブートしているLinuxを使えば済む)。

　パッケージ管理用のGUIはないが、GUIのあるDebianやFedoraといったLinuxでも結局は、端末からコマンドを実行する方が、早くて便利であり、サブであるLinuxでさえ、実際そうしている、NetBSDの場合、ソースならpkgsrcでmakeでき、バイナリならpkginがあって少なくとも日常使う分には、aptやyum/dnfと遜色ないほど便利、別途GUIがあることに異議はないが、実際、パッケージ管理用のGUIは、なくても不便はない。

　更に既に利用可能だった数多くのウィンドウマネージャはもちろん、KDE4、GNOME2、Xfce4に続き、MATEやLXDEのバイナリも公式に加わったことは、ましてMATEやLXDEを最も好み、Unity、KDE、GNOME 3、QT系が苦手な自身としては、満足この上ない。

　また、Firefoxも45.0あたりから？以前と打って変わって最新、もしくは限りなく最新に近いバージョンのバイナリを利用できるようになった為、益々言うことなし。

　そもそもサーバ用途にも使えるし、組み込みにも使え、BeagleBone、Cubieboard、Banana Pi、Raspberry Piなどにも使える(自身はラズパイにRaspbianを入れてしまったが、これをNetBSDへ置き換えても全く問題はない)、パッケージ管理システムが秀逸、あらゆるアーキテクチャに対応、NetBSD上だけでなく、それ以外のOS上でもクロスコンパイルもできる。。。今や、それだけでなく、NetBSDは、日常使いの常用デスクトップ用途にも十二分に通用するようになったと言っても過言ではないと思う。

NetBSDのGRUB 2不調？

　同じUSBメモリの同じパーティションに対し、共に--forceオプション付きで、NetBSDのリポジトリにあったGRUB 2だと微妙に時間がかかる上にセグメンテーションフォルトでgrub-installできずに停止し、DebianのGRUB 2のgrub-installだとインストールできてしまう状況に遭遇したのだが、なぜ。。。？

　探してもなさ気だったから、その名もsend-prコマンドもある模様も送信フォームからsend-prしてみた。

問題なかったUSBメモリの中身をfdiskで表示できなくなった！？〜FATの破損〜解決

　NetBSDとは直接関係ないが、レスキューUSBメモリでいろいろ検証している中で何かやらかしたのか？それまで問題なかったUSBメモリの中身をNetBSDのfdiskやdisklabelで中身を確認しようとすると「DIOCGDEFLABEL及びDIOCGDINFOにおけるデバイス用のioctlが不適切」といったようなエラーが表示され、終了してしまう。。。マルチブートしているファイルシステムの内、いずれかが壊れたか？

　このUSBメモリ内には、FATとFFSしかない為、NetBSDでもfsck_msdosはあるわけでやってみればよいのだが、滅多にない、こういう状況の時には、Linuxなどを起動してGPartedの[チェック]を使ってfsckしてたので今回もそうしてみることにした。

　FATパーティション2つとFFSパーティション1つから成るUSBメモリにおいて、GPartedで[チェック]してみるとGRUB用のFAT32パーティションでcannot resize this partition to this size.といったようなメッセージが。。。どうやらlibpartedにおけるresizeでエラーになっている模様

　特定のバイト位置だけがおかしいのか？と何通りか開始位置変更とこれに伴いサイズを変更してみたが、変わらず。。。検索するとLinuxでFATをfsckしても直らないケースもあってWindowsで。。。といったような情報があり、それが妥当か？とも思ったものの、Windowsはあっても仮想マシンにしかない為、それならextにすれば、Linuxで対処できる、ext2/ext3なら現行のNetBSDでも対処できるってことか、ということでext3としてみることに。

　それでもマウントはでき、これがGRUB2パーティションだった為、既存の(grub.cfgだけでもよかったが、)grubディレクトリを一時退避、FATのGRUB用パーティションを削除、ext3で再作成後、[チェック](fsck)してみたら、エラーなく完了したため、これをマウント、退避しておいたgrubディレクトリを当該マウントポイントに移動、--force及び--boot-derectoryに当該マウントポイントを指定し、grub-installすることでNetBSDでもマウントできるようになった。

　USBメモリが物理的にどうのというわけではなく、単にFATパーティションが壊れていただけだった模様。

　更にもう1本、検証用に使っていてFFSとFATしかないMBR形式のUSBメモリが、同様の症状となっていた。

　今度は、NetBSD上でfsck_msdosしてみることにし、やってみたら、ブロック修正とfsckで2度実行することにはなったものの、あっという間で、あっさり直った。。。先の1本もNetBSDでfsck_msdosしておけばよかった。。。

fdiskを見ればdisklabelの情報は一致する・さもなくば一致させる

　超今更ながら。。。とてつもなく基本的なことに気づいた。。。

　disklabelが壊れてもfdisk結果を見れば、必要な情報は「全て」書いてある。。。

　逆も真なりだが、当然、どっちも変にいじっちゃって正解がなくなると意味はない。

NetBSDからFreeBSDってマウントできないんだっけ？〜一部勘違い〜含めて解決

　勘違いから後述のようにあたふたしたわけだけど、実は、FFS/UFS云々以前にdd埋め込みしたのは、FreeBSDのbootonlyの.isoだったことから、このパーティションにあるFreeBSDのファイルシステムタイプは、FreeBSD/NetBSDで言うところのcd9660、Debian(Linux)で言うところのiso9660だった。。。mount -t cd9660|iso9660(どっちか)でNetBSDでもDebianでも、このFreeBSDパーティションをマウントすることができた。。。

　ちなみにNetBSDでもdisklabel -lでfstype一覧が表示されることに気づき、disklabelにおいてFreeBSDの.isoをddしたパーティションのfstypeをISO9660、これだけだと項目が少なすぎると言われ変更が有効にならなかった(FreeBSDを入れてUFSだと思い込んでいたこともあってaパーティションをコピー、fsize、bsizeなどを消したら同様のエラーが出たことがあった)こと、検索してみたものの、これというものがなかったことから。。。適当にfsizeを0としてみたら、タイプ指定(mount_cd9660/mount -t cd9660)しなくてもmountできることがわかった。

　単にmount、[Enter]とすることで現在のマウント状況と共にそれぞれのファイルシステムのタイプが表示されることから、FreeBSDのインストーラ兼Liveを起動してやってみたら、cd9660だったというオチ。。。

　ただ、FreeBSDをインストールした環境がない為、NetBSDからFreeBSDをマウントできるよね？できないんだっけ？という素朴な疑問については未確認。

　っていうか、zfsならともかく、NetBSDでmanを見ると、どうやらmount_ffsとmount_ufsは実質、同じみたいだから、UFSならFreeBSDのパーティションもマウントできるってことか。

　NetBSDだと[incorrect super block]となってFreeBSDの入ったパーティションをマウントできなかったんだけど、そういうもの？当然のようにできると思い込んでいて試しておこうと思うこともなかったのだが。。。

　apropos/man -k ufs2やapropos/man -k freebsd mountとすると多少情報出てくるけど、WAPBLかな？違うか。。。この場合、カーネルオプションCOMPAT_FREEBSDの有効・無効も関係ないよね？

　検索してもFreeBSD|OpenBSDでNetBSDのパーティションをマウントって話は多少なりともあるけど、逆はないし。。。OpenBSDは未確認もFreeBSDからNetBSDのパーティションをマウントできることは確認済み。。。単にdisklabelの問題かな。。。？

　NetBSDインストール以前から探し求めていたNetBSD Live版。。。build.shで簡単に生成できるようになっててラッキー、これで*BSDをマウントできるだろうし、FreeBSDのLive兼インストーラと入れ替えられる。。。と思ってたけど、これだと併用だな。。。

MBRパーティションのID TypeとGPTパーティションのType〜一部勘違い〜一部解決

　MBRパーティションとGPTパーティションでは、ファイルシステムのタイプの種類が異なる、というか、GPTの方が新しい仕様であることもあり、その種類も詳細に分かれて、その数も豊富になっている。

　MBR形式とGPT形式のレスキューUSBメモリを2本、ほぼ同じ中身で同時並行して検証・作成している時に、このことを意識することになった。

　これらUSBメモリには、読み書き可能な*BSDのマウントをサポートしていた為、FreeBSDのインストーラ兼LiveのISOディスクイメージをdd埋め込みで入れてあるのだが、最初からだったのか、何かしたからなのか記憶にはないものの、なぜか、マウントできない。。。

　前述の通り、ddしたにしろ元は.isoだからcd9660だったというオチに気づかず、NetBSDだと[incorrect super block]となってマウントできなかった為、Debianで試したのだが、UFS2だと思い込んでいた為、[-o ro,ufstype=ufs2]を付けてUSBメモリ上のFreeBSDのパーティションをマウントしようと試みると[mount : wrong fs type, bad option, bad superblock on /dev/sdb3...]のように出てマウントできず、どうもファイルシステムが正しくない為に読み取れていない模様。

　ただ、一方でDebianでは、オートマウントでそのFreeBSDのパーティションをマウントできており、端末やファイルマネージャでマウントポイントを見るとちゃんとファイル類がリストされている。。。不思議だ。。。

　そこでDebian上でfdisk結果を見比べてみると微妙な項目の有無や違いもあるが、ID Typeと書かれたMBR形式とTypeと書かれたGPT形式のTypeの内容が違う。。。それぞれ、fdiskコマンドの(l)istサブコマンドでタイプ一覧を表示すると結構違うことがわかり、FreeBSDのType|ID TypeはGPT形式では[27 FreeBSD UFS]となっており、MBR形式では[a5 FreeBSD]となっている。

　MBR形式の方は、領域だけ切ってイメージファイルをddした状態でFreeBSDのパーティションにも関わらず、なぜか、[83 Linux]になっており、マウントできないからと[a5 FreeBSD]に変更したところだった。

　FreeBSDで[a5 FreeBSD]がダメなら、[FFSv2]。。。つまり、[a9 NetBSD]か。。。？と変更してみたら。。。Debianでは(ufs指定しなかった為、自動でiso9660として認識され、)マウントできた(ことに気づいていないだけ)。。。[a9 NetBSD]なら、NetBSDでもマウントできるよね？とやってみたが、NetBSDでは、やはり、[incorrect super block]となってマウントできない。。。disklabelの設定が間違っているのか？

　でも、GPT形式では同じイメージファイルをddで埋め込んだはずのパーティションタイプが[27 FreeBSD　UFS]。。。かたやMBR形式だと[a9 NetBSD]。。。なんで？

　GPT形式の方のFreeBSDパーティションも[52 NetBSD　FFS]にしたらNetBSDでもマウントできるのか。。。？とやってみたが、NetBSDではマウントできず、Debianでは、どっちにしてもマウントできた(ufs指定なしでiso9660自動認識されたことに気づいていない)。

　Debianのmount、-tオプションも-oオプションも付けることなく、FreeBSDのパーティションタイプが[52 NetBSD　FFS]だろうが、[27 FreeBSD　UFS]だろうが、あっさりマウントできたけど。。。どっちも-t ufs -o ro,ufstype=ufs2でマウントしたのか、前者は、ufstype=44bsdとして自動的に判断してマウントしたのか。。。？と思ったら、明示的に指定したらどっちも失敗、オプション指定しないとマウントされた。。。なんで？

　あれ？明示的に指定してできてたよな？GPT形式もMBR形式もどっちもできてたよな。。。？あ、LinuxからNetBSDのマウントは試したことあったし、内蔵SSDもNetBSD・Debianマルチブートで相互にオートマウントしててDebian側の/etc/fstabも44bsd指定してるけど、FreeBSDのマウントは試したことなかったか。。。FreeBSDだし、ufstype=44bsdではできないことは確認済みだけど、ufstype=ufs2指定ってできるはずだよね？あれなんで明示的に指定するとマウントできないんだ？もしかしてUFS2じゃないってこと？

　ということでmountで確認、dd埋め込みしたのがFreeBSDのbootオンリーな.isoで実は、ファイルシステムタイプはcd9660/iso9660だった。。。というオチに気づくことができましたとさ。。。めでたし、めでたし！？

　あれ？待てよ？それじゃ、なぜ、Debianでは、GPT形式ではどっちでもマウントできた一方、MBR形式では、ファイルシステムタイプが[a5 FreeBSD]だとダメで[a9 NetBSD]だとマウントできたんだ。。。？iso9660だったんだよね？ってfdiskのファイルシステムタイプにiso9660/cd9660なんてないか。。。それにしても、どうして？(たぶん、何かの勘違い。)

MBR/GPTパーティションとBSDパーティションにおけるパーティションフラグ

　BSDパーティションは、MBR/GPTパーティションの内側に構成されるパーティションという認識でよいよね？

　それだからか、NetBSDのgptコマンドとLinux(Debian)のParted/GPartedでは、実際には、その位置が異なるのか？同じパーティションフラグを操作してもLinuxでのフラグ操作は、NetBSDに、もしくは相互に？反映されない(NetBSDでは、その変更が認識されていない？)気がする。。。

　ちなみに、これ、インストール済みNetBSD Liveイメージをそのままdd、もしくはイメージと用意したUSB上のパーティションをマウントしてrsyncという2通りでGPT形式のUSBメモリでブート検証中、NetBSDのgptコマンドと(Linuxの)Parted/GPartedで、あれこれやっている時にそう感じたんだけど気のせいかな？

NetBSD Live USBの利用とマルチブートほか

　数か月前、build.shで作ったNetBSD 7.0.1のlive-imageを使い、今日、USBメモリにddして実機でインストール済みNetBSDのLive USBを、QEMUで同Liveイメージファイルを起動させてみたらできた(前者はsd0版、後者はwd0版)。

　なぜ数ヶ月後に？という話だが、恥ずかしながら、その時は、sd0版とwd0版、なんで2種類あるんだ？と思いつつ、深く考えることもなく、USBメモリに入れるならNetBSDにUSB挿した時に割り当てられる1つめのデバイス名であるsd0版だよねと思いつつ、ここで勘違いしてHDDかのようにsd0版をQEMU(qemu-system-i386)の唯一の引数として渡してしまうという失態。。。

　当然これでは起動するはずもなく、HDDとして引数にするなら、NetBSDのHDD/SSDとして割り当てられる1つめのデバイスはwd0なんだからwd0版でしょ！という点に思い至らないどころか、wd0版もUSBメモリに使うことがあるのか？いやいや。。。なんてボケっぷりを発揮。。。。

　まぁ、でもどっちにしろ以前、Groovy UD-500SAで壊れかけHDDをUSB接続、NetBSDを起動させた後、PC内臓SSD側のNetBSDがwd0が認識できないかのような謎の不調に見舞われ、HDDとSSD共にwd0だったのが原因か？なんてトラウマもあってwd0版は試したくない。。。なんて発想があさっての方を向いてしまい、QEMUでwd0版を試すこともなく、放置していたから。。。

　つまり、USBメモリに入れるなら、sd0版というところまでは、まだよかったが、なぜか、QEMUでもHDDとして使うなら、wd0版を使うべきという発想に至らなかったことが原因。。。NetBSDユーザーとして素直に考えれば、当然の話なのだが。。。

(あれ？ダメ元で以前作ったsd0版をQEMUで実行してみたら、NetBSDのQEMUのバージョンがあがったのか？[Cant't open /dev/rsd0a: Device not configured]と言われて/bin/shには落ちた。。。から変更さえ加えようとしなければCLI操作でちょっとした使用確認くらいはできる。。。前回のように起動できないのが正常なような気もするが、QEMUとsd0版において、どの挙動が本来の姿なのか不明。。。)

　それでも時間の経過で、すっかり、脳みそがリフレッシュしたのか、今日は、ふとwd0版をQEMUで試してみようと思うに至り、やってみたら、あっさり起動。。。なんだwd0版なら起動するんじゃん！とちょっと感動(しつつ、ということは、wd0版は使えるが、sd0版は、やっぱり何らかの原因で動かないんじゃんと引き続き勘違い。。。)。

　wd0版は不具合がなく、sd0版は不具合があるという誤解を抱えたまま、既にLiveツールなど中身が入っているUSBメモリにパーティションを切ってwd0版をセットしてみた。。。が、ブートできない。。。(ここはsd0を使うべきだから当たり前)。。。。

　他方、試しているのは、GRUB経由。。。これはこれで起動できないハマりポイントで現在も調査中なのだが、その際は、幸いにも即、『netbsd "live-image" usb』をキーにgoogle検索、Re: How to install NetBSD on a USB stickで"the sd0 image will work on USB drives, and the wd0 image will work on SATA drives"という一文を発見、使い分け方が判明した次第。。。

　さて、sd0版をUSBメモリにddすればよいことはわかったが、検証用と化したUSBメモリも、何かの専用にするつもりはないため、当たり前のようにパーティションを切って試したのだが、起動しない。。。

　数時間に渡り、DebianでGPartedやfdiskを使ったり、NetBSDでfdiskなどNetBSD環境だけでやってみたり、GRUBプロンプトからいろいろやってみたりしてみると、なぜか、"NetBSD MBR Boot ... not bootable ..."などとなる。。。

　いろいろとやっている内、ん？もしかしてUSBメモリ全体にsd0版を入れれば起動できるのか？と思うに至り、ddでzero埋めよりもGPartedが早いか。。。とUSBメモリをフォーマット、そのままDebianでもよかったが、NetBSDを起動してUSBメモリ全体にddでsd0版を入れたら、実機でも、あっさりインストール済みNetBSD Live版が起動した。。。

　あとは、これが、USBメモリ内でパーティションを分割してマルチブート状態でもいけるのか、やはり、専用にしないとダメなのかどうか。。。ダメだとしてもマウントして中身をrsyncしてブートローダをごにょごにょしてイメージファイルを作りかえればよいのか？。。。まっ、今日は、sd0/wd0版が起動できることがわかった安堵感から気が抜けたので検証は後日。。。

　すっかり、全容量がNetBSD領域になっているものと思い込んでいたが、NetBSD Liveだけを入れてまるごと使ったMBR形式のUSBメモリをfdiskしてみるとパーティションを追加できる状態になっていることに気づいた。(全て使って余らないはずでは？と思わなくもないが、そういうものなのか？MBRパーティションとBSDパーティションが別だから成せる技なのか？普通に空き領域がある。)

　disklabelの方は、NetBSD Live分を全容量としていたりと手直しする必要はあったが、修正後、GRUB用にFATパーティションを追加、Debianからマウントの上、GRUB2のgrub-installを実行、GRUBから起動できるこも確認済み。

　NetBSDにもGRUB 2あったはずだけどな。。。と思いつつ、リポジトリを探すこともなくDebianを起動したが、pkgin av | grep -i grub2としたら、やっぱりあった。。。

　というわけで別途何らかのLive版などを追加すれば、マルチブートも可能だ。

　先日のとは別に既にマルチブート構成にしてあるMBR形式のUSBメモリで後からNetBSD Liveを入れてもNetBSD Liveをブートできるのか試してみた。

　方法としては、rsyncではなく、ddコピーを使うことに。

　ddコピー元は、先日、まるごと使って起動確認済みのMBR形式のUSBメモリのパーティション、ddコピー先は、既にマルチブート構成になっているUSBメモリに新たにパーティションを追加して行なった。

　するとdynabookとe-oneでは起動するが、なぜか、Pavilion Slimlineでは起動できない。。。

　より具体的には、何れのマシンもrootデバイスを見つけられず、[root device (default sd0c):]というプロンプトが表示され、dynabookとe-oneは、これを[sd0a]として後を[Enter]していったら起動し(、fsはgenericとしてもffsと認識され)たが、Pavilion Slimlineの方は、そこで何を入れても起動できず(、fsはgenericだとmsdosと認識され)、initの絶対パスを問われ、ddb、reboot、haltを選ぶしかなくなった。

　実際には、Pavilionの方を先に試し、うわ。。。起動しないのか・・・と軽くショックを受けたが、なんとなく、dynabookでやってみたら起動した為、多少安堵した。

　ただ、最初にまるごと使ってNetBSD Liveを入れたUSBメモリは、Pavilionでもdynabookでも起動する為、これはどうもNetBSD Liveが先頭パーティションにあることが想定されていると考えてよさそう。。。なんでそうなるんだ？パーティションテーブル？

　と思ったら、hexdumpして気づいてみれば、NetBSD Liveのパーティションをddコピーした後、当該パーティションにfdisk -aでActiveフラグを立て忘れてた。。。Activeフラグ立ててみたらPavilionでも[sd0a]で起動した。。。が、それにしたって、なんで同じx86なのにActiveフラグON/OFF時の挙動がマシンによるんだ。。。？

　イメージファイル自体や起動確認できているUSBメモリやパーティションの先頭512バイトだけdd後、hexdump -Cして可読文字だけ抜き出すとこんな感じだが、起動するUSBメモリでも微妙な表記があることからして関係なさ気。

　こっちより、16進数値の方だな。。。きっと。

　この辺疎いのだが、dd後にinstallbootしてみたり、ddでzero埋めしてみたりもしてはみたものの、少なくとも好転はしなかったように見受けられた。。。

　そこでASCII値である右側のブロックは端折ったが、NetBSD Liveにおいてルートパーティションを聞かれるUSBメモリのMBR512バイトからパーティションテーブル部分(64バイト・1パーティションあたり16バイト)と署名ともなっているマジックナンバー(2バイト)を抜き出してみた。。。内、太字の行がNetBSDの入っている第3パーティション。

　先頭の80はブートフラグがONであることを、太字の8バイト分、前後4バイトがそれぞれLBAの開始セクタ値と終了セクタ値を表わし、リトルエンディアンである場合、それぞれ逆に並べるから開始が00819800、終了が002ff800となり、GNOME-Calculatorのプログラミングモードで確認してみたところ、これらは、10進だと8493056と3143680になる。

　これらの値は、まさにNetBSDパーティションのfdiskなら[start]/disklabelなら[offset]及び[size]と一致するから位置はわかってるはずなんだけどな。。。

　一体、どこの何がNetBSDが先頭のパーティションにあることを期待しているんだ？(なんでルートパーティションを聞かれるんだ？)

　LBA値がある場合、CHSの値は使われない模様も、CHSを10進にしてみても一致するものはない気がするが、もしかしてこれ？

　あ、やっぱり、そう(CHS)っぽい。

　1本まるまる使ってNetBSD Liveをインストール、先頭パーティションにNetBSDがあるUSBメモリを同様に確認してみるとこんな感じ。

　第1パーティションである000001beの行がNetBSD Live。

　次のfdisk結果と見比べるとCHSの開始値と終了値は、太字部分でファイルシステムタイプとしてNetBSDを表わす[a9]を挟んでC、H、Sの並びではなく、hexdumpの結果として左からヘッド、セクタ、シリンダ、逆に並べるとシリンダ、セクタ、ヘッドの順になっている模様。

　その順だとfdisk/fdisk -vの結果とhexdumpの結果は一致する(開始ヘッド:0x20=32、開始セクタ:0x21=33、開始シリンダ:0x00=0、終了ヘッド:0xcf=207、終了セクタ:0x0c=12、終了シリンダ:0xc3=195)。

　一方、NetBSD Live起動時にrootパーティションを指定する必要がある方のUSBメモリにおいては、開始ヘッド:0xaa=170は一致、開始セクタ:0x9b=155に対し27、開始シリンダ:0x10=16に対し528、終了ヘッド:0x5a=90は一致、終了セクタ:0x86=134に対し6、終了シリンダ:0xd4=212に対し724と開始・終了共にヘッドは一致しているが、セクタとシリンダは共に一致していない。

　このUSBメモリの格納状況においては、fdiskにある値の方が正しい。。。だろう。。。ということは、この値でMBRの値を書き換えればよいってことか。。。

　あ。。。シリンダ528。。。って。。。16進2桁じゃ、0x00〜0xff。。。これだと256(0〜255)までしか。。。書き換えようにも限界を越えちゃってダメって話か。。。

　もしこれが原因なら、逆算すると2GB以内にNetBSD Liveがあれば。。。って、これ自体が1.535GBあるから。。。100MB程度GRUBパーティション、その後にNetBSD Liveなら、rootパーティションを聞かれることなく(見つけて)、ログインまで進むってことになるか。。。？

　あれ？rootパーティションを指定しないと起動しない方のUSBメモリの方は、[NetBSD disklabel disk geometry]と[BIOS disk geometry]のCHS値がおかしいな。。。計算が合わない。。。これって修正できる？できるとしたらどうやるんだ？？？

　すんなりログインまでいく方のUSBメモリは、計算合うもんな。。。ただ、1シリンダあたり2048セクタってあり。。。だっけ？

　LBAには対応していて、その値は妥当なんだけどな。。。

　ん〜、頭の中ごちゃごちゃしてきた。。。いっか、rootパーティションを明示的に指定すれば起動するんだから。

　まるごと使って入れたUSBに入れ直してみることにしたら、新たな発見が。。。

　前回は、Debian上でパーティションにddしてみた結果、dd自体はできる一方、どうにもこうにも起動するには至らなかったわけだが、NetBSDだとそもそも、このNetBSD Liveイメージは、ディスク全体には、ddできるが、パーティションには、dd(しようとするとdd: /dev/rsd0a: Read-only file systemとなって)できない。。。もちろん、違うイメージなら、そのパーティションにもddすることはできる。。。そんな制限どこでできるんだ？

　と思ったら、ディスクイメージを作るにあたってMBRイメージを含めるか含めないかでUSBまるごと用かパーティション用かが決まる模様。

　ということは、Linuxでは、BSDパーティションが見えないから？書き込めてしまうが、Read-Onlyというエラーは的を射ていないにしてもNetBSDでは、MBR込みのディスクイメージをパーティションに書き込もうとすると、はじくということか。。。？

　Linuxは、MBRパーティションを対象、NetBSDというか*BSDでは、BSDパーティション(disklabel)を対象に操作していることに起因するのか。。。？

　となるとLinuxで強引にパーティションにddしても結果起動するに至らないし、NetBSDでUSBまるごとddした後、Linux上やLive版のGPartedを使うにしても、GPartedでは、NetBSDパーティションを移動することができないから、いずれにしても先頭にGRUBパーティションを入れつつ、先頭から2GB以内にNetBSD Liveパーティションを収めるパターンは試せないな。。。これを試すなら他のUSBメモリからddか、rsyncか。。。後者は時間かかるし、やってみるなら前者かな。。。

　あれ。。。NetBSD上でdd if=/dev/rsd1a of=/dev/rsd0a bs=1mとしてもできないな。。。単にUSBメモリか、/dev/rsd0aのブロックが壊れてるのか。。。？といっても/dev/rsd0d(全体)にはddできるんだよな。。。なぜ？

　ならば、MBRパーティションを直接操作しているらしきDebian(Linux)でdd if=/dev/sdb3 of=/dev/sdc2 bs=1Mとしてコピー、sdc1をマウントしてこれをブートディレクトリとしてgrub-install、再起動してみたら、NetBSDパーティションにbootフラグを立て忘れたが、Pavilionでも[sda0]、後はデフォルト。。。でNetBSD Liveが起動した。

　尚、これは、GRUB 2においてknetbsd /netbsdとしてカーネルを直接コールした場合であり、2GB以内に収めるとこの他、chainloader +1も機能するようになり、これだとNetBSD標準メニューに遷移し、rootパーティションを明示的に入力することなく、ログインまで進む。。。

　つまり、先頭から2GB以内に収めるとGRUBエントリーからのコールをchainloader +1にすれば、直接ログインまで進み、knetbsd /netbsdとするとrootパーティションの明示的な指定は必要になるが、NetBSDパーティションにActiveフラグを明示的に立てないとログインまで到達しなかったPCでもログインまで到達するようにはなった。

　ということは、先頭から2GB以内に収めれば、CHSがそれぞれ16進数2桁でも収まり、その結果、NetBSD標準メニューからならrootパーティションを見つけられるようになる。。。とは言えそう。

　やはり、NetBSD Live込みでマルチブートする場合には、それでも若干イレギュラーではあるが、まっさらなUSBメモリを用意し、MBR形式でNetBSD LiveをUSBメモリまるごと使ってdd後、必要に応じてdisklabelを調整、NetBSD Liveを先頭に置いたまま、用意したUSBメモリの容量に応じて(普通は全て使って余らない気がするもMBRパーティションとBSDパーティションが別だから成せる技なのか？そもそも、そういうものなのか？)後ろにできる空き領域にGRUBパーティションや他のLive版などを追加していくのが無難そう。

　ん？何がどうだったっけ。。。？？？あれこれ試しまくってたら、混乱してきた。。。

　Linuxでパーティションからパーティションにdd、イメージからパーティションへrsyncのどっちだか忘れたが、先頭から2GBに収まっていない(4GB以上後ろの)第3パーティションにNetBSD LiveがあるMBR形式のUSBメモリでもchainloader +1でNetBSD標準メニューに遷移、マルチユーザーモードを選択すれば、そのままログインまで進むようになっている。。。

　我ながら、先頭から2GBって何だったんだ！？状態。

　あ。。。2GBやマシンによってはActiveフラグ。。。っていのうは、偶然だったのかも！？

　fdisk見ながらパーティションリストだけでなく、上の方の基本情報含め、注意深くdisklabelを修正すれば、rootパーティションが見つからずにddb、reboot、haltしか選べないような状況にあってもMBRパーティションテーブル上のCHSで表現できない範囲にあっても普通にログインまで進むようになるな。。。これってMBRパーティションとBSDパーティションとは別物であり、システム側でこの間の差異を吸収してくれているから？BSDパーティション(disklabel)が正しければ、正しく機能するってことか。。。

　であれば、NetBSD Liveのパーティションは、NetBSD上では2本のUSBメモリなどの間でBSDパーティション間のddはできないから、Linux使ってパーティション間でMBRパーティション間で(半ば強引に)dd、NetBSD(*BSD)でfdisk見ながらdisklabelを修正する方法でなら、一手間かかるという話はさておき、実質、先頭以外のパーティションにも配置できるってことだな。

　まぁ、WindowsやDOSを埋め込まない限り、それでもISOブートできれば先頭パーティションじゃなくてもいけそう？だし、わざわざ、そこまでする機会もないか。

　NetBSD Liveがあれば、FreeBSDのLive兼インストーラはなくてもいいかなと思いつつも、両方あれば、尚良いか？と思うに至る。

　GPT形式のレスキューUSBには、既にFreeBSD 11.0-RCのi386　bootonly.isoが7つめのパーティションに入っているが、MBR形式のレスキューUSB側は、プライマリパーティション数が限られることもあって、あれこれやっている間にFreeBSDインストーラを削除していた。

　最終的にUSBメモリのとある位置に問題があるようで正常に機能するUSBメモリなら何の問題もなさそうな気がするに至るも、改めてプライマリは3つ埋まっており、4しか空いていないMBR形式のレスキューUSBにFreeBSDのbootonly.isoをddしてみたら当初起動せず、先頭じゃなくちゃダメなのか？第4じゃダメなのか？とあれこれやる羽目になった(が、プライマリならパーティション位置に関わらず、正常に機能することがわかったのでMBR形式、GPT形式に関わらず、レスキューUSBは、全て.isoをddするに至っている)。

　その流れでFreeBSD-11.0-RELEASE-i386-mini-memstick.imgも試してみたわけだが、これは、これで少しハマった。。。

　このイメージは、パーティションにddできない。。。というのもGPT形式でFreeBSD boot、FreeBSD UFS、FreeBSD swapの3つから成り、1つずつパーティションを使っており、それは良いのだが、GPTなのにパーティションが3つに制限されていて、そのままでは、それ以上、パーティションを追加できない状態でUSBまるごと1本使う仕様になっている。

　それにしてもマルチブートできないっていうのはな。。。と少し考えた末、Debian(Linux)でgdiskを使おうとNetBSDから再起動し、Debianのリポジトリにあったgdiskをインストール、実行してメニューを眺めると[x extra functionality (experts only)]から[s　resize partition table]で最大128まで設定できることがわかるも既存のパーティション配置上の制約があるようで[Warning! Main partition table overlaps the first partition by 31 blocks!]などといういうメッセージが出て停止してしまい増やすに増やせない。。。

　尚、セクタ調整値は[d display the sector alignment value]で確認でき、FreeBSDのインストーラは、これが1となっており、[l set the sector alignment value]で必要に応じて2048などに変更できる。

　結局、1つだけ増やすことができ、手持ちのマシンはどれもEFI/UEFI非対応だが、既存のGPT形式のレスキューUSBは起動するのに、そのままでもブートできるマシンもあれば、FreeBSDだけ入れたこのUSBメモリだと起動できないマシンもあり、この違いはGRUB 2経由か否かということでパーティション数を4として7GBほど空いてはいるがGRUB用に50Mほど割り当てgrub-install後、試すと予想通り、マシンに依存することなく起動できるようにはなった。

　配置が原因なら改めてGPTで初期化(デフォルト使用パーティション数128)、これに必要なパーティションをddすれば、いけそう。。。ってことは、最初からGPT形式でパーティション切って作るのと同じだから。。。そうなら、そりゃいけるだろうな。。。とすると、はなから-o loop,offset=$((byte/sector*start_pos))使ってイメージをマウントしてディレクトリであるマウントポイントではなく、その元となるループバックデバイス(/dev/loop0など)からGPTで新規作成した任意のパーティションの1つにddすればいいのか。。。？と思ったがddできたように見せかけて書き込まれていない。。。

　そこでレスキューUSBに入れているCloneZillaを使って、1度FreeBSD-11.0-RELEASE-i386-mini-memstick.imgをddしたUSBメモリからでUFS部分だけイメージ抽出してパーティションやディスク全体にddしてみたりしたが、何れもエラーは出ないものの、それじゃダメみたいだ。。。まだ、試してはいないものの、同様に他のパーティション(FreeBSD bootとFreeBSD swap)も含め、3つともイメージ化してUSBメモリをGPT形式で初期化、相応のパーティションを3つ作り、それぞれddすればいけるかも？仮にできたとしても、かなり面倒だけど。

　気にはなるが。。。普段使っていないFreeBSDにかかりきりになってもいられない。。。しかもNetBSD Liveがある今はなおさら。。。と言い逃げしてみる。

　それにしても3つに制限してるのは、そうせざるを得ない事情があるから？壊されたくないから？それとも。。。初期値は128だから敢えてやらなければ、こうはならないはずだが、しかもインストーラの段階で。。。FreeBSDだけしか使わないユーザーならいざ知らず、ユーザーフレンドリーとは言い難く。。。ちょっと意外な気もするが。。。

　何れにしても一筋の専属ユーザーでない場合、FreeBSDのインストーラ兼Live版をUSBメモリで使うならCD/DVDとUSBのハイブリッドISOである模様のISOディスクイメージを使うのが無難と思われる。

　disklabel上でFreeBSD Liveのパーティションを、とりあえず4.2BSDとか、fsize、bsize、cpg/sgs値とか、NetBSD(ルートパーティションa)と同じように書いておいたんだけど、マウントできない。。。CD9660/ISO9660(後で気づけばmountと違ってdisklabel上にはISO9660はあってもCD9660は存在しない)とかfstypeに書くと完了できないし、ならばunusedじゃないからMSDOS、fsize、bsize、cpg/sgs値をカラにしたら、disklabelもエラーなく完了でき、mount時タイプ指定しないとMSDOSじゃマウントできないって言われるけどcd9660指定すればmountできるようになった。

　fstypeって他に何指定できるんだろ？apropos disklabel fstype...あ！disklabel -lなんてのがあったのか...でもfstypeだけ指定しても項目が少なすぎるって怒られるのもある。。。一体何をどうすれば。。。？

　あ、fstypeをISO9660、fsizeを0にしたら、タイプ指定しなくてもmount /dev/... /mntであっさりマウントされた。。。適当にやってみただけなんだけど、fsize、bsize、cpg/sgs値って何を基準にどうやって決めてて、どうすればその値がわかるんだろ？

インストール済みNetBSDのLiveイメージの作成

　NetBSDを初めてインストールしようという時から当然、Live版は気になっており、インストール後は、まぁ、いいかと思っていた時期もあった。

　NetBSD Live専用のJibbedも気になっていて後にダウンロードしてみたら、手持ちのNetBSDマシンは全てi386なのに対し、x86_64(64bit/amd64)版だった。。。BlackBSDとか他にもいくつかあったが、古い情報なのか既に入手できなかったり、サイズがでかかったり。。。と今ひとつ、NetBSDのパッケージにあるmklivecdは、何度試してもなぜか作成できなかった。。。

　それでもレスキューUSBの作成などをしてみるとCLIで十分も*BSDにアクセスできるそこそこコマンドが充実したものでサイズは大きくても200MB前後のものが欲しくなり、現状、FreeBSDのインストーラ兼Liveイメージを使わせて頂いているが、NetBSDユーザーとしては、というか、やはり、多少なりとも使い慣れたNetBSDのLive版が欲しいところ。。。

　『ておくれ』Live版なるものも気にはなり、何度かダウンロードさせて頂こうかとも思ったものの、Xを含む多彩なパッケージが組み込まれていることもあってイメージファイルが4GB以上とサイズが大きく、レスキュー用途で十分な自身としては、使わせて頂くには至っていなかった。

　そんな中、数か月前に遅まきながら、NetBSDのリポジトリからsrc.tar.gzやxsrc.tar.gzをもってくれば、build.shでlive-imageターゲットもあってNetBSDのLive版を作成できるということを知り、Liveイメージ目当てで初めてbuild.shを試し、先のwd0版とsd0版のNetBSDライブイメージも生成されるに至った次第。

　いろいろ調べながら、合わせ技でやってみたら、シングルコアCeleron M 520 1.6GHz/2GB RAMでGENERICカーネルベースのrelease版？に約3時間、live版生成に30分程度とトータル3時間半くらいかかったものの、エラーもなく実行するだけだったという意味で簡単にできた。

　と言っても、必要な時だけsuしてくれる-Uオプションをbuild.shに指定してる情報ばかりなんだから、すぐに気づけよって話だが「基本、全ての作業は、rootじゃなくてユーザー権限でやる」、ついては、展開するビルド用のルートとなるディレクトリを決め(作成し)たら、「そのディレクトリ(/usr/srcならsrc)の所有者・グループがユーザーやユーザーグループでない場合、少なくとも所有者については事前に変更しておく」、それからそのディレクトリに移動してソースをダウンロードすればユーザー権限で展開できる、「(少なくともi386の場合？)pub/NetBSD/NetBSD-`uname -r`/source/sets以下のファイルは、(よくわからなければ尚更、)全部ダウンロードして全部展開しておく(のが無難)」という点、特に最後の点については、しばらく気づかずハマったけど。。。探した限り、明解に書いてあるところは見当たらなかったが、なぜだろう。。。？(と思いきや最も基本的なドキュメントに書いてあった。)

　結果、レスキュー用途には、十分過ぎるものができたわけだけど、NetBSDのfdiskでサイズを見るとsd0版は1.4GB、wd0版は2.0GB。。。wd0版に対し、vnconfig/vndconfigで作成したデバイスをマウント、df -hしてみるとサイズ1.8GBで中身は726MBとちょっとでかい。。。体験版の最小構成という意味では素晴らしいと思うし、manが入ってるのは重宝するかも？通常のディスクのようにパッケージ追加もできるのはメリットではある、Xがあれば端末を複数起動できるっていうだけでも便利だけど、っていうかUSBメモリだけで全て完結するこのイメージは、自身が思い描いていたLive版の域を越えてすごい。。。しかも探しても無難なものが見つからなかったNetBSDで。。。しかも本家版、それが多少の時間はかかるにしても、こんなに簡単にできるとは。。。

　今回使ったUSBメモリは余ってたやつだから専用にしても問題はないけど、他とマルチブートして使えれば尚良し、マルチブートにしても、このサイズでも十二分に収まるのは収まるし、むしろありがたいとも言えるけど。。。自身が想定した滅多に使うことがないCLIベースで十分なレスキュー用にはちょっと豪華過ぎる。。。というかCLIでもいい。。。か。。。な？

　うっかり、Xも入れてビルドしちゃったけど、MKX11=noとセットしておけば、というかデフォルトはnoだけど(もちろんこれと同じ意味を持つ-xオプションも付けなければ)、もっと小さくなるよね？カーネル機能も絞り込めば、ある程度、小さくなるのか？っていうか1.4GBの箱のサイズはどうやって決まるんだ？設定できるのか？それがわかったとして700MB強っていうのもでかいが、Xは外すにしても例えば、ツールを取捨選択できるとかサイズ変更する手立てが何かあるのだろうか？イメージ自分で編集して再作成すればいいのか？何れにしても手持ちマシンもスペックはそれぞれ、近い内にオリジナルカーネルをビルドするに至っていたはず、今回、build.shに触れたのを機にいろいろやってみるかな。

(あ、箱の縮小については、FFSv2は未対応だった気がしなくもないけどFFSv1なら、GPT形式の場合、単にできてからgpt resizeしてから、MBR形式の場合、fdisk、disklabel調整して？resize_ffsすればいいのか。。。)

　っていうか、NetBSDだとsd0版がvnconfig/vndconfigした後、mountで"mount_ffs: /dev/vnd0a on /mnt/img: incorrect super block"エラーになるのはなぜ。。。？

　念の為、Debianで確認してみたらmount -t ufs -o ro,loop,offset=$((512*2048)),ufstype=44bsd xxx.img /mntでwd0版もsd0版もマウントでき、それぞれdf -hを確認するとwd0版のサイズは1.9GBで使用量が727MB、sd0版はサイズが1.4GBで使用量が703MBとなっている。(*BSDとLinuxでのサイズや使用量の多少の差異は、これに限らず、同じLinuxでもデスクトップ環境標準のサイズ表示機能を持つツール、例えばファイルマネージャ間でも異なったりするし、ここでも大勢に影響はない。)

　あ。。。NetBSDでdisklabel vnd0すると。。。wd0版は正常だけど、sd0版は、disklabel見るとBSDパーティションがaからpまであってoffsetが全部0でsizeもtotal sectorsと同一、ラップしまくりで壊れてるな。。。Debianはこれを見ないからいけるのか。。。

　とりあえず、ルートパーティションとswapサイズの内訳がわからないから、bとeからpを消し、残ったa,c,dのsizeをtotal sectors:2883584からoffset(=sectors/cylinder)値2048を引いた2881536に、aとcのoffsetを2048に、4.2BSDとなっていたcのラベルをunusedにしてsudo disklabel -e vnd0を保存終了後、マウントしてみたら何事もなかったかのようにマウントできた。。。df -hしてみるとサイズは1.4GB、使用量は703MB、というわけでsd0の方はDebianとも一致してる。

　vndconfig -u/unmount、vndconfig/mountを何回か繰り返しやってみてるけど、disklabel修正後は、何度やってもマウントできるな。。。なんの拍子に壊れたんだ？直ったし、まっいいか。

　NetBSD 7.0.2のソースを新たにダウンロード、MKX11=noにしてbuild.shでimage-liveを生成、vndconfig/mount、df -hしてみたら、wd0版は1.8GB/521MB、sd0版は。。。と思ったら、また、NetBSDだと[incorrect super block]となってマウントできないが、今度はfdisk/disklabel共におかしなところはない。。。Debianだとwd0版は1.9GB/521MB、sd0版は1.4GB/522MB。。。200MB前後減ったには減ったがXを入れなくてもこのサイズか。。。

　ちなみに前回と異なり、今回は、Dual Core(Core 2 4300 1.80GHz) CPU/RAM 2GBマシンでやってみたのだが、-jオプションを付け忘れ。。。/etc/mk.confのMAKE_JOBS=4を読んでくれるかと思いきや、そうではないようで(usr/src/BUILDINGによれば、この場合のjオプションに相当する環境変数はNBUILDJOBSだったが、廃止されたのでjオプションを使えとのこと)。。。ということで放っておくだけでよいから楽だけど、やはり、3時間半かかった。。。シングルコアマシンと同じくらいかかったが、-jオプションをつけないとデュアルでもコア1つしか使わないのか？。。。更にXない分、減量してもlive-imageの生成時間には影響ないのか。。。

　更なるスリム化を図るべく、build.shについてもっと調べてみるか。。。まずは、usr/src/BUILDINGとusr/src/UPDATINGだな。。。

NetBSDは論理パーティションからでも起動できたっぽい

　これまで表面的かつ部分的な理解のみで、ここ数年、DebianやFedoraも入れてはいるものの、NetBSDに至っては手持ちの全てのマシンに入れると共にデスクトップ用途もNetBSDをメイン、たまにLinuxという状況で今尚、利用させて頂くに至っているが、*BSD、NetBSDについては、徐々にでもより理解を深めたいと思っており、流し読み程度だったmanも折に触れ熟読することも増えてきた。

　そんな中、man fdiskを読んでいたら、「i386については、LBA/Logical Block Addressing対応ならDOS/MBRブートセクタ/usr/mdec/mbr_extを使うと拡張パーティション内に切った論理パーティションからでもNetBSDを起動できる」とある。。。apropos/man -k mbr_extとするとx86/mbr(man mbr/man 8 mbr)にも情報があり、確認してみると「(/usr/mdec/mbr_extは)8GB超のパーティションから起動する為の拡張機能をサポートするBIOSを持つシステムにおいてのみサポートされる」と書いてある。

　fdiskで論理パーティションが表示されることは知っていたが、NetBSDを起動できるとは知らなかった。

　と言ってもサブマシンであるデスクトップの内1台は、基本パーティションにFreeDOSとNetBSD、論理パーティションにDebian、Fedoraを入れてみたものの、結果的に基本パーティション3つを使い切る状況には至っていない、FreeBSD/OpenBSDはdynabookに入れてみたものの、見送った、仮に入れるにしてもOpenBSDも論理パーティションからの起動に対応していると思われ、FreeBSDを基本パーティションに入れたとしてもちょうど3つ。。。新たにマシンを買うとなると64bit、UEFI/GPTが既定だろうし。。。いろいろ検証していた際にこれを知っていれば、おそらく試していたはずだが、時既に遅し。。。今となっては/usr/mdec/mbr_extを利用することはなさ気。

NetBSDのfdiskは-uと-vを併用すると設定可能項目が増えるらしい

　同じくman fdiskを読んでみると「冗長化の-vオプションは、2つ以上指定すると出力を増量する」。。。これは普通だが、これに加えて「-uオプションと併用すると通常、許可されるよりも多くの変更を許容する。。。」とある。。。へ〜。。。追加で何を設定できるのかについては未確認も、そんな隠し技があったとは。。。

不具合の出たマシンのNetBSD/OpenboxのExitに対処〜勘違い〜対処〜解決

　ここまででアップデート後、謎の不具合が出たMATE、LXDE、途中おかしくなったGNOMEは正常に機能するようになったし、KDE4(openbox-kde-session)はマシンによって起動するものとしないものがあるが、Xfce4は常に起動できていた。

　一方、起動はするし、端末でopenbox --exitすればログアウトはできるものの、OpenboxメニューのExitが効かない状況に遭遇。。。加えて[Desktop Settings]もクリックすると[Desktop Manager not active.]というポップアップ表示がでる。。。その他のメニューは機能するのに、なぜ？

　Exitに割り当てられているコマンドは・・・~/.config/openbox/menu.xmlを見るとlxde-logoutになっている。。。機能するdynabookで確認してみても同様。。。

　/usr/pkg/bin/lxde-logoutはスクリプトファイルで中身を見ると実際には、lxsession-logoutを実行しているが、これもdynabookでも同様。。。

　端末からlxde-logoutを試すと。。。Error :LXSession is not running.、dynabookでは、MATEを開いているのにも関わらず、LXDE用のログアウトを含むボタン付きパネルが表示される。。。これはこれでなんでだ？って話だが、Pavilionの方のOpenboxはログアウトに使っている一方で起動時にlxsessionが起動していないってことか。。。

　openbox --exitに書き換えてもよいといえばよいが、一方でlxde-logoutできていることからして対処しておかないとLXDEにも影響あるか。。。と思ったら、LXDEは当然lxsessionを起動するから問題ないか。。。

　あ！違うじゃん。。。このメニュー。。。なぜか、dynabookもこうなってるが、これってLXDEデスクトップ上で右クリックした際のメニューから[デスクトップの設定]を選んで[デスクトップをクリックしたときウィンドウマネージャのメニューを表示する(S)]にチェックを入れた時のメニュー。。。Openboxの[Exit]選択時のログアウトポップアップは、lxsession-logoutじゃなくてFluxboxのような小さなポップアップだもんね。。。参照パスが違うのか？menu.xmlが違うのか？

　ということで/usr/pkg/etc/xdg/openbox/menu.xmlを見るとOpenboxらしいメニューなので/usr/pkg/etc/xdg/openboxを~/.config以下の既存のopenboxディレクトリを一応退避してコピー(cp -r)、Openboxを起動してみたら相応のメニューが表示され、Logoutメニューで小さな確認ポップアップが表示され、ログアウトすることができるようになった。

　が、LXDEもデスクトップ上で右クリックした時のメニューが同じになっちゃった。。。LogoutクリックでOpenboxを終了していいですか？。。。ってLXDEだし。。。みたいな。さっきのパスのopenbox直下とその下にLXDEディレクトリがあってそこにもmenu.xmlあるからそれで使い分けできるんじゃなかったっけ？？？

　そこで~/.config/openboxを再確認。。。なんでopenbox直下にlxde-rc.xml？ということで眺めつつ、結構なボリュームなのでmenu.xmlを検索してみると1ヶ所だけヒット、[default menu file...]に続いて[<file>/usr/pkg/share/lxde/openbox/menu.xml</file>]とあり、ファイル名からしてもLXDEはこれを参照しているものと思われる。。。そこでパスを~/.config/openbox/LXDE/menu.xmlに書き換えてみたところ、LXDEとOpenboxの右クリックメニューがそれぞれ相応のものとなった。

　要するに~/.config/openbox以下はOpenbox、LXDE共に参照するが、Openboxは直でmenu.xmlを、LXDEは、lxde-rc.xmlを読んでから[default]として書かれたパスのxxx.xmlを参照するわけか。。。って、これ今まで自動でそうなってたよな。。。

　これってOpenboxの仕様変更か？それともインストール時に配置される構成ファイルの記載ミス、もしくは、構成ファイルのリストアップミス？

　ん？wipからLXDEを入れたマシンとLXDEのバイナリを入れたマシンでファイル構成が違うな。。。wipから入れた方は、/usr/pkg/etc/xdg/openbox以下にlxde-rc.xmlもLXDEディレクトリもない。。。から、やるにしても当該ファイルを探してコピーしないと先の対処ができない。。。となると仕様変更なのか？パスや入れ込むファイル類を間違えたのか？

　wipから入れた方のデスクトップPC/NetBSDは、デフォルトの~/.config/openbox以下にLXDEディレクトリはない一方、そもそもlxde-rc.xmlとmenu.xmlがあるが、このmenu.xmlはLXDE用、というわけでLXDEディレクトリを作成してもよいが、今回は、任意のファイル名lxde-menu.xmlとしてリネーム、Openbox用のmenu.xmlをfind検索すると/usr/pkg/etc/xdg/openbox/menu.xmlがあり、中身を見るとこれが該当するので~/.config/openbox/menu.xmlとしてコピー、lxde-rc.xmlのmenu.xml行をフルパス指定のlxde-menu.xmlに置き換え、Openbox、LXDEをそれぞれ起動、右クリックメニューを表示させてみると、それぞれのメニューが表示されたので解決。

　尚、openbox-kde-sessionでは1台は起動でき、もう1台は起動不能、他方、gnome-session、openboxでは起動できたが、openbox-sessionとopenbox-gnome-sessionの方は、gdmから起動した1台は未だに[Your session only lasted less than 10 seconds....]メッセージ付きのポップアップが表示され、ログインシェルからxinit/startxで起動した1台は、やはりエラーで起動できず、終了。。。KDEもたぶんstartkdeならいけるだろうし、Openboxはopenbox、GNOMEもgnome-sessionでは起動できるわけだから、いいと言えばいいんだけど。。。なんでだ？？？

　あれ？[Your session only lasted less than 10 seconds....]って出てたマシンのopenbox-kde-sessionも正常に起動するようになってる。。。マシンを再起動する必要があったのかも？

　いずれにせよ、これでKDE4(4.14.3)、GNOME2(2.32.1)、Xfce4(4.12.0)、LXDE 1.0、MATE 1.14.0などのデスクトップ環境は快適。

　KDE4はアプリは全て日本語対応になっているが、メインメニューが英語のまま、MATE 14.0は、一部のアプリのみメニューバー上のメニューが選択はでき、サブメニューは表示され選択できるものの、(メイン)メニューバー上の文字が表示されないものがあるけど、大勢に影響はないし、ご愛嬌ってことでいいっしょ。

不具合の出たマシンのNetBSD/GNOME2に対処・解決済み

　GNOMEをgdm経由で起動しようとすると[Your session only lasted less than 10 seconds....]といったポップアップが表示され、起動しない。

　ログインシェルから起動しても今ひとつよくわからないエラーで起動しない。

　このエラー、他でも起きたことがあるけど、あれこれやっている内に他はなんとかなったこともあるが、結局、何が原因でどうなっているんだ。。。？

　こんな時は、やっぱり、せっかく複数台あるんだから、うまく動いているNetBSDマシンとそうでないマシンのGNOMEパッケージ群を比較からだよね。。。

　不具合の出ているデスクトップPC(Pavilion Slimline)/NetBSDのGNOME関連パッケージは以下。

　gnome-main-menuの説明にMATE Desktop main menuとあるのはご愛嬌として。。。

　正常なノートPC(dynabook Satellite)/NetBSDのGNOME関連パッケージは以下。

　gnome-panelとgnome-sessionがない。。。いつの間に、あったものが、なくなったんだ・・・？

　というわけでdynabookでpkg_tarup -a -d /mnt/nfs gnome-panel、Pavilionでpkg_add -v path/gnome-panel-2.32.1nb48。

　続いてdynabookでpkg_tarup -a -d /mnt/nfs gnome-session。。。依存関係、超多い。。。pkg_tarupで初めてこんなに時間かかった。。。Pavilionでpkg_add -v path/gnome-session-2.26.2nb52。。。と思ったらインストール済みのlibxklavierとlibgnomekbdが干渉、それぞれpkg_delete -f後、gnome-sessionのインストールが完了。

　~/.xinitrcにgnome-sessionとしてログインシェルからxinit/startxしたら、元の通り、無事GNOMEを起動することができるようになった。。。

　尚、openbox-gnome-sessionやopenbox-kde-sessionで起動できなかったこともあって試しにOpenboxを起動してみたら起動もするし、右クリックメニューも使えるが、[Exit]を選んでもログアウトできず、端末からopenbox --exitするハメに。。。ターミナル他アプリは起動できるのに。。。なんでだ？と思ったら、このメニューちょっと違うような。。。

不具合の出たマシンのNetBSD/MATEに対処しようと思ったら解決してた

　あれ？MATE、日本語対応していないけど[ウィンドウ]も表示されるし、一連のパッケージもメニューバーにかかることなく、正常に機能するようになってる。。。

　LXDEと原因一緒だったのか！？

　もう1台の方は日本語表示できているのにおかしいなと思ってたら、どっちもGDMを使っていて、gdm用の~/.dmrcで[Desktop]部でSession=の他にLanguage=ja_JP.UTF-8行を追加すれば起動セッションに関わらず、MATE含め、GDM経由で起動したデスクトップが日本語表示されるようになることを思い出した。

不具合の出たマシンのNetBSD/LXDEに対処・解決済み

　まず、ちょっとした不具合のあるデスクトップPC(Pavilion Slimline)/NetBSDにおいて、ちょっと前まであったことを確認していたlxdeパッケージ自体が対処中に何らかの理由で削除され、なくなっていたので入れてみることに。

　ついてはノートPC(dynabook Satellite)/NetBSDでpkg_tarup -a -d /mnt/nfs lxde、Pavilionでpkg_add -v path/lxde-1.0.tgz、その際、lxde-icon-themeがないといわれ、これもpkg_tarup -a -d /mnt/nfs lxde-icon-theme後、pkg_add -v path/lxde-1.0.tgz、更にpcmanfmがないといわれ、pkg_tarup -a -d /mnt/nfs pcmanfm後、pkg_add -v path/lxde-1.0.tgzとして、ようやくlxde 1.0のインストール完了。

　これでLXDEは起動するが、lxpanelが表示されない当初の状態になった。

　さて、なぜ/usr/pkg/bin以下にもあるlxpanelが表示されないのか・・・？

　とりあえず、以前も確認したように~/.confg/lxpanel/LXDE/panels/panelファイルがいるが、これは既にある。

　ならばということで端末からlxpanelとタイプして起動してみると。。。libmenu-cache.so.2がない。。。ls /usr/pkg/lib/libmenu.*するとlibmenu-cache.so.3はあるのでこれをlibmenu-cache.so.2としてコピー後、lxpanel &したらパネルが表示された。

　ログアウト後、再度、LXDEにログインしてみたら、無事パネルも表示され、LXDEは、正常に使える状態になった。

　LXDEについては、アップデートに、またその後の対処に伴い、一部パッケージが欠けた、一部ライブラリがアップデートされた為に依存するライブラリのバージョンがなくなったことに起因して不具合が出たということである模様。

2台のNetBSD上のインストール済みLXDEとMATEを比較してみる

　ほぼ正常に機能しているノートPC(dynabook Satellite)/NetBSDのLXDE・MATEとちょっとした不具合のあるデスクトップPC(Pavilion Slimline)/NetBSDのLXDE・MATE、バージョンを含め、インストール済みのパッケージを比較してみることに。

　不具合の出ているデスクトップPC(Pavilion Slimline)/NetBSDのLXDEとMATE関連パッケージは以下。

　あ、lxde自体がない。。。dynabookでpkg_tarupしよう。。。

　機能しているノートPC(dynabook)/NetBSDのLXDEとMATE関連パッケージ(関連しないものを除外)は以下。

リポジトリにあったパッケージがなくなることがあるのは何故？

　『MATEの修復を試みる』でも触れたが、NetBSDでは？、pkgsrc、バイナリに関わらず、公式リポジトリに上がったパッケージが、なくなることが、よくあるのだが、これって何で？

　これまで認識しているものとしては、デスクトップ環境やブラウザ、前者は両方(一部のパッケージだけ残っていることもある)、後者はバイナリ。

　その都度、一応探してみてはいるが、理由を含め、アナウンスがあった様子もない。。。

　これって状況によってはアップデート時なんかに整合性がとれなくなることだってあるよね？？？

　常々、気軽に聞けるとこがあるといいなと思いつつも、NetBSD CommunityはあるもTwitterはちょっと違うし、ニュースグループってNetBSDのに限らず、使ったことないからなんだけど面倒そう。。。アーカイブは公開されているから、探すだけならsite:netbsd.org keywordなどでも事足りてるし、そこそこ重宝はしているけど。。。IRCって何。。。って感じだし、send-prはバグ報告だし、ユーザーグループにもネット上で対話式のQ&Aはなさそうだし、となるとdaemonforumsかな。。。メールでユーザー登録しようかとも思ったものの、[FAQ]、[Search]とか一向に検索できないが、これもユーザー登録しないと使えない？？？。。。説明にはそんなこと書いてないな。。。なんて時点で無理っぽい。。。けど、これもなんならsite:daemonforums.org keywordすればその中だけ探せるわけで。。。それでも解消しない疑問って結構あるんだよな。。。

　と思ったら、まさにdeamonforums.orgのQuestion about i386 binary package availability, vs amd64の回答にあるような事情によるものである模様だが、7.0、7.0.1、7.0.2それぞれだけでなく、メジャーバージョンアップグレードではないからか、中には、またがって存在しない期間があったケースもあった気が。。。amd64ではこうしたことはなさ気、i386は減りゆく一方だから対策を講じるまでもないのか。。。

　続けて探していたら、https://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/READMEに以下のように書いてある。

　でも1日、2日どころの話じゃないんだよな。。。

　お？pkgin fugしてみたら、大量に出てきて、もしやと思って検索してみたら、なかったパッケージも続々とできてる。。。MATE 1.14.0、LXDE 1.0、KDE4、Xfce4、Firefox 49.0、firefox-l10n-49.0、Seamonkey、Midori。。。

　不定期に任意のタイミングでなくなったり、おかれたりするのかな・・・？何れにしても数日以上に渡ってなくなってしまうケースを回避することはできないものなのだろうか。。。？

　pkgin fug実行しておこう。。。と思ったら。。。

　adobe-flash-pluginはmakeする必要があり、バイナリはないはずだから当然なんだけど、こういう時、とりあえず除外できるといいんだけどな。。。pkgin...まぁ、この場合は、先にadobe-flash-plugin11をmake update/make replaceしろってことか。。。

　改めてpkgin fug。

　アップグレード対象379、インストールするもの込みで381。。。警告46、エラー3。。。一応完了。

　が、ログを一通り眺めても、(errorや)Errorをキーに検索してみても3つどころか1つもエラーらしきものはないな。。。見落としてる？警告はパスに関する似たようなものばかりでたいして影響はなさ気。

　おお、Firefoxは49.0にアップデートされ、起動したら何もしなくても日本語対応済みになっている。

　一方、.desktopファイルがことごとくないのか、インストール時のパス指定・構成が間違っているのか、端末からは起動できる為、インストールはされているようだが、アプリケーション実行バー上のアップデート対象だったアプリがクリックしても起動せず、パネル追加できず、LXDEだった為、lxpanelctl restartしてみたら、バーだけでなく、メインメニューからも、ことごとく消えた。。。dynabookだけで以下でアップデートしたPavilionの方はこうした症状はない。。。なんで？lxmenu-dateか？マシンによってバージョンが違い、wipから入れた古い(Pavilionの)方が機能しているが。。。と思ったら、dynabookも再起動したらバーにアプリを追加できるようになった。。。lxmenu-dateがアップデートでアンインストール&インストールされた影響か？lxpanelctlしないでpkg_admin rebuild/rebuild-treeすればよかったっぽくもある？

　っていうか、最新のバイナリがあるならデスクトップPC/NetBSDの方のwipから入れたMATE/LXDEなんかもアップデートすれば、例の対処しなくてもよかったのか。。。？と思い、そっちでもpkgin fugしてみることに。

　するとMATEもLXDEもアップデートされていない。。。wip含め、pkgsrcからmake installしたものは、pkginのアップデート対象にならないのか？いや、バイナリはなく、ソースしかない為、make installしたadobe-flash-pluginは、リポジトリにバイナリがないってはじかれたんだから対象になってるよな。。。wipからmake installしたものがはじかれるのか。。。？サブマシンだし、まいっか、今回は。

　ちなみにエラーは、webminの...postinstallスクリプトを実行できなかったとかなんとか。。。使ってないからよしとする。ってか後で削除する。

　先日コピーしたnyftp.netbsd.orgのパッケージ群リストからMATEだけ取り出して日付順(例は逆順)でソートしてみた。

　これによるとMATE関連のバイナリが生成・アップされたのは、この時点で2016/07/03〜2016/11/01の間の約4ヶ月の間。

　MATEやLXDEがpkgsrc入りした2016Q2(2016年第2四半期)リリースのアナウンスが2016/07/12(できたのは2016/06/12っぽい)であり、自身は07/26に気づいてdynabookのSSDにインストール。

　NetBSD 7.0のリリースが2015/09/15(発表米国時間2015/10/08)、7.0.1が2016/05/22、 7.0.2が2016/10/21があったが、少なくとも10月末から11月初旬にかけては、MATEやLXDE関連のほんとどのバイナリがリポジトリからなくなっており、2016/11/06に確認した際には、存在した。

　とすると、やはり、リリースのタイミングでバイナリの生成に時間がかかるからか、数日に渡ってリポジトリ上からバイナリがなくなることがある。。。？また、前述のリンク先にあったようにi386用は優先されないから更に多少遅れることがある。。。？という認識でよいのだろうか？

　ところで、ここでまた疑問が。。。当初、pkgsrcはmakeが通るものだけが置かれているのかと思いきや、運用してみるとそうではないものも結構ある。。。にも関わらず、バイナリが生成されるのは、なぜ？

　これってたまたま？そうじゃなくてバイナリ配布できるものは全て通るが、できないものの中だけに通らないものがある？それとも個々人のマシン環境上、依存関係のミスマッチなどでエラーになるだけでpkgsrc開発者は通ったものしか置いていない？

　例えば、つい先日、Audacityを入れてみようと思ったら、バイナリがなかったのでmake installしようとしたらFAIL_REASON brokenとかでビルドできなかったが、MATEやLXDE同様、Audacityのバイナリがある今は、cvs update -Pdすれば、makeが通るようになっているってことなのか？

　ん？もしかして今までずっと-current落として使っちゃってたのかも・・・？

MATEの修復を試みる

　デスクトップマシンのNetBSD、アップデートに伴い、いろいろなことが絡み合った挙句、いくつか不具合があって、その内の1つにMATEを起動し、アプリを開くとウィンドウにウィンドウバーがなく、一部を除き、デスクトップ左上位置に合わせて開き、上部タスクバーにかぶる恰好となり、順次重なり合ってしまう現象がある。

　ウィンドウの設定なのか？とMATEメインメニューの[システム] > [設定]から[ウィンドウ]を選んでみると起動しない。。。

　このウィンドウを端末から起動させてみると。。。

　あれ、ライブラリがないとな。。。アップデートの混乱に乗じてなくなっちゃったのかな。。。？

　確かにない。。。

　リポジトリもバイナリはない。。。

　ソースはあるね。。。ってことでビルド。。。

　これでよいだろう。。。さて、起動。。。

　げ、[The current window manager is unsuported]と書かれたポップアップウィンドウが表示された。。。

　あ、だってこれ、GNOME2用、ってことはMetacity用だもんね。。。MATEだとMarco。。。ん？

　じゃなんでないって言われるんだ？

　試しにNetBSDのMATEが正常に機能するノートPCの方も見てみたけどそのライブラリは同じバージョンがある。。。

　改めて確認してみてもウィンドウマネージャはMarcoだよな。。。ノートも同様。。。

　とノートのNetBSDのMATEを起動してみたら、そうだ、そういえば、先日バイナリがリリースされ(今は、またMATEもLXDEもバイナリもソースも全て揃ってなさ気)、それを入れたノートのNetBSDにおけるMATE(デスクトップはwipから入れた)では、日本語メニューが正常に表示されるFileZillaやUPnP関連ツールや英語メニューなら(日本語メニューでなければ)表示されるFirefoxもあるが、多くのパッケージにおいては、ことごとく、メニューバー上の該当する位置をクリックすれば、サブメニューは表示されるものの、メニューバー上のメニューの文字だけ見えないというちょっとした不具合はあるんだった。。。

　それにしてもエラーメッセージをキーに調べてみるとバグらしき情報が多いが、ノートの方はメニューが見えない以外は、正常に機能しているだけに他に何かありそうなんだけどな。。。

/bin/shの入力履歴とTAB補完

　前回、アップデートに絡んでLXDEやMATEなどに影響の出たデスクトップPCのNetBSDにおいて原因を手探りする中で使用している/bin/shにおいて端末上で入力履歴を表示しようと上矢印キーを押すと"~[[A"のようなメタ文字になってしまい、ファイル名など入力途中でTabキーを押して補完しようとすると単に空白となってしまう状況に遭遇。

　man shの結果、懐かしのset -o emacs/set -o tabcompleteとすればよいことがわかる(初心忘るるべからず)もログインシェルでは再ログイン後も有効になるが、デスクトップやウィンドウマネージャ上の端末では有効にならず、.xinitrcや.xprofile、.xsessionなどに追記してみるもダメ。。。結果、単に/etc/skel/.shrcを~/.shrcとしてコピーすればよいことが判明。

　というか、新規ユーザー作成の際、当該ファイルは自動的にコピーされるのだが、不具合を探りつつ、あれこれと手直ししたり、元に戻したりする中で一部を残し、ドットファイルを退避(その後、削除)した中に~/.shrcも含めてしまったという。。。

　作業中、当然のように/etc/skelも眺めたが、/bin/shにおいて、なぜか、ここで必要なのは、.profileだけだと思い込んでしまったことが解決を著しく遅らせることとなった。(まさに思い込みは禁物。。。)

　メインマシンではないものの、これが判明するまでは、面倒ながらも履歴を使わず、都度入力、入力ミスしたらCtrl+Cでやり直し。。。と時間の浪費著しいことを。。。

pkgin autoremove

　Re: How to remove pkgsrc orphan dependencies?から拝借したスクリプトとpkgin -n ar結果の関係が少し見えてきた。。。

　pkgin -n arの出力をソートした結果であるpkgin_nar.sortと先の拝借したスクリプトの結果から得られるPKG.automatic-notrequiredを比較してみると前者の83件に対し、前者のみに含まれるのは21件(何れも内1件は[82 packages to be autoremoved:]というヘッダ行なので実際のパッケージ総数は82、一致数は20)、前者・後者共通なのが62件、ここで前者にのみ含まれたものは、PKG.automatic-requiredに全て含まれており、一致していることがわかる。

　よってpkgin -n arの結果は、PKG.automatic-notrequired全件とPKG.automatic-requiredの一部パッケージであるということになる。

　また、若干すっきりしないように見える結果ではあるものの、自動的にインストールされた他のインストール済みパッケージに依存しない・されない葉・リーフパッケージ(leaf package)全件を表示するpkg_leavesコマンドの結果とも一致することがわかる。

　そのスクリプトは以下なわけだが、ここにあるように、これは、/var/db/pkg以下の各パッケージにおいて当該パッケージを必要とするパッケージのリストである+REQUIREDファイルがないもの全件と、これがあるものの一部ということになる。

　と、ここまではわかったが、PKG.automatic-notrequiredだけ削除、PKG.automatic-requiredの一部パッケージも合わせて、つまり、pkgin arするのは、どっちがベターなのか？

　というか、PKG.automatic-required、PKG.automatic-notrequired、PKG.manual-required、PKG.manual-notrequiredって具体的に言うとどういうことだ？？？

　automatic(automatic=YESと書かれた+INSTALLED_INFOファイルがある場合)とは、インストール・アップデートのみ？それともアンインストールも自動？？？manualは、これが手作業？まさか全く違う意味？？？ってことはないか。。。

　また、required(+REQUIRED_BYファイルのサイズがゼロ以外)は依存関係があるもの？あったもの？、notrequired(+REQUIRED_BYファイルのサイズがゼロ)は、依存関係がないもの？なくなったもの？？？

　PKG.manual-required、PKG.manual-notrequiredを眺めてみるとmake(ビルド)したか、バイナリかに関わらず、自身が意図的にインストールしたもの(その後、アップデートしたものも含む)と一部それに依存してインストールされた？と思われるものがある気がする。

　一方、PKG.automatic-required、PKG.automatic-notrequiredを眺めてみるとmake(ビルド)したか、バイナリかに関わらず、自身が意図的にインストールしたもの(その後、アップデートしたものも含む)自体ではなく、これに依存してインストールされた？と思われるものがある気がする。。。また、何らかの状況下で仮に意図的にインストールすることになったものがあるにしても、それらは、そもそもpkgin show-deps(pkgin sd)/pkgin show-full-deps(pkgin sfd)/show-rev-deps(pkgin srd)やpkg_info -r/-R/-n/-Nで得られるような何らかの依存関係があったものである気がする。。。

　あ、automaticについては、man pkg_adminの[set]の項に「依存関係は引き継がれるものの、ユーザーによって直接インストールされなかったパッケージについては、"automatic=YES"という設定によって印付け(マーク)される」とあるのを発見。([Packages that are not installed directly by the user but pulled in as dependencies are marked by setting "automatic=YES".])

　ちなみにpkg_admin set/unsetについて、それだけでは、よくわからなかったが、man pkg_install.confを併せて眺めてみたところ、どうやら、そこにある変数及び設定値をパッケージごとに登録・削除できる模様。

　ということは、required/notrequiredの意味はともかく、automatic/manualについては、解釈は、あっているようだ。

　ただ、これらやその一部が、pkgin autoremoveやpkg_leavesの結果と一致するということは。。。と言ってもpkgin rm(remove)は依存関係も含めて削除されるわけだから、pkgin rmやpkg_leavesでリストアップされるのは、他のパッケージとの兼ね合いなどで自動的に解決できなかったものってことだよね。。。？

　だとするとPKG.automatic-requiredは、ユーザーが直接インストールしたものではないパッケージの内、他のパッケージと依存関係にあるものという理解で良さげ？

　他方、PKG.automatic-notrequiredは依存関係のないもの？？？インストール・アップデート、ビルド時には他のパッケージに依存してインストールされたが、インストール後は依存関係にないもの？？？それとも当初は、依存関係にあるパッケージがあったが、makeした際などに異なるバージョンなど他と干渉(Conflict)したなどの理由でpkg_delete -fで依存関係を無視して強制削除した結果、孤立してしまったもの。。。？？？

　ん〜。。。すっきりしない。。。site:netbsd.org "+REQUIRED_BY"とか"+INSTALLED_INFO"とかしてみても文脈から読み取ることができそうな部分もなくはないけど、それ自体の定義ってなさ気。。。(ただ、後者については、前述の通り、pkg_admin setの項に説明はあったので一応解決。)

　何れにしてもpkgin autoremoveするならpkgin -n ar | lessなどで確認しつつ、削除したくないものがある場合は、やはり、pkgin keepする必要はあるだろう。

　が、逆にこれによって疑問が湧くのは、試しにkeep/unkeepしてみるという以外に、どんな動機でpkgin unkeepするんだ？という点。。。pkgin arで削除してほしい場合？。。。それってどんな状況・・・？他方、keep/unkeepってpkg_deleteしたパッケージが依存するパッケージに対しても影響するものなんだろうか。。。？影響する場合、keepされたものを除いて削除してくれるのか。。。？それとも依存関係にあるもの全て削除できなくなるのか。。。？何れにしてもここで削除されないように除外したものは、のちにバージョンアップする場合に備えてpkgin unkeep/pkgin ukなどでアップデート直後に元に戻しておくべき？？？

　あ、先日Firefoxの言語パックにおいて言語パックは、バージョン49がバイナリリポジトリにあったが、makeが通らず、バイナリリポジトリにないインストール済みのFirefoxに合わせるべく47のままにしておきたい言語パックをpkgin keしてみたが、それでもpkgin ug/fug対象になったことを考えるとアップデートにはkeep/unkeepは影響しないのか。。。

　う〜む。。。

pkg_admin rebuild/pkg_admin rebuild-tree

　メインとしているノートPCのNetBSDでpkg_admin rebuild-treeを実行、いくつか依存関係が未解決と報告されるものがあったので依存関係の解決を図ってみることに。

　python34とImageMagickはインストールされていなかったが、pkg_info -r packageしてみたところ、そもそもpy34-sipとkismetは、他との依存関係がなく、不要と判断し、pkgin rm py34-sip kismet、poppler-glibについては、これ自体が古く、popplerのバージョンが46とより新しいことが原因だった為、pkg_add -uuv poppler-glibとして46にアップデートすることで依存関係も解決。

　ところが、libclucene-2.3.3.4nb5とboost-libsは、pkg_info -r packageすると何れも依存関係が大量にあり、libcluceneは、2.3.3.4nb5のみ、boost-libsは、バージョン1.61.0のみリポジトリにあって何れにしてもどこからかもってきて強制的バージョンを下げるか上げるかするしか解決策がなく、かといって共に依存関係が多い為、強行した場合、更に依存関係が拗れるリスクがあるので放置。

　一方、pkg_admin rebuildの結果は、以下メッセージが多発。。。

　+CONTENTSには/pathへのシンボリックリンクがあるけど、実際ターゲットはないよってことだけど、+CONTENTS内のパスを削除した方がいいのかどうかわからないし、それくらいなら問題なさそう？なので放置。

　よく見るとxfce4-volman-0.2.0nb25の各言語のパスにメッセージカタログのバイナリthunar-volman.moがない、kde-i18n-ja-3.5.10nb28の各種ファイルパスがないというメッセージが複数行、suse_glib2-13.1nb1についてのメッセージが1行。

　thunar-volman.moがないのは、日本語以外なので放置しても良さげ、KDE4が入っているものの、(pkgsrcにはあるも)kde4-l10nは入れていないが、どっちにしろKDE 3.5用言語パックkde-i18n-ja-3.5.10nb28は不要、よって当該パッケージ自体削除しても良さげ、suse_glib2は、adobe-flashとこれに付随するLinuxエミュレーションなどとの間に依存関係にあるが、本当に必要なら、ないと言われているdefaults.listをどこからかもってくれば良さげ。

　ということで実害はなさげ。

　尚、この改善をしたからなのか？試した古いノートPCにおいてSSDに換装後、NetBSD/Debian共に爆速となった起動が、それでも速いものの、ある日からNetBSDのみ10秒程度遅くなっていたが、これを境に爆速に戻った。

カーネルマイナーアップグレード後pkgin arしてみた

　NetBSD 7.0.2へアップグレードしたところで1台(デスクトップPavilion)で思い切ってpkgin ar(autoremove)してみることにした。

　その際、20個弱pkgin ke(keep)して削除を回避してみたら、pkgin ar候補が40個くらい減ったのは。。。なぜ？と思いつつも実行。

　終了後、ログを確認できるということで/var/log/pkgin/install_err.logを眺めてみると

のように、まだ依存関係上、他のパッケージが必要としているよ。。。というものがいくつかある。。。が、順繰り削除していって、この例の場合、mpageも最終的には削除される模様。。。

　これは、自身が勝手に想像していた『孤立パッケージ』とはイメージが違う。。。自身としては、他から依存されない。。。ひいては当然循環依存もないものが、pkgin ar候補として出てくることを想定していたのだが。。。

　とりあえず、pkgin ar後もシステムは安定、各種パッケージにも影響はなさ気。

　ちなみに直前の7.0.1時点でpkgin fugしてあった当該マシンにおいては、7.0.2にアップグレード後に実行したpkgin ug/pkgin fug共に意図的に最新版を使っていないFirefoxの言語パックのみ候補として表示されたので今回のカーネルのアップグレードに伴ってアップデートされたパッケージはない模様。

NetBSD 7.0.1からNetBSD 7.0.2へアップグレード

　気づけば、21日にリリースされていた模様のNetBSD 7.0.2へアップグレード。(sysinstをISOブートしたUSBメモリを使用し、手持ち3台のNetBSDをアップグレード。)

　3台とも[c: Configure network]でネットワークを構成しておかないとアップグレードできなかった。。。ネットワークインタフェースが複数あったからか？ISOブートしたからか？

pkgin autoremove

　ここ数年NetBSDを使わせて頂いてはいるものの、未だによくわかっていない部分がたくさんあるが、その1つにpkgin autoremove(pkgin ar)がある。

　孤立したパッケージを削除するコマンドであることはわかるのだが、以前、初めて実行してみたら、いろいろなところで収集がつかなくなったことがあった。。。と言っても、その時は、何も考えずpkgin fug、pkg_rolling-replaceやpkg_chk(-u/-a/-b/-s)などをした際、依存関係にあるパッケージがごっそり削除されるのを回避したくて、makeでひっかかったパッケージがあった場合、常にpkg_delete -fした為、各所で依存関係が崩れていた可能性が結構高いこと、pkgsrc/wipはそれぞれアップデートはしたものの、中をいろいろいじってしまっていたこともあり、入れ替えが必要だった可能性あったことなど他の要因も相まっていたと思われる。

　今、実行してみると、どのマシンもpkgin autoremoveすると80個前後とか、検証でいろいろなパッケージを入れていたマシンに至っては、320個前後とか対象となる孤立パッケージがあると報告される。

　その中には、gnome-terminal他GNOME系パッケージやbsdtar、更に意図して入れたはずのevinceやfluxboxなど、いやいや削除しなくてもいいんじゃない？。。。というようなパッケージもあったりする。

　ただ、ここ数日の経験でpkginのケースならpkgin autoremoveに「いやいや削除しなくても・・・」というパッケージがある場合には、あらかじめpkgin keep(pkgin ke)しておけばよいことがわかった。(よくわからないけどgettextとか、findutilsとか、kBuildとかって削除してもよかったっけ？とか思わなくもないものは選別も難しいが。。。孤立パッケージなのだから、他に依存関係上の影響もないはずで必要ならまたインストールすればよいのだろう。。。と微妙に割りきれない思いが残る。。。)

　当初、孤立パッケージを削除したって影響ないでしょと思ったら、他の要因の可能性が高いとは言え、失敗したので、その後、クリーンインストールしたことを考えると清々しく意気揚々とやる気になることもあるが、面倒だと思うこともあってpkgin autoremoveできずにいるが、いざ、これをやってみようかなと思う時というのは、往々にして他の要因もあって失敗する可能性が高いんじゃないか。。。って時だったりして躊躇したりする。

　慎重になって検索した結果、Re: How to remove pkgsrc orphan dependencies?にたどり着いた。

　まだ、ざっとしか目を通していない段階で、そのスクリプトを使わせて頂き、各NetBSDマシン上で実行、それぞれwcコマンドでカウントしてみるとpkgin arで対象となる数(pkgin -n ar | wc)とはまた違う数字が得られ、pkg_leavesの結果もまた異なる。。。これらの違いを知るには、少なくともリンク先の一連のスレッドの内容をちゃんと理解する必要がありそう。。。と思ってよく読んでみたのだが、質問者は最終的にこのスクリプトとpkg_leavesの結果が同じだったことで納得して終わっている。。。違う場合、どう消化すればよいのかについては、列挙されたパッケージをcommコマンドなどで見比べて依存関係を追うなりなんなり、他を当たるしかなさそう。。。

　当該スレッド内でリンクされている同じ質問者と回答者によるRe: What happens if I mix pkgin binaries with pkgsrc-current?の質問内容や回答も興味深いが。。。

　何れにしても、/var/db/pkg/にインストール済みパッケージの情報があるということ自体は知っていたものの、眺めてみたことはなかったのだが、おかげで/var/db/pkg/package以下に各種情報を端的に記したファイルがあること、それらファイルが各package共通とは限らない(全てに同じファイルがあるわけではない)こと、更に、これまで任意コマンドのmanとか、pkgsrcなどのMakefileなどで「なんだそれ？仮の名称？？？」と常々、なんとなく思っていたのだが、+REQUIED_BYとか、プラス記号の付いたものは、実体のあるファイル名だったんだということ等々を遅まきながら知ることができた。。。

　よくよく見るとノートPCのpkgin ar候補には、gnome系パッケージはない。。。pkgin sk | grep gnomeしてみるとgnome系はnon-autoremovableになってる。。。ということは、確か、各種検証を重ねたデスクトップのGNOMEはpkgsrcからmake、メインマシンであるノートPCではバイナリのリポジトリからGNOMEを入れたような気がするが、この違いか。。。？あのリンク先の議論だったかスクリプトだったかにもあった手動とか自動というのは、ソースからとバイナリからの違い・・・？だとするとリンク先では、手動で入れたものは、keepにすべきではないと書いてあったような。。。あれ？ノートの方もgnome-mediaだけはあってpkgin keしたんだっけな。。。？う、、、わけわからなくなってきた。。。思考停止。。。

firefox-l10n入れ替えでハマる

　一昨日、pkgin ugでFirefox自体は47も47.0のFirefox用言語パックをkeepにしてみたところでfirefox-l10n-49.0へアップデート対象となったわけだが、pkg_tarup -a -d ...しておいて後で入れ替えればいいかと思い、これを含めアップデートしてみることに。

　試してみたのは、前回アップデート後も正常に使えているメインマシンのノートPC/NetBSD。

　ところが、このマシン上でpkg_tarupしたものを一時的に保持してインストールしようとした言語パックは、なぜか、インストール時に必要ファイル群をことごとく削除できなかった旨のメッセージを表示後、失敗に終わり、意味があるのかないのかよくわからないものの、pkg_admin rebuild/rebuild-treeを実行してみても同様。

　試しにFirefox自体を。。。と思ったら、pkg_add -u/-uu/-fu/-fuuでは自前のリポジトリの同バージョンのFirefoxに入れ替えることはできなかったのでアンインストール後、再度インストールを試みたが、なぜか、インストールに失敗。。。。

　そこで、そもそもpkg_tarupしたパッケージ用のディレクトリがあってFTPアクセスできる前回、アップデート後、イマイチ不調に終わったデスクトップマシン/NetBSD上の当該ディレクトリに既にあったFirefox 47.0/Firefox-l10n-47.0をインストールすると先のようなエラーや失敗もなくインストール完了。

　しかし、不思議というか、おもいしろいというか、[Add-ons]から[Language]を確認するとJapaneseだけ[Japanese Language Pack is incompatible with Nightly 47.0.](互換性がない)とあって[Enable]ボタンがない一方、他の言語については全て[Enable]ボタンがある。。。なぜ？(上にあるイタリア語でいっか。。。って理解できないけどね。)

keep/unkeep

　NetBSDのパッケージ管理システムにおいては、keepとかunkeepという設定があって前者は、"non auto-removable"(非自動削除・自動削除可能ではない)、後者は、"auto-removable"(自動削除可能)として設定されるとある。

　今までこれの意味を理解することを避けてあやふやにしてきたけど、そろそろそうもいかなそうなので試しているところ。

　例えば、pkginを使っているとpkg ug・pkg fugなどを実行した時、たまにpkgin: gcc47-4.7.4nb1 has no associated repositoryのように表示され、停止してしまうことがある。

　まぁ、古いからとかいう理由もあって(今の)バイナリのリポジトリにそんなパッケージないよということなんだけど、もしかして、"non auto-removable"(pkgin keep/ke)にしてからpkgin ugすれば、通る？かとやってみたら、通って、ふむふむ、こうやって使うのか。。。と思ったのも束の間。

　アップグレード対象を眺めてみるとfirefox-l10n-49.0がある。。。firefox 49自体は、makeが通らず、バイナリもない。。。よってこれまで使っていた47.0を使っているのだが、言語パックだけアップデートされると、せっかく日本語対応できているFirefoxが日本語対応できなくなってしまう？よね？(メニュー類だけで検索コンテンツに影響があるわけでもなく実害はほとんどないが。)

　そこでpkgin show-keep/show-unkeepでfirefoxと指定して確認するとFirefoxも言語パックもkeep("non auto-removable")になっている。。。あれ？こうなっていれば、先のリポジトリになかったgcc47をkeepした時のように「対象から外されて」アップデートされないのかと思ったら、それはリポジトリにないからであってfirefox-l10nに関しては、リポジトリに、より最新があるからアップデートされるってことでkeep/unkeepは関係ないのか。。。それにしてもpkgin fugじゃなくてpkgin ugなら。。。あ、man pkginのug(upgrade)のイマイチ意味のわからない" If the installed dependencies match the listed needed dependencies, don't upgrade them."は、やっぱり自身の勘違いで今回の言語パックのケースみたいな時にアップデートされないっていう意味じゃないのか。。。

　となると、やっぱり、pkginに除外フラグが欲しいし、あったら便利だと思うんだけど。。。ないのか？見落としてるのか？他に何か方法があるのか。。。？

　前回、あるマシンで日本語対応できていたFirefoxが対応しなくなっていて言語パックもなかった。。。というのは、こういうことで起こるのか。。。

　っていうか、keep/unkeep、ついでにpkgin ugも具体的に何がどうなるからどういう状況で有用なのか未だによくわからない。。。

ん？リポジトリ整理中？ or タイミングを逸した？

　妄想の域を出ないけど、これって、もしかしてリポジトリ上のバイナリパッケージ生成中とか、精査・整理中などの理由で全てのパッケージが揃うまでに時間がかかるとか、はたまた、とあるパッケージを見たときに複数回バージョンアップがなされてとか、そうしたタイミングに当たったときにアップデートすると必要なパッケージがなかったり、アップデート対象のバージョンがいくつか飛んで順次古いパッケージが残っているわけでもないから直接アップデートできずに。。。とかで不整合が起きる！？とか！？

　っていうのは、気のせいか。。。？そんなことあったら、もっと話題になってて、とっくになんとかしているはず。。。と思いたいが。。。

　ただ、それらしい雰囲気は漂っている。。。特にしばらくアップデートしていなかったNetBSDマシンにおいて久々にアップデートした場合。。。

　今回は、どちらも今日アップデートした一方、正常な方は、メインマシンであることもあり、頻繁にアップデート、不思議な挙動になった方は、久々のアップデート。

　久々のアップデートになったのには、サブだからという理由以外に、もう1つ理由がある。

　NetBSDでインストール済みパッケージ全てを対象にアップデートしようと思うとバイナリベースの場合、pkgin upgrade(ug)やpkgin full-upgrade(fug)が便利、pkg_chk -bプラスアルファを使う手もあるが、依存関係にあるパッケージ含め、何らかのパッケージのバイナリがリポジトリにない場合の対処など、その仕組みが単純ではない為、前者を使いがち。

　更にNetBSDでは、ソースからコンパイル・ビルドする方法とビルド済みバイナリをインストールする方法を利用できるが、他方、ソースでの配布は許容されるが、バイナリの配布は許容されないパッケージがあった場合、ソースはあるが、バイナリがないというケースも出てくるし、ソースには、非公式のwipもあって混在してインストールしてあると当然、これも公式リポジトリにはバイナリがないという状況が出てくる。

　そんな中、pkgin ug/pkgin fugしようとした時、インストール済みとバイナリのリポジトリを見比べてリポジトリにないものがあるとアップデートできない旨のメッセージと共に停止してしまうことがある。

　どうもpkginには、特定のパッケージを除外する方法がないようなので、これに対処する為には、リポジトリにないと言われるインストール済みパッケージを都度削除するしかない。。。

　と言っても、これを見越してソースからビルドする際に必ず同時にパッケージも生成しておいたり、pkg_tarupでインストール済みパッケージからバイナリを生成しておいたりすれば、削除してアップデートした後にはソースからビルドしなくてもバイナリをインストールすることはできる。。。

　pkgin ug/pkgin fug時にインストール済みパッケージの削除が必要となった際には、pkg_tarupしていたものの、「これに備えて」ソースからのビルド時、バイナリも生成しておくという発想はなかったし、その場合、当然、その分、時間がかかるとか、依存関係にあるものも含めてバイナリを生成する場合、/etc/mk.confに設定すべき環境変数の設定の組み合わせがイマイチよくわかっていないこともあってpkgsrcやwipからビルドしたものについては、「常に」バイナリを生成するという習慣はなかった。。。

　前置きが長くなったが、こんな具合にリポジトリにないと言われた時、ちょっとした手間を面倒がって後回しにすることがあるというのが、もう1つの理由。

　確かにNetBSDのドキュメントに一貫してソースからビルドすることを推奨とは書いてあったが、それにしても、まさか、ここまで影響があるとは。。。

　そういえば、NetBSDの公式リポジトリ上のバイナリは、とあるパッケージに目を向けると1つだけ存在するものと数世代に渡って過去バージョンもあるものがあるが、過去バージョンも全てあるわけではない。

　以前からちょっと気になっていたものの、長きに渡り、広く配布されているディストロという点で盲信していた部分もあって、どうせ自身の理解不足で管理不行き届きの結果に違いないからクリーンインストールもやむなしと割り切り、深く考えずにここまできたが、これだと自身もいろいろな形で何度か経験してきた通り、タイミングや環境によっては、必然的にアップデート時の不具合が出る可能性があるよね。。。

　やっぱり、気のせいではなかったか。。。もっと早く気づけよって話だが。。。他のNetBSDな人たちは、どんな風に割りきっているんだろう？というか、この状況は放置されてる？気づいてないってことはないだろう。。。と考えると、手のつけようがないってこと。。。なのか？それともNetBSDは、その前提で使うものと割りきろうってこと。。。なのか！？pkg_compとpkg_chkでとか、pkg_rolling-replaceで、もしくは、例外なく全てコンパイル・ビルドしているのか。。！？確かに過去バージョンから順次全てのバージョンをリポジトリにおいておくというのは現実的じゃない気はするが。。。

　pkg_chkだと。。。package moved or obsolete?。。。になったパッケージの除外方法がわからない。。。除外というよりPKGCHK_UPDATE_CONFを使ってアップデート対象だけリストアップするのか。。。あれ違う。。。PKGCHK_NOTAGSか？。。。これも違うか。。。とするとpkg_rolling-replaceで-X使うしかないか。。。pkgsrcやwipも入れ替えないとダメか。。。な？

　それにしても以前あったバイナリもなくなることがある時点でバイナリベースでのアップデートには無理があると思うが、DebianやFedoraでは、遭遇したことがなく、良きに計らわれている気がする。。。ソースからビルドしたものの管理はしていないにしてもLinuxではリポジトリにあるバイナリはどうやって管理しているんだろ？

　そうか、そういうことか。。。今回については、例えばFirefox周り、なんかおかしいなと思ったんだよね。。。

　既にバージョン49が出ているらしき今、アップデート後も正常だったメインマシンのメインOSであるNetBSDも47だから微妙ではあるが、Firefox 47で日本語パックも効いていて(47があって)日本語対応されているが、LXDEやMATEの挙動が変になったサブマシンのNetBSDの方は以前は日本語対応済みで利用できていたFirefoxも久々の全体のアップデート後には、バージョンが44で言語パックが無効になっており、日本語対応になっておらず、Firefox上で言語パックを更新しようとすると(もう既に対応終了したようで)44にはアップデートできない旨、表示される状態になっている。。。

　NetBSDの公式リポジトリ(バイナリ)では、Firefox自体のバイナリがあったり、なかったりする(ここ数年見た限りではある方が珍しい、もしくは、ほんの一時期だけ存在する可能性も。。。) 、そんな今は、Firefox自体のバイナリは存在しないが、Firefox用言語パックのバイナリは、飛び飛びだが、古いものからいくつかあり、最新は49。。。

　それでも間が良かったのか、メインマシンのFirefoxは少なくともバージョン45くらいからはバイナリベースで順次更新できていたし、順次なら言語パックはインストールせずともFirefox上からアップデートできていた。

　一方、今回のアップデート後に挙動がおかしいマシンのNetBSDにおいては、リポジトリ上にFirefox用言語パックのバージョン44はないのでインストールできない、バージョンに関わらず、Firefox自体のバイナリもないので日本語対応させるべくアップデートするなら、まず、Firefox自体をソースからアップデート(make updateかreplace)するか、ちょっと古いが正常に機能しているマシンのNetBSDで言語パック共々？pkg_tarupしてバージョン47のバイナリをFTPを介してインストールするしかない状態。。。が、どうせなら何れも49にアップデートしたいところ。。。

　と思って、とりあえず、Firefoxだけmake updateしてみたら、失敗、正常に使えているメインマシンのFirefox 47とFirefox-l10n-47.0をpkg_tarup -a -d ...生成したパッケージは、今回異変のあるマシンに置いてある為、そこをNFSマウントして-dオプションに渡し、そこからfirefox-47.0nb1とfirefox-l10n-47.0のバイナリをインストール、言語パックの方が44のPLISTと衝突しているらしきエラーが出て入らないのでpkg_admin rebuildしてみたらエラーなくインストールでき、ブラウザ上でJapaneseを有効にしてURL入力欄にabout:configとタイプ、設定に入ってgeneral.useragent.localeをja-JPにして再起動で日本語化も完了。

　あれ？でもFirefoxもリポジトリにバイナリはないが、pkgin fugできたな。。。何が違う？？？keep/unkeepの違い？？？未だに普段使いレベルの理解すらできていない。。。

共有ライブラリ消失

　何らかのライブラリ(共有ライブラリ・shared library)が見当たらない旨のエラーは、これが初めてというわけではないが、今日は、FileZilla起動時にlibgnutls.so.28がない(が、より新しいlibgnutls.so.30はある)エラーで起動しないという事象に遭遇。(アイコンクリックやメニュー選択では単に起動しないだけだが、ターミナルから起動すると当該ライブラリが存在しない旨のエラーが表示された。)

　幸い同じバージョンのNetBSDを3台のマシンに入れており、内2台は同様だったものの、FileZillaのバージョンは同じも残り1台は正常に機能し(libgnutls.so.28があり)、libgnutls.so.28と実際には、libgnutls.so.28.41.10もあったのでこれらを当該マシンからscpで他の2台にコピーすることで解決。

　これらのマシン間の違いと言えば、当該ライブラリがなかったマシン2台については、直近、インストール済みパッケージ全体に対してアップデートを行なっており、当該ライブラリのあった1台はアップデート前だったという点。

　よってアップデートに伴い、消失。。。というより、確証はないが、同じ共有ライブラリを使う他のパッケージのアップデートに合わせて共有ライブラリもバージョンアップされ、その際に相対的に古いライブラリが不要と判断され削除されたとか、そういうことのような気がする。

　それにしても同じOSを入れたマシンが複数台あると自前でなんとかなって助かるケースも多い。

　と言ってもLinuxでは、同じディストロの同バージョンを入れていてもそんな風に感じたことはないし、他の*BSDは長期に渡って使ったことがないからそうした経験もなくわからないので、そう実感するのは、NetBSDのみだが、NetBSDでは、コンパイルはもとより、インストール済みパッケージから簡単にバイナリを生成できるpkg_tarupがあって高速マシンでバイナリを生成、ロースペックマシンには、FTPなどを介して当該バイナリをインストールできたりもするため尚更そう感じるのかもしれない。

LXDEが起動しない・MATEのWMが起動していない模様

　これもアップデートに起因するようでLXDEは[Your session only lasted less than 10 seconds....]といったポップアップが表示され、起動せず、MATEは起動するが、どうもWMが起動していない模様。

　これらが入っているマシンは、2台あり、1台は、公式リポジトリに入る前にwipや外部(それら公式サイトの)ソースからコンパイルして入れたもので今回の不具合が起きたのはこのマシン、もう1台は、何れもこの7月に公式リポジトリにあったバイナリを入れたもので相変わらず正常に起動している。

　不具合のあるマシンでもGNOMEを起動確認するのは忘れたが、gdmからKDE4、Xfce4、Fluxbox、Openbox、JWMなどは普通に起動するし、MATEも起動するアプリのメニューバーが全てデスクトップメニューバーの左端にかぶって開き、最上段のアプリを閉じないと下のアプリやMATEメニューは利用できなかったりはするものの、起動できないわけでもない。

　ただ、少し眺めてみるとLXDEについては、lxsession含め、いくつか必要そうなものが/usr/pkg/bin以下にない。。。7月にはあったLXDEやMATEも一部を除きバイナリがリポジトリからなくなってる。。。

　また、MATEのデフォルトのウィンドウマネージャmarcoもGNOMEのウィンドウマネージャmetacityも入っているし、dbusやhalも起動している。

　ノートPC(dynabook)でlxsessionをpkg_tarupしてデスクトップPC(Pavilion Slimline)のNetBSDに入れてみたりはしたが。。。

　何れも似たようなケースが以前にもあったような気もするが、思い出せず、今日は対処する気にもなれないので放置してある。

disklabelの表示が変

　fdiskは正常もdisklabel結果が壊れる(変な)のはなぜ？

　dynabookのSSDにDebianを追加インストールした後の現象。

　以前、HDDからクローニングしたSSDには、MSDOSパーティション形式で基本パーティションにFreeDOS/NetBSDが入っており、今回、追加で拡張パーティションを作って空き領域の先頭にext3フォーマットでDebian、末尾にswap領域、つまり、Debianとスワップパーティションの間に空き領域を残した恰好でインストール。

　Debianインストール後、NetBSDからマウントすべく、disklabelを確認すると反映されておらず、mbrlabelで更新したが、FreeDOSに相当するwd0eの他にsizeが1セクタ違いのwd0fが重複、Debian相当のwd0gやスワップ相当のwd0hのoffset値がwd0dのoffset+size値よりも大きいというか、wd0dのサイズがFreeDOSとNetBSD分しかないように見受けられ(以前と変わっていない模様で)小さい為に書き込もうとすると当然のごとく各所でセクタ位置が被っている旨のエラーが出る。

　それで良いのか自信はないものの、重複し、size値が1異なる模様のwd0eを削除、これに伴い、重複していたf、後のgやhのラベルを1つずつズラし、算数ばりに末尾に作ったスワップ領域の[offset]+[size]の合計値をwd0dの[size]値、[total sectors]値として[sectors/cylinder]値で割った商を切り上げた値を[cylinders]値としたらエラーなく、disklabelを終了させることができ、disklabel wd0とした時もエラーなくこれが表示されるようになった。

　ただ、/etc/fstabでDebianのパーティションを自動マウントする場合、fsckによるファイルシステムチェックの要否(要の場合、ルートパーティションかそれ以外か)を示す末尾の数値を0にしないと起動中に(exitすれば起動継続できるが)シェルに落ちるので、とりあえず[... 0 0]としてこれを回避している。

　そもそもLinux swapパーティションに何かあることは確かだと思ったのでレスキューUSBメモリに入れてあるGParted Liveで確認したところ、なぜか、[ext3]になっていたLinuxスワップ領域のパーティションのファイルシステムを[linux-swap]に変更、[スワップの有効化]をし、Debianパーティションをマウント、これにより新たに割り振られたUUIDでDebianの/etc/fstabのswap行も書き換え、その後、Debianにおいては、UUIDが怪しいぞエラーのチェックをすることもなく、通常起動するようになったが、他方、Debianパーティションをオートマウントする際のNetBSD側の起動時の挙動は変わらず。

　他のデスクトップマシンのHDDにもNetBSD/Debian/Fedoraをマルチブート、このdynabookでも、SSDクローニング後も、実は、まだ使えそうだったHDDにNetBSDとMageiaをマルチブート、それぞれマウントさせていたが、やはり、今回のようなことはなかったはず。。。

　違うとすれば、HDDかSSDか、空き領域末尾にスワップを配置し、中間に空き領域を作ったこと。。。となるとSSDだから？SSDは、その性質から容量全部使おうとすると耐久性が落ちるとか、不具合があるとかいう話もある模様、だとすれば、そんなSSDにおいて変なところに空き領域作った。。。というか末尾に領域を確保しちゃったから？それとも気まぐれ？たまたま？disklabelが壊れた？

　とりあえず、エラーはなくなったし、手動でもfsckさえしなければ自動でもマウントもできるのでよいといえばよいが、どうやったら、NetBSD側でDebianのパーティションのfsckを有効にしつつ、自動マウントできるようになるんだろ。。。？

　Debianの方も既に修復はしたもののスワップ領域の設定が変だったし、これに起因してUUIDも振りなおすことになったし、修復後もblkidの結果、/dev/sda2のNetBSDパーティションに加え、なぜか、PARTUUIDのみないものの、/dev/sda7が重複して表示されていたり、そもそもインストールに失敗し、再インストールするハメになったことなど微妙。。。NetBSDだけでなく、Debianも変となると。。。SSDの領域の末尾を空けたら解消されるのか。。。な？そうだったとしても今更、遅いのか。。。な？

　ということでLinux swapパーティションを前に移動、末尾を空き領域とし、mbrlabelしてみるとdisklabelが更新されていないようだったのでmbrlabel -rwとして更新、今度は、wd0eだけでなく、wd0fも重複していた為、これらを削除の上、先のように再計算して各所を修正してみるも変化なし。。。と思ったら、HDDを使っているマルチブートマシンで確認したところ同様であることから、Linuxのオートマウントのfsckでチェックすると。。。という件については、これはこれでよい模様。。。残るはNetBSDのdisklabelが変になるのはなんで？というのとDebianのblkid結果でNetBSDのパーティション用とは別に重複したものがあるのは何で？という点。。。なんでだろ？

やっぱり、disklabelの表示変かも

　新品で買ったUSBメモリ、Debian 8.4.0上でdmesgを確認するとデバイスはsd0、ファイルシステムはfat、Debianでは、すんなりマウントでき、HTMLファイルや.exeなどが入っていたが、再起動してNetBSD 7.0.1でマウントしようとするとできず、fdiskを見るとパーティションがないことになっており、disklabelを見るとaとdしかなく、aは4.2BSDとなっていてmbrlabelの結果を見るとa、b、d、e、fがあり、ディスクラベル間のラップも多すぎて手直しが必要な箇所が多すぎる状態。。。

　今回、USBメモリをGPT形式にすべく、NetBSDでやってみることにし、ファイルシステムは、NetBSDで未対応のext4フォーマットとしたかった為、Debianで行なうことにしたのだが、fdisk、disklabel、mbrlabel結果がおかしな状態なので当然もgpt createもfdiskでのフォーマットもできない。。。

　結果、NetBSD上でゼロ埋め(dd if=/dev/zero of=/dev/rsd0d bs=1m(Linuxだと1M))し、gptコマンドでフォーマットすることにした。

　USBメモリでもそうだから、前回の話も併せて考えるとSDDに起因する話ではなさ気。

　以前はこんなことなかったはずだけど、なぜ？

あ、mbrlabelじゃなくてdisklabel使うべきだったっぽい

　NetBSDの知識を掘り下げようと、いろいろ見ていく中で先のNetBSD/FreeDOS/DebianをマルチブートしているdynabookのNetBSDにおけるdisklabelの表示が変だったが、mbrlabelコマンドではなく、素直にdisklabelコマンドを使えば、正しく書き直すことができる模様だということがわかった。

　組み込み対話エディタで編集ならsudo disklabel -i -r wd0、$EDITORに設定済みのエディタを使うならsudo disklabel -e -I wd0、ラベル未設定ならsudo disklabel -i -I wd0。

　関連するmanには一通り目を通すべきだと痛感。

NetBSD 7.0からNetBSD 7.0.1にアップグレード

　ちょっと遅くなったものの、2016/05/22リリースのNetBSD 7.0.1にアップグレード。

　今回は、netbsd-INSTALL.gzを/に置いてreboot、[5. Drop to boot prompt]を選択してインストールしてみたらネットワークが構成されず、リポジトリにアクセスできなかった為、失敗。。。やっぱり、当該ディスクから起動したらダメなのかな？と思い、USBメモリからNetBSD( 6.1.2の)インストーラ・アップデータを起動、[b:Upgrade NetBSD on a hard disk]メニューを選択、リポジトリとパスを7.0.1に指定し、アップグレード、正常に終了。

NetBSDを他に入れ替えるべく複数試した結果、NetBSDに戻った話

　疲れからか、Debian/Fedoraとマルチブートしているもの含め、他2台のNetBSDは残しつつもラズパイ購入の決め手ともなった消費電力計測で実測値を目の当たりにしたことでメインとすることにしたノートパソコンdynabookのNetBSDを入れ替えちゃうか！と迂闊にも思ってしまった。

　そこでFreeBSDを入れたら、インストール自体は早かったが、敢えて旧バージョンを入れた後のアップグレードやパッケージのインストールが異様に遅く、調べると近年？日本にはリポジトリがないらしく、この点の改善は限界がある模様。

　ということでOpenBSDに入れ替えたら、インストールも一通り使えるまでにはなるのもあっという間だったものの、samba共有をマウントするにあたり、shlightでつまづき、Firefoxがたまたま？メモリリーク気味だったりで、FreeBSD/OpenBSDは、今回は見送ることに。

　Mageiaも気になるが、NetBSDと入れ替える気になるほどではない。。。ということでマルチブートすることにしたところ、結果、再生・視聴はできたが、VLCも各種プラグインも適切な同じリポジトリ(tainted)からインストールしないとmp4a(AAC)がないとか言われて再生されなかったり、UPnP/DLNAクライアントとして機能させようにもXBMC/Kodi、VLC含め、各種ソフトウェアで対応させるまでに至らず、Mageiaは「簡易なLinux」とは程遠く、少なくともこれらの点についてはNetBSD以上に手間と時間がかかり、GUIのrpmdrakeはCLIのurpmiのみをベースにしているわけではないのか？不思議とurpmiの機能が不足しているように思われたり。。。、それでもLinuxらしさが活きることもあるかと今のところマルチブートにしたままにしてある。

　なんだかんだでNetBSDのトータルバランスの良さを痛感させられることとなり、やはり、NetBSDをメインで使うに至るという結果となった。

ftp/curl/wget

　NetBSDでDLNAクライアントを検証していたら現時点ではTotemのみがまともに動いた(VLCは1.1.13しか動作しない現象でダメだった)ことからTotemの使い勝手を確認がてらYouTubeで動画検索でもしてみようと検索したら、なんと失敗。

　「libgdataが最新か否か確認してみてね」といったようなメッセージが表示され、確かに古かったのでpkgin ugやpkg_add -uでアップデートしようとしたらあえなく失敗、make updateだと時間かかりそうだし、make replaceしちゃおうと思ったら、これも素直にいかず、途中、curlも依存関係にあり、何やらそんなftpオプションはないぞエラーが。

　しばし、考えたあと、あ！。。。/etc/mk.confでFETCH_USING=curlにしてたんだ。。。curl置き換えてインストールしようとしてるってことはcurlないんだもんね。。。そりゃそうだということでwgetに変更したら、あっさり継続された。

　が、https://curl.haxx.se/download/からファイルをダウンロードすると何度やっても50%前後で止まってしまうのでmirrorリンクをクリック、シンガポールにあるらしき1サイトしか、しかもバージョンがより新しいcurl-7.49.0しか検索できなかったが、他のもあるだろうとたかをくくって、あまりよろしくはないのだろうが、直接Makefileを編集、バージョンはcurl-7.48.0、ファイルタイプは.tar.bz2とそのままにMASTER_SITESをhttp://www.execve.net/curl/に変更したら、あっさりダウンロード完了。

　やっと入ったと思ってpkg_tarupして実際に使うマシンからFTP指定してpkg_addしたら、今度は、[pkg_add: Conflicting PLIST with curl-7.47.1: man/man3/...]といったようなエラーが。。。

　とりあえず、makeしたマシンでTotemを起動したら、「YouTubeプラグインを有効にできませんでした」のエラー表示。。。ということはlibgdataが新しすぎたのか。。。というわけでpkg_delete -r curlしてMakefileを編集、バージョンをcurl-7.47.1としてmake install。

　が、バイナリのアップデート時のエラーにもあったエラーとなっているPLIST上の[/man/man3...]をコメントアウト。。。すると無事完了。

　Totemを起動しようとしたら、curlを削除する際、totemは依存として表示されなかったが、そんなことないだろと思っていた通り、消えていた。。。

　pkgin in totemとすると先で入れ直したのに古いlibgdataと一緒にインストールしようとし、やると失敗する為、pkg_add -v totemとしてインストール、ようやくYouTubeプラグインを有効にし、確認。。。「libgdataが最新かどうか確認してね」、確認するとまた古いlibgdata 0.6.6が。。。libgdata 0.16.1のパッケージを生成しておいたのでlibgdataを強制削除、ローカルからインストールを試みると「curl-48.0を入れようとしたら、curl-7.47.1が入ってるよ」。。。そりゃ入ってるさ！わざわざ入れたんだから！。。。。。

　結局、Totem 2.32.0とlibgdata 0.6.0が、更にlibgdata 0.16.0とcurl-7.48.0がそれぞれ依存関係にあってTotem 2.32.0とlibgdata 0.16.0、curl-7.47.1だと依存関係が成立せず、YouTubeプラグインを有効にできないか、または、有効にできても、そこに検索機能はあっても結局、使えない状態でしたとさ。。。おしまい。

　別にYouTube観たかったわけでもなく、ほんの軽い気持ちで始めたのにハマった。

　The 堂々巡り。

NetBSDでgptパーティションの操作とマウント

　NetBSD 4.0から/sbin/gptコマンドとNetBSD 3.0で登場するもNetBSD 5.0のGENERICから採用された模様のdrvctlコマンド、更にNetBSD-current-20141104(NetBSD 6.0と7.0の間)から/sbin/dkctlというコマンドが加わった。

　まだ、少し使いづらい部分はあり、対応するファイルシステムの制限などもあって課題も多い模様もGPTも使えるようになったはずと探した結果としてusing-large-disksを眺めていたら、少なくとも、これらを併用するとgptテーブルで作成された記憶媒体内のパーティションをマウントすることができることがわかった。

　ただ、検証に使ったUSBメモリの2つめのパーティションにNetBSDで未対応のext4パーティションがあり、そこ以降が読めない為、1つめにあったext3でフォーマットしたブートパーティションのみマウントすることができたが、未対応のファイルシステムにあたらなければ、もしくはこれが最後の方にあれば、そこまでのパーティションについては、他の対応済みフォーマットのパーティションはマウントできるはず。

$ sudo gpt show sd0
     start      size  index  contents
         0         1         PMBR
         1         1         Pri GPT header
         2        32         Pri GPT table
        34      2014         
      2048      2048      1  GPT part - BIOS Boot
      4096    102400      2  GPT part - Windows basic data
    106496   8192000      3  GPT part - Windows basic data
   8298496    102400      4  GPT part - Windows basic data
   8400896    880640      5  GPT part - Windows basic data
   9281536    512000      7  GPT part - Windows basic data
   9793536   5863391         
  15656927        32         Sec GPT table
  15656959         1         Sec GPT header
$ 

　まず、showオプション付きのその名もズバリgptコマンドにdmesgなどで確認した当該デバイスを引数として渡すとデバイスのGPTパーティション一覧が表示される。

　GRUB2を入れてあったからかBIOS BootとWindows basic dataしかないが、gptコマンドではパーティションの作成もでき、その際は、それなりの表記となる模様。

$ sudo dkctl sd0 listwedges
/dev/rsd0d: 6 wedges:
dk0: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, 2048 blocks at 2048, type: 
dk1: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, 102400 blocks at 4096, type: 
dk2: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, 8192000 blocks at 106496, type: 
dk3: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, 102400 blocks at 8298496, type: 
dk4: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, 880640 blocks at 8400896, type: 
dk5: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, 512000 blocks at 9281536, type: 
$ 

　続いてデバイスを引数としたdkctlコマンドにlistwedgesオプションを付けて実行する。

　dk?が、従来のディスクラベルに相当しつつ、/dev以下の仮想デバイスとして生成される模様でxxx部はGUIDと思われる、wedgeは『くさび』という意味である模様、クサビを打って目印(ラベル)を付けたといった意味合いだろうか？

　ファイルシステムタイプと/dev/dk?、マウントポイントを指定してmountを実行すれば、マウントできる。

　冒頭述べたとおり、ファイルシステムなど対応済みのもののみで構成されていれば、全てマウントできるはずだが、今回は、未対応のext4以前にあったext3のパーティションしかマウントできなかった。

　NetBSDをメインとして使いつつ、各種インストーラ・レスキューツールを入れてあるUSBメモリはGPT・GRUB2の組み合わせた方が都合が良いことがわかり、そうしていた為、GPTを認識できないと思い込んで勘違いしていたNetBSDではなく、Linuxマシンで作業していたのだが、NetBSDにgpt、dkctlコマンドがあって実はGPT対応されていたことはありがたい(一方、欲を言えばext4も対応してくれていたらよりありがたかったが。。。先のとおり、このUSBメモリにはext4がある為、唯一マウントできたGRUB用パーティションでのGRUB編集以外はサーバとしてラズパイに入れたRaspbian Jessieや他のLinuxマシンで編集することになる。)

　あれから各種インストーラ・レスキュー用USBメモリを差し替えた関係でext4も使わなかったこともあり、NetBSDで一連のGPT操作ができたことでいちいちマルチブート構成やUSBのLinuxを起動させることもなく、NetBSDで作業を完結させることができるようになった。

気づけばリポジトリにlibreOffice 5の日本語対応版バイナリがあった

　先のlibreOffice 5のビルドは、バイナリのリポジトリにlibreoffice4とlibreoffice5-binがあって何れも日本語表示・日本語入力ができなかった為にやってみるに至った。

　今回、ダメ元でCUPSプリンタを認識できるのか確認する為、LibreOfficeで試してみるか。。。とリポジトリを検索すると、これら以外にlibreoffice-5が追加されていたので早速インストールしてみたら日本語表示も日本語入力もあっさりできた。

　オフィススイートをバイナリでインストールできて日本語(国際化)対応できているというのは一般に大歓迎されることだろうし、デスクトップ用途としてNetBSDっていう選択もアリだよねと判断される条件の1つが整ったとも言えると思う。

　また、以前は古すぎたバイナリリポジトリのFirefoxも最新か1つ前くらいまでのバイナリが問題なく、機能するようになったのでこれもデスクトップ用途としては大歓迎。

　オフィススイートもブラウザもビルドしようと思うと時間かかるから最新(に限りなく近い)バイナリという選択肢もあるというのはありがたい。

　ただ、確認したかったCUPSプリンタについては、LibreOfficeでも[generic printer]があるのみでプリンタの追加ができず、自動認識されたものしか表示されない模様、いつからなのか仕組みが変わってしまったようで訳分からず、確認どころではなくなってしまった。

rpi用NetBSD/evbarm

　最近になってRaspberry Pi欲しい度が急上昇。

　と言っても最新のRaspberry Pi 3 Model Bでもzeroでもなく、Raspberry Pi 2 Model Bが欲しい。

　2012年Raspberry Pi Model AとModel B発売当初は、ふーんと気になった程度、2014年7月、Raspberry Pi Model Bの新たなバージョンB+が、2014年11月、Model Aの上位モデルとなるRaspberry Pi Model A+が、更にそれまで全て700 MHzシングルコア、RAMは256MBか512MBだったのが、2015年2月に900 MHzクアッドコアCPU、RAM1GBとなったRaspberry Pi 2 Model Bの登場で何にしても使ってみない手はないだろ？と思うようになり、2016年、わずか5ドルながらRPi 1 A/A+/B/B+に勝るとも劣らない700 MHzシングルコア、RAM512MBのRaspberry Pi zeroや初の64ビット、1.2 GHzクアッドコアCPU、RAM1GBのRaspberry Pi 3 Bが立て続けに出て、気になることこの上なし。

　尤もふとWebサーバにも。。。とも思ったが、やっぱりやめてファイルサーバ(NAS)、滅多に使うことはないがプリンタサーバ、スキャナ共有あたりを想定しているのでクロック周波数が上がったCPUクアッドコア、RAM1GBで電源も5V/2.5A(従来5V/2A)以上が推奨され消費電力も増えるRPi 3 Model Bはファイルサーバにするには、オーバースペックだからいらない、700 MHzシングルコアCPUでRAMが256MBのRaspberry Pi Model A/A+(一部のB)、RAM512MBのB/B+は非力、1GHzシングルコアCPU、RAM512GBのrpi zeroも微妙に非力な気がする一方、別途持っていてもよいかなと思わなくもないが、そもそも入手も困難、なら900MHzクアッドコアCPU、RAM1GBのRaspberry Pi 2 Model Bが妥当かななんて思っている。

　OSは、当然のごとく、操作性が変わらないはずのNetBSDにする前提で考えていたのだが、構成を考える内に現時点ではLinuxにしようかなと考えている。

　なぜかというとNetBSDは、(/etc/fstabに追記してオートマウントするにしても)UUIDに対応していない模様だから。(マルチブートしているNetBSD/Fedora/Debianでファイル共有する際に初めて気づいたが、これらのパーティションと関連付けられるデバイス名は固定なので特に問題はない。)

　実際のところどうなんだっけ？と思い、見つかったdevice-namingの[Wedges can have a name which defaults to a UUID]辺りを読むとdkドライバのユニットであるwedge(の集合)は、接続時に与えられるユニットを一意に識別する名称の文字列。。。その上で最終的にsd3fのような名前と関連付けしているわけだけど、wedgeは、厳密に1つだけ名称を持つことにしていることもあって現時点では、'by-name', 'by-uuid', 'by-label'といった別名を持つことはできないんだよねといった旨が書いてあり、どうやら、既に一意に識別できてるから、やろうと思えば、すぐにでもできなくもないんだけど、今はやっていないんだよね的な雰囲気。

　確かに特定のデバイスが、常に同じ名称でマウントされてデスクトップなどにも表示される為、マウントポイントは特定できるにしても関連付けられるデバイス名は、接続した順のようなので常に同じデバイス名と関連付けられることが保証されるというわけではなさそう。

　想定としては、ブートパーティションをmicro SDカード、システムパーティションをUSBメモリ、ファイルサーバとして使うにあたり、Sambaで手持ちのセルフパワー&バスパワーのUSBハブに、やはり手持ちの2TBのUSB外付けHDDを接続して共有、場合によってはRpi用のACアダプタを使うことなく、Rpi自体もUSBハブに。。。24時間365日稼働させておくことはまずないが、いずれかのマシンを起動した時には、常時稼働させておきたい。。。と考えている。

　普段、UUIDに対応していなくても、困ることもないと思っていたし、むしろセキュリティ上どうなん？と思わなくもない一方、こうした想定において接続都度、関連付けられる/dev以下のデバイスが変わることがあると(半)自動マウントするにあたり、困るケースも出てくるだろう。

　というわけでUUID対応していたら、迷わず、NetBSD/evbarm使いたいんだけど、ossp-uuidパッケージ入れるとできるのかな？違うか。。。FreeBSDはどうなんだろ？とも思わなくもないが、ここは、やむなくとまでは言わないまでもLinux。。。標準でDebianベースのRaspbianか準標準でFedoraベースのPidoraかな。。。と。

　結局、買ってRasbianを入れることにした。

• Raspberry Pi
• Raspberry Pi導入検討に至った経緯
• Raspberry Piと関連パーツ購入を検討
• Raspberry Pi 2 Model B一式の選定と購入
• Raspberry Pi 2 Model B用OSの準備
• Raspbian Jessieの初期設定
• Raspbian Jessieで各種サーバを設定
• Raspberry Pi 2 Model B/Raspbianをサーバとして運用中
• ラズパイ用USBメモリ差替時LVMのinactiveでハマった話
• ラズパイシステム用USBメモリ再移行作業
• Raspbian Jessie 8からStretch 9へのアップグレード
• Raspbian Stretch 9からBuster 10へのアップグレード
• Raspberry Pi OS/Raspbian Buster 10からbullseye 11へのアップグレード
• Raspberry Pi OS BullseyeからBookwormへアップグレード
• Raspberry Piのホスト名変更とmDNS
• 自作スマートスピーカー用Raspberry Pi 3 B+を購入
• Raspberry Pi 3 Model B+とデスクトップPC周辺機器でパソコン化
• Raspberry Pi 3 Model B+とノートPC液晶他でパソコン化
• Raspberry Pi 3 Model B+とUSB HDDブート
• Raspberry Piの起動
• USB WiFiで復活したRaspberry Pi 3B+内蔵無線LANの謎
• ラズパイboot/reboot/shutdownボタン回路
• Raspberry Pi 3B+のハードウェア設定値がデフォルト値じゃない！？
• Raspberry Pi/スマホにWireGuardでVPN
• Raspberry Pi/スマホにSoftEther/OpenVPN互換でVPN
• Raspbianが勝手に喋りだした原因はOrca！？
• ラズパイ2 Bのディスクは3 B+で使えないの！？
• Raspberry PiでZoneMinderインストールとカメラ映像表示
• Raspberry Pi OS/Debian bullseyeにZoneMinderをインストール
• ラズパイ2BサーバのシステムディスクをUSBメモリからSSDに換装
• 謎が謎を呼ぶラズパイ2Bの挙動...と思いきや3B+でも同様
• HDMIケーブル接続のRaspberry Pi 2BとTVで動画視聴
• Raspberry Pi 400はサブパソコンを優に超越
• Raspberry Pi 400でできることは数知れず
• Raspberry Pi Imagerは時短にもなってすごい！
• SSHでPermission denied publickey 究極の対処法
• Raspberry Pi 400/arm64 Linux/Box86/Box64/WineでWindowsアプリ起動
• Raspberry Pi OSで壊れたPIXELとWineの復旧
• arm64 Raspberry Pi 400/Raspberry Pi OS/KVMで仮想化
• Raspberry Pi 400/Raspberry Pi OSにFlatpakをFlatpakからアプリをインストール
• Raspberry Pi 400/Raspberry Pi OSにsnapをsnapからアプリをインストール
• ラズパイで急に日本語入力不能にfcitx5-mozcからibus-kkcに変更・解決
• ラズパイ起動時デスクトップアイコン実行･フリーズ問題解決
• Raspberry Pi 400/USBメモリにAndroid 12L/LineageOS 19をインストール
• Raspberry Pi 400/USBメモリにAOSP 13/Android 13をインストール
• Raspberry Pi 400にWaydroidでLineageOS 18.xベースAndroid 11
• ラズパイ/Julius/Open JTalkでスマートスピーカーを自作

GNOMEやLXDEでキーボード入力が効かなくなった！？

　ある日、[Ctrl]だか、[Shift]キーだかを複数回、連続で押下したか何かで「スティッキー・キー。。。」云々というポップアップが表示された。

　これまでもそんなことは何度かあったが、今回は、その後に端末(ターミナル)はじめ、テキストエディタやブラウザでも入力ができなくなった(と思ったら、支援機能の設定の一環で入力から表示までの時間が遅延していただけで各キーとも長押しすれば、効くことがわかった)。

　これは、身体の状態(身体機能)などにより、やむなくキーボード入力に時間がかかる場合などを考慮した支援機能が、おそらく先の「スティッキー・キー。。。」云々というポップアップの何らかのボタン押下の際に有効になったようで、これ自体はキーボード支援機能のデフォルト設定となっている入力及び表示速度の設定に応じた正しい挙動であることが判明。

　本件、最初はGNOMEで起き、確認のため起動したLXDEでも発生、GNOMEの場合、メニューから[設定] > [キーボード]などで表示される[キーボード設定]の[アクセシビリティ]タブの[スロー・キー]の項の[長いキー押下のみ受け入れる(O)]のチェックボックスのチェックを外すことで従来通り、入力が機能するようになった(尚、併せて同じタブ上の[キーボードからアクセシビリティ機能を切り替えられるようにする(A)]のチェックも外した)。

　ただ、GNOMEで設定した内容は、LXDE上では反映されず、GNOME用のものであり、.desktopの設定で表示させることもできるかとは思うが、LXDEでは[キーボード設定]メニューが表示されず、(xfce4の)アプリケーションファインダー内にも存在しなかったため、コマンドを探すべく、/usr/pkg/bin内を眺めたところ、それらしき[gnome-keyboard-properties]([gnome-keybinding-properties]ではない)を発見、マウスは効くのでコピーして他の端末を開いて貼り付け、[スペース]、[&]、[Enter]をそれぞれ長押しすることで[キーボード設定]ポップアップを表示させるも設定は、先にGNOMEで行なった通りになっている。。。そこで[アクセシビリティ]タブの[スロー・キー]の項の[長いキー押下のみ受け入れる(O)]に敢えてチェックを入れてから外してみたらLXDEでも有効になったようで従来通り、遅延なく入力できるようになった(が、一般アカウントで[gnome-keyboard-properties]コマンドを実行したLXDEでの設定は、再起動後、また元に戻っていたので当該コマンドは、sudoなどを使ってrootとして実行しておいた方がよいと思われる)。

passwdコマンドでパスワード変更ができなくなった

　現時点でNetBSDを入れてあり、過去から7.0にアップグレードしたマシンが3台あり、内2台がデスクトップPC、1台がノートPC。

　そのうち、ノートPCだけなのだが、既存ユーザー、新規作成したユーザーに関わらず、当該ユーザーでもrootでもPAMセッションを開始できない旨のエラーにより、passwd変更ができない状況に。

　これまでvncuserやdistccなどは追加したことはあっても通常のユーザーを別途作成した記憶がないので、いつからなのか、さっぱりわからないが、なぜ、ノートPCだけなのか。。。

　大きな違いと言えば、ノートPCのHDDからSSDにクローンを作成、これをSATA-USB変換ケーブルを使ってノートPCで起動してみたことがあったこと、NetBSDにおいてKDE以外のデスクトップは、デスクトップ上のグラフィカルな画面からだとログアウト以外のシャットダウンや再起動がデフォルトではできない状態で画面があってもログアウトとキャンセルしかなかったりしてどのマシンでも基本シャットダウンやリブートはkdm/gdmから行なっているが、未だ非公式のLXDEでは、他のボタンもあったこともあって、ノートPCだけあれこれやってみた結果、デスクトップ上から直接、電源断や再起動ができるようになっていたという点はある。

　検索してみるとNetBSDに関するものが、2〜3件(実質2件？)しかなく、レア過ぎる感もあり、前者の可能性が高い気がしてきた。

　確かにUSB起動してみたときに起動はできたものの、/がwd0aか、sd0aかわからない旨の警告が出ていた。。。クローンだからwd0としてコピーされていたはずなのにUSB起動したから、システムからしたら、なんだこりゃ？状態になったに違いない。。。

　何れも新規インストールの上、適切にブートローダを設定した場合は別だが、他のデスクトップ機では、起動できなかったものの、クローン元のHDDがノートPCのものであり、当然と言えば、当然だと思われ、むしろ、そのノートパソコンにおいてUSB経由でクローンを起動できてしまったことの方が異例であり、本来想定されることではないと考えられる。

　そうだとすれば、やはり、その際にクローン元HDDとクローン先SSDが同時接続されたことでシステムが混乱を来した可能性が高い。

　尤もユーザーを追加する予定はないし、それ以外は、正常に機能している為、このまま放置してもよいし、SSDをSCSI接続で内蔵ドライブとし、正常に機能することも確認済みであるものの、今回の件があって以降は試していないが、問題なければ、換装してもよし、ただ、寿命かと思われたHDD自体に問題がなかったことが判明、当面SSDに換装する必要もなくなったので初期化するもよし、元のHDDの方もパッケージソフトウェアの構成はともかく、データバックアップもさほどの手間はかからない為、NetBSD自体インストールし直すのも抵抗はなく、この状態から復旧する方法があるのかどうかといった興味もなくもないが、どうでも対応はできるので実用上の問題はない。

Blenderのビルド失敗

　Intel Core 2、RAM2GBのx86(i386カーネル)マシンでPKGSRC_COMPILER= ccache gcc、MAKE_JOBS= 4として12時間ほどかけて依存関係は一通りインストールでき、いざ、Blenderのインストール。。。というところでエラー。

　/usr/include/gcc-4.8/xmmintrin.hでスコープ内で定義されていない値が使われているとのことで眺めてみると全ては'__m64'と'__P'に起因しているように見える。

　pkg/50566: graphics/blender build fails on netbsd-7/amd64はあるが、状況は異なる模様。

　どうやらCPUの演算における拡張命令セット関連の値らしいが、find/grepしてみてもpkgsrcのblenderパス以下はもとより、/からたどって検索してみても、そうした値はなさげ、CXXFLAGSに-msse/-msse2/-mavxとかを設定すると何かよいことあるのか？、gcc　4.5と4.8が入っているようだが、5とかGCCのより新しいバージョンにすればよいのか？でも、そういう問題でもない気もする。。。

　たぶん、あとちょっとなのにな。。。

　といってもDebianにはBlender入れてみたし、そもそも、まだ、Blender使ったことないから、どうしてもNetBSDに入れなくてはってわけではないんだけど。

libreOffice 5のビルド失敗

　Intel Core 2、RAM2GBのx86(i386カーネル)マシンでPKGSRC_COMPILER= ccache gcc、MAKE_JOBS= 4として15時間ほどかかった？ところでエラー。。。

　先読みして、あそこでこんなエラーになるからあらかじめ対処しといてね！ってな具合に、もっと早く教えてくれられる時代になったらうれしいよね。。。

　マルチブートしているFedoraにはKDE入れた時にCalligraが、Debianには、LibreOfficeが標準で入っているし、そもそもOfficeスイート、使うことは、まず滅多にないからよいんだけど。

NetBSDにおけるUSB接続とPS/2接続

　ある日、Pavilionのマウスの感度が悪くなり、購入を検討するもそれまで手持ちのもので対処することにした。

　e-oneの標準マウスが壊れた際に買ったELECOM製マウス、e-oneでは、USBポートが2つしかないこともあり、マウスに付属していたと思しきUSB => PS/2変換アダプタを使ってPS/2接続していた。

　Pavilionも標準マウスをPS/2接続していたので、そのまま使おうかとも思ったが、USBポートが5ポートあることもあってUSB接続してみることにした。

　するとマルチブートしているFedora(Linux)では問題なかったが、NetBSDでは、なぜか、X を読み込めないエラーが表示され、結果、kdmを起動できず、タイムアウトを報告してlogin:が表示され、それでもログイン後はstartxやxinitでデスクトップ環境を起動することも、USB接続マウスを利用することも全く問題ないという状況に。

　他のマシンも使って、いろいろ試してみるとNetBSDでもxdmでは問題がなかった為、当初、NetBSDとkdm間固有の問題とも思ったが、xorg.confの(追記ではなく、)書き換えをすればよく、これをしていないことが原因であることがわかった。

NetBSDとシステム統計

　topコマンドやConkyに表示されるものの内、RAMについては、NetBSDの場合、消費量じゃなくて残量だと思われる。

　なぜってデスクトップを起動しただけの状態のRAMが70〜80%、Core 2でCPU2つフルに使ってmake installとか負荷のかかる作業しているとRAMが10MB台とか、マイナスとかになりつつ、それまで使ってなかったスワップ領域も使い出すしね。

　お、直ってる。消費量になってる模様。

VLC他オーディオプレイヤー on NetBSD

　NetBSDで利用可能なオーディオプレイヤーも数多く、ソースコードからのコンパイルの他、公式リポジトリ上にバイナリもある。

　ただし、必要となるコーデック類は、自身で見繕って(コンパイルするなり、)バイナリをインストールするなりする必要がある。

　NetBSDにオーディオプレイヤーをインストールしたのに映像や音声が出力されないという場合には、これに起因する可能性が高い。

　どれとどれが必要か明確に個別に判断できる人は限られると思われ、端末を並べてgrepで絞り込むなどしつつ、pkgin avでリポジトリ上とpkgin lsでインストール済みのパッケージを見比べて入れていくとよいだろう。

　かたっぱしから入れる場合、依存関係を含めたバージョン間の干渉もあり得るが、エラーを見ながら対処すれば、それほど時間がかかるものでもないだろう。

　ALSA関連のバイナリも結構あるが、2014年現在、OSSとpulseaudioがデフォルトの模様、これに起因してgst-plugin0.10-*、gst-plugin1-*、pavucontrol、pavmeter、更にスピーカーやマイクロフォン(ヘッドフォン)用の基準音量調整に何らかのミキサーも必要となる。

NetBSDで利用可能なVLCメディアプレイヤーのバージョン

　NetBSD 7にアップグレードしてからか、以前はこんなことはなかったと思うが、NetBSDの公式リポジトリにVLC 2.1.5nb8、VLC 2.0.9nb21、VLC 1.1.13nb54のバイナリがある時点でVLC 1.1.13しか機能しないケースに遭遇。

　VLC 2.1.5は、リポジトリ上にsmpeg-0.4.4nb16とsmpeg2-2.0.0nb2のバイナリがあり、インストール時に前者が不要の旨のエラーが出力されるも実際には、インストールされておらず、対処にあぐね、VLC 2.0.9nb21をインストールしようとするとlibdvbpsi-1.2.0ではなく、libdvbpsi-0.2.2を要求され、前者をpkg_delete/pkgin rm(pkgin remove)、後者をpkgin inすればインストールは完了するものの、VLC起動時にエラーもなく落ちるのか、そもそも起動していないようでps auxにも表示されない状態となる。

　その後もVLC 1.1.13、VLC 2.0.9、VLC 2.1.5をそれぞれmake install/update/replaceなどもやってみたが、やはり、VLC 1.1.13しか機能しない。

　セキュリティ面はともかく、使えるバージョンがあるので困らないといえば困らないものの、どうすれば、より新しいバージョンが使えるようになるんだろ？

　と思っていたら、2016/02/26、おそらくここ数日内にバイナリが更新されたようでpkgin fugするとVLCも含め、大量にアップデート対象があり、VLC 1.1.13しか機能しないが、大丈夫だろうか？と思っていたら案の定、VLC 2.0.9にアップグレードされ、機能しないどころか、CPU使用率が急上昇し、killしてプロセスは消えたことになっているのに、相変わらずvlcがほぼCPUを占有、マシンの再起動を余儀なくされるという機能しないどころかシステムに不具合を引き起こす状況に。。。

　pkg_chkやpkg_rolling-replaceとは別にバイナリのフルアップグレードは2〜3度行なってきたものの、VLCの件もあり、今回ふと、依存関係とか、安定性とか、全てクリアになってるんだっけ？と思って3台の内、1台だけ試してみたら、ある意味、予感が的中、一方で気づけば、リポジトリ上からVLC 1.1.13が消えていた為、他のマシンに入れておいたVLC 1.1.13をpkg_tarup -a -d ...して-dで指定したローカルのFTPディレクトリに移動、pkg_info -X * | gzip(bzip2) > pkg_summary.gz(bzip2)、当該マシンでpkgin up後、VLC 1.1.13をいれた。

　これまであった3バージョンの内、今回最も古いVLC 1.1.13がリポジトリからなくなったってことは、VLC 2.0.9含む以降が機能しないケースに遭遇している人はいないってこと？だとしたら原因は。。。？

　改めて探してみたら、一連のスレッドの多くは、なんか英文が難解で理解できないのだが、おそらく、I imported vlc21 separately from vlc2 because the vlc2-oss-backend supports NetBSD<7 while the vlc21-oss-backend needs OSSv4 which is only in NetBSD>=7あたりに起因しているように見えるが、そもそもこのスレッドの主題であるmultimedia/vlc{,2,21}においてVLCが３バージョンあることで依存関係が複雑になるし、最も古いバージョンがmultimedia/vlcでより新しいバージョンがmultimedia/vlc2とか、multimedia/vlc21とかってどうなん？より最新の安定版を標準にすべきだと思うけど？って話と相まって、まだ、その必要があるからこそ、併行して提供されてるわけだけど、使っている人がいるのか調査する必要はあるにしても、さすがに、そろそろVLC 1.1.13を削除したらどうかな？ってことも議論になっていて、その結果、vlc 1.1.13を削除、NetBSD 7以前用にvlc 2.0.9をmultimedia/vlc20として残し、multimedia/vlcを最新として更新していくことになった模様。

　というかvlc2-oss-backendとか、vlc21-oss-backendって何？パッケージがあるわけじゃなさげだけど。。。OSSv4ってOpen Sound Systemのバージョン4ってこと？だとしてもOSSにはバージョンごとのパッケージもなさげ。。。何をどうしたらvlc 2.xを使えるのだろう。。。？

　NetBSD 7.0.1、VLC 2.2.3は起動はする、マウントすればNASのファイルも指定、再生はでき、プログレスバーは動くが音が出ない。。。が、なぜか、それまであったはずのコーデックが不足していることに起因するようで1.1.13に戻してみても同様、また、今のところ自身の環境においてVLCは、症状は異なれどバージョンに関わらず、DLNAクライアントとしては機能しないが、VLC 2.2.3もユニバーサルプラグアンドプレイを選択するとDLNAサーバリスト、音源リストまでは表示され、曲を選択、再生ボタンを押しても再生されず、曲をダブルクリックするとVLC自体が落ちる。。。

　pkgsrcの全面入れ替えにより、SeamonkeyやFirefoxなどは更新されており、make updateでSeamonkey 2.38、Firefox 42.0とまさに最新版にすんなりアップデートされた。

　これらはそれ自体が更新されていたが、前回ハマった要因の多くは、pkgvi/mkpatches/make patchしてもパッチをローカルにおかなかった(置く設定をしなかった)り、時に手抜きして直接いじったり、また、make clean-dependsしきれていなかったりで不整合が生じていたからかもしれない。

　以後はmake clean clean-dependsの徹底や何かと分かり易くする為にもパッチをローカルに置くのはもちろん、cvsやgitによるupdateだけでなく、ある程度使ったらある種ルーチンとしてpkgsrcの総入れ替えもすることにするか。。。

　と思ったが、バイナリでもGNOMEの方が安定している為、GNOMEか何かあった際には、JWM、もしくは、Xfce4で以前は大丈夫だったのに今回なぜか、少しおかしいのは、ファイルマネージャとしてのThunarにおいて他ディスクをマウント、参照しようとした時だけ。。。よって、これを使用しない前提でXfce4を使って以後、作業することにした。

　とりあえず、gtk+/gtk2+/gtk3+、gnome、xfce4をpkg_delete -r、pkgin ls | grep -iで確認の上、削除されなかったgnome/xfce4関連パッケージを個別に設定して削除、改めてXfce4パッケージのバイナリをインストールしたところアイコンや画像が表示されない件は解消された。

　が、その後も、いろいろいじったせいか、マウントした他ディスクを参照しようとする際に限り、Thunarが異常終了。(バイナリの再インストールでは解消せず、バイナリのNautilusをインストールしてみたが、こちらでは再現せず、問題なし。)

　尚、その後もGNOME・Xfce4共にpkgsrcにおけるmake installやmake updateでは、各所でmake clean clean-depends後、再実行してみてもperlやxfconfなどよくわからないところに絡んでエラーとなるのでコンパイルするのは諦めた。

　また、以前からNetBSDでもNetworkManagerが使えればGNOMEという選択肢もと思ったが、なぜか使えず、他方、知らない内にXfce4のxfce4-wavelan-plugin(無線のみ)、xfce4-netload-plugin(有線・無線対応)といったプラグインが充実していたのでマシン上の余力はあるものの、とりあえず、GNOMEは入れず、Xfce4を使う方向にするか。。。

　ちなみにwipにあるLXDEは、以前書いたNetBSDにおけるデスクトップ関連のページの手順でインストールはできるが、後継はLXQTとのことでwipのlxqtをmakeしたら、QTがC++であることはわかっていながらも思いの外、コンパイルに時間がかかったので途中でやめ、これに伴い、同じくQTを使うKDEも(LXQTのコンパイルが正常終了するまで一時的に)アンインストールされてしまったこともあり、やはり、少なくとも、しばらくは、Xfce4(かJWM)を使おう。

　尚、検証マシンにおいてマルチブートしているFedoraでは、22からLXQtがリポジトリに正式に登録された模様、タイミング的には23にアップグレードした後だが、インストールの上、使用感を確認、LXDEの使い勝手にKDE風味(Qt)が加わった感じ、ConkyによればRAMの使用量がKDEに次いで多い模様であることがわかった。

　当ページの内容は、NetBSD 6.1.2から6.1.5までの内容であり、NetBSD 7.0へアップグレード後そのまま継続して利用する分には、また、そうでなくても、Xやウィンドウマネージャ、統合デスクトップ環境でもKDEとLXDE、キーボード・マウス、日本語設定などについても問題はない。

　が、7にアップグレード後、GNOME/Xfceに関しては、pkgsrcにおいて、これに影響のあるようなパッケージやこれを含むパッケージにおいてmake installやmake updateを行った後、エラー後の対処でパッケージの先祖返りがあったり、エラー後、対処不能になった場合、記事通りに、やり直しても復旧できないと思われるので注意が必要。(現在ハマり中。)

　(後に手を加え過ぎたのか、個々に更新されたのか(Seamonkeyは更新)、pkgsrc全ての入れ替えで解消されたが、)自身の例では、seamonkeyのmake updateで"gtk+-2.0 were not met."、"pixman-1 not found"などのエラーに見まわれ、かなりハマり、勉強にはなったが、PKG_CONFIG_PATHがどうのというところから、pkg-configなども調べる羽目になるも解決せず、ダメ元のpkgin fugで、ドツボ(こうしたエラー)からは抜け出せたものの、以後、どうやってもGNOME/Xfceがまともに表示されなくなったり、機能しなくなったりしている。

　例えば、こんな感じ。

• それぞれicon-theme系パッケージはインストール済み(、lnなどでパスを通していて)もGNOMEもXfce4、LXDEも何れかがインストールでき、起動できた場合、アイコン類含む画像のパスがおかしくなっているのか、全く表示されない
• GNOMEインストール後、GNOME系のバイナリパッケージを追加するとどれがどう響くのか不明も(アイコン？パネル？ファイルマネージャ？など何らかのものが再表示を繰り返しているのか、)デスクトップ上の無地アイコンと添字テキストや時に添字テキストだけが上下に弾む上、メニュー・タスクパネルが表示されない(右クリックで端末などランチャを作成して起動、操作するしかなくなるが、できるだけましか？)
• GTKのバージョンが相互に干渉するのか、GNOMEのインストール後、Xfce4をインストールするとエラーで依存関係上、削除せざるを得ないとか、新しいバージョンのPLISTが干渉してるぞとかいった状況で既存のパッケージを削除せざるを得ない状況に遭遇しつつ、なんとかインストールを終えるとXfce4も(hal/dbusがインストール・起動済みでも)GNOMEも起動すらできない

　KDEはQTだからか影響なく、正常に機能するが、軽快さから復旧作業はもっぱらJWM、もしくは、ログインシェル上で行っている。

　ちなみにpkgin用repositories.conf、pkg_add用PKG_PATHは、予めNetBSD 7.0に登録変更済み、pkgsrcもcvs update済み。

　NetBSD 7.0にアップグレード後、初めてaproposコマンドを実行したところ、エラーが。。。検索するとmail-index.netbsd.orgで同症状があり解決済みの話だった。

　/etc/man.confの_whatdb行(の代わりにとあるが、これ)の前に_mandb /var/db/man.db行を追加しただけでOKだった。

　バージョンに関係なく？アップグレード後にpostinstallやetcupdateをして構成ファイル群を適切にマージしなかったのが原因の模様。

　NetBSD 7.0においてSeamonkey 2.35のバイナリをpkgin in後、make updateし、Seamonkey 2.38、Firefox 41.0のバイナリをpkgin in後、make updateし、Firefox 42.0をそれぞれ導入することができた。

　既存のpkgsrcはいろいろ手を加えすぎたのか、不都合が散見されたのでバックアップ、新たなものを取得して入れ替えた際にどうやらSeamonkey、Firefox共に更新されていた模様。(よって前回のようにSeamonkeyのアップデートでperlの先祖返りが起こることはなくなった。)

　尚、意図的なのか？たまたまなのか、Seamonkey、Firefox共にバイナリをインストールすると(以下はFirefoxのケースだが、Seamonkeyも同様)以下のようなエラーが表示され、起動できない。(端末から起動しないとエラーすら出ない。)

$ firefox &
$ XPCOMGlueLoad error for file /usr/pkg/lib/firefox/libxul.so:
Shared object "libicui18n.so.55" not found
Couldn't load XPCOM.

　ここで/usr/pkg/lib/libicui18n.so*とすると.soや.so.56は存在するので、これをコピーして対処。

　すると

$ firefox &
$ XPCOMGlueLoad error for file /usr/pkg/lib/firefox/libxul.so:
Shared object "libicuuc.so.55" not found
Couldn't load XPCOM.

　これもコピーで対処したら、

$ firefox &
$ XPCOMGlueLoad error for file /usr/pkg/lib/firefox/libxul.so:
Shared object "libicudata.so.55" not found
Couldn't load XPCOM.

　これもコピーで対処したら、

$ firefox &
$ XPCOMGlueLoad error for file /usr/pkg/lib/firefox/libxul.so:
/usr/pkg/lib/firefox/libxul.so Undefined symbol "ucol_countAvailable_55" (symnum = 80)
Couldn't load XPCOM.

で結局起動せず。

　それならばとmake updateをしてみたところバージョンアップしてくれた上、正常に起動するようになった次第。

　いろいろ作業中だったので当初、何かやらかした結果かとも思ったが、一度、make updateが完了、起動確認したのに間違って(pkg_deleteして即Ctrl+Cしたものの間に合わず、依存関係にあるものが削除され壊れた模様で)削除してしまった後にバイナリを入れても同じ結果だった為、バイナリに起因するものと思われる。

　これ以前にwipのLXQTに再チャレンジするにあたり、MAKE_JOBS(NetBSDにおいてmake -jオプションに相当の環境変数)、ccashe、distccを使っていたのだが、Seamonkeyは何度かやったので(PC作業に限らず、いろいろやりながらでよくわからないが、)きっと早く終わったのだろう。

　LXQTの方は、当初、既にインストール済みのパッケージの干渉、他のPLISTとの干渉、その後、他パッケージにおけるヘッダファイルの(PLISTへの追記？)不足で1つ1つ対処していたらキリがなくなってしまい、疲れたのでやめたが、順調に進んだとしてコンパイル時間だけでもGTKベースのLXDEよりはるかに時間はかかるにしても、そこそこ素直にいけそうな雰囲気。

　FileZillaは相変わらずだった。(NetBSDでHTMLを編集、Fedoraを再起動してFileZillaで。。。というわけの分からない状況になることも多々。他のFTPソフトでもよいが、KDE3.5用で豆腐文字化けしていたり、異様に古かったりで。。。FileZillaが対処されるのを待とうかと。)

　FileZillaを諦め、FTP機能を併せ持ったファイルマネージャGNOME Commanderをインストールしてみた。

　そういう意味では、NautilusやCajaという選択肢もあるが、NautilusはインストールしただけでXfce4を使っていても背景を勝手に変えてしまうとか、期待するFTP機能を使おうと思ったらFTP接続した瞬間に落ちてしまうなど不安定だったので却下、また、FedoraにおいてCajaを試してみたらFTPソフトとしては使い辛く、何れにしても現時点でNetBSDにCajaはないが、Nautilusもそうだろうと考えると論外。

　何れもGNOMEプロジェクトによるものであることもあり、FTPサーバ設定画面は見た目が同じ、(即落ちるので以降の画面は不明も)唯一違ったのは、Nautilusの方は最初の設定画面にパスワード欄がなく、その画面でOKとするとパスワードの保持方法を指定する選択肢付きのパスワード専用の入力画面が表示される点。

　FileZillaで特に気に入っているのは、全て上書きの他、「変更があるファイルのみアップロード」する機能があること、「プログレスバーで進捗がわかる」ペインがあること、リモート・ローカルともにツリー表示なのでカレントディレクトリに限らず、「ツリー上でダイレクトに各所のディレクトリを選択できる」ことなどであり、Windows時代FFFTPから乗り換えて以来、FileZilla以外のFTPソフトを使おうと思わなかったわけだが、インストールできないとなると致し方ない。。。というか。。。結局のところGNOME Commanderを使うことはまずなく、改めてNetBSDでFileZillaが使えるようになるまでの間は、FedoraでFileZillaを使うことになるだろう。

　アップデートやアップグレードなどの過程でPavilion、dynabookのNetBSD上にFileZillaがなかったわけだが、e-oneのNetBSDを起動してみたらFileZillaが入っていたことに気づいた。

　念のため、起動してみると反応なし。

　あれ？と思って端末からfilezilla &とやってみるとlibnettle.so.4という共有ライブラリがないとのこと、確かにないが、libnettle.soはあったのでこれをlibnettle.so.4としてコピー、filezillaを起動してみると続いてlibhogweed.so.2がないとのこと、同様にlibhogweed.soをlibhogweed.so.2としてコピーしたら、FileZillaを起動することができ、サーバへの接続確認も成功。

　よっしゃということでpkg_tarupでe-oneのNetBSDにインストール済みのFileZillaからバイナリを生成し、以前NFS経由でインストールしたらうまくいかなかったこと、Sambaならうまくいったのだが、なぜかSambaがつながらなかったことからdynabookのNetBSDには、NFS経由でコピー中にdynabook側でlsで眺めたらサイズがおかしなことになっており、Ctrl+Cで中断、他の方法でということでPavilionのNetBSDには、外部サーバーへのFTP経由でアップロード(、この後、サーバ上に置いたままpkg_addしてもよかったが、なんか気が引けた為、)ダウンロードした後、サーバ上のバイナリを削除。

　PavilionにおいてローカルにダウンロードしたFileZillaバイナリをpkg_addでインストール、e-oneにあったFileZillaはNetBSD 6.xで入れたもので、何れのPCも6.1.5から7.0にアップグレードしていた為、OSバージョン違いの警告は出たが、無事起動、サーバへの接続もできた。

　これで久しぶりにFileZillaを使うためだけに再起動してFedoraで。。。という無駄な手間をかける必要がなくなった。

　アップグレードに起因するのか？自身のスキル不足も大きいとは思うが、任意のパッケージをmake install/update/replaceなどした際に復旧にあぐねるケースが頻発。

　尚、PKG_PATH、pkginのrepositories.confはNetBSD 7.0用に修正済み、pkgsrcはcvs update済み、のちに既存のものを退避し、新たにpkgsrcを取得。

　例えば、Seamonkeyのアップグレードを試みたところPerlの先祖返りを求められるなど、他でも複数の依存関係にあるパッケージにおいてインストール済みバージョンが新しすぎてエラーになるケースがあり、仕方なく、これに対処すると他に影響があるようで、よくわからないエラーが起こる、makeを終えられず、gtk+関連を使用するGNOMEやXfce4も影響を受け、一時的にとはいえ、削除されるし、解消しないとインストールされない為、別途、GNOMEやXfce4をmake installしても今ひとつ理解できないエラーで完了しない、インストールできてもアイコンなど画像という画像が一切表示されないといったことがあった。

　いろいろやってみたが、GNOMEとXfce4を両方入れると一方、または両方の挙動がおかしくなる、画像の件はlight-desktop(LXDE)も同様だったのでGTKが怪しい？ということでgtk+/gtk2+/gtk3+を削除、再インストールしてみたが、変わらずだった為、なんとなく不整合が直るかも？とpkgin fugしてみたところ画像の件は問題なく表示されるようになった。

　また、FileZillaをmake installしようとすると途中(必ず同じところ)で停止してしまうという現象が。

　これについては、ネット検索したところ、i386固有の問題らしく、https://mail-index.netbsd.org/pkgsrc-bugs/2015/10/05/msg057941.htmlのように修正することで一部対処できたと言えばできたが、解決には至っていない。

　というのもリンク先のようにしてみると先の停止箇所は通過したものの、/usr/pkgsrc/x11/wxGTK30/patches/のパッチ自体が原因で他の依存パッケージにおいてエラーとなり、リンク先をよく見るとpatches/以下にパッチファイルがない状態であることに気づき、パッチを全て削除、pkgvi/mkpatchesを使うとなぜか、エラーとなるのでMakefileを手作業で修正し、make patchというイレギュラーな方法をとってみたところ、パッチに起因するエラーが解消され、クリアしつつ、今度は、wxGTK30のビルド中に異なるエラーで停止、もしやと思い、バックアップしておいたパッチを確認するとpatch-src_unix_fswatcher__kqueue.cppのパッチがまさに当てはまり、これだけ戻したところwxGTK30内のビルドが終わりインストールされ、今度は、最終的なFileZillaのビルドまでいったところで、また停止、そこで全てのパッチを戻してみるも変わらずで、あと少しのような気もするが、FileZillaのインストールを断念。。。

　NetBSD3台の内、他の2台は、NetBSD 7.0にアップグレード後、make関連操作は行っていないこともあり、快適も、芋づる式に削除され、復旧できないと困る為、バイナリはともかく、makeはしないようにして今ハマっている1台で検証中だが。。。

NetBSDのデスクトップで自動マウントさせるスマートな方法はないものか

　NetBSDにおけるKDE/GNOME/Xfce4/LXDEなどで外付けHDDやUSBメモリ、デジタルカメラなどのUSBデバイスを自動マウントさせる方法が今ひとつわからない。

　amd/auto mount daemonや/etc/fstabを使うと一応できるが、正直まどろっこしくスマートでない為、手動マウントするようにしている。

　とはいえ、これはこれでいいのだが、興味本位でLinuxのautofs、devfsの仕組みやudevやUdisksは未実装だとしてもNetBSDにもあるhalやdbus、avahiだけでは実装できないのだろうか？

　と思っていたら、提案が挙がったようだ。

• <a href="http://wiki.netbsd.org/projects/project/improved-automounter-support/">Improved Automounter Support</a>
• New automounter

　のちにパスとタイトルが変わった？模様

CUPS on NetBSD

　NetBSDでは、2014年末現在、印刷においてCUPSを使おうと思うとデスクトップ環境など含め、/etc/mk.confなどでCUPS用オプションを指定の上、make install(やmake update、make replace)する必要が出てくる。

　KDEは何もしなくてもプリンタの検出まではするものの、一方、GNOME/Xfce4/LXDEでは、コンパイル時にオプション指定をすれば、ダイアログなどでCUPSを指定できたり、プリンタを検出できたりするものの、実際には、印刷ができない。

　手持ちの古いHP DeskJet 970Cxiでもlpd/lprやLPRngでは印刷可能、CUPS上での設定や認識も可能も、どうやったらNetBSDでCUPSを使った印刷ができるんだろ？

　尚、パッケージごとのオプション設定状況は、ローカルにpkgsrcが展開してあれば、パッケージのパスに移動(cd)してmake show-optionsとすれば、依存関係を知りたい場合には、make show-dependsとすれば参照できる。

　GNOME/LXDEでは、gtk2のcupsオプションを有効にしてmake update、libgnomeprintのMakefile編集、もしくは/etc/mk.confにcupsを使うべく設定、Xfce4ではこれに加えてxfce4-printのMakefileではLinuxとSunOSのみCUPSを使うようになっているので修正・・・などで各種アプリの印刷ダイアログにCUPSプリンタが表示され、プリンタが反応、印字するところまではいったが、残念なことに他の雑多な状況から、印刷が正常に行なわれるかどうかの確認までは至らなかった。

　この4月にRaspberry Piを買ってサーバとした際、SambaとCUPSも入れてクライアントマシンのFedoraやDebianからUSB接続の古いプリンタでもCUPSプリンタとして使えるようになったのでNetBSDでも試してみたらアップデートに失敗してアプリを再構築することになったり、KDE4がインストールできなくなったり、アップグレードしたりと以前と環境が変わったのでGTK系のアプリでCUPSプリンタの検出ができなかった。

　そこで以前と同様にCUPSプリンタを検出させようかとあれこれ見てみたらgtk2/gtk3のcupsオプションは有効になっているように見える、libgnomeprintもcupsを使うように書き直されているように見える、なぜか、xfce4-printはパッケージがなくなっており、標準でCUPSが使えるように設定されるようになったのかと思いきや、実際には検出すらできず、以前行なった対処すらできなくなっている。

　ネットで検索しても相変わらずできるよ的なWikiはそのままに何らアナウンスがあった様子もなく、NetBSDでCUPSが使える使えないといった情報も見当たらず、自身の勘違い？環境が悪い？気のせい？なのか、NetBSDでCUPSプリンタを使って印刷ってできるの？できないの？対応しているの？してないの？複合機やWindowsマシンに接続されたプリンタに丸投げすることにしてCUPSプリンタに対応するのやめたの？

　と言ってはみても以前にも増してプリンタは使わなくなったんだけど。。。

webmin on NetBSD

　NetBSDでは、意図的にCUPS用オプションを指定しないとこれが有効にならない、その必要性にたどり着くまでの試行錯誤の中、Linux/*BSD/PC-UNIXなどにおいてウェブブラウザ上でグラフィカルに(GUIで)システム管理を行うことができるパッケージwebminなるものがあり、その中でプリンタ管理としてCUPSモジュールがある(過去あった)と知り、webmin 1.600を入れ、1.750にもアップグレードしてみたが、結果、理由は不明なものの、既にwebmin用CUPSモジュールは提供されていなかった。

　ちなみに2000年前後には既にあった模様のwebminは、システム設定をグラフィカルに行うことができるものであり、場合によっては、そんな設定もあるのかといった発見にもつながる、かなり驚きのツール。

　ただ、グラフィカル設定必須という向きには最適なこのツールも各種機能の存在を知っていることが前提とはなるが、往々にしてUNIX系システムへの習熟度合いが高いほど、端末でやった方が早いと感じるかもしれない。

NetBSDとデスクトップ

　NetBSDには、各種ウィンドウマネージャはもちろん、KDE/GNOME/Xfce4といったデスクトップ環境もバイナリ含め、既にある。

　全て、または、一部については、ソースコードからコンパイルしないといけない場合もあるが、GNOME、Xfce4については、ある時点では、両方入れても、また、ある時点では、いずれか一方を使う分には、とタイミングにもよるが、バイナリのみで事足りる。

　また、pkgsrcのwip(テスト中の非公式パッケージのリポジトリ)には、LXDE/LXQt/MATE/Cinnamonもあり、LXDEについては、導入可能であることを確認済み、LXQt/MATE/Cinnamonはコンパイルが通らない一方、MATE/Cinnamonでは、全てではないものの、ファイルマネージャや端末など標準パッケージを個別にインストールすることはできる。

　その後、pkgsrcのwipからCinnamonが消えたものの、MATE、LXQt、Luminaがあり、MATEはインストールでき、暫定措置を講じれば使える状態、Luminaは起動はできないが、無理矢理やればインストールはできる状態、LXQtはまだインストールできない状態(ライブラリのパスを通せば、インストールできるのかも？)。

　お、気づけば、LXDEとMATEが公式リポジトリに入っててバイナリもある。

NetBSDのデスクトップで再起動・電源OFFさせるのは難しい

　NetBSDでは、KDE 3.5やKDE 4だとデスクトップ上からリブートやシャットダウンができるし、gdm/kdmからもこれらの挙動に問題はないが、policykitの設定が正しくできていない為か、NetBSDにおけるGNOME/Xfce4/LXDEなどではデスクトップ上からこれらを行おうとすると失敗、いろいろやってはみたが、未だにできず、ログアウト後、gdmやkdmに戻って、そこで再起動やシャットダウンを行うようにしている。

　どうやったらできるんだろ？

　その後、LXDEを入れ直す機会があり、再インストール後は、なぜか、デスクトップ上のlxde-session-logout/lxsession-logoutの画面から再起動やシャットダウンができるようになった！と思ったら、また、できなくなることがあったり。。。なんで？

　NetBSD 7.0.1、Xfce4では、再起動もシャットダウンもできるようになってる。。。

gdmと言語設定

　gdmを最初に起動すると英語表記となっており、言語設定を変更すると日本語表記に変更できるのだが、他で覚えがないのでなんだが、NetBSDの簡易GUIの言語設定の変更は一時的でログインしてログオフした時点で既に英語表記に戻ってしまう。

　いろいろやってみたところ、Configure Login ManagerでLocalタブにおいて[Themed]、もしくは、[Themed with face browser]変更、そこにあるSessionメニューのLanguageを変更するとログイン、ログアウト後も変更が保持されたが、再起動後に英語表記となってしまう。

Xfce4とConky

　これは、NetBSDに限ったことではないと思うが、まるでレイヤーが2枚あるかのように透過したConkyとデスクトップアイコン群が交互に表示されてしまうという状態に。

　しばらく、いろいろいじってみたが、最終的に[double_buffer=yes]を[double_buffer=no]にしたら何事もなく透過したConkyとデスクトップアイコン群が常に表示される状態になった。

LXDEとConky

　なんの問題もなく表示できていたConkyが、セッションの自動起動としても、デスクトップ表示後に端末から起動しても、デーモンは走っているが、なぜか画面上に表示できなくなった。

　他のデスクトップ上には表示されるのにLXDEだけなぜ？

　LXDEは、軽量化の為、透過仕様を外しているとはいえ、conky含む透過設定は、これまで無視してくれてたはずなのになぜ？

NetBSDとNFS

　NetBSDでは、NFSv2、NFSv3に対応、NFSv4には未対応というか、対応しない意向。

　それはよいとしてNetBSD同士、NetBSDとLinuxの場合、Linux側がNFSサーバであればmount_nfsに-T、mount -t nfsに-o -Tを渡すなどすれば、相互にファイル共有可能。

　ただ、通常利用する分には、なんの問題もないが、ある条件下においては、マウントポイントがフリーズするという状況に遭遇。

　ある条件とは、同じコピーでも数MB以上の圧縮ファイルの場合、また、NFSマウントポイントをリポジトリとした場合など。

　回線・通信(転送)速度が遅いことに起因しているのか？とも思ったが、以前からNFSはこうした傾向があるもSambaでは大丈夫だったことやrcpやscpでは、なんら問題なく差分ではなく初回の1GB程度のコピーも快適なので違う模様。

　ちなみにマルチブートしているマシン上で例えば、NetBSDからFedoraやデータ保管用パーティションをマウントした場合には、何の問題もないのでマウントに起因するものでもないと思われる。

NetBSDにおけるmountとファイルマネージャ

　NetBSDでは、当然、USBデバイスやNFS、Sambaなどによるファイル共有、他パーティションのマウントなどができる。

　NFS/Samba共有をマウント、各種ファイルマネージャを開いてアクセスした際、何が原因なのか、時々、ファイルマネージャがクラッシュして落ちることがある。

　Thunarは即落ちするが、NautilusやCajaは、得てして、階層が深い場合に辿っていると落ちる。

　どうもツリー表示したペインでツリーを辿ると落ちるが、アイコン表示した方は、落ちない模様。

　なんでだろ？

　その後、なぜか、少なくともCajaは落ちなくなった。。。

NetBSDのpkgsrcとバイナリ

　NetBSDでは、pkginやpkg_add他でバイナリを管理したり、pkgsrcをローカルに展開してソースコード情報をもとに管理することもできる。

　何れも適宜、最新の状態にアップデートしておくのが望ましく、バイナリならpkgin ug(upgrade)/pkgin fug(full-upgrade)、pkgsrcなら、/usr/pkgsrcなどpkgsrcトップでcvs update -Pdなどとすればよい。

　ただ、展開したpkgsrcなどでコンパイルエラーに個別に対処し、場当たり的に修正したり、パッチをあてたりしたものは、そのまま残ってアップデートされなかったり、make clean clean-dependsやpkgcleanしきれておらず、主たるパッケージや依存関係にあるパッケージにおいてworkディレクトリが残っていたり、依存関係にあるパッケージの先祖返りなどがあったりするとシステムとして不整合が起きる可能性もあるので、不慮のエラーに見舞われたときなどにもpkgin ug、pkgin fugやpkgcleanをしておくとよい。

　むしろ、そうしないと変にハマることもあるので要注意。

　ちなみにmake clean-dependsについては、常にそうしたい場合、/etc/mk.confで環境変数を使って[CLEANDEPENDS=yes]としておくと、make cleanとするだけで依存関係にあるパッケージも掃除してくれるが、併行して何らかのコンパイルをしている最中においては、これらに関連するパッケージも掃除されてしまう可能性があるのでCLEANDEPENDSの設定含め、make clean-dependsやpkgcleanしないように注意しよう。

　また、インストールは、make install、依存関係にあるパッケージを含むアップデートは、make update(全てのパッケージ対象ならpkg_chk -uに適宜オプションを付与)、依存関係を無視して当該パッケージだけをアップデート(入れ替え)したい場合には、make replace(全てのパッケージ対象ならpkg_rolling-replaceに適宜オプションを付与)する。

それまで動いていたパッケージが、正常に機能しなくなった場合

　例えば、パッケージのインストールや削除、特に[-f]オプションなどで依存関係を無視して強制したりしていると、それに関連して、それまで正常に機能していた全く別のパッケージがうまく動作しないといった状況も起こり得る。

　そうした場合、makeしなくても、全く同じバージョンであってもバイナリによるアップデート、もしくは、アンインストール後、改めてインストールするだけで依存関係が整って正常に機能するケースがある。

　リポジトリにあるバージョンと異なるパッケージなら、自マシン、他マシンに関わらず、安全をみて、なんならpkg_tarupででも予めバイナリを確保しておき、pkg_addを使うが、pkg_add -uは、インストール済みパッケージが同一バージョンだと、その旨のメッセージ付きで何もせず終了するのでpkg_deleteしてから、pkg_addすればよい。

　pkg_addやpkginはローカルにあるパッケージも指定でき、pkg_addでは、普通に当該パスを指定すればOK。

NetBSDでmake replaceやmake updateに失敗、既存のパッケージが削除されてしまった場合

　make replaceやmake update、pkg_chk -u*やpkg_rolling-replace -u*などに失敗し、対処しきれない場合、これらは、まず、インストール済みパッケージを削除してから実行される為、パッケージがなくなってしまうということが起こりうる。

　これを回避する為には、pkg comp pkg chkにあるようにpkg_compでchroot環境を作り、pkg_chk -uanと実際には何もしないnオプション付きでエラーなく完了できることを確認の上、DEPENDS_TARGETやUPDATE_TARGETなど依存関係を含め、バイナリの生成、パッケージのインストールをするように設定しておき、改めてpkg_chk ua、chroot環境に全てのバイナリが生成されるので、これを使って今度は、全てのバイナリをインストールすべく、pkg_chk uabとするのが、現時点では、ベストチョイスのようだ(が、これはパッケージが消失してしまうことを回避する策であって、これで実際にアップデートする為には、pkg_chk -uanで滞りなく完了できる(完了しなければ、完了させる)必要がある)。

　こうした回避策をとらなかった場合、make replaceなら依存関係にあるパッケージに影響はないので当該パッケージのバイナリが生成されつつ、エラーが出て対処できないというケースにおいては、make cleanさえしなければ、workディレクトリ内にバイナリがある為、これをインストールに使うことができるが、エラーによりインストールに失敗しているということは、バイナリでも同様のエラーが出る可能性が高く、バイナリをインストールするにしてもmake cleanでやり直すにしてもエラーの対処法を探るのが現実的な解決策となるだろう。

　おそらく、その多くは、例えば、インストール済みの依存関係にあるパッケージのバージョンの不一致によるエラーであれば、それを更新、既にインストールされている同名のパッケージがあることが原因ならpkg_deleteするといったことで対処できる比較的単純なエラーの可能性が高いものと思われる。

　バイナリが生成される前に起きたエラーである場合、リポジトリにバイナリがある場合は別として、エラーに対処しない限り、削除されたまま、当該パッケージをインストールすることができないという事態になる。

　make updateした場合は、より深刻で依存関係にあるパッケージも影響を受け、アップデート対象か否かによらず、全て削除されてからアップデート作業が実行される為、どのあたりで対処できないエラーに見舞われたかによっては、make clean-depends前で一部バイナリが生成済みだったにしても、たいした助けにならないということもあり得る為、エラーの対処方法を見つける方が近道になる可能性もある。

　pkg_chk -u*やpkg_rolling-replace -u*は言わずもがな。

　何れも/etc/mk.confで当該パッケージ(make package-installでも可)や通常、一時的に作られるものの、バイナリは生成されない依存関係にあるパッケージのバイナリを生成するように設定しておけば、指定したパスにそれらが生成されるが、やはり、エラーがどこで起きたかによっては、復旧の足しにならない可能性もある。

pkgsrcの掃除やアップデートに一縷の望みをかける

　こうした場合、/usr/pkgsrcなどトップディレクトリでmake clean clean-dependsするか、より高速な(一連のworkディレクトリを削除する)pkgtools/pkgcleanをインストールして実行すると以前起きていたエラーが解消する可能性がある。

　それでも解消しない場合、pkgin ugやpkgin fugでバイナリによるインストール済みパッケージの更新、さらにtarballによる入れ替えやcvs、gitなどによるpkgsrcの更新をしてみるとエラーが解消されている可能性もある。

　それでも尚、解消されない場合で、バージョンアップはできないにしても幸運にも別途、同一アーキテクチャのNetBSDマシンがあって、それにもインストール済みのパッケージなら、[pkg_tarup -a package]で依存関係にあるパッケージごとインストール済みパッケージからバイナリを生成、HTTP、FTP、samba、nfs、scpなどの方法で当該マシンにバイナリをインストールすることで復旧時間を最小限に抑えるという手もある。

　さもなければ、リポジトリが更新されるのを気長に待ったのち、更新して試してみるか、そもそもハマったエラーの解消法を見つけるしかないだろう。

NetBSDとscp・ssh

　先の通り、r系コマンドは、セキュリティ面から基本的にssh、scpに置き換えるのが賢明とされており、r系でできる程度のことであれば、導入の手間も変わらないので敢えてr系コマンドを使う理由はない。

　そこでNetBSDとFedora(Linux)をSSHサーバ(リモートホスト)、NetBSDをSSHクライアントとして試してみた。

　SSHサーバをNetBSD、Fedora何れにした場合も共通設定の/etc/ssh/sshd_config、より優先されるユーザー個別設定の~/.ssh/configを適宜編集することになるが、PasswordAuthentication=yes行がコメントアウトされていたら先頭の#を削除して有効にする。

　NetBSDの場合、/etc/rc.d/sshd restart(/etc/rc.confにsshd=yesを追記していない場合には、onerestart)とすればよい。

　Fedoraは、Fedora 23時点では、sshdが動作していれば、構成ファイルを再読み込みさせるべくsshdを再起動する為にsudo systemctl restart sshd、sshdが動作していなければ、sudo systemctl start sshdとすればよい。

　クライアントであるNetBSDでは、(/etc/hostsなどでIPアドレスとホスト名のマッピングができていれば)単にssh username@hostnameやscp file username@hostname:~/pathとすれば、パスワードを聞かれ、リモートホスト側のログインパスワードを入力すればよく、ユーザー名が同じなら[username@]部分は省略可能と簡単だ。

パスワード認証と鍵認証

　ただ、パスワードもマシンの性能向上と共に総当たりで組み合わせを調べる方法ですら、解析にそれほど時間がかからなくなっている昨今、まして、sshを使うなら、より安全な暗号方式を使う鍵認証がベター。

　sshで鍵認証を使うためには、まず、クライアントでssh_keygenコマンドなどを使って鍵を生成、それをscpなどでサーバの利用するアカウントのホームディレクトリ直下の.ssh/ディレクトリにコピーする。

　例えば、RSA認証方式の場合、デフォルトでは、id_rsa(秘密鍵)、id_rsa.pub(公開鍵)という2つのファイルが生成されるので公開鍵であるid_rsa.pubをSSHサーバに.ssh/authorized_keysファイルとしてコピーの上、.sshディレクトリのパーミッションを700、authorized_keysファイルのパーミッションを600にすればよい。

　なお、複数のクライアントからアクセスがある場合など異なる名称で認証鍵を生成する場合には、ssh-keygenコマンドにfオプション付きで鍵の名称を指定して生成した上、先の手順を踏み、コマンドラインからiオプションでパス付きで鍵を指定しつつ、sshを実行するか、別途サーバ側の./ssh/configファイルを作成し、ホストや認証鍵の指定など関連付けを行なえばよい。

　この時、RSA認証を使っているので/etc/ssh/sshd_configファイルにおいてRSAAuthentication yes、というわけで公開鍵認証を使うのでPubkeyAuthentication yesとしてこれらを有効にしておく必要がある。

　これでクライアントからsshを実行することができるようになったはずで、ssh-keygenの際にパスワードを入力した場合には、Password:の表示に従い入力後、空とした場合には、即SSHサーバにログインできるようになる。

　ちなみに試していないのでなんだが、たぶん、構成ファイルでPermitEmptyPasswords noに設定するとパスワード未入力で即ログインという方法は使えなくなると思われる。

　なお、この時点でPasswordAuthenticationの設定値は、yesでもnoでも挙動は同じだが、この値がyesの場合、何らかの原因で鍵認証がうまくいっていないケースでは、その旨のメッセージが表示され、継続するか否かを問われ、ここでyesとするとパスワードを求められるが、これは鍵認証失敗後にパスワード認証できているに過ぎず、PasswordAuthentication noにしてsshdをrestartした後にログインしようとすると鍵認証のみが有効である為、Permission Deniedなどのエラーとなるので原因を探して鍵認証できるように改善する必要がある。

　当然ながらリモートホストの電源が落ちていたり、スリープ状態だったりするとアクセスできないし、アクセス中にスリープ状態になるとネットワークが遮断される(ものの、経過時間にもよるかもしれないが、復帰させれば、継続してアクセスできる)。

マルチブートマシンの各OSをSSHサーバとする場合

　ちなみにSSHサーバとするマシンのOSがマルチブート構成で各OSそれぞれでsshdを走らせる場合、例えば、マルチブートしているだけなのでDHCPから配布されている場合、IPアドレスも期限が切れ再配布時に変わってしまう場合をのぞき、基本的に同一になるし、固定で分けていたら尚更だが、ホスト名が異なるとサーバとするOSに合わせて別々の鍵を生成する必要があったり、それらの名前解決をしなければならず、変更を要すと同時にそのホスト名でアクセスすることになったりする。

　が、もしかしてSSHサーバを設定する以前に、した後でも鍵を生成する時点で？マルチブートしているOS全てのホスト名をクライアント側で同一にしておけばよい？

　というか、とりあえず/etc/hostsで複数のホスト名をIPアドレスにマッピングしておけばよい。

NetBSDとrcp

　NetBSDに限らず、相互のマシンのホームディレクトリ内の暗号化もされない.rhostsファイルに書かれていれば信頼されるホストであるという安易かつ単純なrlogin、rsh、rcpなどのr系コマンドは、場合によっては、モニタやキーボードすらない遠隔地にある、もしくは、別部屋などにあるサーバなどにアクセスすることを主な目的としていることもあり、特にインターネット経由などの場合には、安全性の面からssh、scp(sshは、rlogin・rsh、scpはrcpの機能を含むより強力でより安全なコマンド)を使うべきだが、r系コマンドも全く使えないわけではない。

　と思ってNetBSDでrcpしてみようと思ったら、一瞬戸惑ったが、クライアント側では、リモートサーバ側のIPアドレスとホスト名をスペース区切りでマッピングしたものを/etc/hostsに記載するなどして名前解決の上、リモートサーバ側の/etc/inetd.confのrshd行のコメントを外して/etc/rc.d/inetd restartし、かつ、当該ユーザーのホームディレクトリに.rhostsファイルを作成の上、信頼できるクライアントとしてホスト名(、IPアドレス)とユーザー名が異なる場合には、ユーザー名をスペース区切りで指定しておけば、rcp abc.txt username@hostname:~/(やこの逆)のように指定して実行することでネットワーク越しのコピーが可能となる。

　尚、Fedora(Linux)からもNetBSDにrcpできた。

　ちなみに、今回、これを何に使おうと思ったかというとFirefoxをインストール&最新の42.0にアップグレード済みのPCに入っているNetBSDで/etc/mk.confにおけるDEPENDS_TARGETとUPDATE_TARGET設定の検証も兼ねてpkg_tarupを実行、FileZillaにおいてリポジトリとしてもバイナリをコピーするにしてもSamba、NFSでは今ひとつ、回線やネットワークが細いからかとも思ったが、以前Sambaでは問題なかったことから環境に問題ないことを再確認する為、また、前回のケースでは、外部サーバのFTP経由で他のマシンにコピーしたものの、それにしたってLAN内で済ませたいところ、というわけでFTPサーバか、もしくは、rcpでと思いつつ、コピーならrcpでしょというわけでこれを使うことにした次第(だが、より安全なscpを使うべきだし、そもそも同じものをコピーするなんて無駄なので、この場合、他で書いたFTPを使うのが正解)。

　この時、libvpx 1.5.0以上を求めるエラーが表示され、確認するとインストール済みだったもののバージョンは1.4.0、公式リポジトリ上のlibvpxのバイナリも同様だった為、依存関係として作成済みのlibvpx 1.5.0のバイナリがあることを確認の上、pkg_add -uしたのち、再度Firefoxをpkg_addして完了。

　前後のトピックにもあるが、42.0のバイナリはない為、make installすることになるが、時間がかかる、バイナリを得るならmake packageする手もあるが、コンパイルする分、やはり、時間がかかることから、インストール済みのパッケージからバイナリを生成してくれ、数分もかからないpkg_tarupの方が圧倒的に速く、当然、外部FTPサーバ経由よりもrcpの方が速い(が、前述のとおり、scpの方が賢明だし、そもそも、この場合、LAN内のFTPサーバからの取得が妥当)、また、インターネットごしよりもローカルのバイナリをインストールする方が、より速いということで、おかげで相当な時間短縮となった。

　ここでfirefox-l10n-42.0もpkg_taupしてバイナリを生成、これをインストールしようとしたら、なぜか、言語パックの内、/usr/pkg/lib/firefox/browser/extensions/langpack-ach@firefox.mozilla.org/階層下の一部ファイルが、PLISTと干渉するとかでインストールに失敗すること数回。。。待てよ？エクステンション(プラグイン)だし、システムにインストールする必要なんかなく、もしかして日本語の言語パックとしてlangpack-ja@firefox.mozilla.orgディレクトリを当該マシンにコピーするだけでいいんじゃないか？と思うに至り、コピー後、Firefoxを起動したら言語パックのインストールができるようになり、反映された。

NetBSDとFTP

　NetBSDでパッケージをインストールするにあたり、他のマシンに欲しいパッケージが入っているなら、pkg_tarupを使うのが手っ取り早く、この受け渡しには、rcp、scp、ftp/sftp等々が考えられるわけだが、こういう場合は、やはり、ftpを使うのが無駄もなく、正解だろう。

　sshdを起動していれば、/etc/ssh/sshd_configファイルでsftpもデフォルトで有効になっており、ユーザー名とパスワードの入力が必要にはなるが、コマンドラインから、もしくは、クライアント用のFileZillaなどからもアクセスできる。

　ただ、今回ローカルリポジトリに即アクセスできるようにしたい(anonymousでアクセスしたい)こともあり、ftpを考えてみる。

　NetBSDでもいろいろなftpデーモン(サーバ)が使えるようだが、ftpdを使うなら/etc/inetd.confでコメントアウトされているものを外して有効にし、念の為、/etc/inetd restartしておくのもよいだろう。

　サーバなのでクライアントからアクセスできるようにする必要があり、まして今回ローカルリポジトリとしてanonymousでアクセスできた方がよく、ftpの場合、もう少し作業が必要となる。

　必要なのは、ftp用のユーザー作成と公開するディレクトリ、適宜、これらの所有者・グループやパーミッションを設定、ftpアクセスできるディレクトリはchrootされるのでファイルを列挙できるようにlsコマンドをコピー、とりあえずはデフォルト設定で十分なので編集する必要はないが、/usr/share/examples/ftpd(ftpd含むいくつかは/usr/pkg/share...ではない)以下のftpd.confとftpusersファイルを(/etcでもよいが)/usr/pkg/etc以下にコピー、ftp ftp://server_path/などとしてアクセスできれば完了。

　これについては、簡潔に書かれたここが参考になるだろう。

NetBSDでパッケージを検索をしたい場合

　NetBSDでパッケージを検索したい場合、インストール済みのもの全てならpkg_info -a、pkgin ls/pkgin listなどで、利用中のリポジトリ上のバイナリならpkgin av/pkgin avail、pkgsrcなら前述のコマンド類を使うとよい。

NetBSDでpkgsrcのパッケージを検索をしたい場合

　NetBSDでというか、pkgsrcを使うシステムにおいて、パッケージを検索したい場合、http://www.pkgsrc.se/のリポジトリにあるパッケージを検索するならpkgse、ローカルに展開したpkgsrcを対象に検索したいなら、pkg_select、また、これにも含まれるpkgfindを使うと便利。

　これらは、何れもpkgtools/にある。(/usr/pkgsrc/pkgtools/など)

　オンラインかローカルか、表示の体裁などの差はあれどpkgseやpkgfindがパスと簡易説明のリストであるのに対し、pkg_selectは、より詳細なデータベースであり、一覧からディレクトリ階層を辿ったり、依存関係を参照できたり、インストール済みのパッケージがマーキングされたり、一部機能しないものもあるものの、コンパイルや削除などもできるshellベースのグラフィカル環境となっている。

NetBSDでバイナリによる一括アップデートをしたい場合

　NetBSDでバイナリによる一括アップデートをしたい場合、ローカルに展開したpkgsrcのソースコード情報とインストール済みパッケージを比較してアップデートする為にpkg_chk -uaする方が、より最新にできる可能性が高いが、オンライン、ローカルのバイナリのリポジトリを元にアップデートするpkginをインストール、/usr/pkg/etc/pkgin/repository.confにオンラインやローカルのリポジトリを登録してpkgin ug/upgradeやpkgin fug/full-upgradeならより手軽。

　adobe-flash-plugin11などHTTP/FTPの公式リポジトリにはないパッケージ、また、vlcのように3バージョンあったものが絞られて1つや2つになったとか、何らかの理由で既にリポジトリから消えたバージョンのパッケージがインストール済みである場合など、「リポジトリには、そんなパッケージ見当たらないよ」的なメッセージを表示してアップグレードを中止・終了してしまうことがある。

　前者のように、そもそもバイナリが配布されていないものは、make updateしておき(、もちろん不要ならmake deinstallなり、pkgin removeなり、pkg_deleteなりで削除しても可)、後者のようなケースでは、インストール済みバージョンが必要ならpkg_tarupでバイナリをどこかに確保しておき、pkgin remove、pkg_deleteや必要なら、これに-fオプションをつけるなどして削除しておけば、pkgin ug/pkgin fugを実行することができる。

　尚、pkginでは、除外オプションがなさ気(pkgin keep/unkeepが相当するのかと思いきやそうでもなさ気)なのでアップグレードしてほしくないパッケージもアップグレード対象となってしまう。

　これを回避するというか、アップグレード後に復旧する為には、やはり、自マシン、もしくは、他マシンのNetBSD上で必要なバージョン(pkg_tarupしてインストール済みパッケージから生成されるバイナリ)を確保しておき、後でアップグレードされてしまったものをpkgin remove、確保しておいたバージョンのパッケージをpkgin inするしかなさそう。

　他方、pkgin ugやpkgin fugでひっかかって停止してしまうパッケージをアップデートしてもよい場合には、他のマシンでmake update済みのものをpkg_tarupするなりしてそのマシンの当該パスをFTP(公開し、)指定してpkg_add -uvなどであらかじめアップグレードしておいてからpkgin ug/pkgin fugすれば、完了できる。

　ただ、自身のようにLXDEやMATEなど、まだ非公式なパッケージを多々入れている場合、バイナリベースのpkginでugやfugするとリポジトリにない旨で停止、数が多いと、これらを先の方法でアップデートするのは現実的ではないのでpkg_rolling-replaceなどを使うことになるだろうが、pkgsrcツリーにあれば、全てmakeが通るというものでもないのが悩ましいところ。。。

NetBSDで欲しいパッケージのバイナリがなく、コンパイルもエラーになる場合

　同じアーキテクチャのNetBSDをインストールしたマシンが複数台ある状況において次のようなケースというかなり限られた状況を前提とすることにはなるが、これに当てはまれば、簡単に対処することができる。

　システム構成を同一にしておらず、個々のパッケージにおいてあるマシンにあるパッケージが、他のマシンにはなく、入れたくなったものの、リポジトリにバイナリもなく、コンパイルでもエラーになってしまうという場合、インストール済みパッケージからバイナリパッケージを生成可能なpkg_tarupを使うと便利。

　他のマシンには、SambaやNFS、HTTPやFTP経由でそのまま、もしくは、rcp、scpなどでコピーするなどしてローカルにあっても、そのバイナリをインストールできるからだ。

　もちろん依存関係に不足がないという前提もつくが、動いているマシンには、そうしたパッケージも入っているので、それもpkg_tarup -aとして依存関係にあるパッケージのバイナリも含めて生成すればよい。

　-dオプションを付ければ、生成したバイナリを置いておくべきディレクトリの指定もできる。

　尚、一元管理しておらず、あるマシンで一連のパッケージのバイナリを生成せずにコンパイルしてしまったが、他のマシンでもそれ欲しかった！といった場合にも、もちろんpkg_tarupを使うこともできる。

　コンパイルできるならmake packageしたものをインストールすることもできるわけだが、ビルドする必要がない分、pkg_tarupの方が圧倒的に早い。

　尚、make packageする際、依存関係にあるパッケージのバイナリも生成したい場合には、/etc/mk.confなどでDEPENDS_TARGET="package"を設定しておく。

　ちなみにコンパイル時にバイナリを作成しつつ、パッケージをインストールするには、make package-installを使うことができるが、make installでも/etc/mk.confなどでDEPENDS_TARGET="package-install"を設定しておけば、同様のことができ、make packageする際には、DEPENDS_TARGET="package"を設定しておけば、依存関係にあるパッケージのバイナリも生成できる模様。

Error: Circular dependency detected

　NetBSDでというか、pkgsrcを使うシステムにおいて[Error: Circular dependency detected]、意訳すると「循環依存(関係にあるもの)が検出された」というエラーメッセージが出力されることがある。

　体験上は、Firefoxをmake packageする際に依存関係も併せてパッケージを生成しようとした際、何れも設定値を[package]とすべきところを勘違いして/etc/mk.confで環境変数DEPENDS_TARGET(依存関係にある対象)に[package]、UPDATE_TARGETに[package-install]としてしまった結果、起き(、UPDATE_TARGETを[package]としつつ、Firefoxが削除されたところで止まってしまったのでfirefoxをpackage-installすることで完了し)た。

　Firefoxとこれに依存するパッケージそれぞれが、依存関係にあるのは当然であり、たぶん、依存パッケージ全てがFirefoxと依存関係にあることを報告した結果、バイナリが存在する場合はスルーするにしても何回もFirefoxをインストールしろってどういうつもりだ！ということでエラーになったものと思われる。

NetBSDのdisklabel更新コマンド

　NetBSDでは、というか、*BSDでは、他で基本(プライマリ)パーティションと呼ばれることのあるスライス1つの中にBSDパーティションを定義して以前は8、現在は16まで複数のパーティションに分割できるわけだが、相応の数マルチブートするとディスクラベルの内容が現状と異なるということも起こり得る。

　実用上は特に困ることはないが、ただ、一時的にマウントしたい場合とか、マシン起動時にマウントしておきたい場合、デバイス名を知りたいという可能性がある。

　そんな時、fdisk device_nameを実行することでdisklabelに書くべき、当該パーティションのプリセット値やサイズ情報を得ることもできるが、NetBSD 1.4で登場したmbrlabelコマンドを使うとデフォルトでは標準出力へ表示、オプション指定でdisklabelの書き替えができるようになってる。

WMだかデスクトップが多重起動してる！？

　kdmやgdmといったディスプレイマネージャを使っていて検証なんかで直接叩いたり、startx/xinitでやってみたりした後、ディスプレイマネージャに戻すといったような場合、うっかり、.xinitrcに追記してあるウィンドウマネージャやデスクトップ環境のセッションを削除するなり、コメントアウトするなりしておかないと2重に起動するので要注意。

　そうしないとデスクトップでログアウトを2回繰り返し実行するハメになったりする。