カテゴリー「ubuntu linux」の記事

2013年4月28日 (日)

Mac+外付けHDDにUbuntu 13.04をインストール

以前、「Mac+外付けHDDにUbuntu 12.04をインストール」の中で MacBook Pro (mid 2010, 13 inch) に接続した USB 外付け HDD 内に Ubuntu をインストールする場合について述べたが、その時は「GRUB は内蔵 HDD の EFI 領域にインストールされる」と結論づけていた。

先日、Ubuntu 13.04 がリリースされたため、外付け HDD にもインストールを試みた。その過程で、GRUB を外付け HDD にインストールできないかどうか試したところ、工夫すればできることがわかった。

GRUB を 外付け HDD にインストールすれば、内蔵 HDD を「汚さず」に済む。

また、場合によっては、その外付け HDD を別の Mac に接続して起動することも可能になる(※同じ会社のグラフィックチップを使用していることが条件。筆者が現在所有する Mac は二台とも NVIDIA なので可能)。

但し、インストールされた Ubuntu を起動するには、やはり rEFIt もしくは rEFInd が必要である。option キーを押しながら Mac を起動することによって表示される「OS 選択画面」から直接起動できるようになるわけではない(ちなみに、Fedora は直接起動が可能。「Mac+外付けHDDにFedora 17をインストール」を参照)

なお、以下に掲載するスクリーンショットは Xubuntu のものだが、インストーラープログラム自体は Ubuntu も Kubuntu も Xubuntu も Lubuntu も同じなので、そのいずれをインストールする場合であっても以下の記述が適用できる。

続きを読む "Mac+外付けHDDにUbuntu 13.04をインストール" »

2013年4月27日 (土)

MacBook Pro 13-inch Mid 2010にUbuntu 13.04をインストール

例によって例のごとく、MacBook Pro (13-inch, Mid 2010) に Ubuntu 13.04 64 bit 版をインストールする。

注意点として、Ubuntu 13.04 ではなぜかデフォルトではサウンドが鳴らなくなっている。10.10 ?以前のように特別な設定が必要(後述)。

今回も敢えて EFI インストールではなく、MBR インストールする。そのためには、インストール DVD を起動する際、option キーを押したまま Mac を起動することによって表示される「OS 選択画面」において、「Windows」という名の CD-ROM 形アイコンを選択する(「EFI Boot」という名のアイコンを選択すると EFI 起動になってしまうので、必ず「Windows」のほうを選択する。

また、そのまま起動すると画面が乱れたり、場合によってはフリーズしたりするため、起動時にカーネルパラメーターに「nomodeset」を付けたほうが良い。

パーティション構成は以下の通り。sda1 は EFI 領域なので省略する。いつものように Ubuntu は sda3 にインストールする。その際、「bios boot 領域」と呼ばれる小さな領域が必要。サイズは 1 MiB でよいが、必ず sda2 〜 sda4 でなければならない(sda5 以降に置いてはならない)。

sda2 …… bios boot
sda3 …… Ubuntu 13.04 <-- ここにインストール
sda4 …… Windwos 8 64bit
sda5 …… Linux swap
sda6 …… Fedora 18
sda7 …… openSUSE 12.3
sda8 …… Mac OS X Snow Leopard 10.6.8

ブートローダーは例によって Windows の ブートマネージャーを使用するので、 GRUB は sda3 にインストールする。

インストール終了の後、Ubuntu をブートマネージャーで起動するための設定を行う。まず Fedora で再起動し、Windows 8 のパーティション(「BOOTCAMP」というラベルがついている)をマウントして、sda3 の先頭 512 バイトを ubuntu.img という名前で書き出し、BOOTCAPT パーティションに置く。

$ sudo dd if=/dev/sda3 of=/run/media/hogehoge/BOOTCAMP/ubuntu.img bs=512 count=1

のような感じになる。次に、Windows を起動して、管理者権限のあるコマンドプロンプトで bcdedit を用いてブートマネージャーの設定を行う。ここではその詳細は述べない。

ブートマネージャーの設定の後、MacBook を再起動し、ブートマネージャーで Ubuntu を起動する。

Wi-Fi(無線LAN)を有効化する。そのためには broadcom-wl ドライバーをインストールする必要があるが、GUI の「追加のドライバー」からインストールすることができないので、インストールに使用した DVD の中から

「pool/main/d/dkms/dkms.....deb」
「pool/main/f/fakeroot/fakeroot.....deb」
「pool/restricted/b/bcmwl/bcmwl.....deb」

という三つのパッケージを取り出して一つのディレクトリ内に置き、手動で

$ sudo dpkg -i *.deb

のような感じでインストールする。

グラフィックドライバーに関しては、デフォルトでは「Nouveau」ドライバーが有効になっているが、それでは表示が乱れることが多いので、GUI の「追加のドライバー」から NVIDIA ドライバーをインストールする。

なお、GUI の「追加のドライバー」を起動するには、以下の手順を踏む。

  1. 画面右上の「歯車形アイコン」をクリック →「システム設定...」を選択。
  2. 「システム」セクションの「ソフトウェアとアップデート」をクリック。
  3. 20秒くらい待つ(苦笑)と「ソフトウェアとアップデート」ウィンドウが表示される。
  4. 「追加のドライバー」タブをクリック。

サウンドは、「/etc/modprobe.d/alsa-base.conf」の末尾に「options snd-hda-intel model=mbp55」 と書き加えることで鳴るようになる(要再起動)。


2012年7月29日 (日)

自宅の無線ルーターのアクセスポイントが見つからない

以前から、Fedora と Ubuntu で自宅の無線ルーターに接続しようとすると、近所の家のアクセスポイントは表示されるのに自宅のアクセスポイントは表示されないという不具合があった。同じコンピューター (MacBook Pro) にインストールされている Windows 7 と Mac OS X Snow Leopard と Mandriva Linux では表示されるものの、なぜか Fedora (15?〜17) と Ubuntu (11.04? 〜 12.04) では表示されないのである。

無線ルーター (プラネックスコミュニケーションズ社製のMZK-W300NH3) を再起動したり、設定をいろいろいじったりしているうちに、いつの間にか表示されるようになったことはあったが、何をどうしたら見つかるようになるのか、そもそも何が原因なのかは特定できず、途方に暮れていた。

ところが昨日、検索サイトで検索してみると、とあるサイトに一般論として「アクセスポイントのチャンネルが他のルーターと競合している可能性がある」という記述を見つけた。

そういえば、ずっと以前にも同じような問題を抱えて、チャンネル設定で直ったことがあったのを思い出した。

そこで、正常に無線ルーターにつながっている別のコンピューターのウェブブラウザで無線ルーターの設定画面を表示して、チャンネル設定が「自動」になっているものを「2」に合わせてみたところ、たちどころに MacBook Pro 上の Ubuntu にもアクセスポイントが表示された。Fedora で起動しても、ちゃんと表示されることが確認された。

筆者の自宅は近所に住宅が建て込んでいる関係上、無線LAN設定プログラム上にはかなりの数のアクセスポイントが表示される。その上、新幹線の高架線路もすぐ近くを通っているため、新幹線が通過するたびに車内の無線LANアクセスポイントまで自宅に届いてしまう。そのような環境ゆえに、チャンネルの競合が通常よりは幾分起こりやすいのではないかと推測される。

なお、ウェブ情報によると、日本で使われているチャンネルは1〜13で、そのうち1と4と7と13はよく使われるとのこと。筆者がチャンネルを2に合わせたのは、それらのチャンネルをさけたためである。

ただ、なぜ Fedora と Ubuntu だけがそのような不具合を生じたのかはよくわらかない。チャンネルを手動で2に合わせる前は、自動設定により13になっていたことを確認している。もしかしたら、Fedora と Ubuntu の無線LAN接続プログラムはチャンネル13を認識しないのかもしれない。

2012年6月10日 (日)

Mac+外付けHDDにUbuntu 12.04をインストール

Fedora 17 に引き続き、MacBook Pro mid 2010 13 inch に 接続した USB 外付けハードディスクに Ubuntu 12.04 64bit 版(amd64)をインストールできないかどうか試したところ、EFI で起動するようにすればうまくインストールできることがわかった。

筆者はこれまでにも何度か Fedora や Ubuntu を EFI で起動するようにインストールできないか試したことがあったが、うまくいかなかった。おそらく GRUB が Mac の EFI にちゃんと対応していなかったのだろう。

だからと言って外付け HDD に MBR 起動でインストールしてしまうと、起動が不可となるケースがほとんどだった(Ubuntu では一応成功していたが、Fedora は起動できなかった)。

だが今回、いくつかの Linux ディストリビューションで EFI 起動でのインストールを試したところ、どうやら以前に比べると Mac の EFI への対応度が上がったらしく、起動が可能となっていた。

ということは、おそらく外付け HDD だけでなく内蔵 HDD に対しても EFI インストールは可能なのだろう。とりあえず今回は外付け HDD への EFI 起動インストールを試みるにとどめ、内蔵 HDD への試みはまた後日とする。

以下に、Ubuntu 12.04 を Mac の USB 外付け HDD に EFI インストールする場合の要領を述べる。

前提条件

まず外付け HDD は「GUID パーティション」としてフォーマットされていなければならない(と思う。もしかしたら MBR でフォーマットされていても可能なのかもしれないが試していない)。

次に、USB メモリに rEFIt をインストールしておかなければならない。Fedora 17 と違い、Ubuntu 12.04 amd64 は Mac の EFI に特別な対応を行っていないので、rEFIt が必要。USB メモリへのインストールの方法についてはここでは述べないので他の情報源を参照してください。

もう一つ、インストール CD (Live CD) 自体を EFI で起動しなければならない。そのためには Mac を起動の際 Option を押し続けることで表示される「OS 選択画面」において、「EFI Boot」という名前の CD-ROM 型アイコンを選択する(この時、「Windows」という名前の CD-ROM 型アイコンを選択すると MBR 起動してしまい、そのままインストールを行うと、インストールされた Ubuntu は EFI 起動できない)。

インストール

インストールの手順そのものは、これまでに何度も行った「MBR インストール」の場合と同じである。ただ、ブートローダーのインストール場所として「sdb(外付け HDDのデバイス名)」を選択しても、sda(内蔵 HDD)の EFI 領域にインストールされる。

ブート

インストール終了後、実際に Ubuntu 12.04 がインストールされた HDD からブートするには、先ほど述べたように rEFIt が必要。Mac の起動時に Option キーを押したままにすれば「OS選択画面」が表示される。そこで rEFIt の USB メモリを差してしばらくすると、画面に「rEFIt」という名前のアイコンがあらわれるのでそれを選択する。すると、また同じような選択画面があらわれるが、そこには「品」の字に似たアイコンに「Boot EFI\ubuntu\grubx64.efi from EFI」という名前のついた項目が表示されるので、それを選択すれば起動できるはず。

Fedora 17 と違い、Ubuntu 12.04 の場合は内蔵 HDD に GRUB がインストールされるため、Ubuntu がインストールされた外付け HDD を別の Mac につないでも Ubuntu を起動することはできない。


なお、Ubuntu が不要となり、HDD から消去したとしても、EFI 領域にインストールされた Ubuntu の GRUB は残ってしまう。

残っていても支障はないが、どうしても削除したい場合は、rEFIt に付属している EFI Shell を使う。以下にその方法を説明する。

EFI Shell の起動

rEFIt の OS 選択画面の下段にはディスプレイの形をした一回り小さなアイコンがあるので、それを選択すれば、Shell が起動する。

EFI パーティションのデバイス名を調べる

まず、デバイス名が列挙されたリストが表示されるが、スクロールさせることができない。そこで、「map -b」というコマンドを打ち込むと、スクロールさせることのできる形で表示される。

リストで EFI 領域のデバイス名を探す。おそらく fs0 という名前になっている。

EFI パーティション内へ移動

そこで「fs0:」と打って fs0 内に移動する。その際、EFI Shell 上では日本語キーボード配列が有効にならないため、:(コロン)を打つには L (エル) の右隣のキーをシフトと同時に押す必要がある。

GRUB を削除

fs0 内に移動すれば、あとは DOS コマンドや bash コマンドと似たようなコマンドが使える。ls もしくは dir コマンドでファイルを表示、cd でディレクトリ移動、rm ディレクトリ名 でディレクトリを削除、などである。

Ubuntu の GRUB は fs0 内の EFI\ubuntu ディレクトリ内にある。ubuntu ディレクトリごと削除すれば GBUB も削除される。バックスラッシュを打つには L (エル) の三つ右隣にある「む」キーを押す。

EFI Shell を終了

exit コマンドで Shell から抜けることができる。

2012年2月 2日 (木)

Thunderbird 10.0でiCloudメールを使う[HowTo]

これまで iCloud メールを Thunderbird で送受信するには、特別なアカウント設定とフォルダ設定が必要だったが、その後、 iCloud メールに一応の対応が行われたらしく、アカウント設定に関してはデフォルトのままで可能となったようだ。

一方、フォルダ設定に関しては、以前のように送信がうまくいかないということはなくなった。しかしながら、現在でも Thunderbird の認識するフォルダ名と iCloud メールのフォルダ名が異なっているため、送信済みメールや削除済みメールは iCloud メールの「送信済み」フォルダや「ゴミ箱」フォルダには入らず、「Sent」「Trash」という別のフォルダが勝手に作成されてそこに入ってしまうことになる。

ただ、それでも送信は問題なく行えるので、他の iOS デバイスや他のメールクライアントとの同期を行わないのであれば、フォルダ設定はどうしても必要というわけではない。

だが、もし同期を前提にしており、 Thunderbird のフォルダと iCloud メールのフォルダを一致させたいというのであれば、フォルダ設定を行う必要がある。

以下に掲載するのは Thunderbird 10.0 で iCloud メールを使う場合の設定である。今後、Thunderbird もしくは iCloud がバージョンアップされた場合、以下とは異なる可能性がある。

続きを読む "Thunderbird 10.0でiCloudメールを使う[HowTo]" »

2011年10月29日 (土)

Thunderbird 7.01でiCloudメールを使う

iCloud メールは OS X の Mail.app および iOS (iPhone / iPad / iPod touch) のメールアプリと一体化されており、それらのデバイス内で iCloud アカウントを設定すればほぼ自動的にメール設定が完了する(但し OS X 10.7.2 以降、iOS 5 以降が必要)。また Windows でも「iCloud コントロールパネル」がインストールされていれば Outlook での送受信に完全対応する(Outlook 2007 以降)。

更に、その他のメールクライアントでの送受信のためのサーバー設定情報もアップル社によって公開されている。だが、その他のメールクライアントでの送受信は特別な設定を要する場合が多い。

以下に掲載するのは Thunderbird 7.01 で iCloud メールを使う場合の設定である。今後、Thunderbird もしくは iCloud がバージョンアップされた場合、以下とは異なる可能性がある。

(追記:その後、バージョンアップにより事情が変わった。「Thunderbird 10.0でiCloudメールを使う」を参照。以下の情報は役に立たないのでご注意を)

続きを読む "Thunderbird 7.01でiCloudメールを使う" »

2011年3月 8日 (火)

MacBook Pro (Mid 2010) 13inchにUbuntu 10.10をインストール

MacBook Pro (Mid 2010) 13inch に Ubuntu 10.10 をインストールしてみた。同じ日にインストールした Fedora 14 は5つの問題を生じたが、Ubuntu 10.10 のほうは2つしか問題が起きなかった。

一つ目は Fedora 14 と同様、音が鳴らない問題。これは、以前に Mac mini (Early 2009) に Ubuntu 10.10 をインストールした時と同様の方法で解決できた。すなわち、/etc/modprobe.d/alsa-base.confに「options snd-hda-intel model=mbp55」という一行を書き加えたのである。Mac mini の場合は「model=mb5」だったが、MacBook Pro (Mid 2010) 13inch では「mbp=55」になることを事前にウェブ情報で入手していた。

二つ目もの問題は、これも Fedora 14 と同じく、 再起動ができないことである。この問題は今のところ解決方法がわからない。時間があれば、これからもウェブ情報をあたってみるつもりである

(3月9日追記)
再起動できない問題の解決方法がわかった。こちらの記事によると、/etc/default/grub というファイルの「GRUB_CMDLINE_LINUX=""」という部分を「GRUB_CMDLINE_LINUX="nomodeset reboot=pci"」と書き換えて update-grub コマンドを実行すれば、次回の起動時から再起動ができるようになる、とのことだ。

2011年3月 7日 (月)

MacBook Pro購入、クワッドブート

サブマシンとして MacBook Pro Mid 2010 13 inch を購入し、Mac mini Early 2009 と置き換えた。サブマシンには Windows と Fedora と Ubuntu と Mac OS X をインストールしてクワッドブートすることにしているので、今回も MacBook Pro にそれらのインストールを試みる。

(3月21日追記:以下の記述はあくまでクワッドブートを前提としているので、MacBook Pro に Windows 7 だけをインストールしたいという方は参考にしてはならない。Windows 7 をインストールするだけなら「Boot Camp アシスタント」を使用することでいとも簡単にインストールすることが可能である。MacBook Pro (Mid 2010) の Boot Camp は正式にWindow 7 64bit 版に対応している)

商品到着後、初期不良確認を済ませるや否や、すぐさまターゲットディスクモードにしてメインの iMac にFirewire 800で接続、ディスクユーティリティを起動し、MacBook Pro の Mac OS X を保存するために HDD の内容を dmg イメージ化して iMac に保存する。

次に、iMac に Ubuntu 10.10 の Live CD を入れて Ubuntu で起動。Ubuntu の パーティショニングソフト Gparted で MacBook Pro の HDD を切り分ける。

かつて、Mac mini でクワッドブートを構成した時、ウェブ情報をあたってみると、y2blog さんが詳しい記事を掲載されており、それによると「Windows は四つ目のパーティションにインストールしなければならない」とのことだった。そこで

sda2 …… 10GB EXT4
sda3 …… 10GB EXT4
sda4 …… 150GB NTFS
sda5 …… 5GB linux-swap
sda6 …… 75GB FAT (Mac OS X 用)

のようにパーティション分けした(sda1 は EFI のまま変更せず)。

なお、なぜ Mac OS X の ディスクユーティリティを使わずに Gparted を使うのかと言えば、ディスクユーティリティでパーティション分けをするとパーティションの間に未使用領域ができてしまうことが多いからである。たかだか数百MBの未使用領域にすぎないが、何となくいやなのである(苦笑)。

次に、iMac を Mac OS X で起動し、ディスクユーティリティで MacBook Pro の 六番目のパーティションを HFS+ journaling でフォーマットしてそこへ上記の dmg を復元する。

復元後、 Firewire ケーブルを抜き、 MacBook Pro を Mac OS X で起動、復元が成功したことを確認する。 MacBook Pro に Windows Vista のインストールディスクを入れて再起動、option キーを押して ディスクから起動する。

ところが、Vista のインストールがどうもうまくいかない。途中で再起動するところで、BOOTMGR がないと言われて止まってしまうのである。Windows 7 のインストールディスクに変更して試みたものの、それでも止まってしまった。

そこでもう一度、 y2blog さんの記事を Google で探して参照してみたところ、ただ四つ目のパーティションを Windows 用にすればよいのではなく、二番目と三番目は HFS+ でなければならないことがわかった。Mac mini をクワッドブート化した時には留意していたのに、今回は久々だったので、その事実をどうやら失念していたようだ。

すぐに sda2 と sda3 をHFS+ に再フォーマットする。Ubuntu Live CD の Gparted では HFS+ にフォーマットすることはできないので、仕方なく、前のサブマシンの Mac mini (Ubuntu がインストールされている) にターゲットディスクモードでFirewire 接続して、Mac mini の Ubuntu に Gparted と hfsprogs (HFS+ を扱えるようにするパッケージ) を apt-get install し、それらを用いて MacBook Pro のパーティションを

sda2 …… 10GB HFS+ (フォーマット)
sda3 …… 10GB HFS+ (フォーマット)
sda4 …… 150GB NTFS (変更せず)
sda5 …… 5GB linux-swap (変更せず)
sda6 …… 75GB HFS+ (変更せず)

とした。

しかし、その上で Vista のインストールに再チャレンジしたものの、今度は Vista のインストーラーが ディスクをうまく認識してくれず、sda4 をフォーマットしても「インストールできる領域がない」という意味のメッセージが出て前に進まない。そのため、また Windows 7 64bit 版のほうでチャレンジしてみたところ、今度こそようやくインストールに成功した。

その後、sda2 に Fedora 14 を、sda3 に Ubuntu 10.10 をインストールし、無事終了。クワッドブート化に成功した。 MacBook Pro Mid 2010 13 inch における Fedora 14 と Ubuntu 10.10 のインストールについては別記事で述べることにする。

なお、MacBook Pro Mid 2010 13 inch における Windows 7 SP1 64bit 版の動作状況についてだが、起動時に音声がミュートされてしまうという問題が起こっており、今のところ解決方法は見つかっていないものの、それ以外に関しては全く問題ない(2011年3月27日追記:音がミュートされる問題は解決した。→MacBook Pro+Win7で音がミュートされる問題を解決)。2D ネットワークゲーム (MMORPG) の REDSTONE も、64bit 環境でもちゃんと動作している。エクスペリエンス インデックスのスコアは (Bootcamp ドライバー 3.2をすべてインストールした上で) 5.3 となっている。

(追記)
Fedora 14 と Ubuntu 10.10 は、これまでと同様、rEFIt ではなく、Windows 7 の bootmgr でブートしている。
Boot

2010年5月 5日 (水)

Mac mini Early 2009+Ubuntu 10.04でサウンドを鳴らす

Mac mini Early 2009にUbuntu 10.04をインストールしたところ、サウンドが鳴らなかった(調べたところ、この機種はHDA Nvidiaというサウンドチップを搭載しているらしい)。

だが、ここら辺を参考にして/etc/modprobe.d/alsa-base.confに

options snd-hda-intel model=mb5

と書き加えて再起動してみると、鳴るようになった。

但し、どういうわけか、一度目の再起動では画面表示が低解像度となった。そこでもう一度再起動したところ、音にも画面にも問題はなくなった。

2010年4月30日 (金)

Ubuntu 10.04のSambaではMacのメタデータつきファイルが書き込めない

Ubuntu 10.04マシンでSambaサーバーを起動し、Mac OS X Snow Leopard上のファイルをSmabaクライアントを通してUbuntu側へ移そうとしたところ、なぜか一部のファイルが書き込めなかった。

いろいろ調べたところ、メタデータがついているファイル(つまりMac側で「ls -l@」コマンドで表示した時に「@」がついているファイル)だけが書き込みに失敗していることがわかった。

Ubutnu 9.10まではこのようなことはなかったので、10.04でSambaに何らかの仕様の変更があったのかもしれない。/etc/samba/smb.confをいじれば直る程度のものなのかどうか、今のところ不明。

とりあえずMacからUbuntu 10.04マシンにSambaでファイルを移す時は、MacのFinderであらかじめzipに圧縮しておくのが一番簡単だと思う。

(10年5月30日追記)
よくよく調べてみると、Fedora 13でも同じような現象が起きることがわかった。どうも、Linuxの側ではなく、Mac OS X 10.6.3のsambaクライアントの側に問題があるような気がしてきた。

(10年6月16日追記)
Mac OS Xを10.6.4にアップグレードしたら直った。やはり、Linuxの側ではなく、Mac OSのSambaクライアントの問題だったようだ。