コンテンツへスキップ

UEFIでWindows/Linuxのデュアルブート環境構築

最近はLinux環境を仮想PCで構築して使っていましたが、ホストOSの上で動作するのでどうしてもパフォーマンスが劣ります。特にGPS用地形図を自作するときにメモリが不足気味になったため、今さらながらUEFI環境でWindowsとLinuxのデュアルブート環境を構築しました。

 

環境

PCはUEFIブート環境でドライブのパーティションはGPT/MBR混載です。もともとWindows環境で使用していたSSD/HDDはそのままにして、Linux用に新しくドライブを追加しました。

  • CPU:Core i5
  • Memory:16GByte
  • ドライブ:
    • SSD(256GByte)
    • HDD(3TByte)
    • SSD(64GByte) <- Linux用に追加
    • HDD(500GByte) <- Linux用に追加
  • OS:
    • Windows10
    • Ubuntu18.04 <- 新規インストール
PCケースのHDDマウント
久しぶりにPCケースをあけました。こんなにドライブを載せたのは久しぶりです。

 

Windows/ubuntuをデュアルブートにする

今回はWindowsとubuntuを別々のディスクにインストールします。

ドライブの増設

まずはドライブの増設です。今回は余っているHDD/SSDが手元にあったのでそれにUbuntuをインストールすることにしました。

  • SSD(64GByte)
  • HDD(500GByte)
SSD,HDDとUSBメモリ
部屋の片隅で埃をかぶっていたドライブです。何年かぶりに日の目を見るときがやってきました。

久しぶりにPCのケースを開けます。このマザーボードだとSATAは6ポートありますが、今回のドライブ増設で全て埋まってしまいました(HDDx4+光学ドライブ+eSATA)。全部使うことはまず無いだろうと思っていたのに、どうなるか分からないものです。

マザーボードのSATAポート
RAID組んでいるわけでもないのにSATAポートが全て埋まってしまった

Ubuntuのインストール

次にUbuntuをインストールします。インストールイメージをUSBメモリに書き込み、USBからインストーラを立ち上げました。

lili_ubuntu18_20180626.png
LinuxLive USB Creatorを使ってインストールイメージをUSBメモリに書き込みます
BIOS起動選択
作成したUSBメモリからインストーラを起動します。

SSDをシステムディスクとして使うように設定して、あとはインストーラの手順通りに進めていきます。

パーティションは先頭からEFI、ext4と作成しました。ブートローダーはEFIに書き込みます。EFI領域は適当に256MByteとしましたが、Windows10でも100MByteくらいだったのでもっと減らして大丈夫だと思います。スワップ領域は何もしなくてもファイル(/swpfile)として確保されるので作成しません。

パーティション構成
後から見たら変な感じになっていますが・・・とにかく先頭にEFI領域を確保。

UEFI環境でのブートローダー

ubuntuのブートローダはgrub2です。以前のBIOS環境では起動ディスクのMBRにブートストラップローダを書き込み、本体は/bootなど配置していました。複数OS環境を切り替えるために別々のディスクにOS+ブートローダをインストールしておいてBIOS画面から起動ディスクを変更するか、ブートローダに設定を変更して立ち上げるOSを選択できるようにしたものです。

それに対して、UEFI環境ではBIOS(UEFI)が各ディスクのEFIパーティションを自動的に検索します。何もしなくとも、起動先に”Windows”や”Ubuntu”といった名前が並んでいるはずです。

UEFI Boot Priorities
BIOS(UEFI)のブート順選択。電源ONで毎回Windows/ubuntuを選択したいならubuntuを一番上に持って来ればgrub2の画面で選択できます。

grub2もUEFIに対応していて、立ち上がると同じように起動するOSの一覧が表示されます。とても楽ですね。

 

Ubuntu環境の設定

インストールが完了すれば基本的には何もしなくてOKです。NTFSのHDDもマウント出来るのでWindowsで使っているディスクドライブも読み込めます(あまりパフォーマンスは良くないようですが)。

SSD向けの設定

ubuntu 18.04ではIOスケジューラにデフォルトでCFQが選択されるようです。


$ cat /sys/block/sd*/queue/scheduler
noop deadline [cfq]
noop deadline [cfq]
noop deadline [cfq]
noop deadline [cfq]

ディスクドライブがHDDの場合はこれでいいですが、SSDの場合はスケジューラを"noop"もしくは"deadline"にしてやるとパフォーマンスが向上するようです。そこで、”/etc/udev/rules.d/”に以下のように設定ファイルを追加してやります。こうするとドライブの属性が”rotational==0”(つまりSSD)のときIOスケジュールが”deadline”になります。


$ cat /etc/udev/rules.d/60-ssd-scheduler.rules
# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

OSを再起動したあとに確認すると、SSD(ここではsdaとsdb)のIOスケジューラがdeadlineになっているのがわかります。


$ cat /sys/block/sd*/queue/scheduler
noop [deadline] deadline
noop [deadline] deadline
noop deadline [cfq]
noop deadline [cfq]

 

参考

この記事は以下の内容を参考にさせて頂きました。

公開日 カテゴリー PC

sukeについて

自転車で日本一周旅行に出ようとー思い立ったエンジニア。 ガジェット類やセミナーに目がない。 将来は田舎でほっこりとしたいですねー

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください