Partitionierung: freien Platz verschieben

CyborgBeta

Lt. Commander
Registriert
Jan. 2021
Beiträge
1.833
Ich würde versuchen sdb4 zu erweitern und dann wieder zu verkleinern, um freien Speicher zwischen 3 und 4 zu bekommen. Danach dann sdb3 in den Bereich erweitern.
Die Frage ist aber, ob die Partitionsverwaltung das mit NTFS macht. Beim Verkleinern von NTFS sind einige Linux Partitionierungstools etwas wählerisch wenn dabei Daten verschoben werden müssen.
 
  • Gefällt mir
Reaktionen: CyborgBeta
Zuletzt bearbeitet:
CyborgBeta schrieb:
Ich weiß nicht, was du da liest, aber das steht da nicht.

Select the second (extended) partition, and click on Resize/Move.

Second = zweite
both = beide

Das einzige wo in dem Artikel "both" steht ist, dass beide Partitionen nicht gemountet sein dürfen:
Before you start, both partitions will need to be unmounted
 
Bootet auch noch:

https://ibb.co/PYf2yKx

@Mihawk90 : Aha, wie würdest du denn diesen Schritt erklären:

https://ibb.co/rGxxLqr

"Drag the partition to the end of the extended partition, and then click on Resize/Move." ?

Btw, Freundlichkeit hat noch keinem geschadet.
 
CyborgBeta schrieb:
"Drag the partition to the end of the extended partition, and then click on Resize/Move." ?
Da steht doch aber nichts von "beide"?

Grundsätzlich beschreibt der Artikel auch schon mal nicht 100% das Szenario das du hast. Auf den Bildern ist erkennbar, dass es dort eine "Extended Partition" gibt, die wiederum eine weitere Parition enthält, die als Swap formatiert ist. Eine Extended Partition ist quasi nur ein Container für weitere. Und die hast du gar nicht, du hast dort ja nur eine normale Partition, die als NTFS formatiert ist.

Aber wie dem auch sei, "Select the contained swap partition" heißt hier nur, dass die Swap Partition angewählt werden muss, und nicht der "Container".
"Drag the partition [...]" ist dann innerhalb des Fensters das sich öffnet, da die Swap partition frei innerhalb des Containers verschoben werden kann (und muss).

Extended Partitionen sind heute quasi nicht mehr im Gebrauch. Eingeführt wurden die, um die Limitierung des MBR (Master Boot Record) zu umgehen, bei dem nur 4 Partitionen möglich waren. Mit UEFI + Recovery + 1x OS sind dann schon 3 weg und man musste sich entscheiden was man mit der vierten macht. Abhilfe schaffte dann die Extended Partition, in der man beliebig weitere Partitionen anlegen konnte (da die nicht in den MBR geschrieben werden). In Zeiten wo GPT (GUID Partition Table) Standard ist, die dieses Limit nicht hat, hat die Extended ihre Bedeutung verloren.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: CyborgBeta
CyborgBeta schrieb:
Nehme an du meinst die mehreren UEFI Einträge? Bei mir passiert das immer wenn ich nen (bootbaren) USB Stick dran lasse, mit jedem Boot kommt im UEFI ein neuer Eintrag dazu, weiß der Geier warum :rolleyes:
Aber bei einer fest installierten HDD/SSD hatte ich das noch nicht. Was passiert denn, wenn du einen davon wählst? Vor allem einen der nicht mehr existieren "sollte"? Möglich, dass die dann von allein entfernt werden, wenn sie nicht mehr gültig sind. Aber wie gesagt hatte die Situation noch nicht (hab auch kein ASUS board).

edit: auch möglich, dass sich das von allein gibt wenn grub neu generiert wird, s. unten. Bin aber mit UEFI nicht wirklich vertraut, das ist alles eher ne Box schwarzer Magie.

CyborgBeta schrieb:
Du müsstest wohl in Manjaro booten und die Grub config neu generieren lassen. Reinbooten müsste möglich sein, wenn du die Boot Option editierst (E unten), dort solltest du /dev/sdb5 zu deiner "korrekten" Zahl (4?) ändern können.
Alternativ ist auch ein Liveboot von nem USB stick möglich, aber dann musst du vorher chroot en damit das folgende funktioniert.
Wenn Manjaro dann gebootet bist, müsste die grub config neu generiert werden, s. hier:
https://wiki.archlinux.org/title/GRUB#Generate_the_main_configuration_file
 
Zuletzt bearbeitet:
Möchte da eigentlich nicht "manuell" reingrätschen...

Also es ist Folgendes passiert: /dev/sdb5 hatte ich gelöscht, deshalb ist der weiter oben erwähnte freie Speicher entstanden, vormals war dort Manjaro installiert. Jedoch bevor ich sdb5 gelöscht hatte, hatte ich Manjaro ein zweites Mal auf einer anderen ssd (/dev/sda) installiert (hatte erst installiert, dann gelöscht, weil ich noch Nutzerdaten brauchte). Nun booten zwar beide Systeme noch, aber die "Karteileiche" /dev/sdb5 stört etwas.
 
Ah OK alles klar, also ist Manjaro gar nicht mehr auf sdb.
In dem Fall kannst du die grub config einfach direkt neu generieren, grub müsste ja jetzt auf sda sein.
"Manuell reingrätschen" ist das nicht, das ist der Standardweg wie die grub config auch im Rahmen der Installation erstellt wird, und in der Regel auch im Rahmen von Kernel-updates.

Ich nutze Manjaro nicht (bin auf Fedora), aber ich gehe mal davon aus, dass bei einem Kernel update grub automatisch neu generiert wird (da die grub entries auf die neuen kernel images umgeschrieben werden müssen), das heißt das Problem würde sich (theoretisch) mit dem nächsten Kernel-Update von allein lösen.
 
  • Gefällt mir
Reaktionen: CyborgBeta
Funktionierte ganz einfach mit sudo update-grub.
 
Zurück
Oben