it-swarm.com.de

Wie installiere ich Ubuntu 14.04 / 16.04 64-Bit mit einer Dual-Boot-RAID-1-Partition auf einem UEFI / GPT-System?

Update: Frage und Antwort unten gelten auch für Ubuntu 16.04

Ich habe einen Computer mit zwei SSDs und Win (7) auf einer anderen Festplatte vorinstalliert. Die Vorinstallation verwendet (U) EFI/GPT-Boot. Ich möchte den 64-Bit-Desktop von Ubuntu 14.04 auf einer RAID1-Root-Partition auf meinen SSDs installieren und trotzdem mein Win7-System dual booten können. Ist das möglich?

Diese Anleitung Die Verwendung des Desktop-Installationsprogramms funktionierte nicht, wahrscheinlich, weil es (implizit) das Booten des MBR voraussetzt. Weder hat Installation der Serververteilung , wahrscheinlich aus dem gleichen Grund.

22
Niclas Börlin

UPDATE: Ich habe überprüft, dass die folgende Beschreibung auch für Ubuntu 16.04 funktioniert. Andere Benutzer haben gemeldet, dass sie am 17.10 und 18.04.1 arbeiten.

HINWEIS: In diesem HOWTO erhalten Sie keine LVM. Wenn Sie auch LVM möchten, versuchen Sie Installieren Sie den Ubuntu 18.04-Desktop mit RAID 1 und LVM auf einem Computer mit UEFI-BIOS.

Nach Tagen des Versuchs habe ich jetzt ein funktionierendes System! Kurz gesagt bestand die Lösung aus den folgenden Schritten:

  1. Booten Sie mit einer Ubuntu Live CD/USB.
  2. Partitioniert die SSDs nach Bedarf.
  3. Installieren Sie fehlende Pakete (mdadm und grub-efi).
  4. Erstellen Sie die RAID-Partitionen.
  5. Führen Sie das Ubiquity-Installationsprogramm aus (booten Sie jedoch nicht in das neue System).
  6. Patchen Sie das installierte System (initramfs), um das Booten von einem RAID-Root zu ermöglichen.
  7. Füllen Sie die EFI-Partition der ersten SSD mit GRUB und installieren Sie sie in der EFI-Startkette.
  8. Klonen Sie die EFI-Partition auf die andere SSD und installieren Sie sie in der Boot-Kette.
  9. Getan! Ihr System verfügt nun über RAID 1-Redundanz. Es ist zu beachten, dass nach z. ein Kernel-Update, da die UEFI-Partitionen unberührt bleiben.

Eine Schlüsselkomponente von Schritt 6 der Lösung war eine Verzögerung in der Startsequenz, die mich ansonsten direkt zur Eingabeaufforderung GRUB führte (ohne Tastatur!), Wenn eine der SSDs fehlte.

Ausführliches HOWTO

1. Booten

Booten Sie mit EFI vom USB-Stick. Wie genau, hängt von Ihrem System ab. Wählen Sie ubuntu ausprobieren ohne zu installieren .

Starten Sie einen Terminalemulator, z. xterm, um die folgenden Befehle auszuführen.

1.1 Login von einem anderen Computer

Beim Ausprobieren fiel es mir oft leichter, mich von einem anderen, bereits vollständig konfigurierten Computer aus anzumelden. Dieses vereinfachte Ausschneiden und Einfügen von Befehlen usw. Wenn Sie dasselbe tun möchten, können Sie sich über ssh anmelden, indem Sie die folgenden Schritte ausführen:

Installieren Sie auf dem zu konfigurierenden Computer den openssh-Server:

Sudo apt-get install openssh-server

Passwort ändern. Das Standardkennwort für Benutzer ubuntu ist leer. Sie können wahrscheinlich ein Passwort mittlerer Stärke auswählen. Es wird vergessen, sobald Sie Ihren neuen Computer neu starten.

passwd

Jetzt können Sie sich von einem anderen Computer aus in die Ubuntu-Live-Sitzung einloggen. Die folgenden Anweisungen gelten für Linux:

ssh -l ubuntu <your-new-computer>

Wenn Sie eine Warnung über einen mutmaßlichen Man-in-the-Middle-Angriff erhalten, müssen Sie die SSH-Schlüssel löschen, die zur Identifizierung des neuen Computers verwendet werden. Dies liegt daran, dass openssh-server bei jeder Installation neue Serverschlüssel generiert. Der zu verwendende Befehl wird normalerweise gedruckt und sollte so aussehen

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

Nachdem Sie diesen Befehl ausgeführt haben, sollten Sie sich bei der Ubuntu Live-Sitzung anmelden können.

2. Partitionsdatenträger

Löschen Sie alle alten Partitionen und Startblöcke. Warnung! Dadurch werden Daten auf Ihren Datenträgern zerstört!

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

Erstellen Sie neue Partitionen auf der kleinsten Festplatte: 100 MB für ESP, 32 GB für RAID-SWAP, Rest für RAID-Root. Wenn Ihr SDA-Laufwerk das kleinste ist, befolgen Sie Abschnitt 2.1, andernfalls Abschnitt 2.2.

2.1 Partitionstabellen erstellen (/ dev/sda ist kleiner)

Führen Sie die folgenden Schritte aus:

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

Kopieren Sie die Partitionstabelle auf einen anderen Datenträger und generieren Sie eindeutige UUIDs neu (generiert tatsächlich UUIDs für sda neu).

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

2.2 Partitionstabellen erstellen (/ dev/sdb ist kleiner)

Führen Sie die folgenden Schritte aus:

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

Partitionstabelle auf anderen Datenträger kopieren und eindeutige UUIDs neu generieren (generiert UUIDs für sdb neu).

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

2.3 Erstellen Sie ein FAT32-Dateisystem unter/dev/sda

Erstellen Sie ein FAT32-Dateisystem für die EFI-Partition.

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. Installieren Sie fehlende Pakete

Die Ubuntu Live-CD wird ohne zwei Schlüsselpakete geliefert. grub-efi und mdadm. Installieren Sie sie. (Ich bin mir nicht 100% sicher, ob grub-efi hier benötigt wird, aber um die Symmetrie mit der kommenden Installation aufrechtzuerhalten, bringen Sie es ebenfalls ein.)

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

Möglicherweise benötigen Sie grub-efi-AMD64-signed anstelle von grub-efi-AMD64, wenn Sie den sicheren Start aktiviert haben. (Siehe Kommentar von Alecz.)

4. Erstellen Sie die RAID-Partitionen

Erstellen Sie die RAID-Geräte im herabgesetzten Modus. Die Geräte werden später fertiggestellt. Das Erstellen eines vollständigen RAID1 hat mir manchmal Probleme bei der ubiquity -Installation bereitet, nicht sicher warum. (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

Überprüfen Sie den RAID-Status.

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>

Partitionieren Sie die md-Geräte.

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. Führen Sie das Installationsprogramm aus

Führen Sie das Ubiquity-Installationsprogramm aus, mit Ausnahme des Bootloaders das wird trotzdem fehlschlagen . ( Hinweis : Wenn Sie sich über ssh angemeldet haben, möchten Sie dies wahrscheinlich stattdessen auf Ihrem neuen Computer ausführen.)

Sudo ubiquity -b

Wählen Sie als Installationstyp eine andere Option und ändern Sie den Typ md1p1 in ext4, Format: yes und Mount-Punkt /. Die md0p1-Partition wird automatisch als Swap ausgewählt.

Holen Sie sich eine Tasse Kaffee, während die Installation abgeschlossen ist.

Wichtig: Wählen Sie nach Abschluss der Installation Weitere Tests als System aus ist noch nicht startbereit.

Vervollständigen Sie die RAID-Geräte

Verbinden Sie die wartenden SDB-Partitionen mit dem RAID.

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

Stellen Sie sicher, dass alle RAID-Geräte in Ordnung sind (und optional synchronisiert werden).

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>

Der folgende Prozess kann während der Synchronisierung fortgesetzt werden, einschließlich der Neustarts.

6. Konfigurieren Sie das installierte System

Richten Sie ein, um Chroot für das Installationssystem zu aktivieren.

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

Pakete konfigurieren und installieren.

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

Wenn Sie md-Geräte noch synchronisieren, werden möglicherweise gelegentliche Warnungen angezeigt:

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

Dies ist normal und kann ignoriert werden (siehe Antwort unten in diese Frage ).

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

Durch Deaktivieren von quick_boot werden die Diskfilter-Schreibvorgänge werden nicht unterstützt Fehler vermieden. Das Deaktivieren von quiet_boot ist nur eine persönliche Einstellung.

Ändern Sie /etc/mdadm/mdadm.conf, um Beschriftungsreferenzen zu entfernen, d. H. Zu ändern

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

zu

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

Dieser Schritt ist möglicherweise nicht erforderlich. Auf einigen Seiten wurde jedoch darauf hingewiesen, dass die Benennungsschemata möglicherweise instabil sind (name = ubuntu: 0/1). Dadurch wird möglicherweise verhindert, dass sich ein einwandfreies RAID-Gerät während des Startvorgangs zusammensetzt.

Ändern Sie die zu lesenden Zeilen in /etc/default/grub

#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Auch dieser Schritt mag unnötig sein, aber ich ziehe es vor, mit offenen Augen zu booten ...

6.1. Schlaf-Skript hinzufügen

(Es wurde von der Community vorgeschlagen, dass dieser Schritt möglicherweise unnötig ist und durch GRUB_CMDLINE_LINUX="rootdelay=30" in /etc/default/grub ersetzt werden kann. Aus Gründen, die am Ende dieses HOWTOs erläutert werden, schlage ich vor, das Sleep-Skript beizubehalten, obwohl es hässlicher ist als die Verwendung von rootdelay. Also fahren wir mit unserem regulären Programm fort ... )

Erstellen Sie ein Skript, das darauf wartet, dass sich die RAID-Geräte einrichten. Ohne diese Verzögerung wird das Mounten des Root-Servers schlägt möglicherweise fehl, da die RAID-Assembly nicht rechtzeitig fertiggestellt wurde . Ich habe das auf die harte Tour herausgefunden - das Problem trat erst auf, als ich eine der SSDs zur Simulation eines Festplattenausfalls getrennt hatte! Das Timing muss möglicherweise abhängig von der verfügbaren Hardware angepasst werden, z. langsame externe USB-Festplatten usw.

Geben Sie den folgenden Code in /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile ein:

#!/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"

Machen Sie das Skript ausführbar und installieren Sie es.

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

7. Aktivieren Sie den Start von der ersten SSD

Jetzt ist das System fast fertig, nur die UEFI-Boot-Parameter müssen installiert werden.

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

Dadurch wird der Bootloader in /boot/efi/EFI/Ubuntu (a.k.a. EFI/Ubuntu auf /dev/sda1) installiert und zuerst in der UEFI-Bootkette auf dem Computer installiert.

8. Aktivieren Sie den Start von der zweiten SSD

Wir sind fast fertig. Zu diesem Zeitpunkt sollten wir in der Lage sein, auf dem sda -Laufwerk einen Neustart durchzuführen. Darüber hinaus sollte mdadm in der Lage sein, einen Fehler des Laufwerks sda oder sdb zu behandeln. Das EFI ist jedoch nicht RAID, daher müssen wir es klonen .

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

Zusätzlich zur Installation des Bootloaders auf dem zweiten Laufwerk wird dadurch die UUID des FAT32-Dateisystems auf der Partition sdb1 (wie von blkid gemeldet) mit derjenigen von sda1 und /etc/fstab übereinstimmen. (Beachten Sie jedoch, dass die UUIDs für die Partitionen /dev/sda1 und /dev/sdb1 immer noch unterschiedlich sind. Vergleichen Sie ls -la /dev/disk/by-partuuid | grep sd[ab]1 nach der Installation mit blkid /dev/sd[ab]1, um sich selbst zu überzeugen.)

Schließlich müssen wir die Partition sdb1 in die Startreihenfolge einfügen. (Hinweis: Dieser Schritt ist abhängig von Ihrem BIOS möglicherweise nicht erforderlich. Ich habe Berichte erhalten, dass einige BIOS 'automatisch eine Liste gültiger ESPs generieren.)

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

Ich habe es nicht getestet, aber es ist wahrscheinlich notwendig, eindeutige Bezeichnungen (-L) zwischen ESP auf sda und sdb zu haben.

Dadurch wird ein Ausdruck der aktuellen Startreihenfolge erstellt, z.

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

Beachten Sie, dass Ubuntu # 2 (sdb) und Ubuntu (sda) die ersten in der Startreihenfolge sind.

Starten Sie neu

Jetzt können wir neu starten.

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

Das System sollte nun in Ubuntu neu starten (Möglicherweise müssen Sie zuerst die Ubuntu Live-Installationsmedien entfernen.)

Nach dem Booten können Sie ausführen

Sudo update-grub

um den Windows-Bootloader an die Grub-Bootkette anzuhängen.

Fallstricke der virtuellen Maschine

Wenn Sie dies zuerst in einer virtuellen Maschine ausprobieren möchten, gibt es einige Einschränkungen: Anscheinend wird der NVRAM, der die UEFI-Informationen enthält, zwischen Neustarts, nicht jedoch zwischen den Zyklen des Herunterfahrens und Neustarts gespeichert. In diesem Fall landen Sie möglicherweise an der UEFI-Shell-Konsole. Die folgenden Befehle sollten Sie von /dev/sda1 aus in Ihren Computer booten (verwenden Sie FS1: für /dev/sdb1):

FS0:
\EFI\ubuntu\grubx64.efi

Die erste Lösung in der Top-Antwort von EFI-Boot in VirtualBox - Ubuntu 12.04 könnte ebenfalls hilfreich sein.

Simulieren eines Festplattenfehlers

Der Ausfall eines RAID-Komponentengeräts kann mit mdadm simuliert werden. Um jedoch zu überprüfen, ob das Boot-Zeug einen Festplattenfehler überlebt, musste ich den Computer herunterfahren und die Stromversorgung von einer Festplatte trennen. Wenn Sie dies tun, stellen Sie zunächst sicher, dass die MD-Geräte synchronisiert sind .

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>

In den folgenden Anweisungen ist sdX das ausgefallene Gerät (X = a oder b) und sdY das in Ordnung befindliche Gerät.

Trennen Sie ein Laufwerk

Den Computer herunterfahren. Trennen Sie ein Laufwerk. Neustart. Ubuntu sollte nun mit den RAID-Laufwerken im herabgesetzten Modus starten. (Feiern Sie! Dies ist, was Sie erreichen wollten!)

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>

Wiederherstellung von einer ausgefallenen Festplatte

Dies ist der folgende Vorgang, wenn Sie eine fehlerhafte Festplatte ersetzen müssen. Wenn Sie einen Ersatz emulieren möchten, können Sie eine Ubuntu Live-Sitzung starten und verwenden

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

wischen Sie die Festplatte sauber, bevor Sie das reale System neu starten. Wenn Sie gerade die Boot-/RAID-Redundanz im obigen Abschnitt getestet haben, können Sie diesen Schritt überspringen. Sie müssen jedoch mindestens die folgenden Schritte 2 und 4 ausführen, um die vollständige Boot-/RAID-Redundanz für Ihr System wiederherzustellen.

Das Wiederherstellen des RAID + -Bootsystems nach einem Festplattentausch erfordert die folgenden Schritte:

  1. Partitionieren Sie das neue Laufwerk.
  2. Füge Partitionen zu md Geräten hinzu.
  3. Klonen Sie die Startpartition.
  4. Fügen Sie einen EFI-Datensatz für den Klon hinzu.

1. Partitionieren Sie das neue Laufwerk

Kopieren Sie die Partitionstabelle vom fehlerfreien Laufwerk:

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

Randomisieren Sie die UUIDs auf dem neuen Laufwerk neu.

Sudo sgdisk /dev/sdX -G

2. Fügen Sie zu md Geräten hinzu

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

3. Klonen Sie die Boot-Partition

Klonen Sie das ESP vom fehlerfreien Laufwerk. (Vorsicht, führen Sie zuerst einen Dump-to-File-Vorgang für beide ESPs durch, um die Wiederherstellung zu ermöglichen, wenn Sie es wirklich vermasseln.)

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

4. Legen Sie die neu belebte Diskette in die Startreihenfolge ein

Fügen Sie einen EFI-Datensatz für den Klon hinzu. Ändern Sie die Bezeichnung -L nach Bedarf.

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

Wenn Sie das System neu starten, sollte es wieder normal sein (die RAID-Geräte werden möglicherweise noch synchronisiert)!

Warum das Schlaf-Skript?

Es wurde von der Community vorgeschlagen, dass das Hinzufügen eines Schlaf-Skripts möglicherweise nicht erforderlich ist und durch die Verwendung von GRUB_CMDLINE_LINUX="rootdelay=30" in /etc/default/grub gefolgt von Sudo update-grub ersetzt werden kann. Dieser Vorschlag ist auf jeden Fall sauberer und funktioniert in einem Szenario mit Datenträgerausfall/-austausch. Es gibt jedoch eine Einschränkung ...

Ich habe meine zweite SSD abgeklemmt und herausgefunden, dass mit rootdelay=30 usw. anstelle des Sleep-Skripts:
1) Das System bootet im herabgesetzten Modus ohne das "ausgefallene" Laufwerk.
2) Im nicht beeinträchtigten Startmodus (beide Laufwerke vorhanden) wird die Startzeit verkürzt. Die Verzögerung ist nur spürbar, wenn das zweite Laufwerk fehlt.

1) und 2) klangen großartig, bis ich mein zweites Laufwerk wieder hinzufügte. Beim Booten konnte das RAID-Array nicht zusammengebaut werden und ließ mich an der Eingabeaufforderung initramfs zurück, ohne zu wissen, was zu tun ist. Es könnte möglich gewesen sein, die Situation zu retten, indem man a) vom Ubuntu Live-USB-Stick gebootet, b) mdadm installiert und c) das Array manuell neu zusammengebaut hat, aber ... ich habe irgendwo etwas durcheinander gebracht. Stattdessen, wenn ich diesen Test mit dem Sleep-Skript erneut ausführte (ja, ich habe das HOWTO zum n-ten Mal von oben gestartet ...), wurde das System hat gebootet. Die Arrays befanden sich im herabgesetzten Modus, und ich konnte die /dev/sdb[23]-Partitionen ohne zusätzlichen USB-Stick manuell neu hinzufügen. Ich weiß nicht, warum das Schlaf-Skript funktioniert, das rootdelay nicht. Vielleicht wird mdadm durch zwei nicht synchronisierte Komponentengeräte verwirrt, aber ich dachte mdadm wurde entwickelt, um das zu handhaben. Wie auch immer, da das Schlaf-Skript funktioniert, halte ich mich daran.

Es könnte argumentiert werden, dass das Entfernen eines einwandfrei funktionierenden RAID-Komponentengeräts, das Neustarten des RAID im herabgesetzten Modus und das erneute Hinzufügen des Komponentengeräts ein unrealistisches Szenario ist: Das realistische Szenario besteht eher darin, dass ein Gerät ausfällt und durch ein neues ersetzt wird und weniger Gelegenheit für mdadm, verwirrt zu werden. Ich stimme diesem Argument zu. Ich kann jedoch nicht testen, wie das System einen Hardwarefehler toleriert, es sei denn, einige Hardwarekomponenten werden deaktiviert! Und nach dem Testen möchte ich zu einem redundanten, funktionierenden System zurückkehren. (Nun, ich könnte meine zweite SSD an eine andere Maschine anschließen und sie wischen, bevor ich sie wieder hinzufüge, aber das ist nicht machbar.)

Zusammenfassend: Meines Wissens ist die rootdelay -Lösung sauber, schneller als das Sleep-Skript für nicht beeinträchtigte Startvorgänge und sollte für ein echtes Szenario mit Laufwerksausfall/Ersatz funktionieren. Ich kenne jedoch keinen praktikablen Weg, um es zu testen. Also werde ich mich vorerst an das hässliche Schlaf-Skript halten.

35
Niclas Börlin

Mein Vorschlag ist für Debian OS, aber ich denke, es würde auch für Ubuntu und andere funktionieren.

Ein möglicher Weg, um ein Problem zu lösen, das bei vielen Motherboards auftritt, die die UEFI-Einträge nicht korrekt verarbeiten (Debian bootet nicht, selbst wenn Sie den richtigen Eintrag efibootmgr -c -g -d /dev/sda -p 1 -w -L "debian" -l /EFI/debian/grubx64.efi eingegeben haben) 't boot from it), verwenden Sie stattdessen den generischen Eintrag /boot/efi/EFI/boot/bootx4.efi.

Zum Beispiel mag Asus Z87C /EFI/debian/grubx64.efi nicht.

Wenn Sie also die efi-Partition /dev/sda1 in /boot/efi eingebunden haben:

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

Starten Sie dann neu.

Das UEFI-BIOS erkennt eine allgemeine "UEFI OS" -Diskette sowie alle anderen zuvor mit efibootmgr erstellten Einträge, bootet jedoch problemlos von der allgemeinen "UEFI OS" -Diskette.

0