更新：以下の質問と回答はUbuntu 16.04にも適用されます
デュアルSSDとWin（7）が別のディスクにプリインストールされているコンピューターがあります。事前インストールでは、（U）EFI / GPTブートを使用します。Ubuntu 14.04 64ビットデスクトップをSSDのRAID1ルートパーティションにインストールし、Win7システムをデュアルブートできるようにします。これは可能ですか？
デスクトップインストーラーを使用したこのガイドは、おそらく（暗黙的に）MBRブートを前提としているため、機能しませんでした。おそらく同じ理由で、サーバーディストリビューションもインストールしませんでした。
回答:
更新：以下の説明がUbuntu 16.04でも機能することを確認しました。他のユーザーは17.10および18.04.1での作業を報告しています。
注：このHOWTOはLVMを提供しません。LVMも必要な場合は、代わりにUEFI BIOSが搭載されたマシンに、Ubuntu 18.04デスクトップをRAID 1およびLVMでインストールしてみてください。
試行錯誤の末、私は現在、機能するシステムを手に入れました！要するに、ソリューションは次の手順で構成されていました。
ソリューションのステップ6の重要なコンポーネントは、ブートシーケンスの遅延でした。これは、SSDのいずれかが欠落している場合に、GRUBプロンプトに（キーボードなしで！）
USBスティックからEFIを使用して起動します。正確には、システムによって異なります。[ インストールせずにUbuntuを試す]を選択します。
xterm以下のコマンドを実行するなどのために、ターミナルエミュレータを起動します。
これを試している間に、すでに完全に構成された別のコンピューターから簡単にログインできることがよくわかりました。この簡略化されたコマンドのカットアンドペーストなど。同じことをしたい場合は、以下を実行して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ライブセッションにログインできるようになります。
古いパーティションとブートブロックをすべてクリアします。警告！これにより、ディスク上のデータが破壊されます！
sudo sgdisk -z /dev/sda
sudo sgdisk -z /dev/sdb
最小のドライブに新しいパーティションを作成します：ESPの場合は100M、RAID SWAPの場合は32G、RAIDルートの場合は残り。sdaドライブが最小の場合はセクション2.1、そうでない場合はセクション2.2に従ってください。
次の手順を実行します。
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
次の手順を実行します。
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
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
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のコメントを参照してください。）
劣化モードで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
とにかく失敗するブートローダーを除き、ユビキタスインストーラーを実行します。（注：ssh経由でログインしている場合は、代わりに新しいコンピューターでこれを実行することをお勧めします。）
sudo ubiquity -b
インストールタイプとして[ その他]を選択し、md1p1タイプをext4、フォーマット：はい、マウントポイントに変更し/ます。md0p1パーティションは自動的にスワップとして選択されます。
インストールが完了したら、コーヒーを飲みます。
重要：インストールが完了したら、システムの起動準備がまだ完了していないため、[ テストの継続]を選択します。
待機中の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>
以下のプロセスは、再起動を含む同期中も継続する場合があります。
インストールシステムに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=""
繰り返しますが、この手順は不要かもしれませんが、目を開いて起動することを好みます...
（このステップは不要かもしれないし、使用して交換することができるというコミュニティによって示唆されているGRUB_CMDLINE_LINUX="rootdelay=30"中で/etc/default/grub。上の理由から、このHOWTOの下部に説明し、私はそれがにrootdelayを使用するよりも醜いであっても、睡眠スクリプトに固執することをお勧めします。したがって、通常のプログラムを続けます...）
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
これでシステムの準備がほぼ完了しました。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に/dev/sda1インストールされ、コンピューターのUEFIブートチェーンに最初にインストールされます。
ほぼ完了です。この時点で、sdaドライブを再起動できるはずです。さらに、ドライブまたはドライブのmdadm障害を処理できる必要があります。ただし、EFIはRAID化されていないため、クローンを作成する必要があります。sdasdb
dd if=/dev/sda1 of=/dev/sdb1
ブートローダーを2番目のドライブにインストールすることに加えて、これにより、sdb1パーティション上のFAT32ファイルシステムのUUID （によって報告されるblkid）がsda1およびのUUIDと一致し/etc/fstabます。（ただし、/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'
私はそれをテストしませんでしたが、おそらくESP sdaとの間に一意のラベル（-L）が必要sdbです。
これにより、現在の起動順序のプリントアウトが生成されます。たとえば、
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:forを使用/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 +ブートシステムを復元するには、次の手順が必要です。
正常なドライブからパーティションテーブルをコピーします。
sudo sgdisk /dev/sdY -R /dev/sdX
新しいドライブでUUIDを再ランダム化します。
sudo sgdisk /dev/sdX -G
sudo mdadm --add /dev/md0 /dev/sdX2
sudo mdadm --add /dev/md1 /dev/sdX3
正常なドライブからESPを複製します。（慎重に、多分最初に両方のESPのファイルへのダンプを行って、本当にそれを台無しにした場合に回復を有効にしてください。）
sudo dd if=/dev/sdY1 of=/dev/sdX1
クローンの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を開始しました...）、システムが起動しました。アレイは劣化モードにあり、/dev/sdb[23]USBスティックを追加しなくてもパーティションを手動で再追加できました。スリープスクリプトが機能するのに動作しないのはなぜかわかりrootdelayません。おそらくmdadm、わずかに非同期の2つのコンポーネントデバイスに混乱するかもしれませんが、mdadmそれを処理するように設計されました。とにかく、sleepスクリプトが機能するので、私はそれにこだわっています。
完全に健全なRAIDコンポーネントデバイスを削除し、RAIDをデグレードモードに再起動してからコンポーネントデバイスを再度追加することは、非現実的なシナリオであると言えます。 、mdadm混乱する機会が少なくなります。私はその議論に同意します。ただし、実際にハードウェアを無効にすることを除いて、システムがハードウェア障害をどのように許容するかをテストする方法は知りません そして、テスト後、冗長で動作するシステムに戻りたいと思います。（まあ、私は可能性があり、別のマシンに私の第二のSSDを接続し、私はそれを再度追加する前にそれを強打、それは実現可能ではありません。）
要約すると、私の知る限り、rootdelayソリューションはクリーンで、劣化していないブートのスリープスクリプトよりも高速であり、実際のドライブの障害/交換シナリオで機能するはずです。しかし、私はそれをテストするための実行可能な方法を知りません。そのため、当面は、Iいスリープスクリプトに固執します。
mount | grep efi）からマウントされていることがあります。どうやらlinuxはblkidが一致する最初のパーティションをマウントし/etc/fstabます。ただし、これは問題になりません。
apt-get install mdadmとmdadm -A /dev/md0 mdadm -A /dev/md1。
grub-efi-amd64-signedセキュアブートが有効になっていた場合にはそうでない場合、私は、「無効な署名」EFIエラーを得ていました。
私の提案はDebian OS向けですが、Ubuntuなどでも有効だと思います。
UEFIエントリを正しく処理しない多くのマザーボードで発生する問題を解決する1つの可能な方法（正しいエントリを作成しても、Debianは起動しませんefibootmgr -c -g -d /dev/sda -p 1 -w -L "debian" -l /EFI/debian/grubx64.efi。UEFIBIOSは「debian」起動可能ディスクを表示しますが、起動しません。 ）、代わりにジェネリックエントリを使用すること/boot/efi/EFI/boot/bootx4.efiです。
たとえば、Asus Z87Cは好きではありません/EFI/debian/grubx64.efi。
したがって、efiパーティション/dev/sda1を/boot/efipathにマウントした場合：
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」汎用ディスクから問題なく起動します。