Expand sda1 - alles Quark,0?

[alQamar]

Hallo Community,
in den FAQ bin ich nicht fündig geworden.
Ich möchte in einem gestarteten ubuntu 18.10 die Systempartition vergrößern um 4 GB und erhalte diese Meldung

Da ich mit Linux erste Gehversuche mache bin ich irritiert, dass die nicht wie für mich in Windows Umgebungen gewohnt auf anhieb funktioniert.

Danke für Eure Hilfe! Ich hoffe das es so funktioniert und ich nicht extra noch ein anderes Tool wie gparted benötige.

Ergänzung (23. März 2019)

hab jetzt mal mit gparted gebootet und versucht die FS auf allen Partitionen zu prüfen auch dies ist nicht von erfolg gekrönt. Genausowenig wie die Vergrößerung in gparted von der o.g. Partition. Es könnte alles so einfach sein...

 

[rg88]

Verstehe die Frage nicht? Die Fehlermeldung sagt dir doch eindeutig, was nicht passt. Die Partitionsgröße die du ausgewählt hast, ist zu klein.

2854139 Blöcke * 4096 (Blockgröße ist bei dir 4k) = 11.690.553.344 bytes sind also dein Minimum. Du hast offensichtlich weniger ausgewählt.
Was du eigentlich genau machst, geht aus deinen Screenshots für mich nicht hervor.

 

[K-BV]

Wenn du an der Systempartition rum fummelst, geht das nicht aus dem laufenden System. Das geht nur aus einem Live-System (Installationsmedium im Ausprobieren-Modus) heraus. Mit Gparted!

Die Windows-Datenträgerverwaltung macht das zwar aus dem laufenden System heraus, ist aber nur rudimentär nutzbar. Andere Windows-Tools, fahren auch erst runter und partitionieren dann vor Neustart.

Da ich mit Linux erste Gehversuche mache bin ich irritiert, dass die nicht wie für mich in Windows Umgebungen gewohnt auf anhieb funktioniert.

Wenn du das grundsätzlich erwartest, dann lass es besser gleich sein. Linux tickt anders! Ergo muss man sich umstellen und sich dafür Zeit nehmen.

Lesestoff mit weiter führenden Links: https://wiki.ubuntuusers.de/Unterschiede_zu_Windows/

L.G.

 

[alQamar]

"Andere Windows-Tools, fahren auch erst runter und partitionieren dann vor Neustart."
das ist nicht richtig. ein Expand geht immer im laufenden System auch mit Partition Wizard etc.

nun habe ich gparted als live ISO benutzt, kann aber weiterhin nicht die Partition vergrößern.
was tun?

"Was du eigentlich genau machst, geht aus deinen Screenshots für mich nicht hervor."
Ich möchte die Partition sda1 um 4.x GB vergrößern. Vorher hatte diese 12 GB.

 

[rg88]

Die neue Blöckgröße ist sagt aber, dass du genau das nicht machst, sondern weniger als die oben ausgerechnete Größe eingestellt hast. Deshalb diese Fehlermeldung

Ergänzung (24. März 2019)

Ich möchte die Partition sda1 um 4.x GB vergrößern. Vorher hatte diese 12 GB.

Ja, das hab ich angenommen, dass du das vorhast. Aber was du vorhast und was du machst, sind eben zwei verschiedene Sachen
Und das was du machst, sieht man eben auf den Bildern nicht, sondern nur das Endergebnis mit der Fehlermeldung

 

[K-BV]

Poste bitte Mal die Befehlsausgabe von
sudo parted -l
(Keinen Screenshot!)

L.G.

 

[alQamar]

und genau hier liegt die Unlogik der Fehlermeldung.

ich zitiere mal aus dem oben genannten link:
"Problembehebung
Da Windows selbst und viele populäre Programme oft nur kryptische Fehlermeldungen ausgeben, basieren dortige Problemlösungsstrategien häufig auf einem mehr oder weniger wildem Herumprobieren auf gut Glück. Das ist unter Linux anders [...]"

diesen Passus sehe ich jetzt schon nicht so. Eine Partition ist im Ausgangszustand vom System (ubuntu) eigens angelegt und in der Größe zugewiesen worden. Diese zu vergrößern scheitert offenbar daran das sda1 zu klein war?!
Ich stehe auf dem Schlauch. Danke für weitere Instruktionen.

how to repro:
Ubuntu 4.18.0-13
Hilfs Tools > Datenträgerverwaltung > sda1 auswählen > Erweitern auf 16.x GB
Fehlermeldung wie oben beschrieben
jetzt fährt es nicht mehr hoch

Ergänzung (24. März 2019)

ohne Screenshot wird das nichts ich habe kein cut and paste aus der VM
hier der sudo parted -l output aus dem live Gparted

Ergänzung (24. März 2019)

in gparted live sda1 auswählen > auf Fehler prüfen >
Fehler: Dateisystem (ext4) auf /dev/sda1 überprüfen und reparieren
/dev/sda1 kalibieren ✔
Dateisystem ... auf Fehler überprüfen
e2fsck -f -y -v -C 0 '/dev/sda1'

The filesystem size according to the superblock is 2854139 blocks the physical size of the device is 2853888 blocks
Either the suberblock or the partition table is likely to be corrupt.

Das ist also das eigentlich Problem. Die Partitionstabelle (out of the box) stimmt mit der Filesysteminfo auf sda1 nicht überein. Wie korrigiere ich dies?

 

[I'm unknown]

diesen Passus sehe ich jetzt schon nicht so. Eine Partition ist im Ausgangszustand vom System (ubuntu) eigens angelegt und in der Größe zugewiesen worden. Diese zu vergrößern scheitert offenbar daran das sda1 zu klein war?!
Ich stehe auf dem Schlauch. Danke für weitere Instruktionen.

Nun ja, wenn du dich im Vorfeld Informiert hättest, dann wäre dir aufgefallen dass du die Festplatte zu klein gewählt hattest: https://help.ubuntu.com/community/Installation/SystemRequirements#Ubuntu_Desktop_Edition

Ganz davon abgesehen ist es immer mit einem Risiko verbunden die Dateisystemgröße zu ändern. In deinem Fall scheint das nicht funktioniert zu haben, falls du kein Image der VM besitzt wird es vermutlich schneller sein die VM neu aufzusetzen anstatt das Dateisystem und evtl. vorhandene Folgeschäden im System zu finden und zu reparieren.
Falls du dort wichtige Daten hattest gibt es bestimmt ein Backup davon - auch ohne die Partitions- und Dateisystemgrößen ändern zu wollen.

 

[alQamar]

so habe evtl. eine Lösung:
da dies nichts gebracht hat:
https://linuxexpresso.wordpress.com/2010/03/31/repair-a-broken-ext4-superblock-in-ubuntu/

habe ich dies probiert:
the fix is to run "mke2fs -S /dev/xxx && fsck /dev/xxx", it will rebuild the correct superblock size and check your filesystem.
konnte danach die Partition vergrößern, fsck war fehlerfrei

und jetzt ist es ganz kaputt... bootet nicht mehr. ich mach es neu. So einfach.

Ergänzung (24. März 2019)

"Nun ja, wenn du dich im Vorfeld Informiert hättest, dann wäre dir aufgefallen dass du die Festplatte zu klein gewählt hattest: https://help.ubuntu.com/community/Installation/SystemRequirements#Ubuntu_Desktop_Edition"

jetzt macht doch bitte nicht auf schlaubi schlumpf... ich habe die Partitionsgröße gar nicht gewählt. Das hat er alles selbst angelegt mit dem Hyper-V Template.

Wenn das Erweitern einer Partition mit den OS Bordmitteln ein Risiko bei Linux ist, dann ist es wohl nicht das richtige OS für mich. Von Herumfummeln kann hier keine Rede rein.

Ich mache eine neue VM mit 30 GB (Danke für den Link) und schaue ob ich Einfluss auf die Größe der OS Partition habe. Danke für eure Zeit.

 

[K-BV]

ohne Screenshot wird das nichts ich habe kein cut and paste aus der VM

Wie jetzt, das läuft in einer VM....? Schön, dass du das nebenbei auch mal erwähnst!

Wenn das Erweitern einer Partition mit den OS Bordmitteln ein Risiko bei Linux ist, dann ist es wohl nicht das richtige OS für mich

Ja, das ist dann wohl nix für dich. Eine Partition zu verändern ist simpel, wenn man weiß was man tut. Dazu braucht man aber eben etwas Linuxwissen.

Ich bin hier raus!

L.G.

Edit: Du hast im MBR-Modus auf GPT installiert. Mit Linux geht das, im Gegensatz zu Windows. Trotzdem nicht das Gelbe vom Ei. Aber auch hier gilt: Vorher informieren dient der Fehlervermeidung.

 

[Evil E-Lex]

Wie jetzt, das läuft in einer VM....? Schön, dass du das nebenbei auch mal erwähnst!

Das sieht man im ersten Screenshot, wenn man genau hinschaut. Und falls der TE mit "Hyper-V Template" den Eintrag zu Ubuntu aus der Hyper-V Gallery meint, könnte man ihm die eigenwillige Partitionierung kaum anlasten. Die Partitionierung ist dann ja bereits vorgegeben und da darf sich man sich drauf verlassen, das dort sinnvolle Werte vorausgewählt werden.

 

[K-BV]

Das sieht man im ersten Screenshot, wenn man genau hinschaut.

Ja, das ist aber nicht mein/unser Job! Ich denke es nicht zu viel verlangt, gerade diese Info zu posten? Wenn ich Hilfe brauche, dann liefere ich alle relevanten Infos im Text an prominenter Stelle und schaffe damit die beste Voraussetzung für Hilfeleistungen und gut is.
Wie Hyper-V tickt, kann ich nicht sagen (VM läuft hier unter Linux), aber unterschiedliche Bootmodi mit entsprechender Partitionierung....!?
Die Probleme sind aber hausgemacht, wenn man sich nicht informiert oder wichtige Infos nicht bereit stellt.

 

[I'm unknown]

Und falls der TE mit "Hyper-V Template" den Eintrag zu Ubuntu aus der Hyper-V Gallery meint, könnte man ihm die eigenwillige Partitionierung kaum anlasten.

Nun ja, der TE beschwert sich über eine zu kleine Platte und schiebt die Ursache auf Ubuntu. Ubuntu hat jedoch nicht die VM angelegt, daher ist der Fehler eher woanders zu suchen:

diesen Passus sehe ich jetzt schon nicht so. Eine Partition ist im Ausgangszustand vom System (ubuntu) eigens angelegt und in der Größe zugewiesen worden. Diese zu vergrößern scheitert offenbar daran das sda1 zu klein war?!

Außerdem belegt Ubuntu bei automatischer Partitionierung immer die gesamte Platte wenn diese leer war, daher ist unpartitionierter Speicher eher durch den TE entstanden. Deshalb finde ich das Bashing hier eher unangebracht.

 

[Evil E-Lex]

Ihr habt ja recht. 🙂 Habe meine These mit der Hyper-V Gallery geprüft: Dort wird nur Ubuntu 18.04.1 angeboten. Da der TE aber 18.10 installiert hat, kann er Ubuntu nicht über die Hyper-V Gallery bezogen haben, sondern muss es selbst installiert haben.
Warum er dann allerdings eine nur 16 GB große virtuelle Festplatte erzeugt hat, bleibt sein Geheimnis.

 

[K-BV]

Warum er dann allerdings eine nur 16 GB große virtuelle Festplatte erzeugt hat, bleibt sein Geheimnis.

Im Prinzip reicht die ja. Ubuntu kommt mit deutlich weniger klar, auch mit den 11,7 die oben ausgewiesen sind. Nur muss man dann eben mit dem Platz entsprechend haushalten.

L.G.

 

[alQamar]

Ihr habt ja recht. 🙂 Habe meine These mit der Hyper-V Gallery geprüft: Dort wird nur Ubuntu 18.04.1 angeboten. Da der TE aber 18.10 installiert hat, kann er Ubuntu nicht über die Hyper-V Gallery bezogen haben, sondern muss es selbst installiert haben.
Warum er dann allerdings eine nur 16 GB große virtuelle Festplatte erzeugt hat, bleibt sein Geheimnis.

wie wäre es mit folgender Option:
der TE bezieht die VM über Hyper-V Gallery mit default 11 GB Größe
führt ein Wechsel von LTSR zu current durch und damit ein Upgrade auf eine neuere Version. Stellt im Laufe des Betriebs dann fest, dass für spätere Updates platz fehlt (Meldung). Fährt die VM herunter, vergrößert die VHDX von 11 auf 16 GB und kann dann nicht wie in Windows einfach in 10 Sekunden die Boot Partition vergrößern. #mystery

 

[alQamar]

nur um die Wogen zu glätten: ich habe nicht vorgehabt ein Linux bash(ing) von meiner powershell loszutreten. Was mich nervt ist es das einfach Dinge nicht funktionieren und viel auf dem Weg zur Lösung orakelt wird.

Ich habe deutliche Screenshots gemacht. Gefordert werden outputs. Sehe keinen Unterschied. Das Ergebnis zählt.
Dann diese pharisäische Artikel der Windows in dergestalt darstellt als würden wir im Jahr 2003 sein.

Ob es sich hier um eine VM handelt oder nicht ist, mit Verlaub, auch egal. Es geht um einen schlichten Vorgang einer Partitionsvergrößerung.

"Eine Partition zu verändern ist simpel, wenn man weiß was man tut. Dazu braucht man aber eben etwas Linuxwissen."

Da muss man keine Vorbildung für besitzen noch eine Linuxzertifizierung. Dafür habe ich ja die GUI Tools - wie auch gparted live wenn notwendig

Die VM habe ich nochmal neu aufgesetzt - auf gleichem Weg, habe aber vor dem ersten Boot die VHDX direkt auf 35 GB gestellt, wohl anerkennend der hier aufgezeigten Lösungswege und Empfehlungen zum Sizing der OS Partition.

ABER auch in diesem Fall hat dieses Template diese Größe einfach mal ignoriert und wenn ein OS - jedweden Namens - die von ihm selbst erfüllte Partitionsgröße unterschreitet ohne auch nur zu Fragen (und Linux stellt dankenswerterweise wesentlich viele Fragen mehr als Windows) dann ist hier doch der Hase im Pfeffer wenn gleiches OS sich beim späteren Vergrößern dann beschwert die Partition sei zu klein. Die Katze beißt sich in den Schwanz und zwar hausgemacht.

Als Ergebnis bekomme ich jetzt eine andere Meldung: online Shrinking not supported beim ERWEITERN einer Partition. ein fehlerhaftes OS oder einfach doch nur Quark,0?

 

[Evil E-Lex]

wie wäre es mit folgender Option:
der TE bezieht die VM über Hyper-V Gallery mit default 11 GB Größe
führt ein Wechsel von LTSR zu current durch und damit ein Upgrade auf eine neuere Version. Stellt im Laufe des Betriebs dann fest, dass für spätere Updates platz fehlt (Meldung). Fährt die VM herunter, vergrößert die VHDX von 11 auf 16 GB und kann dann nicht wie in Windows einfach in 10 Sekunden die Boot Partition vergrößern. #mystery

Warum machst du es dir so kompliziert? Einfach das ISO von Ubuntu 18.10 Desktop laden und das in eine von dir erstellte VM zu installieren ist wohl zu einfach? Von der Hyper-V-Gallery würde ich grundsätzlich die Finger lassen, das ist ein unausgereiftes Feature, unabhängig davon, ob du damit Windows oder Linux installieren willst.

Ergänzung (26. März 2019)

nur um die Wogen zu glätten: ich habe nicht vorgehabt ein Linux bash(ing) von meiner powershell loszutreten. Was mich nervt ist es das einfach Dinge nicht funktionieren und viel auf dem Weg zur Lösung orakelt wird.

Naja, orakeln passiert immer dann, wenn man unvollständige Informationen liefert. Hättest du direkt im Eingangspost geschrieben, wie du das Ubuntu installiert hast, hätte man dir wohl besser helfen können.

Ergänzung (26. März 2019)

Als Ergebnis bekomme ich jetzt eine andere Meldung: online Shrinking not supported beim ERWEITERN einer Partition. ein fehlerhaftes OS oder einfach doch nur Quark,0?

Das Feature scheint schlicht verbuggt zu sein. Ich käme allerdings nie auf die Idee ein FS, egal ob unter Linux oder Windows, online zu vergrößern. Ich bin auch strikt dagegen, dass diese Mechanismen überhaupt angeboten werden.

Das Feature funktioniert, habs eben in meiner VM getestet. Das Problem scheint durch die GPT-Partitionstabelle zu kommen, die laut deiner Aussage automatisch beim Verwender der Hyper-V-Gallery-Version von Ubuntu erzeugt wird.

Das ist zwar ärgerlich für dich, in der Praxis ist das allerdings irrelevant, weil diese Version kaum jemand nutzen dürfte. Dennoch sollten die Maintainer das mal fixen.

Hier noch ein paar Screens vom erfolgreichen Vergrößern:

 

[alQamar]

Danke Lex ich werde es mal bei Microsoft melden.

 

[alQamar]

sorry für das Necro.

Endlich hab ich es geschafft. Mittlerweile in Windows 10 1909.

Heute nochmals probiert und von 19.04 auf 19.10 geupdated, wieder kernel Panic > da Platte nach Upgrade voll.
Dann mal die 19.10 iso manuell heruntergeladen und aus dem Demo mode wieder neu installiert.
Dort gab es auch eine Möglichkeit Partitionen zu löschen und zu erweitern, aber es beharrte auf der 13 GB Partition... wie auch immer.
Dann also 19.10 auf der kleinen Partition installiert.

In Gnome Part ist immer noch keine Vergrößerung möglich, auch nicht in 19.10, diesmal kommt keine Fehlermeldung aber effektiv passiert auch nichts. Es sieht auch erst so aus, als würde es funktionieren.

Aber so geht es im Terminal:

sudo apt install cloud-guest-utils

sudo growpart /dev/sda 1 -u 'auto' #vergrößert Partition und meldet es dem OS

sudo resize2fs /dev/sda1 #vergrößert Dateisystem in der Partition

Quelle: https://askubuntu.com/questions/24027/how-can-i-resize-an-ext-root-partition-at-runtime