virtualbox が 4.3.30 にバージョンアップしていたので、久しぶりに更新してみた。
そうしたら、また共有フォルダが上手く機能しない様子。色々と設定を試しているうち「Unknown file type “vboxsf”」というエラーメッセージに遭遇した。これは初めて目にしたものだったので、ネットで検索したところ、次の記述を発見した。
--------
I've fixed mine using the following way:
1) Update system's packages
$ sudo apt-get update
2) install virtual box guest additions (referenced from here)
$ sudo apt-get install virtualbox-guest-additions-iso
3) Now install guest additional package (Crucial step! People generally miss this which creates an error “Unknown file type “vboxsf”)
$ apt-get install virtualbox-guest-utils
--------
国内の記事では見つけることができず、英語のページで発見したのが上記のコメント。この内容に従ったところ共有フォルダは利用できるようになった。
…が、今度は、ディスプレイのサイズを上手く調整できなくなってしまった。virtualbox の画面サイズを、ホストである windows7 のデスクトップ上に表示する時、最大サイズより少し小さく設定していたのだが、再起動のたび、デフォルトのサイズに戻ってしまう。guest additions を再度適用して kernel を再構築してもダメ。
その際、ターミナルの画面は従来の処理経過の表示と違って、「building …」となる部分でリンクの所在を表示する形になっていた。最終的には guest additions の適用は成功したってことで終了しているんだけど、依然として画面サイズの検出は上手くいかない状態。
そこで、今回、vboxsf というファイルタイプを認識させるため、iso ファイルをインストールする形を取り、そこから参照するスタイルになっているのが原因だと推測して、ターミナルで打ち込んだコマンドの内容をすべてアンインストールしてみることにした。(それでまた「Unknown file type “vboxsf”」が出てきたら、その時はその時で…(笑)。)
iso ファイルの方は remove しても「そんなものは無いぞ(ボケッ)」って怒られたが、utils の方は無事 remove 成功。そうして再起動したところ、めでたく画面サイズを、指定したとおりの形で再現することができるようになった。(めでたしめでたし…)
2015年8月16日日曜日
2015年7月18日土曜日
(何度目かの) 共有フォルダ設定方法の整理メモ
共有フォルダの自動マウントにチェックが入っていると、以下の位置に自動的にマウントされる。
/media/sf_NAME
NAME は、ホスト OS 側で設定した 「名前」 の値。ただし、このディレクトリのアクセス権は、vboxsf ユーザーグループにのみ許可されているため、ファイルマネージャーで普通に覗こうとすると弾かれてしまう。それを知らなかったので、いつも sf_××× というフォルダができているのにアクセスできず不思議に思っていた。ゲスト OS 側の一般ユーザーから共有フォルダにアクセスするには、あらかじめそのユーザーを vboxsf グループに追加しておく必要があり、そのための書式が
sudo gpasswd -a ユーザ名 vboxsf
ということだった(らしい)。
したがって、VirtualBoxの共有フォルダの設定「自動マウント」にチェックしていると、システムの方では、「既にどこかにマウントしているぞ」と判断して、後からマウントしようとした操作をエラーとするらしい。そのため、
sudo mount vboxsf -t (共有フォルダ名) /media/マウント先
の記述は無視orエラーとなっていた可能性があり、何度もマウントできず悩んだ原因はここにあった様子…。でも、そうなると逆に、何度か起動と終了を繰り返しているうちに、これで有効になって使えていた理由が謎でもある…。
実際は、guest additions or インストーラのバグが原因で共有フォルダがマウントできないってケースもあるようなので、何が原因か、素人には調べても限界があるかな。…ということで、しばらくは vboxsf グループにユーザーを追加する方法で、共有フォルダを利用していこうと思う。
以上、以下のページなどを参考にまとめてみました。
参考:http://vividcode.hatenablog.com/entry/virtualbox/shared_folder
http://rubellum.hatenablog.com/entry/20110508/1304835867
/media/sf_NAME
NAME は、ホスト OS 側で設定した 「名前」 の値。ただし、このディレクトリのアクセス権は、vboxsf ユーザーグループにのみ許可されているため、ファイルマネージャーで普通に覗こうとすると弾かれてしまう。それを知らなかったので、いつも sf_××× というフォルダができているのにアクセスできず不思議に思っていた。ゲスト OS 側の一般ユーザーから共有フォルダにアクセスするには、あらかじめそのユーザーを vboxsf グループに追加しておく必要があり、そのための書式が
sudo gpasswd -a ユーザ名 vboxsf
ということだった(らしい)。
したがって、VirtualBoxの共有フォルダの設定「自動マウント」にチェックしていると、システムの方では、「既にどこかにマウントしているぞ」と判断して、後からマウントしようとした操作をエラーとするらしい。そのため、
sudo mount vboxsf -t (共有フォルダ名) /media/マウント先
の記述は無視orエラーとなっていた可能性があり、何度もマウントできず悩んだ原因はここにあった様子…。でも、そうなると逆に、何度か起動と終了を繰り返しているうちに、これで有効になって使えていた理由が謎でもある…。
実際は、guest additions or インストーラのバグが原因で共有フォルダがマウントできないってケースもあるようなので、何が原因か、素人には調べても限界があるかな。…ということで、しばらくは vboxsf グループにユーザーを追加する方法で、共有フォルダを利用していこうと思う。
以上、以下のページなどを参考にまとめてみました。
参考:http://vividcode.hatenablog.com/entry/virtualbox/shared_folder
http://rubellum.hatenablog.com/entry/20110508/1304835867
2015年6月6日土曜日
Ubuntu 12.04 => 14.04 (32bit)
CaptureStream をインストールするために32bit版のUbuntu12.04をVirtualboxに入れていたが、仮想HDDの空きスペースを大きくできないかと思って、不要そうな(?)コンポーネントをアンインストールしたら、CaptureStreamがまたおかしくなってしまった(笑)。最初から、ダメになってもまた入れ直せばいい、くらいに思っていたので、想定内の事態だったが…。
ただ、Ubuntu自体のバージョンは、12.04である必然性もないので、14.04を入れてみることにした。もともと、64bit版を入れていて上手く保存できない、ってのが事の発端だったので、32bit版の方を…。しかし、やっぱり上手く保存できない…。ということで、一度、12.04を入れて、それをupdateしてみることにした。
結果は、正解。ただ、Virtualboxから起動させると最初「File not found.」が3行出て、「Press any key to continue...」となるようになってしまった。
何が起こっているのか…ということで、いろいろ調べてみたら、どうやらGRUBがおかしくなっているらしいとのこと。参考にしたのはここ。
> http://mitaka1954.cocolog-nifty.com/blog/2014/08/ubuntu-1204-140.html
Webページとの理由とは違って、updateの途中で「GRUB」をインストールしない、という画面が出てきて、変更できなかったような気がする(ダメならやり直せばいいやくらいの意識でやっていたので余りよく覚えていないが…笑)。多分、その辺りが原因だろう。
そこで、アドバイス(?)に従うとこんな風になった。
$ sudo grub-install /dev/sda
[sudo] password for xxxxx:
Installing for i386-pc platform.
Installation finished. No error reported.
これで正常に起動するようになり、万事解決。
ただ、Ubuntu自体のバージョンは、12.04である必然性もないので、14.04を入れてみることにした。もともと、64bit版を入れていて上手く保存できない、ってのが事の発端だったので、32bit版の方を…。しかし、やっぱり上手く保存できない…。ということで、一度、12.04を入れて、それをupdateしてみることにした。
結果は、正解。ただ、Virtualboxから起動させると最初「File not found.」が3行出て、「Press any key to continue...」となるようになってしまった。
何が起こっているのか…ということで、いろいろ調べてみたら、どうやらGRUBがおかしくなっているらしいとのこと。参考にしたのはここ。
> http://mitaka1954.cocolog-nifty.com/blog/2014/08/ubuntu-1204-140.html
Webページとの理由とは違って、updateの途中で「GRUB」をインストールしない、という画面が出てきて、変更できなかったような気がする(ダメならやり直せばいいやくらいの意識でやっていたので余りよく覚えていないが…笑)。多分、その辺りが原因だろう。
そこで、アドバイス(?)に従うとこんな風になった。
$ sudo grub-install /dev/sda
[sudo] password for xxxxx:
Installing for i386-pc platform.
Installation finished. No error reported.
これで正常に起動するようになり、万事解決。
2015年5月6日水曜日
CaptureStream(Linux版) 導入顛末
WindowsXPの時代、NHKの語学講座ファイルのダウンローダとして利用していたのがCaptureStreamだった。熱心な視聴者な訳ではないが、いつか勉強しようと思って、とりあえずファイルだけでも保存しておこうと思ったのがきっかけだった。
しかし、XPもupdateが打ち切られ、それに代わるプラットフォームに移行することが求められていたのだけど、7にインストールするのも大げさな気がして(?)、語学ファイルをダウンロードするためだけに、ずるずるとXPを使っていた。もっとも、virtualboxの中のXPなので、他にはあまり影響がないだろうと思ってのことだったが…。
第一候補は、同じvirtualboxに入っているUbuntu。そう思って昨年以来、何度かトライしてみても自分の利用環境ではダメだった(Ruby版は、解説ページを見つけ、その通りにインストールしたら無事動いていたが、Ubuntuネイティブで動くものを入れておきたかったので)。最初は、プログラムの起動すらせず。フォルダを工夫したりしてそのうち起動はするようになってもファイルのダウンロードで失敗。保存フォルダのアクセス権を見直したり、何かのパッケージが不足しているのかもしれない、と思って、いろいろ検索して、そのページで解説されているパッケージをインストールしたり…。数回トライしたが全滅であった。
参考にしたWebページではどこも、ダウンロードしたファイルを解凍するとすぐ使える、と説明されていて、どうして自分のシステムではダメなのか分からないばかり…。そのうち、CaptureStreamに同梱されいてるffmpegを64bitのものに上書きする、と説明のあるページを発見。同梱されているものは32bitとのことで、解説者のシステムが64bitなので、それに合わせて…という記述だった。それでハタと気がついたのが、14.04にupdateした段階で、hostOSがWindows7-64bitなので、Ubuntuも64bit版をインストールしていたこと。
そこでvirtualboxに新たに32bit版のUbuntuをインストール。それにCaptureStreamを入れ起動させてみた。すると、あんなに苦労していたダウンロードがすんなり成功!あの苦労は何だったのかと馬鹿らしいことこの上なし…の状態になった(笑)。
ここまでは自宅のデスクトップPCの話だったが、同じことだと思い単身赴任先のノートに同じく32bit版UbuntuとCaptureStreamを入れて起動。ところが、プログラムは起動するもののダウンロードに失敗。本体のページの注意書きで「ダウンロードに失敗する時は、libva1/libmp3lame0/libass4のインストールを確認」と記述があったので、
sudo apt-get install libva1:i386 などとインストール。それでも失敗…??。
よく考えたら、自宅のPCでは、32bit版にgnome-shellも入れていて、unityではなく、主にそちらを利用しているので、こちらにもgnomeの拡張パックを入れてみると、無事ダウンロードも成功。どのパッケージが不足していたのかは不明だが、とりあえず目的は達成したので詮索はしないことにする。
ちなみに今回、共有フォルダを起動時にマウントするのに使うrc.localファイルに
sudo gpasswd -a ユーザ名 vboxsf
という記述を追加しておくと、共有フォルダを開く時、アクセス権がないと怒られなくなった(笑)。
しかし、XPもupdateが打ち切られ、それに代わるプラットフォームに移行することが求められていたのだけど、7にインストールするのも大げさな気がして(?)、語学ファイルをダウンロードするためだけに、ずるずるとXPを使っていた。もっとも、virtualboxの中のXPなので、他にはあまり影響がないだろうと思ってのことだったが…。
第一候補は、同じvirtualboxに入っているUbuntu。そう思って昨年以来、何度かトライしてみても自分の利用環境ではダメだった(Ruby版は、解説ページを見つけ、その通りにインストールしたら無事動いていたが、Ubuntuネイティブで動くものを入れておきたかったので)。最初は、プログラムの起動すらせず。フォルダを工夫したりしてそのうち起動はするようになってもファイルのダウンロードで失敗。保存フォルダのアクセス権を見直したり、何かのパッケージが不足しているのかもしれない、と思って、いろいろ検索して、そのページで解説されているパッケージをインストールしたり…。数回トライしたが全滅であった。
参考にしたWebページではどこも、ダウンロードしたファイルを解凍するとすぐ使える、と説明されていて、どうして自分のシステムではダメなのか分からないばかり…。そのうち、CaptureStreamに同梱されいてるffmpegを64bitのものに上書きする、と説明のあるページを発見。同梱されているものは32bitとのことで、解説者のシステムが64bitなので、それに合わせて…という記述だった。それでハタと気がついたのが、14.04にupdateした段階で、hostOSがWindows7-64bitなので、Ubuntuも64bit版をインストールしていたこと。
そこでvirtualboxに新たに32bit版のUbuntuをインストール。それにCaptureStreamを入れ起動させてみた。すると、あんなに苦労していたダウンロードがすんなり成功!あの苦労は何だったのかと馬鹿らしいことこの上なし…の状態になった(笑)。
ここまでは自宅のデスクトップPCの話だったが、同じことだと思い単身赴任先のノートに同じく32bit版UbuntuとCaptureStreamを入れて起動。ところが、プログラムは起動するもののダウンロードに失敗。本体のページの注意書きで「ダウンロードに失敗する時は、libva1/libmp3lame0/libass4のインストールを確認」と記述があったので、
sudo apt-get install libva1:i386 などとインストール。それでも失敗…??。
よく考えたら、自宅のPCでは、32bit版にgnome-shellも入れていて、unityではなく、主にそちらを利用しているので、こちらにもgnomeの拡張パックを入れてみると、無事ダウンロードも成功。どのパッケージが不足していたのかは不明だが、とりあえず目的は達成したので詮索はしないことにする。
ちなみに今回、共有フォルダを起動時にマウントするのに使うrc.localファイルに
sudo gpasswd -a ユーザ名 vboxsf
という記述を追加しておくと、共有フォルダを開く時、アクセス権がないと怒られなくなった(笑)。
登録:
投稿 (Atom)