อัปเดต: คำถามและคำตอบด้านล่างนี้ใช้กับ Ubuntu 16.04
ฉันมีคอมพิวเตอร์ที่มี SSD คู่และ Win (7) ติดตั้งล่วงหน้าในดิสก์อื่น การติดตั้งล่วงหน้าใช้ (U) บูต EFI / GPT ฉันต้องการติดตั้ง Ubuntu 14.04 เดสก์ท็อป 64 บิตบนพาร์ติชันรูท RAID1 บน SSD ของฉันและยังคงสามารถบูตระบบ Win7 ของฉันได้ เป็นไปได้ไหม
คู่มือนี้โดยใช้โปรแกรมติดตั้งเดสก์ท็อปไม่ทำงานอาจเป็นเพราะ (โดยนัย) จะถือว่าการบูตแบบ MBR ไม่ได้ติดตั้งการกระจายเซิร์ฟเวอร์อาจด้วยเหตุผลเดียวกัน
คำตอบ:
อัปเดต: ฉันได้ตรวจสอบแล้วว่าคำอธิบายด้านล่างใช้ได้กับ Ubuntu 16.04 ด้วย ผู้ใช้รายอื่นรายงานว่าทำงานในวันที่ 17.10 และ 18.04.1
หมายเหตุ: HOWTO นี้จะไม่ให้ LVM แก่คุณ หากคุณต้องการ LVM ด้วยให้ลองติดตั้งเดสก์ท็อป Ubuntu 18.04 พร้อม RAID 1 และ LVM บนเครื่องที่มี UEFI BIOSแทน
หลังจากพยายามมาหลายวันฉันก็มีระบบที่ใช้งานได้! โดยสังเขปโซลูชันประกอบด้วยขั้นตอนต่อไปนี้:
ส่วนประกอบสำคัญของขั้นตอนที่ 6 ของการแก้ปัญหาคือความล่าช้าในลำดับการบู๊ตซึ่งมิฉะนั้นฉันก็จะทิ้งฉันไปที่พรอมต์ GRUB (โดยไม่ต้องใช้แป้นพิมพ์!) หาก SSDs ใดตัวหนึ่งหายไป
บูตโดยใช้ EFI จากก้าน USB วิธีการที่แตกต่างกันไปตามระบบของคุณ เลือกลองอูบุนตูไม่ต้องติดตั้ง
เริ่มโปรแกรมจำลองเทอร์มินัลเช่นxtermเพื่อเรียกใช้คำสั่งด้านล่าง
ในขณะที่ลองทำสิ่งนี้ฉันมักจะพบว่าการลงชื่อเข้าใช้จากคอมพิวเตอร์เครื่องอื่นซึ่งมีการกำหนดค่าไว้แล้วนั้นง่ายกว่า คำสั่งตัดและวางแบบง่าย ๆ นี้เป็นต้นหากคุณต้องการทำสิ่งเดียวกันคุณสามารถเข้าสู่ระบบผ่าน ssh โดยทำดังต่อไปนี้:
บนคอมพิวเตอร์ที่จะกำหนดค่าติดตั้งเซิร์ฟเวอร์ openssh:
sudo apt-get install openssh-server
เปลี่ยนรหัสผ่าน. รหัสผ่านเริ่มต้นสำหรับผู้ใช้ubuntuว่างเปล่า คุณอาจเลือกรหัสผ่านที่มีความแรงปานกลาง มันจะถูกลืมทันทีที่คุณรีบูทคอมพิวเตอร์เครื่องใหม่
passwd
ตอนนี้คุณสามารถเข้าสู่เซสชัน ubuntu live จากคอมพิวเตอร์เครื่องอื่น คำแนะนำด้านล่างสำหรับ linux:
ssh -l ubuntu <your-new-computer>
หากคุณได้รับคำเตือนเกี่ยวกับการโจมตีคนที่ต้องสงสัยว่าเป็นคนกลางคุณต้องล้างปุ่ม ssh ที่ใช้เพื่อระบุคอมพิวเตอร์เครื่องใหม่ นี่เป็นเพราะopenssh-serverสร้างคีย์เซิร์ฟเวอร์ใหม่เมื่อใดก็ตามที่มีการติดตั้ง โดยทั่วไปคำสั่งที่ใช้จะถูกพิมพ์และควรมีลักษณะเช่นนี้
ssh-keygen -f <path-to-.ssh/known_hosts> -R <your-new-computer>
หลังจากรันคำสั่งนั้นคุณควรจะสามารถเข้าสู่เซสชัน ubuntu live ได้
ล้างพาร์ติชันเก่าและบล็อกการบูต คำเตือน! นี่จะทำลายข้อมูลบนดิสก์ของคุณ!
sudo sgdisk -z /dev/sda
sudo sgdisk -z /dev/sdb
สร้างพาร์ติชั่นใหม่บนไดรฟ์ที่เล็กที่สุดของคุณ: 100M สำหรับ ESP, 32G สำหรับ RAID SWAP, สำหรับ RAID root ถ้าไดรฟ์ 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 ที่ไม่ซ้ำกัน (จริง ๆ แล้วจะสร้าง UUIDs ใหม่สำหรับ sda)
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 ที่ไม่ซ้ำกัน (จริง ๆ แล้วจะสร้าง UUIDs สำหรับ sdb)
sudo sgdisk /dev/sdb -R /dev/sda -G
สร้างระบบไฟล์ FAT32 สำหรับพาร์ติชัน EFI
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
อูบุนตูไลฟ์ซีดีมาโดยไม่มีแพ็คเกจหลักสองชุด Grub-efi และ mdadm ติดตั้งพวกเขา (ฉันไม่แน่ใจ 100% ว่าต้องใช้ grub-efi ที่นี่ แต่เพื่อรักษาความสมมาตรในการติดตั้งที่จะมาถึงให้นำมันเข้ามาด้วย)
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ติดตั้งด้านล่างไม่แน่ใจว่าทำไม (mount / unmount? format?)
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 ตัวใดตัวหนึ่งเพื่อจำลองความล้มเหลวของดิสก์! อาจต้องปรับเปลี่ยนเวลาขึ้นอยู่กับฮาร์ดแวร์ที่มีเช่นดิสก์ 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(aka EFI/Ubuntuบน/dev/sda1) และติดตั้งก่อนในเชนการบูต UEFI บนคอมพิวเตอร์
เราเกือบเสร็จแล้ว ณ จุดนี้เราควรจะสามารถรีบูตsdaไดรฟ์ นอกจากนี้mdadmควรสามารถจัดการกับความล้มเหลวของไดรฟ์sdaหรือ sdbอย่างไรก็ตาม EFI จะไม่บุกเข้าไปดังนั้นเราจึงจำเป็นที่จะโคลน
dd if=/dev/sda1 of=/dev/sdb1
นอกจากการติดตั้งบูตในไดรฟ์ที่สองนี้จะทำให้ UUID ของระบบ FAT32 ไฟล์บนsdb1พาร์ติชัน (ตามการรายงานblkid) การแข่งขันของและsda1 /etc/fstab(อย่างไรก็ตามโปรดทราบว่า UUIDs สำหรับ/dev/sda1และ/dev/sdb1พาร์ติชันจะยังคงแตกต่างกัน - เปรียบเทียบ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'
ผมไม่ได้ทดสอบ แต่มันอาจจะมีความจำเป็นต้องมีป้ายชื่อที่ไม่ซ้ำกัน (-L) ระหว่าง ESP บนและsdasdb
สิ่งนี้จะสร้างผลงานพิมพ์ของลำดับการบู๊ตปัจจุบันเช่น
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 บูตโหลดเดอร์เข้ากับเชนการบูตด้วง
หากคุณต้องการลองใช้เครื่องเสมือนก่อนมีข้อ จำกัด บางประการ: เห็นได้ชัดว่า NVRAM ที่เก็บข้อมูล UEFI จะถูกจดจำระหว่างการรีบูต แต่ไม่ใช่ระหว่างรอบการรีสตาร์ท ในกรณีดังกล่าวคุณอาจสิ้นสุดที่คอนโซล UEFI Shell คำสั่งต่อไปนี้ควรบูตคุณเข้าสู่เครื่องจาก/dev/sda1(ใช้FS1:สำหรับ/dev/sdb1):
FS0:
\EFI\ubuntu\grubx64.efi
ทางออกแรกในคำตอบสูงสุดของการบูต UEFI ในกล่องเสมือน - Ubuntu 12.04อาจเป็นประโยชน์
ความล้มเหลวของอุปกรณ์ส่วนประกอบ RAID mdadmทั้งสามารถจำลองการใช้ อย่างไรก็ตามเพื่อตรวจสอบว่าสิ่งที่บูตจะอยู่รอดดิสก์ล้มเหลวฉันต้องปิดเครื่องคอมพิวเตอร์และตัดการเชื่อมต่อพลังงานจากดิสก์ ถ้าคุณทำเช่นนั้นเป็นครั้งแรกให้แน่ใจว่าอุปกรณ์ md จะ sync'ed
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 เป็นอุปกรณ์ที่ใช้ได้
ปิดเครื่องคอมพิวเตอร์ ถอดไดรฟ์ เริ่มต้นใหม่. ตอนนี้อูบุนตูควรบูตด้วยไดรฟ์ 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 ที่ซ้ำซ้อนในส่วนด้านบนคุณสามารถข้ามขั้นตอนนี้ได้ อย่างไรก็ตามคุณต้องดำเนินการอย่างน้อย 2 และ 4 ด้านล่างเพื่อกู้คืนการบูท / RAID แบบเต็มสำหรับระบบของคุณ
การกู้คืนระบบการบูต RAID + หลังจากการเปลี่ยนดิสก์ต้องใช้ขั้นตอนต่อไปนี้:
คัดลอกตารางพาร์ติชันจากไดรฟ์ที่มีสุขภาพดี:
sudo sgdisk /dev/sdY -R /dev/sdX
สุ่ม UUIDs บนไดรฟ์ใหม่อีกครั้ง
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คำแนะนำนี้สะอาดกว่าแน่นอนและทำงานในสถานการณ์ความล้มเหลวของดิสก์ / แทนที่ อย่างไรก็ตามมีข้อแม้ ...
ฉันยกเลิกการเชื่อมต่อ SSD ตัวที่สองและพบว่ามีrootdelay=30ฯลฯ แทนที่สลีปสคริปต์:
1) ระบบทำการบู๊ตในโหมดที่เสื่อมโทรมโดยไม่มีไดรฟ์ "ล้มเหลว"
2) ในการบูทที่ไม่มีการสลายตัว (มีไดรฟ์ทั้งคู่อยู่) เวลาบูตจะลดลง การหน่วงเวลาสามารถรับรู้ได้เฉพาะเมื่อไดรฟ์ที่สองหายไป
1) และ 2) ฟังดูดีจนกระทั่งฉันเพิ่มไดรฟ์ที่สองอีกครั้ง ตอนบูตอาร์เรย์ RAID ไม่สามารถรวบรวมและทิ้งฉันไว้ที่initramfsพรอมต์โดยไม่ทราบว่าต้องทำอะไร มันอาจจะเป็นไปได้ที่จะกอบกู้สถานการณ์โดย a) การบูตไปยังแท่ง USB Ubuntu Live, b) การติดตั้งmdadmและ c) ประกอบอาร์เรย์ขึ้นใหม่ด้วยตนเอง แต่ ... ฉันทำบางสิ่งบางอย่างยุ่งเหยิง แต่เมื่อฉันอีกครั้งวิ่งทดสอบนี้มีสคริปต์การนอนหลับ (ใช่ฉันได้เริ่มต้น HOWTO จากด้านบนเป็นครั้งที่ n ... ), ระบบไม่บูต อาร์เรย์อยู่ในโหมดที่เสื่อมโทรมและฉันสามารถเพิ่ม/dev/sdb[23]พาร์ติชันใหม่ได้เองโดยไม่ต้องใช้ USB เสริม ฉันไม่รู้ว่าทำไมสคริปต์สลีปทำงานในขณะที่สคริปต์rootdelayไม่ทำงาน บางทีอาจmdadmจะสับสนโดยอุปกรณ์ส่วนประกอบสองตัวที่ไม่ซิงค์กันเล็กน้อย แต่ฉันคิดว่าmdadmถูกออกแบบมาเพื่อจัดการกับมัน อย่างไรก็ตามเนื่องจากสคริปต์การนอนหลับทำงานได้ฉันก็ยังติดอยู่
มันอาจจะเป็นที่ถกเถียงกันอยู่ว่าการถอดอุปกรณ์ส่วนประกอบ RAID ที่แข็งแรงสมบูรณ์การบู๊ต RAID กลับไปที่โหมดที่เสื่อมโทรมจากนั้นการเพิ่มอุปกรณ์คอมโพเนนต์อีกครั้งเป็นสถานการณ์ที่ไม่สมจริง: สถานการณ์จริงคืออุปกรณ์หนึ่งล้มเหลวและถูกแทนที่ด้วยอุปกรณ์ใหม่ ปล่อยให้โอกาสน้อยลงที่mdadmจะสับสน ฉันเห็นด้วยกับข้อโต้แย้งนั้น อย่างไรก็ตามฉันไม่ทราบวิธีทดสอบว่าระบบยอมรับความล้มเหลวของฮาร์ดแวร์ได้อย่างไรยกเว้นการปิดใช้งานฮาร์ดแวร์บางตัว! และหลังจากการทดสอบฉันต้องการกลับไปใช้ระบบการทำงานที่ซ้ำซ้อน (ดีฉันสามารถต่อ SSD ตัวที่สองของฉันกับเครื่องอื่นและปัดก่อนที่จะเพิ่มอีกครั้ง แต่นั่นไม่เป็นไปได้)
โดยสรุป: สำหรับความรู้ของฉันrootdelayโซลูชันนั้นสะอาดเร็วกว่าสลีปสคริปต์สำหรับบูทที่ไม่มีการสลายตัวและควรใช้งานได้จริงสำหรับความล้มเหลวของไดรฟ์ / การเปลี่ยนสถานการณ์จริง อย่างไรก็ตามฉันไม่ทราบวิธีที่เป็นไปได้ในการทดสอบ ดังนั้นในขณะนี้ฉันจะยึดติดกับสคริปต์การนอนหลับที่น่าเกลียด
mount | grep efi) /etc/fstabเห็นได้ชัดว่าเมาท์ลินุกซ์พาร์ทิชันแรกที่มีการแข่งขัน blkid แม้ว่าจะไม่เป็นปัญหาก็ตาม
apt-get install mdadm mdadm -A /dev/md0 mdadm -A /dev/md1
grub-efi-amd64-signedมิฉะนั้นฉันได้รับข้อผิดพลาด "ลายเซ็นไม่ถูกต้อง" efi หากเปิดใช้งานการบูตอย่างปลอดภัย
ข้อเสนอแนะของฉันสำหรับ Debian OS แต่ฉันคิดว่ามันจะใช้ได้กับ Ubuntu และคนอื่น ๆ
วิธีหนึ่งที่เป็นไปได้ในการแก้ปัญหาที่เกิดขึ้นกับเมนบอร์ดจำนวนมากที่จัดการกับรายการ UEFI ไม่ถูกต้อง (Debian ไม่บูตแม้ว่าคุณจะทำรายการถูกต้องแล้วก็ตาม efibootmgr -c -g -d /dev/sda -p 1 -w -L "debian" -l /EFI/debian/grubx64.efiแล้ว UEFI BIOS จะแสดงดิสก์ที่สามารถบู๊ตได้ "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" ทั่วไปโดยไม่มีปัญหาใด ๆ