« 2012年11月 | トップページ | 2013年3月 »

2013年1月24日 (木)

Fedora 18をメディアなしでインストールする

内蔵ハードディスク内にあらかじめインストールされている Ubuntu 12.10 の GRUB を使って、Fedora 18 のインストール DVD(Live CD/DVD ではない)の iso イメージ内からインストーラーを起動する覚え書き。

Fedora 17 でも同じやり方で起動できることを確認している。

使用したマシンは MacBook Pro Mid 2010 13 inch (MacBookPro7,1) だが、普通の Windows マシンでも同じやり方が可能なはずである。

以下の作業は Ubuntu 上で行う。

  1. USB 外付け HDD のパーティションの一つを EXT4 でフォーマットし、「ext」というラベルをつける。この作業はパーティショニングツール「Gparted」で行った。
  2. ext パーティション内に「Fedora」というディレクトリを作成し、そこに、インストール DVD の iso イメージファイルをコピーする。※注1
  3. /boot ディレクトリ内に「install」というディレクトリを作成する。
  4. インストール DVD の iso イメージファイルをマウントし、「isolinux」ディレクトリ内から「vmlinuz」と「initrd.img」を「/boot/install」ディレクトリへコピーする。
  5. Ubuntu の GRUB の設定ファイルに、Fedora を起動するための記述を行う。そのためには「/etc/grub.d/40_custom」の中に
    menuentry "Fedora Install" {
        set root='hd0,gpt3' ※注2
        linux /boot/install/vmlinuz repo=hd:LABEL=ext:/Fedora ※注3
        initrd /boot/install/initrd.img
        }
    
    と書き加える。
  6. 「update-grub2」コマンドでいまの記述を GRUB に反映させる。
  7. コンピューターを再起動する。
  8. コンピューターに複数の OS がインストールされているなら、再起動時、いま作業をした Ubuntu をもう一度起動するようにする。Ubuntu が起動する過程で表示される GRUB の選択画面において、「Fedora Install」を選択する。すると、Fedora インストーラーが立ち上がるはず。

以上。


※注1
筆者の環境では Fedora 18 のインストーラーが起動の過程で内蔵 HDD をうまく認識しないという不具合があったので外付け HDD に iso を置いた。そのような不具合がない環境なら内蔵 HDD に置いてもかまわないだろう。


※注2
二行目の「hd, gpt3」の部分は、筆者の Ubuntu が一番目のハードディスクの三番目の GPT パーティションにインストールされていることを意味する。環境によって適宜書き換える必要がある。例えば二番目ディスクの七番目のパーティションなら「hd1,gpt7」になる。ハードディスクの番号は0を起点にしているが、パーティションのほうは1が起点である。

なお、GPT パーティションではなく、MBR パーティションの場合はまた別の記述になるはずだが、筆者は把握していない(インストールされている Ubuntu の GRUB の記述を参考にすればよい)。


※注3
「repo=」以下で iso の置かれたパーティションを指定しているが、筆者はその際、ラベルで指定した。これは、筆者の環境では外付け HDD のデバイス名が起動のたびに「sdb」になったり「sdc」になったりして一定しなかったためである。もし一定しているならデバイス名で

repo=hd:/dev/sda3:/Fedora

などと指定することも可能である。特に、注1で述べたように内蔵 HDD に置いた場合はわざわざラベルをつけるまでもなく、デバイス名で指定したほうがいいだろう。


なお、くれぐれも「:」(コロン)が二つあることを見落とさないように。

説明しておくと、「hd:デバイス名:ディレクトリ名」となっており、この場合のディレクトリ名は iso ファイルを内包しているディレクトリである。ディレクトリ名だけを指定すればよく、iso ファイル自体は指定する必要がない。パーティションのトップレベルに置かれている場合は

repo=hd:/dev/sda3:/

のようにスラッシュで終える。なお、このパーティションは VFAT でフォーマットされたものでもよく、その場合は

repo=hd:D¥:/Fedora

などと Windows のドライブ名で指定する(但し、ディレクトリ名のほうはバックスラッシュではなく普通のスラッシュで区切らなければならない)とのことだが、筆者はこのやり方は試していない。

2013年1月21日 (月)

MacBook Pro 13-inch Mid 2010+Fedora 18で無線LAN[更新]

前回の記事で述べたように、MacBook Pro (13-inch, Mid 2010) に Fedora 18 をインストールすると無線 LAN (broadcom4322)が有効にならない。Fedora 17 以前は rpmfusion の nonfree レボジトリーから「kmod-wl」パッケージをインストールすればそれだけで有効になったが、18 ではそれだけではうまくいかなかったのである。

数日間の試行錯誤の末、有効化に成功した。うまくいかなかったのは次の三つ要因による。

  • Fedora 18 起動時に「wl モジュール」が自動でロードされない。
  • 「wl モジュール」がロードされたとしても「ssb モジュール」とコンフリクトを起こす。
  • コンフリクトを避けるには「ssb モジュール」をロードさせないようにする必要があり、そのためには「/etc/modprobe.d/」ディレクトリ内で「blacklist ssb」と指定すればよいはずなのに、それが機能しない。

一つ目の点について、起動時にモジュールをロードさせるには「rc.local」ファイル内に「modprobe wl」と記述すればよいとのこと。

三つ目の点についてだが、本来、「kmod-wl」パッケージをインストールした時点で「/etc/modprobe.d/」ディレクトリ内に blacklist ファイルが作られるのでロードされなくなるはずなのに、それがうまく機能していないようだ。ウェブ情報では grub のカーネルパラメーターで blacklist を指定する方法などが紹介されていたが、筆者はもっと簡単に、「rc.local」ファイルで wl をロードするついでに ssb をアンロードする方法をとることにした。

rc.local ファイルは存在しないので、新規作成する必要がある。

$ sudo vi /etc/rc.d/rc.local

rc.local
#!/bin/sh

modprobe -r ssb
modprobe wl

そして、rc.local に実行権を与える。

$ sudo chmod 700 /etc/rc.d/rc.local

以上で、次回の起動時から無線 LAN が有効になる。


[更新]2013/01/27

カーネルを 3.7.4-204 にアップグレードし、kmod-wl もそれに対応したバージョンにアップグレードしたところ、上記の不具合は解消された。rc.local がなくても正常に無線 LAN が機能するようになった。

2013年1月17日 (木)

MacBook Pro 13-inch Mid 2010にFedora 18をインストール[更新]

実は、Alpha 版の頃から何度か MacBook Pro (13-inch, Mid 2010) への Fedora 18 のインストールを試みていたのだが、Live DVD を MBR 起動しようとすると、途中で止まってしまい、起動できないという問題を抱えていた。残念ながら、この問題は Fedora 18 の正式リリース版でも解消されなかった。

(この問題は、おそらく Mac の内蔵 HDD を五つ以上のパーティションに分けている場合にのみ起こると思われる)

ということは、Live DVD を EFI 起動せざるを得ないが、そうするとインストーラープログラムが強制的に Fedora の GRUB を EFI にインストールしてしまい、MBR にはインストールできなくなる(できるようにする方法があるのかもしれないが、筆者は把握していない)。

必然的に、今回は EFI インストールを選択するしかないということになる。これまでは MBR インストールした上で Windows 8 の Bootmanager で起動するという方法をとっていたが、今回は(とりあえず)あきらめるしかないようだ。(追記2013/01/24:MBR 起動の方法が判明した。文末参照)

EFI インストールの方法は当ブログの過去記事「Mac+外付けHDDにFedora 17をインストール」で述べたのとほぼ同じである。

但し、Fedora 17 の Live CD は Mac の EFI で直接起動できたのに、18 ではなぜかそれもできなくなっている。そのため、USB メモリーにインストールした rEFIt を用いて、そこから Live DVD を起動する必要がある。

インストールに際しては、上記の記事でも述べているように、Fedora を Mac の EFI から起動させるための特別な HFS+ パーティションが必要である。好都合なことに、MacBook Pro (13-inch, Mid 2010) の内蔵 HDD の一番後ろには 128 MB ほどの空きスペースが取られていた(Mac OS X のディスクユーティリティ.app で HDD を HFS+ でフォーマットするとパーティションの間にそのような空きスペースができることが多い)ため、それを利用して Fedora 18 起動用の HFS+ パーティションを作ることにした。この作業は GParted Live CD で行った。そのパーティションのサイズは 64 MB とした。

その結果、筆者の MacBook Pro は以下のようなパーティション構成となった。

  • sda1 …… EFI 領域
  • sda2 …… Bios Boot (FAT32)
  • sda3 …… Ubuntu (EXT4)
  • sda4 …… Windows 8 (NTFS)
  • sda5 …… Linux Swap
  • sda6 …… Fedora 18 (EXT4)
  • sda7 …… Mandriva 2011 (EXT4)
  • sda8 …… Mac OS X Snow Leopard
  • sda9 …… Fedora Boot 用(HFS+。64 MB。新規作成)

Fedora 18 からはインストールプログラム「anaconda」の仕様が大きく変わっている。詳細はここでは述べないが、インストールの際、パーティションを指定する段階で、sda9 を「/boot/efi」と指定すれば、インストールを進めることができる。

インストール自体は問題なく終了した。

しかし、無線 LAN がなぜか有効にならないという問題が生じた。ハードウェア自体が認識されていないようだ。17 までは rpmfusion の nonfree レポジトリから「kmod-wl」というパッケージをインストールすれば有効となったが、18 ではそれがうまくいかない。現在、解決策を模索中である。判明したらここに追記するかもしれない。

(追記)
MacBook Pro (13-inch, Mid 2010) の無線 LAN チップは ハードウェア的には Fedora 18 に認識されている(lspci -nnk で調べると表示される)。ということは、やはりドライバーの問題のようだ。kmod-wl ではなく、akmod-wl のほうでも試したが、やはりうまくいかなかった。ウェブ情報によれば、deb 用のドライバーをコンバートして使うという方法があるという。だが、そのやり方は複雑なので、引き続き別の方法を模索する。


(追記2013/01/21)
無線 LAN の問題は解決した。詳細は次回の記事で述べている。


(追記2013/01/24)
Fedora 18 の DVD を MBR 起動させる方法がわかった。起動時のカーネルパラメーターに「acpi=off」と指定すればよい。具体的には、

  1. Fedora DVD を MBR 起動する(option キーを押しながら Mac を起動すれば表示される「OS 選択画面」上で「Windows」と書かれた CD の形のアイコンを選択する)。
  2. しばらくしたら Fedora 18 のブート選択画面が現れるので、Tab キーを押す。
  3. 画面の下のほうに「vmlinuz」で始まる文字列が表示されるはず。その最後に更に「acpi=off」と書き加える。この時、キーボード配列が日本のものになっていないので、= を打つには数字の 0 の二つ右隣(「へ」キー)を押す必要がある。
  4. return キーを押してブートする

という手順を踏む。

ところが、そのようにして MBR 起動してこれまで通りインストールを進めることができるかと思いきや、別の問題が生じた。

Fedora 18 のインストーラーではなぜか、GRUB を任意のパーティションの先頭にインストールすることができないのである。いろいろ調べたが、どうもそういうオプションが存在しないようだ。

仕方なく、GRUB は一旦、MBR にインストールし、あとで Fedora をインストールしたパーティションの先頭にインストールし直した後、Windows で MBR を修復するという方法をとることにした。

(個人的には、過去に MBR の修復に失敗して Windows を再インストールするはめになったことが何度かあり、そうなってしまうと、Windows 環境を一から再構築せねばならず、非常に手間がかかるため、できればこんなやり方は避けたいのが本音である。次期 Fedora では修正されていることを願う)

以上の結果、Fedora 18 も 17 以前と同様、MBR インストールして Windows 8 の Bootmanager で起動することに成功した。上記のパーティション構成リストに掲載されている sda9 は不要となったので削除した。


(追記2013/01/27)

上記のやり方で MBR インストールした Fedora 18 は、当然ながら、カーネルパラメーターに acpi=off を付けないと起動ができない。また、画面表示の解像度は 1280 x 800 では表示されず、1024 x768 になってしまう。

だが、カーネルを 3.7.4-204 にアップグレードすれば、それらの問題はすべて解決する。acpi=off も必要なくなるし、1280 x 800 表示も可能になる。

2013年1月11日 (金)

メモ.app 1.1で項目が重複するのを回避する

(注意:この記事は Mountain Lion 10.8.2 に付属している「メモ.app 1.1」について書かれている。今後、メモ.app がバージョンアップした場合、以下の問題は解決されている可能性がある)

Mountain Lion から標準装備されるようになったメモ.app を愛用しているが、残念なことに、現時点(Mountain Lion 10.8.2、メモ.app 1.1)では iCloud などと同期するように設定している場合、メモ項目が重複することがある。

これは、メモ.app がサーバーと同期しようとしている時にメモ.app を終了させてしまった時に起こるようだ。ではどうしてそのような事態が頻発するのかというと、メモ.app の自動アップデート機能に原因がある。

メモ.app は、メモ内に何かを書き込んだらすぐさま自動でアップデートする仕様になっているが、その他にも、メモ.app がアクティブになる(要するにメニューバーの左端、リンゴマークのすぐ右に「メモ」と表示されている状態になる)たびに自動アップデートが行われる。これがくせ者である。

どういうことかというと、メモを書き終えてしばらくして、何か他の作業をしている途中に、「あ、メモ.app はいま使わないから終了させよう」と思い立ち、メモ. app をアクティブにして command + Q で終了、もしくはメニューバーから「終了」させたとしよう。すると、メモ.app がアクティブになった時点でアップデートをはじめてしまうため、その直後に終了させることによって、アップデートの中断が生じ、結果的に、アップデートが不完全だった項目はローカルディスクに保存されてしまい、サーバーのものと重複するという事態が起こるのである。

なので、これを回避するには、メモ.app を終了させる前にアクティブ状態のまま30秒ほど待つとよい、ということになる。

だが、それでは30秒もの間、パソコンの前で何もせずにじっと座っていなければならない(笑)。他の作業が何もできないのである。「効率を上げてなんぼ」のコンピューターにとって、致命的とは言わないまでも、大きな支障なのは確かだ。

そこで、筆者は以下のようにして解決している。

メモ.app に何かを書き込んだら、とりあえずメモ.app を「隠す」(command + H、もしくはメニューバーの「メモ」→「メモを隠す」)。そして、しばらくしてメモ.app を終了させようと思い立ったら、アクティブにはせず、command + tab を押して「アプリケーションスイッチャー」を表示して、tab を連打してメモ.app アイコンを選択、そして command キーは押したまま tab キーだけを離して Q キーを押す。そうすれば、メモ.app が「隠れた」状態のまま終了させることができる。アクティブにしないことによって、自動アップデートが始まるのを避けるのである。

メモ.app に何かを書き込んですぐに終了したいという場合も、一旦「隠」しておき、他の作業を行いながら30秒ほど待って、それから上記のやり方で終了させる。

もしメモ.app をフルスクリーンで使用しているなら、「隠す」ことはできないので、メモ.app 以外のスペースに移動し、そこで何か作業をしながら30秒ほど待った後に、上記のやり方でアプリケーションスイッチャーによって終了させるとよい。

あるいは、アプリケーションスイッチャーではなく、Dock 上のメモ.app アイコンを control クリック(もしくは右クリック)して終了させてもよい。

このようにすれば、決して重複は起こらない。筆者がこれまで体験した限りでは、一度も重複は起きていない。まぁ、それでもあまりスマートな方法とはいえないが(苦笑)。

今後のバージョンアップで、重複問題がもっとスマートに解決されるよう願っている。

« 2012年11月 | トップページ | 2013年3月 »