webentwicklung-frage-antwort-db.com.de

rEFInd: Sehr langsamer Start bei Verwendung von EFI Stub Loader

Nach einer kürzlichen Neuinstallation trat bei rEFInd ein sehr seltsames Problem auf: Während es sowohl GRUB als auch vmlinuz auf meiner/boot-Partition erkennt, ist die Verwendung der letzteren extrem langsam .

Unmittelbar nach der Auswahl von "Boot vmlinuz-4.8.0-53-generic from 191 MiB ext2 volume" wird ein schwarzer Bildschirm mit dem folgenden Text angezeigt:

Starting vmlinuz-4.8.0-53-generic
Using load options 'root=UUID=6641e1e2-6829-49cc-bf88-85ba5eefbff8 ro quiet splash nomodeset vt.handoff=7 initrd=\initrd.img-4.8.0-53-generic'

Nach ungefähr einer Minute des Wartens (!) Bootet Linux normal (und ziemlich schnell).

Wenn ich dagegen GRUB wähle, gehe ich zum Startmenü GRUB und nach Auswahl der Standardoption wird Linux sofort gestartet.

Was könnte der Grund dafür sein?

Mein Setup umfasst eine SSD (auf der Linux und Windows installiert sind) und eine HDD (auf der mein/home installiert ist), wobei eine ext2/boot-Partition und die EFI-Partition (ursprünglich von Windows erstellt) unter/boot/efi bereitgestellt sind. Hier ist meine/etc/fstab:

UUID=6641e1e2-6829-49cc-bf88-85ba5eefbff8 /               ext4    errors=remount-ro 0       1
UUID=3c804805-c41e-4b9d-af02-118b98858ae4 /boot           ext2    defaults        0       2
UUID=8EA5-5319  /boot/efi       vfat    umask=0077      0       1
UUID=bf088ec8-140d-4829-8de7-deb1d375b0e5 /home           ext4    defaults        0       2
UUID=E2A8CA84A8CA5727 /mnt/Windows    ntfs    defaults,umask=007,gid=46 0       0
UUID=3fb0b28d-87d8-4162-b469-1c157a4d00b0 none            swap    sw              0       0
1
fstanis

Ich bin der Betreuer von REFInd.

Dies ist ein Problem mit dem Dateisystemtreiber. Aus Gründen, die ich nicht vollständig verstehe, sind einige der Dateisystemtreiber von rEFInd (insbesondere der Treiber ext2_x64.efi) auf einigen Computern langsam. Ich habe dem Treibercode vor einigen Jahren einen groben Readahead-Cache hinzugefügt, was sehr geholfen hat. Unter VirtualBox hat sich die Geschwindigkeit von einer Ladezeit von etwa 3 Minuten auf einige zehn Sekunden (IIRC) verbessert. Einige Computer haben jedoch auch mit diesem Cache weiterhin Probleme.

Die Lösung besteht darin, auf ein anderes Dateisystem zu wechseln. Der ext4fs-Treiber von rEFInd ist viel schneller als der ext2/3fs-Treiber, und die Btrfs- und ReiserFS-Treiber sind noch schneller. (Beachten Sie, dass der ext4fs-Treiber ext2fs lesen kann, aber auf diese Weise kaum oder gar keine Geschwindigkeitsverbesserung bietet. Er muss ein tatsächliches ext4-Dateisystem lesen, um eine Geschwindigkeitsverbesserung zu erzielen.) Im schlimmsten Fall können Sie FAT verwenden, was erforderlich ist kein spezieller Treiber (in alle EFIs eingebaut); oder auf einem Mac können Sie HFS + verwenden. (Es gibt auch einen HFS + -Treiber, der mit rEFInd geliefert wird. Im Prinzip können Sie HFS + also auch auf einem Nicht-Mac-PC verwenden, aber es macht wenig oder gar keinen Sinn, dies zu tun.) Ein Wechsel von einem Standard-Linux-Dateisystem ist jedoch nicht ratsam. Ubuntu verlässt sich bei einigen (aber nicht allen) Kernel-Updates auf symbolische Links, was FAT zu einer schlechten Wahl macht. und obwohl HFS + funktionieren sollte, wird es von Ubuntu nicht offiziell unterstützt. Sogar ReiserFS ist im Ubuntu-Installationsprogramm keine Option, daher würde ich Ubuntu davon abhalten. Das lässt ext4fs und Btrfs übrig.

Der Wechsel ist recht unkompliziert, aber nicht risikofrei. Wenn Sie einen Fehler machen, ist Ihr System möglicherweise nicht mehr bootfähig. Das Bare-Bones-Verfahren ist:

  1. Kopieren Sie den neuen Dateisystemtreiber in das Unterverzeichnis rEFInd drivers oder drivers_x64 (wahrscheinlich /boot/efi/EFI/refind/drivers oder /boot/efi/EFI/refind/drivers_x64). Durch das Entfernen der alten ext2_x64.efi -Datei von diesem Speicherort wird die Ladezeit von rEFInd um ungefähr eine Sekunde verringert.
  2. Hängen Sie den ESP (/boot/efi) aus.
  3. Sichern Sie die Partition /boot. Sie können hierfür Zip, tar, cp oder ein anderes Tool auf Dateiebene verwenden.
  4. Hängen Sie /boot aus.
  5. Erstellen Sie ein neues Dateisystem auf der Partition /boot.
  6. Geben Sie Sudo blkid /dev/sda{x} ein (indem Sie /dev/sda{x} in den Bezeichner für Ihre /boot -Partition ändern), um den neuen UUID-Wert zu ermitteln.
  7. Bearbeiten Sie /etc/fstab, um den UUID-Wert und den Dateisystemtyp für die Partition /boot zu ändern.
  8. Geben Sie Sudo mount -a ein, um die neue /boot -Partition bereitzustellen. (Es wird sich wahrscheinlich beschweren, dass es keinen /boot/efi Einhängepunkt gibt. Sie können diese Warnung ignorieren.)
  9. Stellen Sie die gesicherten /boot Dateien im neuen /boot Dateisystem wieder her.

Zu diesem Zeitpunkt sollten Sie in der Lage sein, neu zu starten, und es wird besser funktionieren. Ein Fehler kann jedoch dazu führen, dass das System nicht mehr gestartet werden kann. Um dieses Risiko zu verringern, können Sie mindestens einen funktionierenden Kernel, eine initrd-Datei und refind_linux.conf von /boot nach /boot/efi kopieren und Ihre Fähigkeit testen, den Kernel über ESP zu starten. Bevor Sie beginnen. Auf diese Weise können Sie im Falle eines Problems zurückgreifen und neu starten. Wenn es keine Probleme gibt, können Sie den Kernel natürlich aus dem ESP löschen, sobald Sie fertig sind.

Weitere Informationen zu den Treibern von rEFInd finden Sie in der Dokumentation zu diesem Thema:

http://www.rodsbooks.com/refind/drivers.html

4
Rod Smith