Linux 14.985 Themen, 106.409 Beiträge

Ubuntu bzw. Grub2 kann kein GPT

Xdata / 45 Antworten / Flachansicht Nickles

hi

Entgegen den Behauptungen " Ubuntu, oder Linux allgemein, kann GPT " gilt:
-- Es kann es nicht!

Weil Grub2 es nicht kann.

Zwar wird im UEFI modus gestartet Linux, speziell Ubuntu, sauber installiert,
es kommt aber nach der Installation nur ein schwarzes Grub-Fenster.

Windows 10 hat das problemlos, ohne Wenn und Aber gepackt.
Wird in den schwarzen toten Grub Startbildschirm exit eingegeben startet immerhin noch Windows 10.

Warum schafft es Linux nicht
-- so wie es Windows vormacht:
Default und ohne kryptischen Umwege dies und mehr
direkt umzusetzen?

Es ist nicht der erste Versuch.

Ob ohne oder mit schon instalierten Windows, mit
AsRock, MSI, gigabyte UEFI Motherboards.

Windows kan GPT immer.
Ubuntu kann GPT nie.

Immer kommt ein schwarzer Grub unereichbar das insallierte Linux!

bei Antwort benachrichtigen
Borlander Greif 72 „Danke Borlander, für Deine hilfreichen Richtigstellungen und erkenntniserweiternden Klarstellungen. So hatte ich z.B. noch ...“
Optionen
In welchem Entwicklungsstadium befindet sich das Dateisystem [ReFS]. Mein im August erstandenes Notebook wurde noch mit WIN10 Home auf NTFS ausgeliefert[...]. 

ReFS ist ab Win2012 Server bzw. Win8.1 verfügbar. (Steht übrigens auch im Wikipedia-Artikel.) Windows kann bislang allerdings nicht von ReFS booten und es wurden einige NTFS-Features entfernt.

dass Windows seine Dateien nicht einfach auf der Partition nacheinander Aufspielt, sondern nach einem bestimmten Algorithmus anordnet. […] Hiermit ist meiner Meinung nach zunächst einmal eindeutig Bewiesen das NTFS entsprechende Algorithmen besitzt!

Windows besitzt Mechanismen um die Anordnung der zum Systemstart benötigten Dateien zu optimieren. Das passiert aber soweit mir bekannt nicht online (direkt beim erstellen der Dateien), sondern muss durch die (automatische) Ausführung eines entsprechenden Systemtools realisiert werden. Das ganze würde ich nun aber nicht als Bestandteil von NTFS bezeichnen, sondern ist eine Windows-Spezifische Funktion.

Ein Dateisystem als solches spezifiziert eigentlich erst mal nur die Datenstrukturen zur Dateiverwaltung auf einem Speichergerät. Die Algorithmen sind Bestandteil eines Dateisystemtreibers bzw. einer Implementierung des Dateisystems. Eine solche Implementierung sollte als Minimalanforderung im Regelbetrieb sicherstellen, dass Dateisystemoperationen die Datenstrukturen des Dateisystems aus einem fehlerfreien Ausgangszustand in einen fehlerfreien Folgezustand überführen. Die allen praxisrelevanten Dateisystemen existiert natürlich auch eine Referenzimplementierung, die das leistet. Der Folgezustand kann auch identisch mit dem Ausgangszustand bleiben, wenn die Dateisystemoperation mit Fehlerbehandlung abgebrochen werden muss (z.B. weil nicht mehr genug Platz auf dem Datenträger vorhanden ist). Moderne Dateisysteme besitzen oft auch Datenstrukturen die Implementationen erlauben die robust sind gegenüber Unterbrechungen bei Schreibvorgängen und einen abschließenden atomaren Zustandswechsel ermöglichen. Siehe auch COW (CopyOnWrite).

Auch glaube ich nicht das Windows bei der Veränderung einer größeren Datei den vielleicht gleichbleibenden Anteil beibehält und nur die zusätzlichen bzw. veränderten Teile neu abspeichert. Ich glaube vielmehr das Windows zunächst mal nur die MFT Daten und diese Bereiche zunächst noch fürs Überschreiben sperrt; und die komplette Datei neu anlegt!

Hier muss ich Deinen Glauben leider in den Grundfesten erschüttern:

Bei schreibende Zugriffe auf bestehende Dateien wird aus gutem Grund nicht jedes mal die komplette Datei kopiert. Das wäre für die IO-Performance und das Gesamtsystem fatal: Jedes Schreiben in eine Log-Datei, jede Änderung in der Registry würde das richtig teuer weil für die Ablage von ein paar Bytes schnell Datenmengen im MB-Bereich kopiert werden müssten. Noch extremere Auswirkungen hätte das ganze beim Einsatz von einer VM. Schon der Start eines Windows-Systems in der VM würde dann Schreiboperationen von wahrscheinlich mindestens 100GB nach sich ziehen um jedes mal das Image zu kopieren. Abgesehen davon könnte man dann nur noch Schreibend auf Datei zugreifen, wenn das Dateisystem noch so viel Platz bietet dass alle zum schreiben zu öffnenden Dateien darin gleichzeitig Platz fänden.

Bei COW beschränkt man sich für gewöhnlich darauf, dass nur Sektoren die verändert werden temporär doppelt vorgehalten werden. Nach Abschluss der Operation werden dann die neuen Sektoren der Datei zugeordnet. Dieser Ansatz zieht fast zwangsläufig eine Fragmentierung nach sich, aber erlaubt auf der anderen Seite auch ein sehr schlankes vorhalten von älteren Dateiversionen, da unveränderte Sektoren nur einmalig gespeichert werden müssen. Ich vermute, dass bei den Schattenkopien von Windows ein solches Verfahren zum Einsatz kommt. Das wird zumindest in vielen Dateisystemen umgesetzt.

Und hier fehlt jetzt meiner Meinung nach ein Algorithmus der Windows erst einmal auf die Suche nach einem von der Größe her passenden Bereich suchen lassen würde um dann dort zusammenhängend zu Speichern!

Das ist bei NTFS der Standard. Um diese schnell zu ermöglichen wird das Datenträgerbitmap mit den verfügbaren Sektoren mitgeführt.

Windows beginnt dann mit dem Speichern beim ersten freien Fitzelchen und setzt das dann über den gesamten Bereich fort.

So lief das ganze klassischerweise bei FAT. Wobei ich nicht ausschließen möchte, dass es FAT-Implementierungen gibt die das besser machen.

bei Antwort benachrichtigen