UEFI / GPTシステムにデュアルブートRAID 1パーティションでUbuntu 14.04 / 16.04 64ビットをインストールする方法

Question

更新：以下の質問と回答はUbuntu 16.04にも適用されます

デュアルSSDとWin（7）が別のディスクにプリインストールされているコンピューターがあります。事前インストールでは、（U）EFI/GPTブートを使用します。 Ubuntu 14.04 64ビットデスクトップをSSDのRAID1ルートパーティションにインストールし、Win7システムをデュアルブートできるようにします。これは可能ですか？

このガイドデスクトップインストーラの使用は機能しませんでした。おそらく（暗黙的に）MBRの起動を前提としているためです。おそらく同じ理由でサーバーディストリビューションのインストールもしませんでした。

Niclas B&#246;rlin · Accepted Answer

更新：以下の説明がUbuntu 16.04でも機能することを確認しました。他のユーザーが17.10および18.04.1。での作業を報告しています

注：このHOWTOはLVMを提供しません。 LVMも必要な場合は、 EFI BIOSが搭載されたマシンにUbuntu 18.04デスクトップをRAID 1およびLVMでインストールを試してください。

試行錯誤の末、現在は動作するシステムができました！簡単に言えば、ソリューションは次の手順で構成されていました。

Ubuntu Live CD/USBを使用して起動します。
必要に応じてSSDをパーティション分割します。
不足しているパッケージ（mdadmおよびgrub-efi）をインストールします。
RAIDパーティションを作成します。
Ubiquityインストーラーを実行します（ただし、新しいシステムを起動しないでください）。
インストールされたシステム（initramfs）にパッチを適用して、RAIDルートからの起動を有効にします。
最初のSSDのEFIパーティションにGRUBを入力し、EFIブートチェーンにインストールします。
クローンEFIパーティションを他のSSDにコピーし、ブートチェーンにインストールします。
できた！これで、システムにRAID 1冗長性が追加されました。特別なことは何もする必要がないことに注意してくださいUEFIパーティションは変更されないため、カーネルが更新されます。

ソリューションのステップ6の重要なコンポーネントは、ブートシーケンスの遅延でした。これは、SSDのいずれかが欠落している場合にGRUBプロンプト（キーボードなし！）.

詳細なHOWTO

1.ブート

USBスティックからEFIを使用して起動します。正確には、システムによって異なります。 を選択して、インストールせずにubuntuを試してください。

ターミナルエミュレーターを起動します。 xtermは、以下のコマンドを実行します。

1.1別のコンピューターからのログイン

これを試している間に、すでに完全に構成された別のコンピューターから簡単にログインできることがよくわかりました。この簡略化されたコマンドのカットアンドペーストなど。同じことをしたい場合は、以下を実行してssh経由でログインできます。

構成するコンピューターに、opensshサーバーをインストールします。

Sudo apt-get install openssh-server

パスワードを変更する。ユーザーubuntuのデフォルトのパスワードは空白です。おそらく中程度の強度のパスワードを選択できます。新しいコンピューターを再起動するとすぐに忘れられます。

passwd

これで、別のコンピューターからUbuntuライブセッションにログインできます。以下の手順はLinux向けです。

ssh -l ubuntu <your-new-computer>

中間者攻撃の疑いに関する警告が表示された場合は、新しいコンピューターを識別するために使用されたsshキーをクリアする必要があります。これは、openssh-serverがインストールされるたびに新しいサーバーキーを生成するためです。使用するコマンドは通常印刷され、次のようになります。

ssh-keygen -f <path-to-.ssh/known_hosts> -R <your-new-computer>

そのコマンドを実行すると、ubuntuライブセッションにログインできるようになります。

2.パーティションディスク

古いパーティションとブートブロックをすべてクリアします。 警告！これにより、ディスク上のデータが破壊されます！

Sudo sgdisk -z /dev/sda Sudo sgdisk -z /dev/sdb

最小のドライブに新しいパーティションを作成します：ESPの場合は100M、RAID SWAPの場合は32G、RAIDルートの場合は残り。 sdaドライブが最小の場合はセクション2.1、そうでない場合はセクション2.2に従ってください。

2.1パーティションテーブルを作成する（/ dev/sdaは小さい）

次の手順を実行します。

Sudo sgdisk -n 1:0:+100M -t 1:ef00 -c 1:"EFI System" /dev/sda Sudo sgdisk -n 2:0:+32G -t 2:fd00 -c 2:"Linux RAID" /dev/sda Sudo sgdisk -n 3:0:0 -t 3:fd00 -c 3:"Linux RAID" /dev/sda

パーティションテーブルを他のディスクにコピーし、一意のUUIDを再生成します（実際にはsdaのUUIDを再生成します）。

Sudo sgdisk /dev/sda -R /dev/sdb -G

2.2パーティションテーブルの作成（/ dev/sdbの方が小さい）

次の手順を実行します。

Sudo sgdisk -n 1:0:+100M -t 1:ef00 -c 1:"EFI System" /dev/sdb Sudo sgdisk -n 2:0:+32G -t 2:fd00 -c 2:"Linux RAID" /dev/sdb Sudo sgdisk -n 3:0:0 -t 3:fd00 -c 3:"Linux RAID" /dev/sdb

パーティションテーブルを他のディスクにコピーし、一意のUUIDを再生成します（実際にはsdbのUUIDを再生成します）。

Sudo sgdisk /dev/sdb -R /dev/sda -G

2.3/dev/sdaにFAT32ファイルシステムを作成する

EFIパーティション用のFAT32ファイルシステムを作成します。

Sudo mkfs.fat -F 32 /dev/sda1 mkdir /tmp/sda1 Sudo mount /dev/sda1 /tmp/sda1 Sudo mkdir /tmp/sda1/EFI Sudo umount /dev/sda1

3.不足しているパッケージをインストールする

Ubuntu Live CDには、2つの主要なパッケージが付属していません。 grub-efiおよびmdadm。それらをインストールします。（ここではgrub-efiが100％必要であるとは確信していませんが、今後のインストールとの対称性を維持するために、同様にそれを取り込みます。）

Sudo apt-get update Sudo apt-get -y install grub-efi-AMD64 # (or grub-efi-AMD64-signed) Sudo apt-get -y install mdadm

セキュアブートを有効にしている場合は、grub-efi-AMD64-signedではなくgrub-efi-AMD64が必要になる場合があります。（Aleczのコメントを参照してください。）

4. RAIDパーティションを作成します

劣化モードでRAIDデバイスを作成します。デバイスは後で完成します。完全なRAID1を作成すると、以下のubiquityインストール中に問題が発生することがありましたが、その理由はわかりません。（マウント/アンマウント？フォーマット？）

Sudo mdadm --create /dev/md0 --bitmap=internal --level=1 --raid-disks=2 /dev/sda2 missing Sudo mdadm --create /dev/md1 --bitmap=internal --level=1 --raid-disks=2 /dev/sda3 missing

RAIDステータスを確認します。

cat /proc/mdstat Personalities : [raid1] md1 : active raid1 sda3[0] 216269952 blocks super 1.2 [2/1] [U_] bitmap: 0/2 pages [0KB], 65536KB chunk md0 : active raid1 sda2[0] 33537920 blocks super 1.2 [2/1] [U_] bitmap: 0/1 pages [0KB], 65536KB chunk unused devices: <none>

Mdデバイスをパーティション分割します。

Sudo sgdisk -z /dev/md0 Sudo sgdisk -z /dev/md1 Sudo sgdisk -N 1 -t 1:8200 -c 1:"Linux swap" /dev/md0 Sudo sgdisk -N 1 -t 1:8300 -c 1:"Linux filesystem" /dev/md1

5.インストーラーを実行する

ブートローダーを除いて、ユビキタスインストーラーを実行しますとにかく失敗します。（注：ssh経由でログインしている場合は、代わりに新しいコンピュータでこれを実行することをお勧めします。）

Sudo ubiquity -b

Something elseをインストールタイプとして選択し、md1p1タイプをext4に変更します。フォーマット：yes、マウントポイント/。 md0p1パーティションは、スワップとして自動的に選択されます。

インストールが完了したら、コーヒーを飲みます。

重要：インストールが完了したら、システムとしてテストの継続を選択しますまだ起動準備ができていません。

RAIDデバイスを完成させる

待機中のsdbパーティションをRAIDに接続します。

Sudo mdadm --add /dev/md0 /dev/sdb2 Sudo mdadm --add /dev/md1 /dev/sdb3

すべてのRAIDデバイスが正常であることを確認します（オプションで同期）。

cat /proc/mdstat Personalities : [raid1] md1 : active raid1 sdb3[1] sda3[0] 216269952 blocks super 1.2 [2/1] [U_] [>....................] recovery = 0.2% (465536/216269952) finish=17.9min speed=200000K/sec bitmap: 2/2 pages [8KB], 65536KB chunk md0 : active raid1 sdb2[1] sda2[0] 33537920 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk unused devices: <none>

以下のプロセスは、再起動を含む同期中も継続する場合があります。

6.インストール済みシステムを構成する

インストールシステムにchrootを有効にするように設定します。

Sudo -s mount /dev/md1p1 /mnt mount -o bind /dev /mnt/dev mount -o bind /dev/pts /mnt/dev/pts mount -o bind /sys /mnt/sys mount -o bind /proc /mnt/proc cat /etc/resolv.conf >> /mnt/etc/resolv.conf chroot /mnt

パッケージを構成およびインストールします。

apt-get install -y grub-efi-AMD64 # (or grub-efi-AMD64-signed; same as in step 3) apt-get install -y mdadm

Mdデバイスがまだ同期している場合、次のような警告が時々表示されることがあります。

/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..

これは正常であり、無視できます（この質問の最後の回答を参照）。

nano /etc/grub.d/10_linux # change quick_boot and quiet_boot to 0

quick_bootを無効にすると、 Diskfilterの書き込みはサポートされませんバグを回避できます。 quiet_bootを無効にするのは個人的な好みのみです。

/etc/mdadm/mdadm.confを変更して、ラベル参照を削除します。つまり、変更します。

ARRAY /dev/md/0 metadata=1.2 name=ubuntu:0 UUID=f0e36215:7232c9e1:2800002e:e80a5599 ARRAY /dev/md/1 metadata=1.2 name=ubuntu:1 UUID=4b42f85c:46b93d8e:f7ed9920:42ea4623

に

ARRAY /dev/md/0 UUID=f0e36215:7232c9e1:2800002e:e80a5599 ARRAY /dev/md/1 UUID=4b42f85c:46b93d8e:f7ed9920:42ea4623

この手順は不要かもしれませんが、いくつかのページでは、命名スキームが不安定で（name = ubuntu：0/1）、ブート中に完全に細かいRAIDデバイスが組み立てられないことを示唆しています。

/etc/default/grubの行を変更して読み取ります

#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" GRUB_CMDLINE_LINUX=""

繰り返しますが、この手順は不要かもしれませんが、目を開いて起動することを好みます...

6.1。スリープスクリプトを追加する

（このステップは不要であり、GRUB_CMDLINE_LINUX="rootdelay=30"で/etc/default/grubを使用して置き換えることができるとコミュニティから提案されています。このHOWTOの最後で説明した理由により、rootdelayを使用するよりもsleepくてもスリープスクリプトを使用することをお勧めします。 したがって、私たちは通常のプログラムを続けます...）

RAIDデバイスが安定するのを待つスクリプトを作成します。この遅延がない場合、 RAIDアセンブリが時間内に終了しないためにルートのマウントが失敗する可能性があります私はこれを難しい方法で見つけました-ディスク障害をシミュレートするためにSSDの1つを切断するまで、問題は現れませんでした！利用可能なハードウェアに応じて、タイミングを調整する必要がある場合があります。遅い外部USBディスクなど.

次のコードを/usr/share/initramfs-tools/scripts/local-premount/sleepAwhileに入力します。

#!/bin/sh echo echo "sleeping for 30 seconds while udevd and mdadm settle down" sleep 5 echo "sleeping for 25 seconds while udevd and mdadm settle down" sleep 5 echo "sleeping for 20 seconds while udevd and mdadm settle down" sleep 5 echo "sleeping for 15 seconds while udevd and mdadm settle down" sleep 5 echo "sleeping for 10 seconds while udevd and mdadm settle down" sleep 5 echo "sleeping for 5 seconds while udevd and mdadm settle down" sleep 5 echo "done sleeping"

スクリプトを実行可能にしてインストールします。

chmod a+x /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile update-grub update-initramfs -u

7.最初のSSDからの起動を有効にします

これでシステムの準備がほぼ整いました。UEFIブートパラメータのみをインストールする必要があります。

mount /dev/sda1 /boot/efi grub-install --boot-directory=/boot --bootloader-id=Ubuntu --target=x86_64-efi --efi-directory=/boot/efi --recheck update-grub umount /dev/sda1

これにより、ブートローダーが/boot/efi/EFI/Ubuntu（EFI/Ubuntuのa.k.a. /dev/sda1）にインストールされ、コンピューターのUEFIブートチェーンに最初にインストールされます。

8. 2番目のSSDからの起動を有効にします

ほぼ完了です。この時点で、sdaドライブを再起動できるはずです。さらに、mdadmはsdaまたはsdbドライブの障害を処理できる必要があります。ただし、EFIはRAID化されていないため、クローン化する必要があります。

dd if=/dev/sda1 of=/dev/sdb1

2番目のドライブにブートローダーをインストールすることに加えて、これにより、sdb1パーティション上のFAT32ファイルシステムのUUID（blkidによって報告される）がsda1および/etc/fstabのUUIDと一致します。（ただし、/dev/sda1パーティションと/dev/sdb1パーティションのUUIDはまだ異なることに注意してください。インストール後にls -la /dev/disk/by-partuuid | grep sd[ab]1とblkid /dev/sd[ab]1を比較して確認してください。）

最後に、ブート順序にsdb1パーティションを挿入する必要があります。（注：BIOSによっては、この手順は不要な場合があります。一部のBIOSが有効なESPのリストを自動的に生成するという報告を受けています。）

efibootmgr -c -g -d /dev/sdb -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'

テストはしませんでしたが、sdaとsdbのESPの間に一意のラベル（-L）が必要になる可能性があります。

これにより、現在の起動順序のプリントアウトが生成されます。

Timeout: 0 seconds BootOrder: 0009,0008,0000,0001,0002,000B,0003,0004,0005,0006,0007 Boot0000 Windows Boot Manager Boot0001 DTO UEFI USB Floppy/CD Boot0002 DTO UEFI USB Hard Drive Boot0003* DTO UEFI ATAPI CD-ROM Drive Boot0004 CD/DVD Drive Boot0005 DTO Legacy USB Floppy/CD Boot0006* Hard Drive Boot0007* IBA GE Slot 00C8 v1550 Boot0008* Ubuntu Boot000B KingstonDT 101 II PMAP Boot0009* Ubuntu #2

Ubuntu＃2（sdb）とUbuntu（sda）が起動順序の最初であることに注意してください。

リブート

これでリブートする準備ができました。

exit # from chroot exit # from Sudo -s Sudo reboot

これでシステムがUbuntuで再起動します（最初にUbuntu Liveインストールメディアを削除する必要がある場合があります）。

起動後、実行できます

Sudo update-grub

windowsブートローダーをgrubブートチェーンに接続します。

仮想マシンの落とし穴

最初に仮想マシンでこれを試してみたい場合、いくつかの注意事項があります。どうやら、UEFI情報を保持するNVRAMは再起動間で記憶されますが、シャットダウンと再起動のサイクル間では記憶されません。その場合、UEFI Shellコンソールが表示される場合があります。次のコマンドを実行すると、/dev/sda1からマシンが起動します（FS1:には/dev/sdb1を使用します）。

FS0: \EFI\ubuntu\grubx64.efi

virtualboxでのUEFIブート-Ubuntu 12.04 の一番上の答えの最初の解決策も役立つかもしれません。

ディスク障害のシミュレーション

いずれかのRAIDコンポーネントデバイスの障害は、mdadmを使用してシミュレートできます。ただし、ブートスタッフがディスク障害に耐えることを確認するには、コンピューターをシャットダウンし、ディスクの電源を切断する必要がありました。その場合、まずmdデバイスが同期されていることを確認してください。

cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md1 : active raid1 sdb3[2] sda3[0] 216269952 blocks super 1.2 [2/2] [UU] bitmap: 2/2 pages [8KB], 65536KB chunk md0 : active raid1 sda2[0] sdb2[2] 33537920 blocks super 1.2 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk unused devices: <none>

以下の手順では、sdXは障害が発生したデバイス（X = aまたはb）であり、sdYは正常なデバイスです。

ドライブを切断する

コンピューターを終了させて下さい。ドライブを切断します。再起動。これで、UbuntuはRAIDドライブを劣化モードで起動するはずです。（お祝い！これがあなたが達成しようとしていたことです！;）

cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md1 : active raid1 sda3[0] 216269952 blocks super 1.2 [2/1] [U_] bitmap: 2/2 pages [8KB], 65536KB chunk md0 : active raid1 sda2[0] 33537920 blocks super 1.2 [2/1] [U_] bitmap: 0/1 pages [0KB], 65536KB chunk unused devices: <none>

故障したディスクから回復する

これは、障害のあるディスクを交換する必要がある場合に従うべきプロセスです。代替品をエミュレートする場合は、Ubuntu Liveセッションを起動して使用できます

dd if=/dev/zero of=/dev/sdX

実際のシステムで再起動する前に、ディスクをきれいに消去します。上記のセクションでブート/ RAIDの冗長性をテストしたばかりの場合は、この手順をスキップできます。ただし、システムの完全なブート/ RAID冗長性を回復するには、少なくとも以下の手順2と4を実行する必要があります。

ディスクの交換後にRAID +ブートシステムを復元するには、次の手順が必要です。

新しいドライブをパーティション分割します。
Mdデバイスにパーティションを追加します。
ブートパーティションのクローンを作成します。
クローンのEFIレコードを追加します。

1.新しいドライブをパーティション分割します

正常なドライブからパーティションテーブルをコピーします。

Sudo sgdisk /dev/sdY -R /dev/sdX

新しいドライブのUUIDを再ランダム化します。

Sudo sgdisk /dev/sdX -G

2. mdデバイスに追加する

Sudo mdadm --add /dev/md0 /dev/sdX2 Sudo mdadm --add /dev/md1 /dev/sdX3

3.ブートパーティションのクローンを作成する

正常なドライブからESPを複製します。（慎重に、多分最初に両方のESPのファイルへのダンプを行って、本当にそれを台無しにしてしまった場合に回復を有効にしてください。）

Sudo dd if=/dev/sdY1 of=/dev/sdX1

4.新しく復活したディスクをブート順序に挿入します

クローンのEFIレコードを追加します。必要に応じて-Lラベルを変更します。

Sudo efibootmgr -c -g -d /dev/sdX -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'

これで、システムを再起動すると通常の状態に戻るはずです（RAIDデバイスはまだ同期しています）！

なぜスリープスクリプトなのですか？

コミュニティから、スリープスクリプトの追加は不要である可能性があり、GRUB_CMDLINE_LINUX="rootdelay=30"の後に/etc/default/grubを使用し、その後にSudo update-grubを使用することで置き換えることができると示唆されています。この提案は確かにクリーンであり、ディスク障害/交換シナリオで機能します。ただし、注意事項があります...

2番目のSSDを切断し、スリープスクリプトの代わりにrootdelay=30などを使用して、それを見つけました。
1）システムは「故障した」ドライブなしで劣化モードで起動します。
2）非劣化ブート（両方のドライブが存在する）では、ブート時間が短縮されます。遅延は、2番目のドライブが欠落している場合にのみ認識されます。

1）および2）2番目のドライブを再度追加するまで、すばらしい音でした。起動時に、RAIDアレイがアセンブルに失敗し、どうすればよいかわからずにinitramfsプロンプトが表示されました。 a）Ubuntu Live USBスティックを起動し、b）mdadmをインストールし、c）アレイを手動で再組み立てすることで状況を回復できるかもしれませんが、...どこかで台無しになりました。代わりに、このテストをスリープスクリプト（はい、n回目からHOWTOを開始しました...）で再実行すると、システムdidブート。アレイは劣化モードになっており、余分なUSBスティックなしで手動で/dev/sdb[23]パーティションを再追加できました。スリープスクリプトが機能するのにrootdelayが機能しないのはなぜかわかりません。おそらくmdadmは2つのわずかに非同期のコンポーネントデバイスに混乱しますが、mdadmはそれを処理するように設計されていると思います。とにかく、sleepスクリプトが機能するので、私はそれにこだわっています。

完全に健全なRAIDコンポーネントデバイスを削除し、RAIDを劣化モードに再起動してからコンポーネントデバイスを再度追加することは、非現実的なシナリオであると言えます。、mdadmが混乱する可能性を少なくします。私はその議論に同意します。ただし、実際にハードウェアを無効にすることを除いて、システムがハードウェア障害をどのように許容するかをテストする方法はわかりません！そして、テスト後、冗長で動作するシステムに戻りたいと思います。（まあ、私はcould2番目のSSDを別のマシンに接続し、再度追加する前にスワイプしますが、それは現実的ではありません。）

要約すると、私の知る限り、rootdelayソリューションはクリーンで、劣化していないブートのスリープスクリプトよりも高速であり、実際のドライブの障害/交換シナリオで機能するはずです。しかし、私はそれをテストするための実行可能な方法を知りません。したがって、当分の間、私はsleepいスリープスクリプトに固執します。

Nicola Giampietro · Answer

私の提案はDebian OS向けですが、Ubuntuなどでも有効だと思います。

UEFIエントリを正しく処理しない多くのマザーボードで発生する問題を解決する1つの可能な方法（正しいエントリefibootmgr -c -g -d /dev/sda -p 1 -w -L "debian" -l /EFI/debian/grubx64.efiを作成しても、Debianは起動しません。UEFIBIOSは「debian」ブート可能ディスクを表示しますが、「そこからブートしない」）、代わりに汎用エントリ/boot/efi/EFI/boot/bootx4.efiを使用します。

たとえば、Asus Z87Cは/EFI/debian/grubx64.efiが好きではありません。

したがって、efiパーティション/dev/sda1を/boot/efiパスにマウントした場合：

mkdir /boot/efi/EFI/boot cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/boot/bootx4.efi

次に再起動します。

UEFI BIOSは、「UEFI OS」汎用ディスク、およびefibootmgrで以前に作成された他のエントリも表示しますが、「UEFI OS」汎用ディスクから問題なく起動します。