Hallo Ich frage mich gerade, wie das Betriebssystem von der Festplatte in den RAM kommt? Ich weiß schon, dass das BIOS den Code von der Festplatte holt, der in der Bootsequenz steht. Aber das müsste ja bedeuten, dass im BIOS schon ein HDD Treiber vorhanden ist, oder? Noch eine Frage: Wie sieht das beim Raspberry Pi (also bei ARM) aus? Da müsste doch das ganze gleich aussehen, oder (halt statt HDD-Treiber ein SD-Karten-Treiber)? Gibt es da dann irgendwelche bestimmten Dinge, die im Code in der Bootsequenz stehen müssen, damit sie vom BIOS geladen werden? Ich glaube ich habe mal irgendwo gelesen, dass in den letzten 16 Bit des Bootsektor eine bestimmte Zahl stehen muss, oder so ähnlich... :D Und gibt es irgendwelche Tutorials für die ARM-Programmierung? Gibt es dort dann auch den "protected Mode", die GDT und die IDT usw? mfg
Beim PC ist es im Wesentlichen so, wie Du es beschrieben hast. Das BIOS enthält einen rudimentären Treiber, für den/die Festplattencontroller auf dem Mainboard. Bei ARM ist es prinzipiell ähnlich, aber bei jedem Hersteller etwas unterschiedlich. Da ist das "BIOS" genauer gesagt der Bootloader in einem internen ROM oder FLASH Speicher abgelegt, der dann verschiedene Boot-Modi unterstüzt. Das kann das Booten von einer SD-Karte mit einem bestimmten Format sein oder auch das Booten via USB oder serieller Schnittstelle oder das Booten von einem externen ROM oder Flash-Speicher. Der Boot-Modus oder die Bootreihenfolge kann meistens über bestimmte PINs am Chip gesteuert werden.
Samuel J. schrieb: > Aber das müsste ja bedeuten, dass im BIOS schon > ein HDD Treiber vorhanden ist, oder? Ja, und für alles andere von dem das BIOS booten kann, wie CD, USB-Stick usw. Das ist aber nicht viel zu programmieren, der Aufwand steckt i.A. im Controller. Man muss bloss eine Funktion aufrufen "lies Sektor x an Speicheradresse y" und ein bisschen Fehlerbehandlung wie "Disk not found", das wars schon. Georg
Beim x86 lädt der Bootloader, welcher im ersten Sektor des Speichermediums liegt (jedenfalls ein Teil davon), der dann z.B. über die BIOS Interrupts das OS (Kernel) in den RAM lädt. Eine schöne Auflistung der Interrupts gibts hier: http://en.wikipedia.org/wiki/BIOS_interrupt_call (unten Abschnitt Interrupt table). Für Disk Operationen ist dabei der Interrupt 13h zuständig. Beim ARM gibts kein BIOS. Der Bootloader sitzt im ROM und muss dann einen Treiber enthalten, der das Lesen von einem Speichermedium ermöglicht.
Samuel J. schrieb: > Ich frage mich gerade, wie das Betriebssystem von der Festplatte in den > RAM kommt? > Ich weiß schon, dass das BIOS den Code von der Festplatte holt, der in > der Bootsequenz steht. Aber das müsste ja bedeuten, dass im BIOS schon > ein HDD Treiber vorhanden ist, oder? http://de.wikipedia.org/wiki/Bootsektor http://de.wikipedia.org/wiki/Master_Boot_Record http://de.wikipedia.org/wiki/Chainloader Hier wird ein primitiver Bootloader entwickelt der das "OS" (dort ein Helloworld) lädt und ausführt: http://www.lowlevel.eu/wiki/Teil_4_-_Hello_World > Noch eine Frage: Wie sieht das beim Raspberry Pi (also bei ARM) aus? Da > müsste doch das ganze gleich aussehen, oder (halt statt HDD-Treiber ein > SD-Karten-Treiber)? Das steht bei dem im ROM, nennt sich dort nicht BIOS, im Prinzip ist es das selbe, der Ablauf ist dann halt ein bischen anders. > Gibt es da dann irgendwelche bestimmten Dinge, die im Code in der > Bootsequenz stehen müssen, damit sie vom BIOS geladen werden? s. o. wikipedia, alle ist dort erklärt. > Ich glaube > ich habe mal irgendwo gelesen, dass in den letzten 16 Bit des Bootsektor > eine bestimmte Zahl stehen muss, oder so ähnlich... :D 0x55 0xAA Endemarkierung > Und gibt es irgendwelche Tutorials für die ARM-Programmierung? > Gibt es dort dann auch den "protected Mode", die GDT und die IDT usw? PM: Nein, völlig andere Architektur. Wenn mich nicht alles täuscht ist dort der Speicher von Haus aus linear Addressierbar, kenne mich aber nicht wirklich mit ARM aus.
eure Angaben zum Laden von einen OS sind aber schon recht veraltet. Aktuell verwendet man eigentlich UEFI. Also den Nachfolger vom Bios. Diese kann nicht nur den Datenträger ansprechen, sondern auch das Dateisystem. Es startet dort direkt den OS-Loader. Es kann damit auch gleich ein boot-Menü anzeigen, wenn mehre OS installiert sind.
1. gibt es wahrscheinlich noch mehr BIOS als UEFI systeme, 2. war nach BIOS gefragt
Vlad Tepesch schrieb: > 1. gibt es wahrscheinlich noch mehr BIOS als UEFI systeme, alle fertig-Computer kommen seit 4-5 Jahren mit UFFI, es betrifft also fast nur alte XP und Vista Computer und Freaks die ihren PC selber zusammenbauen und angst vor UEFI haben. > 2. war nach BIOS gefragt die frage war: > wie wird das OS beim booten aus der HDD geladen?
Samuel J. schrieb: > Ich weiß schon, dass das BIOS den Code von der Festplatte holt, der in > der Bootsequenz steht. Aber das müsste ja bedeuten, dass im BIOS schon > ein HDD Treiber vorhanden ist, oder? Peter II schrieb: > die frage war: > >> wie wird das OS beim booten aus der HDD geladen? Das sieht aber nicht so aus, was er da im Eingangsposting geschrieben hatte... Aber letztlich ist es gleichgültig, ob der HDD-Treiber, der die Arbeit macht, in einem BIOS, in UEFI, oder sonstwo steckt - es ist ein Plattentreiber vorhanden
Uhu Uhuhu schrieb: > Aber letztlich ist es gleichgültig, ob der HDD-Treiber, der die Arbeit > macht, in einem BIOS, in UEFI, oder sonstwo steckt - es ist ein > Plattentreiber vorhanden Wobei die Frage eigentlich eher rethorisch war - es ist sicher auch dem TO klar, dass man ohne Treiber nichts von einer Festplatte lesen kann. Peter II schrieb: > Diese kann nicht nur den Datenträger ansprechen, sondern auch das > Dateisystem Das heisst eigentlich nichts weiter, als dass die Funktionen des Windows-Loaders oder Grub oder sonst einem Multibootloader ins BIOS aufgenommen worden sind. Wobei sicher nicht jedes beliebige Dateisystem möglich ist. Georg
Georg schrieb: > Wobei sicher nicht jedes beliebige Dateisystem > möglich ist. Zur Zeit nur FAT(32) und mehr oder weniger experimentell NTFS, kommt aber auf den Hersteller an ob das Modul mit dabei ist.
Wichtig wäre vlt. die Erwähnung, dass es sich logischerweise um "generische" Treiber für ganze Geräteklassen handelt - im Gegensatz zu den hersteller- und gerätespezifischen Treibern für andere Zusatzgeräte, die erst zu einem späteren Zeitpunkt geladen werden. Bei Tatstatur und Grafik ist das ähnlich, sonst wäre ein Computer zu diesem Zeitpunkt unbedienbar (z.B. BIOS-Einstellungen). Damit werden gerade so die wesentlichsten Grundfunktionen erreicht, die jedes blockbasierte Speichermedium einfach leisten muss, ohne jede Individualität - zu dem Zeitpunkt "weiss" der Computer noch nicht, wie "toll" die gerade angesprochene Festplatte z.B. sonst noch ist ... :-)
:
Bearbeitet durch User
Wobei ich bisher keinen überzeugenden Grund erkennen kann, einen Bootloader mit Kenntnis komplexer Filesystem-Strukturen in ein BIOS zu übernehmen. Allenfalls die aufkommende Methode, zu ladende Komponenten zu zertifizieren und zu kontrollieren, böte da einen Zusammenhang. Denn damit handelt man sich BIOSe ein, die einen starken Bezug zum zu ladenden System herstellen, womit man sich in der Wahl des System nun vom BIOS leiten muss. Bei neueren Systemen hätte man dann die Wahl zwischen einem BIOS Update, den es altersbedingt nicht gibt, einem Zwischenlayer oder Hilfsfilesystem für den Loader oder der Verschrottung. Vielmehr gehört ins BIOS nur eine Schnittstelle zum I/O-System - die ist seit Jahrzehnten drin, nur veraltet - und ein einfach gehaltenes Verfahren zu Beschreibung dessen, was geladen werden soll. Der Rest gehört zum Filesystem, d.h. der Loader im BIOS läd einen zweiten Loader, der das Filesystem kennt. Das bewahrt Flexibilität. Oder kann es sein, dass Flexibilität nicht gewollt ist?
Volle Zustimmung, A.K. Es gibt durchaus glaubwürdige Quellen im Internet, die die Schlussfolgerung ziehen, dass UEFI insbesondere mit "Secure Boot" (und was sich so nennen muss, bezweckt meist das Gegenteil) eher dazu dient, Windows 8 den Weg in den Markt zu ebnen. Als Servicetechniker habe ich schon erlebt, dass die "Angst vor UEFI" gerechtfertigt ist, denn gängige Servicetools machen auf UEFI Systemen oft Probleme - und Nachfolger sind bisher nicht durchgängig verfügbar. Auch der Transfer auf neue Hardware im Defektfall ist sehr heikel: UEFI-BIOSse sind nicht immer voll kompatibel zueinander. Zumal man ganz klar sagen muss: UEFI bringt dort, wo man nicht zwangsläufig GPT braucht, keinerlei Vorteil.
Wobei ich oben den Begriff "BIOS" stellvertredend für jeden Layer verwendet habe, der das System startet. Ob das in PC-Tradition BIOS oder anders heisst ist mir daber erst einmal egal.
Samuel J. schrieb: > Ich frage mich gerade, wie das Betriebssystem von der Festplatte in den > RAM kommt? http://wiki.osdev.org/Bare_Bones
A. K. schrieb: > Wobei ich bisher keinen überzeugenden Grund erkennen kann, einen > Bootloader mit Kenntnis komplexer Filesystem-Strukturen in ein BIOS zu > übernehmen ich finde es sinnvoll. Warum Daten in einen extra Sektor "verstecken" die wo niemand sinnvoll rankommt. Man kann jetzt einfach einen USB-Stick mit FAT formatieren und sein OS-Loader drauf kopieren und schon bootet er. man muss nicht mir irgendwelchen ISOs anfangen und ihn bootfähig machen. Was gab es bei Lilo oder Grub nicht schon für merkwürdige Probleme weil der bootloader zu groß für eine Sektor war und das nachladen vom 2. oder 3. Teil gescheitert ist. Diese Altlast kann man damit endlich Entsorgen. Jetzt gibt es einfach eine Datei und diese hat keine (praxisrelevante) Größenbeschränkung. Ob man das ganze Secureboot von UEFI braucht ist eine andere Frage.
Peter II schrieb: > ich finde es sinnvoll. Warum Daten in einen extra Sektor "verstecken" > die wo niemand sinnvoll rankommt. Ich finde es soweit sinnvoll, wie man ein einfaches Filesystem wie FAT32 als universelles und einheitliches Boot-Filesystem definierte. Das wäre die erwähnte modernisierte Beschreibung dessen, was geladen werden muss, als Ersatz der in die Jahre gekommenen Methode der ersten Sektors. Darin könnten notwendige Basiselemente wie Kernel/HALs und Treiber enthalten sein. Gleichzeitig ist das einfach genug - und in seiner 8.3-Grundversion wohl auch frei von Rechten - um problemlos ein BIOS zu bevölkern, ohne häufigere Updates zu erfordern. Ein Problem habe ich mit dem oben erwähnten NTFS. Generell mit der Idee, im Laufe der Zeit im BIOS etliche gängigen Filesysteme in ihrer Komplexität im BIOS unterbringen zu wollen. Einerseits widerspricht es meinem Sinn für Systematik und Flexibilität. Andererseits ist mir unwohl bei der Vorstellung, quartalsweise im Rahmen von Fixdays das BIOS gleich mit updaten zu müssen.
:
Bearbeitet durch User
A. K. schrieb: > Ich finde es soweit sinnvoll, wie man ein einfaches Filesystem wie FAT32 > als universelles und einheitliches Boot-Filesystem definierte. Du beziehst Dich auf UEFI, oder? Der Vorteil des alten Bootsektor-Verfahrens war ja, daß überhaupt keine Annahmen über Dateisysteme o.ä. gemacht wurden. Das BIOS lädt den ersten Sektor der Festplatte in den Speicher und ruft darin enthaltenen Code auf. Der Rest (Partitionstabelle, Bootloader in Partitionen etc.) ist bereits von diesem Code abhängig und also nicht vom BIOS vorgeschrieben, das weiß gar nichts davon, und erst recht überhaupt nichts von irgendwelchen Dateisystemen. Das ist --mal von der Codegrößenbeschränkung auf einen Sektor abgesehen-- ein extrem elegantes und unendlich flexibles Verfahren.
:
Bearbeitet durch User
Rufus Τ. Firefly schrieb: > Du beziehst Dich auf UEFI, oder? Ich kenne den Aufbau von UEFI selbst nicht, nur stand oben etwas von FAT32 und experimentellem NTFS. Darauf bezog ich mich.
Rufus Τ. Firefly schrieb: > Das ist --mal von der Codegrößenbeschränkung auf einen Sektor > abgesehen-- ein extrem elegantes und unendlich flexibles Verfahren. wo ist das flexibel? jedes OS was man installiert, überschreibt wieder den 1.Sektor. Wenn man mehre OS auf der Platte hat, welches ist denn für den OS-Loader zuständig? Bei einem Filesystem, legt jedes OS einfach eine Datei ab, und das UEFI bietet einer Auswahl an.
Rufus Τ. Firefly schrieb: > Das ist --mal von der Codegrößenbeschränkung auf einen Sektor > abgesehen-- ein extrem elegantes und unendlich flexibles Verfahren. Korrekt. ich habe damit auch kein Problem. Die Frage stellte sich mir nur, ob man das dezent modernisieren könnte, ohne Flexibilität zu verlieren und ohne erhebliche Komplexität in den ROM-Bootloader einbringen zu müssen. Ein readonly-FAT32 scheint mir an dieser Stelle heutzutage vertretbar. Es wäre natürlich auch eine andere Loader-Spezifikation denkbar, aber FAT32 ist halt da und ist gut bekannt.
Anders System machen es ja auch nicht anders. der RasPI lädt auch seine Paramter von einer Konfig Datei von einen FAT-Dateisystem. Navis starten auch den Kernel von einen FAT-Dateisystem (Navigon) PCs haben sich bis jetzt nur nicht mit angepasst.
Peter II schrieb: > Bei einem Filesystem, legt jedes OS einfach eine Datei ab, und das UEFI > bietet einer Auswahl an. Und das klassische Verfahren wäre dazu kompatibel, indem ein sekundärer Bootloader geladen wird, der exakt diese Funktion bietet.
Peter II schrieb: > Wenn man mehre OS auf der Platte hat, welches ist denn für den OS-Loader > zuständig? Es muss eben ein Bootlader vorhanden sein, zu dem alle OSe kompatibel sind - das hat doch bisher bestens geklappt - warum soll das plötzlich nicht mehr brauchbar sein, außer zum Anheizen eines Verdrängungswettbewerbs, der doch letztlich nur wieder wie dieser unsägliche Browserkrieg ausgehen wird. Da die Hardware doch sowieso vor allem in Fernost hergestellt wird, werden die Chinesen mit ihrem Sinn für Pluralität schon dafür sorgen, dass sich solcher M$-Mist nicht durchsetzen wird. > wo ist das flexibel? jedes OS was man installiert, überschreibt wieder > den 1.Sektor. Der Urlader in BIOS & Co. lädt den eigentlichen Bootlader lädt, der das OS auswählt und lädt ist das in der Tat die flexibelste Lösung. Ob der Ulader im 1. Sektor der Datenträgers liegt, oder nicht, tut keinem weh, so lange sich alle daran halten.
Uhu Uhuhu schrieb: > Es muss eben ein Bootlader vorhanden sein, zu dem alle OSe kompatibel > sind - das hat doch bisher bestens geklappt - warum soll das plötzlich > nicht mehr brauchbar sein, was hat denn daran bist jetzt gut geklappt? Noch nie Leute Hilfe rufen gehört? Wo ist mein Linux hin, ich kenn es nicht mehr bootet? Nach Linux, kann ich Windows nicht mehr bootet? Wie kann ich Win98 und WinNt gleichzeitig installieren?` Das zeigt doch nur das, es bis jetzt nicht wirklich funktioniert hat. Man hat nur damit gelebt weil es keine andere Möglichkeit gab. Schön war so noch nie.
Uhu Uhuhu schrieb: > Da die Hardware doch sowieso vor allem in Fernost hergestellt wird, > werden die Chinesen mit ihrem Sinn für Pluralität schon dafür sorgen, > dass sich solcher M$-Mist nicht durchsetzen wird. EFI wird hauptsächlich von Intel gefördert. Und es hat sich schon durchgesetzt auch wenn es viele gar nicht gemerkt haben. Und nur weil MS auch etwas mitredet, warum soll es dann schlecht sein?
Hier gabs doch schon mal eine ewig lange BIOS vs UEFI Diskussion. konnte sie leider nur nicht finden. Hauptkritik war damals wohl, dass die Hersteller Ihre Marktmacht missbrauchen könnten um Linux oder andere Alternative OSe auszusperren (mittels SecureBoot). Auserdem wurde der integrierte TCP/IP Stack kritisiert, der am OS vorbei heimtelefonieren kann. (Die Diskussion wurde geführt bevor die Snowden Affäre so heiß geworden ist. Ich glaube mittlerweile sieht jeder ein dass solche Lücken, falls vorhanden, definitiv genutzt werden. Mit Paranoia hat das nichts mehr zu tun).
Peter II schrieb: > Noch nie Leute Hilfe rufen gehört? > > Wo ist mein Linux hin, ich kenn es nicht mehr bootet? Wunderbar beobachtet, nur hat das mit dem beschriebenen Mechanismus überhaupt nichts zu tun, sondern mit den sekundären Loadern wie ntloader, und ob die fremde Systeme berücksichtigen. Was Microsoft noch nie getan hat und wohl auch nie tun wird. Im gleichen Geiste dient UEFI auch hauptsächlich dazu, Nicht-Windows-Systeme möglichst fernzuhalten. Wenn du das als Fortschritt ansiehst, ok, deine persönliche Meinung, es gibt aber auch Menschen, die mehr kennen und benutzen wollen als nur MS-Software. Natürlich gab es immer mal wieder Probleme mit den immer grösser werdenen Festplatten, aber auch das hat mit dem Mechanismus erster Sektor nichts zu tun, sondern ob das BIOS die Festplatte überhaupt richtig erkennt. Im Prinzip ist es überhaupt kein Problem, auch von zukünftigen Exa- oder Peta-Byte-Platten den ersten Sektor zu lesen. Deshalb ist es völlig überflüssig, sich im BIOS den nie endenen Ärger mit zahlreichen und immer neuen oder, wie bei MS, undokumentiert geänderten Dateisystemen einzuhandeln. Georg
Ich hab auch so meine vorbehalte gegen UEFI. Habe jetzt schon mehr als einmal und an mehr als einem PC mit UEFI erlebt, dass beim Booten die Meldung kommt: "Das BIOS ist korrupt. Es wird eine Wiederherstellung aus einem Backup durchgefuehrt..." Komisch, das gibts erst seit UEFI, vorher hat das immer tadellos funktioniert. A. K. schrieb: > Oder kann es sein, dass Flexibilität nicht gewollt ist? Ich denke schon. Es ist ja immerhin so, das Microsoft per Windows-Update Schluessel in irgendeinem Speicher auf dem Mainboard ablegen kann. Und jeder OS-Hersteller, der sich keinen Schluessel von M$ kauft, dessen OS kann man dann nicht mit diesem Mainboard verwenden. Gilt "nur" in verwendung mit "SecureBoot" soweit ich weiss. Fedora soll einen Schluessel gekauft haben, soweit ich weiss. Im Endeffekt entscheidet Microsoft darueber, mit welchem OS man seine Hardware weiter benutzen darf, wenn man einmal SecureBoot + Windows8 installiert hatte... Ja, gut man soll das alles abschalten koennen, aber ob sich alle Hersteller fuer die naechsten droelf Jahre dran halten, besweifel ich dann doch stark.
1 | Ohne bewussten Eingriff des Nutzers startet also außer dem |
2 | vorinstallierten Windows 8 kein anderes Betriebssystem, außer |
3 | wenn es einen von Microsoft digital signierten UEFI-Bootloader |
4 | mitbringt. |
5 | |
6 | ... |
7 | |
8 | Auch bei aktiviertem Secure Boot lässt sich per BIOS-Setup das |
9 | Laden eines Compatibility Support Module (CSM) erlauben. Dieses |
10 | CSM stellt nach dem eigentlichen Firmware-Start BIOS-Kompatibilität |
11 | her, sodass beliebige andere Betriebssysteme ohne UEFI-Bootloader |
12 | starten. Genau aus diesem Grund verlangt Microsoft in den Hardware |
13 | Certification Requirements für Rechner mit Windows-8-Logo, dass bei |
14 | Secure Boot das CSM unterbunden wird. |
http://www.heise.de/ct/meldung/Mainboard-Firmware-fuer-UEFI-Secure-Boot-1704822.html Ganz zu schweigen von den ganzen LapTop-Problemen, wo man die Laptops in den Muell werfen konnte, weil UEFI/SecureBoot dafuer gesorgt haben das die nichts mehr gemacht haben. Wird schon seine Gruende haben, weshalb die Linuxgemeinde so ihre Vorbehalten gegen SecureBoot usw. hat. Schoene neue Welt...
Georg schrieb: > mit zahlreichen und immer neuen oder, wie bei MS, undokumentiert > geänderten Dateisystemen einzuhandeln. Wenn der Bootloader eines BIOS nach dem neuesten Patch nicht mehr funktioniert, dann ist die Kiste ohne Fallback-BIOS nur noch Sondermüll. Ich weiss nicht wie es euch geht, aber mein Adrenalinpegel unterscheidet sehr gut zwischen Patchday vom Betriebssystem und Patchday vom BIOS.
Georg schrieb: > Wunderbar beobachtet, nur hat das mit dem beschriebenen Mechanismus > überhaupt nichts zu tun, sondern mit den sekundären Loadern wie > ntloader, und ob die fremde Systeme berücksichtigen. doch hat es, Windows konnte über seinen sekundären Loadern genauso Linux sarten. Nur hat Linux oft einfach den MBR überschrieben. > Im gleichen Geiste dient UEFI > auch hauptsächlich dazu, Nicht-Windows-Systeme möglichst fernzuhalten. > Wenn du das als Fortschritt ansiehst, ok, deine persönliche Meinung, es > gibt aber auch Menschen, die mehr kennen und benutzen wollen als nur > MS-Software. wie jeder den nicht versteht, das UEFI und SecureBoot nicht das gleiche ist. SecureBoot ist eines von vielen Modulen im UEFI was PCs abschaltbar ist. Und Linux kann mittlerweile auch von UEFI booten (mit oder ohne SecureBoot). Wo sieht du dort versuche Linux fernzuhalten? Was sieht du als alternative? Warten bis Linux (wer auch immer das sein mag) eine eigene Spezifikation für ein Bios veröffentlicht oder noch 100Jahre lang, die Altlasten rumschleppen? Was ist wenn in ein paar Jahren, der Nachfolger von SATA (NVMe) nicht mehr zum alten Bios passt und er gar kein OS mehr bootet kann. Dann wird der Grund auch auf MS geschoben.
Aber nein, nicht gleich das Kind mit dem Bade ausschütten. Von IDE zu SATA gab es auch Adapter. Ein sinnvolles Konzept ist jedoch nicht gleichbedeutend mit einer Altlast. Heute neigt man leider dazu, durch übermäßige Spezialisierung kurzlebige Lösungen zu produzieren. Dann lieber einen einfachen Standard, der ohne regelmäßige Updates funktioniert - zumindest bei wichtigen Systemkomponenten. Im Übrigen hat Microsoft schon eine Mitschuld: Es gibt eine Anweisung für PC-OEMs, daß Rechner mit Windows 8 / 8.1 zwangsläufig mit UEFI und Secure Boot installiert werden müssen, obwohl das System problemlos mit BIOS liefe. Ein Schelm, wer Böses dabei denkt, nicht wahr? Leider sind wir jetzt schon weit Offtopic...
Sebastian schrieb: > Im Übrigen hat Microsoft schon eine Mitschuld: Es gibt eine Anweisung > für PC-OEMs, daß Rechner mit Windows 8 / 8.1 zwangsläufig mit UEFI und > Secure Boot installiert werden müssen, obwohl das System problemlos mit > BIOS liefe. Ein Schelm, wer Böses dabei denkt, nicht wahr? nicht ganz, große Festplatten (>2TB) haben brauche eine GPT und MS unterstützt nun mal nur GBT in Kombination mit UEFI. Damit läuft es ebend nicht problemlos. Klar hätte MS auch auf GPT für nicht BIOS unterstützten können, aber warum sollte sie?` Und wie viele PCs kennst du wo SecureBoot nicht abschaltbar ist?
A. K. schrieb: > Wenn der Bootloader eines BIOS Man sollte zwischen Urlader und Bootlader unterscheiden. Aufgabe des Urladers ist, den Bootlader zu laden und zu starten.
Peter II schrieb: > Nur hat Linux oft einfach den MBR überschrieben. Das ist wohl weniger Linux, als das System, das vor der Tastatur sitzt. Bei einer Linux-Installtion hat man die Wahl, den Bootlader auf den MBR oder auf die Partition zu installieren.
Uhu Uhuhu schrieb: > Man sollte zwischen Urlader und Bootlader unterscheiden. Könntest du mir das bitte ins Englische übersetzen? ;-) Ich hätte freilich noch IPL anzubieten. Initial Program Load.
Peter II schrieb: > GBT Wie darf man diese Abkürzung deuten? Green-Bank-Teleskop Gotthard-Basistunnel Green Bank Telescope
Uhu Uhuhu schrieb: >> GBT > > Wie darf man diese Abkürzung deuten? Wenn du das etwas weiter entsächselst, dann passt es.
:
Bearbeitet durch User
Uhu Uhuhu schrieb: > Peter II schrieb: >> GBT > > Wie darf man diese Abkürzung deuten? Es ist wohl eher GPT ( GUID Partition Table) gemeint... Zu meinem NTFS Kommentar: Beim Support für NTFS geht es nicht darum von dort einen Bootloader zu laden (was natürlich funktioniert), sondern eher um in der EFI Shell auf das Dateisystem zugreifen zu können. Es gibt übrigens auch einen kommerziellen UEFI Treiber der das MAC Dateisystem kann. Die Partition auf welcher der Bootloader liegt (EFI System Partition), ist mit FAT32 spezifiziert.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.