BIOS-Boot funktioniert nicht, aber über das Boot-Menü schon

Tanzmusikus schrieb:
Vielleicht hilft ein Vertauschen der SSDs am SATA-Controller,
also zw. den beiden gespiegelten Boot-LW: SATA_1 <-> SATA_2.
Das habe ich alles gemacht, alle internen SATA-Ports und sogar mit unterschiedlichen SSDs probiert.

@nightlite Ich bin ich ganz sicher, was du mir sagen willst. Es geht nicht um das Booten von Windows.
Der Eintrag für die SSD ist im BIOS vorhanden (und steht an erster Stelle der Boot-Liste).
 
  • Gefällt mir
Reaktionen: Tanzmusikus
nightlite schrieb:
Wenn du das System gestartet ist kannst du nachschauen ob das System per UEFI oder im MBR-Mode gebootet hat?
Wie Du vielleicht überlesen hast, wurde das bereits getestet:
hlehofer schrieb:
cartridge_case schrieb:
Deaktiviere mal den UEFI-Boot.
Hab ich gemacht.
Bringt keine Änderung (abgesehen von einem blinkenden Cursor bevor die Insert-Boot-Media-Meldung kommt.
@nightlite Also ist der UEFI-Boot-Modus aktiv.

***

BootIce (v1.3.4.0 von 2016) ist veraltet.
Meiner eigenen Erfahrung nach ist mit dem Programm Vorsicht walten zu lassen.
Ich hatte mir damit einen WBM damit zerschossen als ich nur eine simple Prio-Änderung vorgenommen hatte.
Zum Glück hatte ich vorher ein Backup mit EasyUEFI gemacht.

***

@hlehofer

Mein Vorschlag ist:
Sichere die Start-Partition "bios_grub" auf einen anderen Datenträger (z.B. mit EasyUEFI oder Efibootmgr).
Dann lösche sie.
Nun sollte der UEFI-Boot auch automatisch möglich sein.

Grüße
 
@hlehofer
Hier wird erwähnt, dass ein Hardware-RAID für das problemfreie Booten gespiegelter Laufwerke nötig wäre:
https://de.trbc4him.org/300826-is-it-possible-and-wise-RWBVHS

Ein BIOS-RAID (auch Fake-RAID genannt) oder ein Software-RAID (z.B. durch Linux, Windows) sollen eventuell ebenso möglich sein. Welches der genannten Arten verwendest Du denn?

https://askubuntu.com/questions/43036/how-do-i-install-grub-on-a-raid-system-installation/57010
https://help.ubuntu.com/community/FakeRaidHowto
https://help.ubuntu.com/community/Installation/SoftwareRAID
https://serverfault.com/questions/7...ut-the-grub-bios-partition-on-a-software-raid

Grüße
 
@Tanzmusikus
Das Löschen der bios_grub Partition werde ich bei nächsten Gelegenheit testen. Das klingt interessant.

Zum Boot-RAID:
Gleich vorweg: ich habe auch mit nur einer SSD getestet.
Die Installation erfolgt ganz normal auf eine single SSD und natürlich kann das System auch so betrieben werden. Es wird aber in der Dokumentation ausdrücklich empfohlen, auch für die Boot-SSD ein ZFS-Mirror-Pool einzurichten, was ich auch getan habe. Man fügt dazu einfach eine zweite SSD dazu, worauf das System die Daten der Boot-SSD auf diese spiegelt.
Alles RAID ist rein Software (die SATA-Ports im BIOS sind auf AHCI gestellt).
 
  • Gefällt mir
Reaktionen: Tanzmusikus
hlehofer schrieb:
Das Löschen der bios_grub Partition werde ich bei nächsten Gelegenheit testen. Das klingt interessant.
Auf jeden Fall Backup machen!

Die RAW-Partition mit "bios_grub"-Flag wird verwendet, um einen GPT-partitionierten Datenträger für Linux im Legacy/BIOS-Modus bootfähig zu machen.

***

Wenn Du ein Software-RAID (Linux) nutzt, dann sollte das Spiegeln (glaube ich) nur die Datenpartition(en) betreffen. Also die Bootpartition(en) -> ESP (FAT32) und ggf. bios_grub (RAW) sollten "unique" (also nicht gespiegelt) sein. Bin mir aber nicht sicher, hab's nur gelesen. Könntest beides testen, wenn Du magst ... oder es lassen. :daumen:

***

Bitte auch mal ein paar Infos zum System geben - Danke!
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
sudo parted -l

Falls noch nicht geschehen: sudo apt-get install efibootmgr ... sowie: sudo efibootmgr -v

***

Hier ist noch ein gutes Lehrbeispiel für Durcheinander beim Wechsel von BIOS/MBR auf (U)EFI/GPT:
http://www.ubuntu-forum.de/artikel/67424/grub2-nach-umstellung-von-mbr-auf-gpt.html

Grüße
 
So, am Ende wird doch alles gut.

Zuerst habe ich erstaunt festgestellt, dass das System im BIOS Mode läuft:
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
BIOS

Dann habe ich die 'bios_grub'-Partition gelöscht und rebootet.
Das hat nichts gebracht (sowohl mit UEFI im BIOS ein- und ausgeschalten).

Ich habe parallel im TrueNAS-Forum mit einigen der Stichworten aus obigem Post gesucht. Dabei bin ich auf ein Posting gestoßen, wo bei einem Boot-Problem vorgeschlagen wird, die Boot-Disk am HBA anzuschließen.
Einen HBA (Avago LSI SAS 9211-8i) habe ich auch im System. Ich habe ich hier gar nicht erwähnt, da ich in dem Ding nicht mehr sah als 8 zusätzliche SATA-Ports. Ich wäre nicht auf die Idee gekommen, dass an den HBA angeschlossene Devices bootfähig sind (und habe es natürlich auch nicht getestet).
Jedenfalls wird die SSD am HBA gebootet und alles funktioniert wie erwartet (bei deaktiviertem UEFI im BIOS, mit aktivem wird nicht gebootet).

Vielen Dank hier Allen für den Input, vor allem natürlich @Tanzmusikus, der die entscheidenen Hinweise lieferte.
 
  • Gefällt mir
Reaktionen: Tanzmusikus
hlehofer schrieb:
Jedenfalls wird die SSD am HBA gebootet und alles funktioniert wie erwartet (bei deaktiviertem UEFI im BIOS, mit aktivem wird nicht gebootet).
Na dann ist ja alles klaro mit Manjaro (reimt sich so schön).

***

BIOS-Boot mit MBR oder GPT?
Willst Du bei BIOS/CSM bleiben ... oder UEFI-only-Boot umsetzen?

Naja egal, wenn's Dir egal ist. :daumen:


Gestern kamen mir noch diese Ideen (lasse sie jetzt einfach hier stehen für Interessierte):

Hier sind Infos zu BIOS/MBR/"bios_grub" ... und (U)EFI/GPT/"ESP":
https://qastack.com.de/ubuntu/500359/efi-boot-partition-and-biosgrub-partition
Dir sollte klar werden, ob Du Dein Linux-System im Legacy-BIOS ... oder (U)EFI-only Modus booten möchtest.

Meine Empfehlung wäre (U)EFI-Boot.


hlehofer schrieb:
@nightlite Ich bin ich ganz sicher, was du mir sagen willst. Es geht nicht um das Booten von Windows.
Der Eintrag für die SSD ist im BIOS vorhanden (und steht an erster Stelle der Boot-Liste).
Vermutlich meint er, dass Du mal überprüfen könntest, ob es sich im NVRAM des Mainboards um einen aktuellen oder verweisten (boot-unfähigen) EFI-Eintrag handelt.

Testweise also Löschen und Neuerstellen des EFI-Booteintrages mittels efibootmgr.
https://wiki.gentoo.org/wiki/Efibootmgr/de

Grüße
 
Tanzmusikus schrieb:
BIOS-Boot mit MBR oder GPT?
Willst Du bei BIOS/CSM bleiben ... oder UEFI-only-Boot umsetzen?

Naja egal, wenn's Dir egal ist. :daumen:
Die Boot-SSD sind GPT (laut parted)
Zumindest kurzfristig will ich da nichts ändern. Das System funktioniert gerade gut, also am Besten gar nicht mehr hingreifen. :)

Irgendwann wird es mich stören, und dann beginnt die ganze Spielerei von vorne...

Ich bin mir auch nicht so ganz sicher, ob diese Motherboard wirklich UEFI tauglich ist.
Im BIOS steht bei der UEFi-Option nur, dass dieser Modus benötigt wird, um Disks größer als 2 TB zu booten.
Das Board kommt aus einer Zeit, wo das ganze UEFI-Thema erst ganz langsam aufkam.

Tanzmusikus schrieb:
Dir sollte klar werden, ob Du Dein Linux-System im Legacy-BIOS ... oder (U)EFI-only Modus booten möchtest.

Meine Empfehlung wäre (U)EFI-Boot.
Was macht das für einen Unterschied? Wenn das System erst einmal gebootet ist, spielt das doch keine Rolle mehr, oder übersehe ich das etas?
 
hlehofer schrieb:
Im BIOS steht bei der UEFi-Option nur, dass dieser Modus benötigt wird, um Disks größer als 2 TB zu booten.
Das Board kommt aus einer Zeit, wo das ganze UEFI-Thema erst ganz langsam aufkam.
Der 1. Satz ist auch vollkommen korrekt, egal wie viele Funktion das UEFI unterstützt oder nicht.
Zumindest ist ein (wie-auch-immer-gearteter) UEFI-Modus möglich.

hlehofer schrieb:
Was macht das für einen Unterschied? Wenn das System erst einmal gebootet ist, spielt das doch keine Rolle mehr, oder übersehe ich das etas?
Das stimmt, das spielt dann keine große Rolle mehr.

Allerdings ist UEFI-Boot so schön klar strukturiert und man kann x-beliebig viele Primärpartitionen erstellen.
Und man kann auch x-beliebig viele EFI-Partitionen anlegen. Löschen oder Verschieben eines BS inkl. Partition/BL ist sowas von simpel.

Just my 2 cents ...
 
Zurück
Oben