Alexander (HH): Universeller Bootmanager

Beitrag lesen

Moin Moin!

Dazu kommt (auch wenn Vinzenz mir immer gern das Gegenteil einreden möchte), dass schon kleine Pannen dazu führen können, dass ein NTFS-Volume komplett futsch ist, während FAT32 doch ziemlich robust und im Schadensfall leicht zu reparieren ist - notfalls sogar von Hand mit einem Hex-Editor und selbst wenn das Backup nicht tagesaktuell ist.

NTFS hat Journaling, FAT nicht. Ich hab schon mehr als einer NT-Kiste im laufenden Betrieb den Strom gekappt, das NTFS hat das jedes mal problemlos überlebt. Im Gegensatz zu FAT, da ist mir tatsächlich ein paar Mal das Dateisysten kaputt gegangen.

Und ganz ehrlich: Entweder habe ich ein gutes, automatisch erstelltes und geprüftes Backup, oder der Rechner ist für ein Backup zu unwichtig und wird im Problemfall stumpf neu aufgesetzt oder mit einem Image beglückt. Aber ich werde auf gar keinen Fall mit einem Hex-Editor an einer x Gigabyte großen FAT-Partition herumfrickeln. Dafür ist mir meine Zeit einfach zu schade.

Ja, aber wenn Du aus einem anderen Bootloader (Syslinux, Grub, LILO) Windows in verschiedenen Konfigurationen starten willst, MUSST Du NTLDR bzw. den von NTLDR gestarteten Prozessen mitteilen, welche Konfiguration aktiv sein soll.

Ich glaube, du irrst.

Nein, ich beschreibe Dein Problem.

Wenn ich den Windows-Kernel (ntoskrnl.exe) direkt starten wollte, dann müsste ich ihm eine Reihe von Informationen mitgeben bzw. etwas Vorarbeit leisten. Aber ntldr fängt mit Null an und ermittelt all diese Boot-Informationen ja erst.

Exakt das ist Dein Problem.  NTLDR ist nicht dafür vorgesehen, von einem vorgeschalteten Boot-Loader Informationen darüber zu bekommen, wie Windows gestartet werden soll.

Eigentlich alle Bootloader für Linux und Co. übergeben dazu einen String an den Betriebssystemkern bzw. den vorgeschalteten Loader (z.B. memdisk, Chain-Loader, comboot-Programme, ...). Den müßte Dein Spezial-Loader für Windows auswerten und wenigstens in Teilen weiterreichen.

Nicht wenn ich tatsächlich ntldr lade und starte, so wie das sonst der Code im Bootsektor tut. Dann macht ntldr die Arbeit und stellt die gesammelten Informationen schließlich dem OS-Kernel zur Verfügung.

Genau das ist Dein Problem. Du willst nicht, dass NTLDR & Co. selbst austüfteln, was möglich ist, und ein entsprechendes Menü produzieren bzw. eine sinnvolle Auswahl automatisch treffen. Du willst, dass diese Auswahl *vor* NTLDR & Co passiert, im Menü des vorgeschalteten Boot-Loaders (LILO, GRUB, SYSLINUX). Und Du willst, dass NTLDR & Co. diese Information bekommen, auswerten und entsprechend handeln, OHNE selbst ein Menü anzubieten oder automatisch eine der Möglichkeiten auswählen. Dazu muß die Auswahl aus dem Menü des vorgeschalteten Boot-Loaders an NTLDR weitergegeben werden, der muß entsprechend handeln und seinerseits bestimmte Informationen weitergeben. Geschieht das nicht, hast Du den Status quo: Zwei kaskadierte Menüs.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".