Linux lässt sich nicht mehr hochfahren (OMV5)

Thunfischsalat

Lieutenant
Registriert
März 2012
Beiträge
791
Guten Abend,
ich bin recht neu bei OMV5 und generell unerfahren mit Linux.
Ich hatte auf einem alten AM1 System mit einem USB-Stick einen Testballoon laufen, um zu sehen wie alles läuft und ob ich auch alles zum laufen kriege, bevor ich mir die Hardware anschaffe.
Gestern, beim Hochfahren hat das System starke Geräusche (Lüfter?) gemacht und ich habe es sofort heruntergefahren.
Nachdem ich im Gehäuse nach der Fehlerquelle gesucht habe und alles wieder zusammengebaut habe konnte ich das System nicht mehr hochfahren.
Entweder wurde kein Bootmedium gefunden oder er lies sich nur in die "Built-in EFI Shell" booten. Ich vermute durch mein Shutdown beim Hochfahren habe ich etwas zerschossen.
Im BIOS kann ich entsprechend nur den Stick auswählen, welcher nicht bootet, oder wiederum in die EFI Shell gehen.
In der EFI-Shell habe ich aber keine Ahnung was ich machen kann. Ich weiß ich sehe dort die Partitionen, aber wofür welche ist ist oder was der nächste Schritt ist ist mir immer noch ein Rätsel. (Ich bin die letzten 15 Jahre fast nur mit Windows gefahren.)

Wenn ich einen Live-Stick (mit ct-Desinfec't) starte und "Win-Drives einhängen" auswähle, kann ich den OMV5-Stick und seine Dateienstruktur sehen. Nur fehlt mir wiederum das Wissen, um was für einen Fehler es sich handelt oder wo ich anfangen soll zu suchen.

Ich könnte den Stick mit dem OS einfach neu flashen, aber ich würde gerne Fehlersuche betreiben und so dazulernen.
Ich denke im Unterforum "Linux" ist mein Anliegen besser aufgehoben als beim "NAS", falls nicht möge man mich verschieben.
 
Zuletzt bearbeitet:
Ist deine omv5 Installation denn überhaupt im EFI/UEFI Modus gewesen oder noch im legacy BIOS/CSM?
Das wäre nämlich die naheliegendste Vermutung bei dem genannten Fehlerbild.
Stell den Bootvorgang mal auf legacy/CSM um und teste erneut. Wie man dies einstellt solltest du dem Handbuch des Mainboards entnehmen können.
 
  • Gefällt mir
Reaktionen: Thunfischsalat
Nun, da gibt es gar nicht so viel zu lernen. Der Boot-Vorgang ist nix wirklich kompliziertes.
  • Auf dem Boot-Medium muss ein Bereich reserviert sein, der ein Programm starten kann (Boot-Sektor)
  • Dieses Programm ist entweder
    • Ein sehr kleiner Boot-Loader (z.B. GRUB, sozusagen eine Weiterleitungssoftware an das nächste Programm)
    • Ein Betriebssystem-Kernel
    • Ein anderes Programm (z.B. ein Spiel)
  • Wenn das Programm eine gewisse Größe überschreitet oder ein komplexeres (verschlüsseltes) Dateisystem laden soll, kann es nötig sein, noch mal ein Zwischen-Programm zu laden, was die "Treiber" für das Dateisystem zur Verfügung stellt - das wäre dann die "init ramdisk" unter Linux
  • Danach geht es dann weiter zum Betriebssystem, bei Windows funktioniert es ähnlich.
Was kann also dein Problem sein?
  1. Dein Boot-Sektor (meist der erste Bereich auf der Festplatte) ist defekt oder wurde irgendwie überschrieben
  2. Die Partitionen oder der ganze Speicher können nicht gelesen werden.
  3. EFI / Legacy wurde verstellt
Soweit ich weiß, nutzt OMV den Boot-Manager GRUB. Wenn also die Datenpartition noch erhalten sind, musst du GRUB einfach noch mal erstellen lassen... das geht mit der Live-CD und grub-install bzw. update-grub oder ähnlichem.

Vorher würde ich aber in jedem Fall einen anderen USB-Stick installieren und prüfen, ob die Daten gerettet werden können oder ein Image des Sticks machen (nur zur Sicherheit).
 
  • Gefällt mir
Reaktionen: Thunfischsalat
@snaxilian Seitdem ich W7 nutzte gehe ich eigentlich immer den Weg mit UEFI.
Ich habe mal alle (legacy) boot orders durchgeprüft und dort enden sie Immer im nicht gefundenen Bootmedium bzw. wird als einzige mögliche (nicht UEFI) bootoption der USB-Stick angeboten und es wird wiederum kein Bootmedium gefunden.
Bei "UEFI: SanDisk" komme kurz ein Mainboard-Logo und ich werde sofort zurück zu den Bootoptionen des BIOS/UEFI geschmissen.
Nur wenn ich "UEFI: Built-in EFI Shell" komme ich in die EFI-Shell.

@sandreas
Zu 2.: Mithilfe der Live-CD kann ich zumindest zwei "Datenträger" und deren Inhalt sehen.
Also scheint der Stick ok zu sein oder waren es drei Partitionen?

Zu 3.: Die Booteinstellungen habe ich bereits überprüft

Zu 1.: Wie ist dieser Bootsektor normalerweise benannt? Ist es eine eigene Partition? Die ganze Architektur ist mir noch ziemlich fremd.
Also ist die Lösung des Problems einfach eine neue Partition?
Wie gesagt es war nur ein Testballoon und es sind keine wichtigen Daten auf dem Stick.
Die vorhandenen Einstellungen könnte ich in wenigen Stunden (und diesmal ohne zu pfuschen) wiederherstellen.

EDIT: Ach jetzt weiß ich wieder was du meinst mit GRUB neu erstellen. Also mit den Befehlen aus der Konsole heraus.
Wenn ich das aus der LIVE-CD heraus mache wie stelle ich sicher, dass das GRUB vom OMV5 geupdatet wird und nicht das von der LIVE-CD?
EDIT2: Ich habe mithilfe von Google "GRUB reparieren" einige Beiträge gefunden und werde mich mit dem Ergebnis melden, wenn ich fertig bin. Danke soweit.
 
Zuletzt bearbeitet:
So ich habe jetzt den bootloader neu installiert (glaube ich zumindest).
Ich bin dem Guide gefolgt: https://wiki.debianforum.de/Grub_reparieren
Und habe mithilfe des Debian Netinstallers GRUB repariert. War dann so wie bei "Wiederherstellung bei Logical Volume Management" beschrieben.
Keine Ahnung ob das bei mir das Richtige war.


Jetzt habe ich beim Booten eine kurze Auswahl die ich zuvor, glaube ich, nicht hatte.
"DEBIAN GNU/Linux, with Linux 5.10.0-0.bpo.8"
und dann entsprechend mit "\5.10.0-0.bpo.7" und "\5.10.0-0.bpo.5"
Zusätzlich die drei oben genannten im Recovery Mode und einmal ein "System Setup".
Das verzögert ein bisschen das booten.
Kann man die Auswahl per default überspringen? Da wurde wohl mehr installiert als nötig.

Was ich nicht verstehe ist, dass ich für die Reparatur das root-Verzeichnis benennen sollte. Hab einfach sda1, sda2 und sda3 durchprobiert.
War dann bei sda2 richtig. Ist das bei allen Linux bzw. Debian Distros gleich? Was befindet sich sonst auf sda2 und was ist dann eigentlich auf sda1? Ist sda3 dann das Nutzerverzeichnis?
(Ich weiß das "sd" für "Festplatten" steht und folgend alle Platten nach dem Alphabet durchnummeriert sind.)

Kurzes googlen gab mir keine Antwort.
 
Zuletzt bearbeitet:
Thunfischsalat schrieb:
Was ich nicht verstehe ist, dass ich für die Reparatur das root-Verzeichnis benennen sollte.
Ein Bootloader ist ein Programm, was "weiterleitet". Der Master-Boot-Record befindet sich am Anfang deiner "Festplatte". EFI ist nochmal ein anderes Thema, dafür braucht man ne eigene EFI Partition, die mit FAT32 formatiert ist und bestimmte Dateien enthält.

Kurz gesagt lädt der Bootloader das Dateisystem und startet das Betriebssystem oder besser "den Kernel". Unter Linux gibt es verschiedene Partitionen für verschiedene Zwecke. Damit Grub das Menü erzeugen kann, welches "Programm" gestartet werden soll, muss es wissen, wo die Daten liegen. Deshalb musst du die Partition auswählen, auf der das "Programm" liegt.

Die Erklärung ist natürlich stark vereinfacht, aber im Grunde musst du nur wissen, das Grub eine Konfigurationsdatei hat, die das Menü anzeigt und dieses Menü meist am Anfang der Platte auf einer boot-Partition liegt. Grub selbst liegt im Master-Boot-Record und zeigt das Menü nur an bzw. startet die dort hinterlegten Programme. Jeder Menü-Eintrag ist eine Weiterleitung und wo die hingeht, musst du zumindest grob festlegen. Grub bzw. der Installer kann nur schlecht "automagisch" ermitteln, was du starten willst.

Bezüglich BIOS und EFI: Das BIOS / EFI ist sozusagen die Firmware deines Systems. Die sucht je nach Einstellung entweder den Master-Boot-Record oder die EFI-Partition auf einer Festplatte / einem Stick. Das Programm was dort liegt, kann dann entweder ein Betriebssystem sein oder so ein "Weiterleitungs-Tool" wie grub.

Verwendest du ein exotisches Dateisystem (z.B. ZFS), kann GRUB das nicht einfach so laden und benötigt einen Zwischenschritt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Thunfischsalat
Zurück
Oben