CẬP NHẬT: Tôi đã xác minh rằng mô tả bên dưới cũng hoạt động cho Ubuntu 16.04. Những người dùng khác đã báo cáo làm việc vào ngày 17.10 và 18.04.1.
LƯU Ý: HOWTO này sẽ không cung cấp cho bạn LVM. Nếu bạn cũng muốn LVM, hãy thử Cài đặt máy tính để bàn Ubuntu 18.04 với RAID 1 và LVM trên máy với UEFI BIOS .
Sau nhiều ngày cố gắng, giờ tôi đã có một hệ thống làm việc! Tóm lại, giải pháp bao gồm các bước sau:
- Khởi động bằng đĩa CD / USB Ubuntu Live.
- Phân vùng ổ SSD theo yêu cầu.
- Cài đặt các gói bị thiếu (mdadm và grub-efi).
- Tạo các phân vùng RAID.
- Chạy trình cài đặt Ubiquity (nhưng không khởi động vào hệ thống mới).
- Vá hệ thống đã cài đặt (initramfs) để cho phép khởi động từ gốc RAID.
- Tạo phân vùng EFI của SSD đầu tiên với GRUB và cài đặt nó vào chuỗi khởi động EFI.
- Sao chép phân vùng EFI sang ổ SSD khác và cài đặt nó vào chuỗi khởi động.
- Làm xong! Hệ thống của bạn bây giờ sẽ có dự phòng RAID 1. Lưu ý rằng không có gì đặc biệt cần phải được thực hiện sau khi cập nhật kernel, vì các phân vùng UEFI chưa được xử lý.
Một thành phần quan trọng của bước 6 của giải pháp là sự chậm trễ trong trình tự khởi động, nếu không tôi đã đổ thẳng vào dấu nhắc GRUB (không có bàn phím!) Nếu thiếu một trong hai ổ SSD.
Chi tiết HOWTO
1. Khởi động
Khởi động bằng EFI từ thanh USB. Chính xác làm thế nào sẽ thay đổi bởi hệ thống của bạn. Chọn Dùng thử Ubuntu mà không cần cài đặt .
Bắt đầu một trình giả lập thiết bị đầu cuối, ví dụ xtermđể chạy các lệnh bên dưới.
1.1 Đăng nhập từ máy tính khác
Trong khi thử điều này, tôi thường thấy dễ dàng hơn để đăng nhập từ một máy tính khác, đã được cấu hình đầy đủ. Việc cắt và dán đơn giản hóa các lệnh này, v.v. Nếu bạn muốn làm như vậy, bạn có thể đăng nhập qua ssh bằng cách thực hiện như sau:
Trên máy tính được cấu hình, cài đặt máy chủ openssh:
sudo apt-get install openssh-server
Đổi mật khẩu. Mật khẩu mặc định cho người dùng ubuntulà trống. Bạn có thể chọn một mật khẩu cường độ trung bình. Nó sẽ bị lãng quên ngay khi bạn khởi động lại máy tính mới.
passwd
Bây giờ bạn có thể đăng nhập vào phiên trực tiếp trên Ubuntu từ một máy tính khác. Các hướng dẫn dưới đây là dành cho linux:
ssh -l ubuntu <your-new-computer>
Nếu bạn nhận được cảnh báo về một cuộc tấn công giữa người bị nghi ngờ, bạn cần xóa các phím ssh được sử dụng để xác định máy tính mới. Điều này là do openssh-servertạo khóa máy chủ mới bất cứ khi nào nó được cài đặt. Lệnh sử dụng thường được in và sẽ giống như
ssh-keygen -f <path-to-.ssh/known_hosts> -R <your-new-computer>
Sau khi thực hiện lệnh đó, bạn sẽ có thể đăng nhập vào phiên trực tiếp trên Ubuntu.
2. Đĩa phân vùng
Xóa mọi phân vùng cũ và khối khởi động. Cảnh báo! Điều này sẽ phá hủy dữ liệu trên đĩa của bạn!
sudo sgdisk -z /dev/sda
sudo sgdisk -z /dev/sdb
Tạo các phân vùng mới trên các ổ đĩa nhỏ nhất của bạn: 100M cho ESP, 32G cho RAID SWAP, phần còn lại cho root RAID. Nếu ổ đĩa sda của bạn nhỏ nhất, hãy làm theo Mục 2.1, nếu không thì Mục 2.2.
2.1 Tạo bảng phân vùng (/ dev / sda nhỏ hơn)
Thực hiện các bước sau:
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
Sao chép bảng phân vùng vào đĩa khác và tạo lại các UUID duy nhất (thực sự sẽ tạo lại UUID cho sda).
sudo sgdisk /dev/sda -R /dev/sdb -G
2.2 Tạo bảng phân vùng (/ dev / sdb nhỏ hơn)
Thực hiện các bước sau:
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
Sao chép bảng phân vùng vào đĩa khác và tạo lại các UUID duy nhất (thực sự sẽ tạo lại UUID cho sdb).
sudo sgdisk /dev/sdb -R /dev/sda -G
2.3 Tạo hệ thống tệp FAT32 trên / dev / sda
Tạo hệ thống tệp FAT32 cho phân vùng 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
3. Cài đặt các gói bị thiếu
Ubuntu Live CD không có hai gói chính; grub-efi và mdadm. Cài đặt chúng. (Tôi không chắc chắn 100% grub-efi ở đây, nhưng để duy trì tính đối xứng với bản cài đặt sắp tới, hãy mang nó vào.)
sudo apt-get update
sudo apt-get -y install grub-efi-amd64 # (or grub-efi-amd64-signed)
sudo apt-get -y install mdadm
Bạn có thể cần grub-efi-amd64-signedthay vì grub-efi-amd64nếu bạn đã bật khởi động an toàn. (Xem bình luận của Alecz.)
4. Tạo phân vùng RAID
Tạo các thiết bị RAID ở chế độ xuống cấp. Các thiết bị sẽ được hoàn thành sau. Việc tạo một RAID1 đầy đủ đôi khi khiến tôi gặp vấn đề trong quá trình ubiquitycài đặt bên dưới, không biết tại sao. (định dạng gắn kết / unmount?)
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
Xác nhận trạng thái 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>
Phân vùng các thiết bị 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. Chạy trình cài đặt
Chạy trình cài đặt có mặt khắp nơi, ngoại trừ bộ tải khởi động sẽ không thành công . ( Lưu ý : Nếu bạn đã đăng nhập qua ssh, có thể bạn sẽ muốn thực hiện điều này trên máy tính mới của mình.)
sudo ubiquity -b
Chọn một cái gì đó khác làm kiểu cài đặt và sửa đổi md1p1loại thành ext4, định dạng: có và điểm gắn kết /. Các md0p1phân vùng sẽ tự động được chọn như hoán đổi.
Nhận một tách cà phê trong khi cài đặt kết thúc.
Quan trọng: Sau khi cài đặt kết thúc, chọn Tiếp tục kiểm tra vì hệ thống chưa sẵn sàng khởi động.
Hoàn thành các thiết bị RAID
Đính kèm các phân vùng sdb chờ vào RAID.
sudo mdadm --add /dev/md0 /dev/sdb2
sudo mdadm --add /dev/md1 /dev/sdb3
Xác minh tất cả các thiết bị RAID đều ổn (và tùy chọn đồng bộ hóa).
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>
Quá trình bên dưới có thể tiếp tục trong quá trình đồng bộ hóa, bao gồm cả việc khởi động lại.
6. Cấu hình hệ thống đã cài đặt
Thiết lập để kích hoạt chroot vào hệ thống cài đặt.
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
Cấu hình và cài đặt gói.
apt-get install -y grub-efi-amd64 # (or grub-efi-amd64-signed; same as in step 3)
apt-get install -y mdadm
Nếu thiết bị md của bạn vẫn đang đồng bộ hóa, bạn có thể thấy các cảnh báo không thường xuyên như:
/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
Điều này là bình thường và có thể bỏ qua (xem câu trả lời ở dưới cùng của
câu hỏi này ).
nano /etc/grub.d/10_linux
# change quick_boot and quiet_boot to 0
Vô hiệu hóa quick_bootsẽ tránh các lỗi ghi Diskfilter không được hỗ trợ . Vô hiệu hóa chỉ quiet_bootlà sở thích cá nhân.
Sửa đổi /etc/mdadm/mdadm.conf để xóa mọi tham chiếu nhãn, tức là thay đổi
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
đến
ARRAY /dev/md/0 UUID=f0e36215:7232c9e1:2800002e:e80a5599
ARRAY /dev/md/1 UUID=4b42f85c:46b93d8e:f7ed9920:42ea4623
Bước này có thể không cần thiết, nhưng tôi đã thấy một số trang gợi ý rằng các sơ đồ đặt tên có thể không ổn định (name = ub Ubuntu: 0/1) và điều này có thể ngăn một thiết bị RAID hoàn toàn tốt trong quá trình khởi động.
Sửa đổi dòng /etc/default/grubđể đọc
#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
Một lần nữa, bước này có thể không cần thiết, nhưng tôi thích khởi động với đôi mắt mở ...
6.1. Thêm kịch bản ngủ
(Nó đã được đề xuất bởi các cộng đồng rằng bước này có thể là không cần thiết và có thể được thay thế sử dụng GRUB_CMDLINE_LINUX="rootdelay=30"trong /etc/default/grub. Vì lý do giải thích ở dưới cùng của HOWTO này, tôi đề nghị để dính với kịch bản giấc ngủ mặc dù nó là xấu xí vì sử dụng rootdelay. Như vậy, chúng tôi tiếp tục với chương trình thường xuyên của mình ... )
Tạo một tập lệnh sẽ chờ các thiết bị RAID giải quyết. Nếu không có sự chậm trễ này, việc cài đặt root có thể thất bại do việc lắp ráp RAID không được hoàn thành kịp thời gian . Tôi đã phát hiện ra điều này một cách khó khăn - vấn đề không xuất hiện cho đến khi tôi ngắt kết nối một trong các ổ SSD để mô phỏng lỗi ổ đĩa! Thời gian có thể cần phải được điều chỉnh tùy thuộc vào phần cứng có sẵn, ví dụ như đĩa USB ngoài chậm, v.v.
Nhập mã sau vào /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"
Làm cho tập lệnh thực thi và cài đặt nó.
chmod a+x /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile
update-grub
update-initramfs -u
7. Kích hoạt khởi động từ ổ SSD đầu tiên
Bây giờ hệ thống gần như đã sẵn sàng, chỉ cần cài đặt các tham số khởi động 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
Điều này sẽ cài đặt bộ nạp khởi động trong /boot/efi/EFI/Ubuntu(aka EFI/Ubuntutrên /dev/sda1) và cài đặt nó đầu tiên trong chuỗi khởi động UEFI trên máy tính.
8. Kích hoạt khởi động từ ổ SSD thứ hai
Chúng ta sắp xong rồi. Tại thời điểm này, chúng tôi sẽ có thể khởi động lại trên sdaổ đĩa. Hơn nữa, mdadmcó thể xử lý lỗi của ổ đĩa sdahoặc sdbổ đĩa. Tuy nhiên, EFI không được RAID, vì vậy chúng tôi cần sao chép nó .
dd if=/dev/sda1 of=/dev/sdb1
Ngoài việc cài đặt bộ tải khởi động trên ổ đĩa thứ hai, điều này sẽ làm cho UUID của hệ thống tệp FAT32 trên sdb1phân vùng (như được báo cáo bởi blkid) khớp với sda1và /etc/fstab. (Tuy nhiên, lưu ý rằng các UUID cho /dev/sda1và /dev/sdb1phân vùng sẽ vẫn khác nhau - so sánh ls -la /dev/disk/by-partuuid | grep sd[ab]1với blkid /dev/sd[ab]1sau khi cài đặt để tự kiểm tra.)
Cuối cùng, chúng ta phải chèn sdb1phân vùng vào thứ tự khởi động. (Lưu ý: Bước này có thể không cần thiết, tùy thuộc vào BIOS của bạn. Tôi đã nhận được báo cáo rằng một số BIOS 'tự động tạo danh sách các ESP hợp lệ.)
efibootmgr -c -g -d /dev/sdb -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'
Tôi đã không kiểm tra nó, nhưng có lẽ cần phải có nhãn duy nhất (-L) giữa ESP sdavà sdb.
Điều này sẽ tạo ra một bản in của thứ tự khởi động hiện tại, ví dụ
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
Lưu ý rằng Ubuntu # 2 (sdb) và Ubuntu (sda) là thứ đầu tiên trong thứ tự khởi động.
Khởi động lại
Bây giờ chúng tôi đã sẵn sàng để khởi động lại.
exit # from chroot
exit # from sudo -s
sudo reboot
Bây giờ hệ thống sẽ khởi động lại vào Ubuntu (Trước tiên, bạn có thể phải xóa phương tiện cài đặt Ubuntu Live.)
Sau khi khởi động, bạn có thể chạy
sudo update-grub
để gắn bộ tải khởi động Windows vào chuỗi khởi động grub.
Máy ảo gotchas
Nếu bạn muốn thử điều này trong một máy ảo trước tiên, có một số lưu ý: Rõ ràng, NVRAM chứa thông tin UEFI được ghi nhớ giữa các lần khởi động lại, nhưng không phải giữa các chu kỳ khởi động lại. Trong trường hợp đó, bạn có thể kết thúc tại bảng điều khiển UEFI Shell. Các lệnh sau sẽ khởi động bạn vào máy của bạn từ /dev/sda1(sử dụng FS1:cho /dev/sdb1):
FS0:
\EFI\ubuntu\grubx64.efi
Giải pháp đầu tiên trong câu trả lời hàng đầu về khởi động UEFI trong hộp ảo - Ubuntu 12.04 cũng có thể hữu ích.
Mô phỏng lỗi đĩa
Lỗi của một trong hai thiết bị thành phần RAID có thể được mô phỏng bằng cách sử dụng mdadm. Tuy nhiên, để xác minh rằng các công cụ khởi động sẽ tồn tại trong một lỗi đĩa, tôi đã phải tắt máy tính và ngắt kết nối nguồn khỏi đĩa. Nếu bạn làm như vậy, trước tiên hãy đảm bảo rằng các thiết bị md được đồng bộ hóa .
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>
Trong các hướng dẫn bên dưới, sdX là thiết bị thất bại (X = a hoặc b) và sdY là thiết bị ok.
Ngắt kết nối ổ đĩa
Tắt máy tính. Ngắt kết nối ổ đĩa. Khởi động lại. Ubuntu sẽ khởi động với các ổ RAID ở chế độ xuống cấp. (Kỷ niệm! Đây là những gì bạn đã cố gắng để đạt được!)
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>
Khôi phục từ một đĩa bị lỗi
Đây là quá trình để làm theo nếu bạn cần thay thế một đĩa bị lỗi. Nếu bạn muốn mô phỏng một sự thay thế, bạn có thể khởi động vào phiên Ubuntu Live và sử dụng
dd if=/dev/zero of=/dev/sdX
để xóa sạch đĩa trước khi khởi động lại vào hệ thống thực. Nếu bạn vừa kiểm tra dự phòng boot / RAID trong phần trên, bạn có thể bỏ qua bước này. Tuy nhiên, ít nhất bạn phải thực hiện các bước 2 và 4 dưới đây để khôi phục dự phòng khởi động / RAID đầy đủ cho hệ thống của bạn.
Khôi phục hệ thống khởi động RAID + sau khi thay thế đĩa yêu cầu các bước sau:
- Phân vùng ổ đĩa mới.
- Thêm phân vùng cho các thiết bị md.
- Nhân bản phân vùng khởi động.
- Thêm một bản ghi EFI cho bản sao.
1. Phân vùng ổ đĩa mới
Sao chép bảng phân vùng từ ổ đĩa lành mạnh:
sudo sgdisk /dev/sdY -R /dev/sdX
Tái ngẫu nhiên các UUID trên ổ đĩa mới.
sudo sgdisk /dev/sdX -G
2. Thêm vào thiết bị md
sudo mdadm --add /dev/md0 /dev/sdX2
sudo mdadm --add /dev/md1 /dev/sdX3
3. Sao chép phân vùng khởi động
Nhân bản ESP từ ổ đĩa lành mạnh. (Cẩn thận, trước tiên có thể thực hiện kết xuất tệp của cả hai ESP để cho phép khôi phục nếu bạn thực sự làm hỏng nó.)
sudo dd if=/dev/sdY1 of=/dev/sdX1
4. Đưa đĩa vừa được khôi phục vào thứ tự khởi động
Thêm một bản ghi EFI cho bản sao. Sửa đổi nhãn -L theo yêu cầu.
sudo efibootmgr -c -g -d /dev/sdX -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'
Bây giờ, khởi động lại hệ thống sẽ khiến nó trở lại bình thường (các thiết bị RAID vẫn có thể được đồng bộ hóa)!
Tại sao kịch bản ngủ?
Nó đã được đề xuất bởi cộng đồng rằng việc thêm một kịch bản giấc ngủ có thể là không cần thiết và có thể được thay thế bằng cách sử dụng GRUB_CMDLINE_LINUX="rootdelay=30"trong /etc/default/grubtiếp theo sudo update-grub. Đề xuất này chắc chắn sạch hơn và không hoạt động trong trường hợp hỏng / thay thế đĩa. Tuy nhiên có một lời cảnh báo...
Tôi đã ngắt kết nối ổ SSD thứ hai của mình và phát hiện ra rằng rootdelay=30, v.v. thay vì tập lệnh ngủ:
1) Hệ thống khởi động ở chế độ xuống cấp mà không có ổ "bị lỗi".
2) Trong khởi động không xuống cấp (có cả hai ổ đĩa), thời gian khởi động được giảm. Độ trễ chỉ có thể cảm nhận được với ổ đĩa thứ hai bị mất.
1) và 2) nghe có vẻ tuyệt vời cho đến khi tôi thêm lại ổ đĩa thứ hai của mình. Khi khởi động, mảng RAID không thể lắp ráp và để lại cho tôi initramfsdấu nhắc mà không biết phải làm gì. Có thể có thể cứu vãn tình huống bằng cách a) khởi động vào thanh USB Ubuntu Live, b) cài đặt mdadmvà c) lắp ráp lại mảng một cách thủ công nhưng ... tôi đã nhầm ở đâu đó. Thay vào đó, khi tôi chạy lại thử nghiệm này với kịch bản ngủ (vâng, tôi đã khởi động HOWTO từ đầu đến lần thứ n ...), hệ thống đã khởi động. Các mảng ở chế độ xuống cấp và tôi có thể tự thêm lại các /dev/sdb[23]phân vùng mà không cần thêm USB. Tôi không biết tại sao kịch bản ngủ hoạt động trong khi rootdelaykhông. Có lẽ mdadmbị nhầm lẫn bởi hai thiết bị thành phần hơi không đồng bộ, nhưng tôi nghĩmdadmđược thiết kế để xử lý điều đó. Dù sao, vì kịch bản ngủ hoạt động, tôi vẫn gắn bó với nó.
Có thể lập luận rằng việc loại bỏ một thiết bị thành phần RAID hoàn toàn khỏe mạnh, khởi động lại RAID về chế độ xuống cấp và sau đó thêm lại thiết bị thành phần là một tình huống không thực tế: Kịch bản thực tế là một thiết bị bị lỗi và được thay thế bằng một thiết bị mới , để lại ít cơ hội mdadmđể bị lẫn lộn. Tôi đồng ý với lập luận đó. Tuy nhiên, tôi không biết cách kiểm tra hệ thống chịu đựng lỗi phần cứng như thế nào ngoại trừ việc thực sự vô hiệu hóa một số phần cứng! Và sau khi thử nghiệm, tôi muốn quay trở lại một hệ thống làm việc dư thừa. (Chà, tôi có thể gắn SSD thứ hai của mình vào một máy khác và vuốt nó trước khi tôi thêm lại, nhưng điều đó không khả thi.)
Tóm lại: Theo hiểu biết của tôi, rootdelaygiải pháp sạch sẽ, nhanh hơn kịch bản ngủ cho giày không xuống cấp và nên hoạt động cho kịch bản thay thế / thất bại ổ đĩa thực. Tuy nhiên, tôi không biết một cách khả thi để kiểm tra nó. Vì vậy, trong thời gian này, tôi sẽ dính vào kịch bản giấc ngủ xấu xí.