Kubuntu von 500GB SSD auf 1TB SSD

[Wolfgang Bauer]

Grüß euch,

Weil der Platz auf der 500GB SSD mit Kubuntu 23.10 knapp wurde
habe ich das System auf eine 1TB SSD migriert.
Jetzt habe ich da 454.57GB nicht belegten Speicherplatz.
Kann mit dem partitionmanager die 476.31GB erweitern/zuordnen?
https://www.wolfgang-bauer.at/bilder/kubuntu%20auf%201TB.png

Freundliche Grüße
Wolfgang
--
wieso, weshalb, warum
wer nicht fragt bleibt dumm
Titelsong aus Sesamstraße.

[Marco Moock]

Am 05.02.2024 12:21 Uhr schrieb Wolfgang Bauer:

> Kann mit dem partitionmanager die 476.31GB erweitern/zuordnen?

Ja, aber nur im Live-System weil / in Benutzung ist und du das ja
vergrößern willst.

--
Gruß
Marco

Spam und Werbung bitte an ichschic...@cartoonies.org

[Bernd Mayer]

Am 05.02.24 um 12:21 schrieb Wolfgang Bauer:

> Grüß euch,
>
> Weil der Platz auf der 500GB SSD mit Kubuntu 23.10 knapp wurde
> habe ich das System auf eine 1TB SSD migriert.
> Jetzt habe ich da 454.57GB nicht belegten Speicherplatz.
> Kann mit dem partitionmanager die 476.31GB erweitern/zuordnen?
> https://www.wolfgang-bauer.at/bilder/kubuntu%20auf%201TB.png
>

Hallo,

ja - das geht.

Mit der gparted-live-cd hab ich das schon mehrmals gemacht.

https://gparted.org/livecd.php


Bernd Mayer

[Marc Haber]

Wolfgang Bauer <wolfgan...@mein.gmx> wrote:
>Kann mit dem partitionmanager die 476.31GB erweitern/zuordnen?

Das geht, das ist aber eine Operation am offenen Herzen. Nicht ohne
ein Backup probieren.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[Marco Moock]

Am 05.02.2024 14:20 Uhr schrieb Marc Haber:

> Das geht, das ist aber eine Operation am offenen Herzen. Nicht ohne
> ein Backup probieren.

Wobei das bei mir bisher noch nicht schiefgelaufen ist.
Die Partitionierungsprogramme scheinen damit Erfahrung zu haben.

[Wolfgang Bauer]

Bernd Mayer schrieb:

Ich mache es von Kubuntu auf der 500GB SSD aus mit gparted.
Der Vorgang läuft noch.

Freundliche Grüße
Wolfgang
--
Irren ist menschlich.
Aber wenn man richtigen Mist bauen will,
braucht man dazu einen Computer.

[Wolfgang Bauer]

Marc Haber schrieb:

> Wolfgang Bauer <wolfgan...@mein.gmx> wrote:

>> Kann mit dem partitionmanager die 476.31GB erweitern/zuordnen?

> Das geht, das ist aber eine Operation am offenen Herzen. Nicht ohne
> ein Backup probieren.

gparted auf Kubuntu 500 GB SSD rödelt jetzt schon zwei Stunden
und es ist noch kein Ende in Sicht.
Mit Acronis Disc Director Suite wäre das längst erledigt.
Aber gut, ich versuche es erstmal mit Bordmitteln.

Freundliche Grüße
Wolfgang
--
"Sie haben die Arbeitsmoral einer Katze!", brüllt der Chef.
"Wie kommen Sie denn darauf?"
"Das fragen Sie noch? Sie schleichen jeden Tag ins Büro,
legen die Pfoten auf den Tisch und warten auf Ihre Mäuse!"

[Marco Moock]

Am 05.02.2024 16:25 Uhr schrieb Wolfgang Bauer:

> gparted auf Kubuntu 500 GB SSD rödelt jetzt schon zwei Stunden
> und es ist noch kein Ende in Sicht.

Je nachdem, was du da gemacht hast, muss jeder Eintrag für eine Datei
angefasst werden, was eben Zeit beansprucht.

[Wolfgang Bauer]

Marco Moock schrieb:

> Am 05.02.2024 16:25 Uhr schrieb Wolfgang Bauer:

>> gparted auf Kubuntu 500 GB SSD rödelt jetzt schon zwei Stunden
>> und es ist noch kein Ende in Sicht.

> Je nachdem, was du da gemacht hast, muss jeder Eintrag für eine Datei
> angefasst werden, was eben Zeit beansprucht.

https://www.wolfgang-bauer.at/bilder/gparted.png

Freundliche Grüße
Wolfgang
--
Wenn ich mit meiner Katze spiele,
wer kann da sagen wer zu wessen Belustigung dient?
Michele de Montaigne

[Paul Muster]

Am 05.02.2024 um 16:35 schrieb Wolfgang Bauer:
> Marco Moock schrieb:
>> Am 05.02.2024 16:25 Uhr schrieb Wolfgang Bauer:

>>> gparted auf Kubuntu 500 GB SSD rödelt jetzt schon zwei Stunden
>>> und es ist noch kein Ende in Sicht.
>
>> Je nachdem, was du da gemacht hast, muss jeder Eintrag für eine Datei
>> angefasst werden, was eben Zeit beansprucht.
>
> https://www.wolfgang-bauer.at/bilder/gparted.png

Tja, der Computer macht halt, was ihm gesagt wurde. Ob das sinnvoll ist
oder nicht, er tut es einfach.


mfG Paul

[Bernd Mayer]

Am 05.02.24 um 16:35 schrieb Wolfgang Bauer:

> Marco Moock schrieb:
>> Am 05.02.2024 16:25 Uhr schrieb Wolfgang Bauer:
>
>>> gparted auf Kubuntu 500 GB SSD rödelt jetzt schon zwei Stunden
>>> und es ist noch kein Ende in Sicht.
>
>> Je nachdem, was du da gemacht hast, muss jeder Eintrag für eine Datei
>> angefasst werden, was eben Zeit beansprucht.
>
> https://www.wolfgang-bauer.at/bilder/gparted.png
>

Hallo,

das sind ja 4 Vorgänge.

Bei dreien davon wird fast die komplette SSD verschoben, erst nach
rechts und dann wieder nach links.

Bei Festplatten kann man mit hdparm -I nach der Zeit für secure erase
suchen, dann hat man einen Anhaltspunkt wie lang das jeweils dauert.


Bernd Mayer

[Wolfgang Bauer]

Martin Schnitkemper schrieb:

> Am Mo, 05.02.2024 um 16:25 schrieb Wolfgang Bauer:

>> gparted auf Kubuntu 500 GB SSD rödelt jetzt schon zwei Stunden
>> und es ist noch kein Ende in Sicht.

> Keine Ahnung, was gparted alles macht, aber parted mit anschließendem
> resize2fs erledigt die Aufgabe in wenigen Sekunden.

Um das anzuwenden fehlt mir die genaue Kenntnis.

>> Mit Acronis Disc Director Suite wäre das längst erledigt.
>> Aber gut, ich versuche es erstmal mit Bordmitteln.

> Bei Wahl der richtigen Bordmittel wäre es auch längst erledigt.

Das glaube ich dir.

Freundliche Grüße
Wolfgang
--
Wichtig ist, daß man nie aufhört zu fragen...
Albert Einstein

[Marco Moock]

Am 05.02.2024 16:35 Uhr schrieb Wolfgang Bauer:

> https://www.wolfgang-bauer.at/bilder/gparted.png

Nach rechts verschieben bedeutet, dass alles angefasst werden muss,
weil die Blöcke sich alle ändern. Das dauert dann halt.

[Marco Moock]

Am 05.02.2024 16:53 Uhr schrieb Martin Schnitkemper:

> Keine Ahnung, was gparted alles macht, aber parted mit anschließendem
> resize2fs erledigt die Aufgabe in wenigen Sekunden.

Wie man oben sehen kann hat er die ganze Partition verschoben.

[Frank Miller]

Martin Schnitkemper wrote:

> Am Mo, 05.02.2024 um 17:06 schrieb Bernd Mayer:
>
>> Bei dreien davon wird fast die komplette SSD verschoben, erst nach
>> rechts und dann wieder nach links.
>

> Da es sich tatsächlich nur um zwei MB handelt vermute ich mal, dass hier
> die Partitionausrichtung korrigiert werden soll:
> https://www.thomas-krenn.com/de/wiki/Partition_Alignment

Klingt für mich nicht logisch, da die Partition erst 2MB nach rechts und im
übernächsten Schritt wieder 2MB zurück nach links verschoben wird.
Ich gehe von einer falschen Bedienung des Programms aus.

[Frank Miller]

Marco Moock wrote:
> Am 05.02.2024 16:53 Uhr schrieb Martin Schnitkemper:
>
>> Keine Ahnung, was gparted alles macht, aber parted mit anschließendem
>> resize2fs erledigt die Aufgabe in wenigen Sekunden.
>
> Wie man oben sehen kann hat er die ganze Partition verschoben.

Und zwar zwei mal. Hin und wieder zurück. Kann man machen, muss man nicht.

[Frank Miller]

Wolfgang Bauer wrote:
> Marco Moock schrieb:
>> Am 05.02.2024 16:25 Uhr schrieb Wolfgang Bauer:
>
>>> gparted auf Kubuntu 500 GB SSD rödelt jetzt schon zwei Stunden
>>> und es ist noch kein Ende in Sicht.
>
>> Je nachdem, was du da gemacht hast, muss jeder Eintrag für eine Datei
>> angefasst werden, was eben Zeit beansprucht.
>
> https://www.wolfgang-bauer.at/bilder/gparted.png

Wie man sehen kann, hast du die Partition erst auf 909 GB vergrößert, dann
verschoben, anschließend nochmal um knapp 10 GB vergrößert und wieder
zurück verschoben.

Das reine Vergrößern, wie von dir gewünscht, hätte nicht mal 20 Sekunden
gedauert. Aber allein schon der erste Verschiebevorgang dauerte über
zwei Stunden. Daß die ganze Aktion jetzt mehr als vier Stunden dauert,
liegt allein an deiner undurchdachten Bedienung.
Ich bezweifle, daß "Acronis Disc Director Suite" das schneller erledigt
hätte, wie du behauptest.

[Wolfgang Bauer]

Frank Miller schrieb:

> Martin Schnitkemper wrote:

>> Da es sich tatsächlich nur um zwei MB handelt vermute ich mal, dass hier
>> die Partitionausrichtung korrigiert werden soll:
>> https://www.thomas-krenn.com/de/wiki/Partition_Alignment

> Klingt für mich nicht logisch, da die Partition erst 2MB nach rechts und im
> übernächsten Schritt wieder 2MB zurück nach links verschoben wird.
> Ich gehe von einer falschen Bedienung des Programms aus.

Ja das ist so. Ich mache sonst nichts mit gparted.

Freundliche Grüße
Wolfgang
--
Früher Vogelsang macht den Winter lang.

[Wolfgang Bauer]

Frank Miller schrieb:

> Wolfgang Bauer wrote:

>> https://www.wolfgang-bauer.at/bilder/gparted.png

> Wie man sehen kann, hast du die Partition erst auf 909 GB vergrößert, dann
> verschoben, anschließend nochmal um knapp 10 GB vergrößert und wieder
> zurück verschoben.

> Das reine Vergrößern, wie von dir gewünscht, hätte nicht mal 20 Sekunden
> gedauert. Aber allein schon der erste Verschiebevorgang dauerte über
> zwei Stunden. Daß die ganze Aktion jetzt mehr als vier Stunden dauert,
> liegt allein an deiner undurchdachten Bedienung.

Ich habe mich in die Bediehnung des gparted erst reinfinden müssen.
Deswegen mehrere Arbeitsschritte.

> Ich bezweifle, daß "Acronis Disc Director Suite" das schneller erledigt
> hätte, wie du behauptest.

Bei Acronis Disc Director Suite hätte ich die Partition mit der Maus
anfassen und vergrößern können.

Freundliche Grüße
Wolfgang
--
Dass mir mein Hund das Liebste sei, sagst du oh Mensch sei Sünde,
mein Hund ist mir im Sturme treu, der Mensch nicht mal im Winde.
Franz von Assisi

[Wolfgang Bauer]

Marco Moock schrieb:

> Am 05.02.2024 16:35 Uhr schrieb Wolfgang Bauer:

>> https://www.wolfgang-bauer.at/bilder/gparted.png

> Nach rechts verschieben bedeutet, dass alles angefasst werden muss,
> weil die Blöcke sich alle ändern. Das dauert dann halt.

Jetzt sieht es so aus. https://www.wolfgang-bauer.at/bilder/gparted2.png

[Frank Miller]

Wolfgang Bauer wrote:
> Frank Miller schrieb:
>> Wolfgang Bauer wrote:
>
>>> https://www.wolfgang-bauer.at/bilder/gparted.png
>
>> Wie man sehen kann, hast du die Partition erst auf 909 GB vergrößert, dann
>> verschoben, anschließend nochmal um knapp 10 GB vergrößert und wieder
>> zurück verschoben.
>
>> Das reine Vergrößern, wie von dir gewünscht, hätte nicht mal 20 Sekunden
>> gedauert. Aber allein schon der erste Verschiebevorgang dauerte über
>> zwei Stunden. Daß die ganze Aktion jetzt mehr als vier Stunden dauert,
>> liegt allein an deiner undurchdachten Bedienung.
>
> Ich habe mich in die Bediehnung des gparted erst reinfinden müssen.
> Deswegen mehrere Arbeitsschritte.
>
>> Ich bezweifle, daß "Acronis Disc Director Suite" das schneller erledigt
>> hätte, wie du behauptest.
>
> Bei Acronis Disc Director Suite hätte ich die Partition mit der Maus
> anfassen und vergrößern können.

Das kannst du mit gparted ebenso. Schau mal auf das erste von dir gepostete
Bild: https://www.wolfgang-bauer.at/bilder/kubuntu%20auf%201TB.png

[Frank Miller]

Frank Miller wrote:
> Wolfgang Bauer wrote:
[..snip..]

>> Bei Acronis Disc Director Suite hätte ich die Partition mit der Maus
>> anfassen und vergrößern können.
>
> Das kannst du mit gparted ebenso. Schau mal auf das erste von dir gepostete
> Bild: https://www.wolfgang-bauer.at/bilder/kubuntu%20auf%201TB.png

Übrigens: Acronis Disc Director nutzt intern 49 Drittprogramme, die fast alle
unter GPLv2-Lizenz stehen: https://kb.acronis.com/content/61962
Letztlich ist es nur eine andere "Verpackung" als gparted.

[Bernd Mayer]

Am 05.02.24 um 20:14 schrieb Wolfgang Bauer:

> Marco Moock schrieb:
>> Am 05.02.2024 16:35 Uhr schrieb Wolfgang Bauer:
>
>>> https://www.wolfgang-bauer.at/bilder/gparted.png
>
>> Nach rechts verschieben bedeutet, dass alles angefasst werden muss,
>> weil die Blöcke sich alle ändern. Das dauert dann halt.
>
> Jetzt sieht es so aus. https://www.wolfgang-bauer.at/bilder/gparted2.png
>
> Freundliche Grüße
> Wolfgang

Hallo,

was machen die 51,12 GiB?

Ist das so gewollt oder sind die einfach so entstanden?

Wichtig ist ja, daß die Daten noch vorhanden sind und das System bootet.

Was für SSDs sind das denn?


Bernd Mayer

[Marc Haber]

Martin Schnitkemper <news.trash...@spamgourmet.com> wrote:
>Das ist eben das Problem einer 1:1-Kopie vom alten auf den neuen
>Datenträger, dass solche Altlasten übernommen werden. Auch aus dem Grund
>wäre es schon besser gewesen, die Partition neu in ihrer endgültigen Größe
>zu erstellen, denn fdisk legt die Partition automatisch richtig ausgerichtet
>an, und dann den Datenbestand aus einer Sicherung zurück zu laden.

Dann hätte man halt den Bootloader neu installieren müssen. Für einen
halbwegs guten Linuxer kein großes Problem, aber Wolfgang ist halt
kein solcher, und das ist jetzt echt nicht böse gemeint.

[Andreas Kohlbach]

On Mon, 5 Feb 2024 14:31:44 +0100, Marco Moock wrote:
>
> Am 05.02.2024 14:20 Uhr schrieb Marc Haber:
>
>> Das geht, das ist aber eine Operation am offenen Herzen. Nicht ohne
>> ein Backup probieren.
>
> Wobei das bei mir bisher noch nicht schiefgelaufen ist.

Bei mir auch nicht. Trotzdem, Operation am offenen Herzen... Man erhält
IIRC auch einen Haufen Warnmeldungen, wenn man es trotzdem macht.

Also besser ein anderes System booten, besagte Platte dort mounten, um
die Änderungen über dieses vorzunehmen.
--
Andreas

[Frank Miller]

Ich würde die betreffende Platte vom anderen System aus *nicht* mounten.
GParted rät stark davon ab und deaktiviert ggf. sogar einige Optionen,
wenn eine Partition gemountet ist, die verändert werden soll. Alternativ
kann es auch vorkommen, daß GParted zu ändernde Partitionen selber erst
unmountet, bevor Operationen vorgenommen werden.


Autovergleich? ;)

Eine Systemplatte aus dem selben gerade laufenden System heraus zu verändern
ist wie einen Automotor während der Fahrt im Auto zu reparieren. Kann man
machen, wenn man Mad Max oder Chuck Norris heißt.

Eine Systemplatte von einem anderen unabhängigen System aus zu verändern,
während sie dort gemountet ist, ist wie die Reparatur eines laufenden Automotors,
während das Auto in der Garage steht. Kann man machen, wenn man sich der
Risiken bewusst ist und weiß, was man tunlichst vermeiden sollte.

Eine Systemplatte von einem anderen unabhängigen System aus zu verändern,
während sie dort nicht gemountet ist, ist wie die Reparatur eines Motors,
der nicht läuft. Die am wenigsten risikobehaftete Variante für Max Mustermann,
Wolfgang Bauer und Co.

[Rupert Haselbeck]

Frank Miller schrieb:

> Eine Systemplatte von einem anderen unabhängigen System aus zu verändern,
> während sie dort nicht gemountet ist, ist wie die Reparatur eines Motors,
> der nicht läuft. Die am wenigsten risikobehaftete Variante für Max Mustermann,
> Wolfgang Bauer und Co.

Das ist völlig richtig, aber du übersiehst, dass dies eines Wolfgang
Bauer nicht würdig ist :-)

MfG
Rupert

[Wolfgang Bauer]

Bernd Mayer schrieb:

> Am 05.02.24 um 20:14 schrieb Wolfgang Bauer:

>> Jetzt sieht es so aus. https://www.wolfgang-bauer.at/bilder/gparted2.png

> Hallo,

> was machen die 51,12 GiB?

> Ist das so gewollt oder sind die einfach so entstanden?

Gewollt ist es nicht.

> Wichtig ist ja, daß die Daten noch vorhanden sind und das System bootet.

Ja das paßt alles.

> Was für SSDs sind das denn?

Vom PC Händler meines Vertrauens, Western Digital WD Green
SATA SSD 2.5"

[Gerald E¡scher]

Wolfgang Bauer schrieb am 6/2/2024 13:25:

> Vom PC Händler meines Vertrauens, Western Digital WD Green
> SATA SSD 2.5"

Auweia, das auch noch. Die WD Green sind ziemlich langsam. Die haben
zwar einen schnellen Cache von ein paar GB Größe, sodass bei üblichem
Betrieb in einem Desktop oder Notbuch die geringe Geschwindigkeit
nicht auffällt, aber wenn beim Kopieren großer Datenmengen der Cache
voll wird, wird es ziemlich zäh.
Genau das hast du bei deiner unnötigen Verschieberei der Partition
erlebt.

--
Gerald

[Wolfgang Bauer]

Martin Schnitkemper schrieb:

> Am Di, 06.02.2024 um 13:25 schrieb Wolfgang Bauer:

>>> was machen die 51,12 GiB?
>>
>>> Ist das so gewollt oder sind die einfach so entstanden?
>>
>> Gewollt ist es nicht.

> Dann schiebe sdb3 doch zurück über den unbelegten Bereich bis nach
> sdb2 und erweitere sdb3 bis zum Ende des Datenträgers.

Ich habe noch etwas geändert, habe aber nun Angst mir das System
zu crashen. https://www.wolfgang-bauer.at/bilder/gparted3.png
Sowie ich das verstehe geht das mit verschieben nicht.

Freundliche Grüße
Wolfgang
--
Wenn die Guten nicht kämpfen, werden die Schlechten siegen.

[Bernd Mayer]

Am 06.02.24 um 14:56 schrieb Gerald E¡scher:

Hallo,

ja - ich hatte mir auch letzten Monat eine WD Green SN350 NVMe bestellt.

Und da steht drauf "Built for light and casual use".

Wenn ich das vorher gewusst hätte ...


Bernd Mayer

[Wolfgang Bauer]

Martin Schnitkemper schrieb:

> Am Di, 06.02.2024 um 14:55 schrieb Wolfgang Bauer:

>> https://www.wolfgang-bauer.at/bilder/gparted3.png
>> Sowie ich das verstehe geht das mit verschieben nicht.

> ...weil die Partition sda3 offensichtlich eingehängt ist, dazu noch auf
> einem völlig unsinnigen Mountpoint.

Ich habe Kubuntu von der 500GB SSD nach 1TB SSD migriert.
Auf die 500GB SSD wurde Kubuntu vom USB Stick installiert,
auch der Mountpoint wurde so gesetzt.

> Das Veränderungen an eingehängten Partitionen nicht möglich sind und du
> statt dessen von einem Livesystem starten und von dort deine
> Verschiebeaktionen durchführen sollst, wurde dir hier ja schon mehrfach
> erklärt.

Wenn ich von Kubuntu auf 500GB gparted starte ist die 1TB SSD
nicht eingehängt. Was macht es für einen Unterschied wenn ich
gparted-live benutze?

[Arno Lutz]

Am 06.02.24 um 02:28 schrieb Frank Miller:

> Eine Systemplatte von einem anderen unabhängigen System aus zu verändern,
> während sie dort gemountet ist, ist wie die Reparatur eines laufenden Automotors,
> während das Auto in der Garage steht. Kann man machen, wenn man sich der
> Risiken bewusst ist und weiß, was man tunlichst vermeiden sollte.

IMHO wird zum Bearbeiten die Partition ausgehängt!
Habs noch nie anders erlebt.

Gruß
Arno

[Gerald E¡scher]

Bernd Mayer schrieb am 6/2/2024 15:22:

> Am 06.02.24 um 14:56 schrieb Gerald E¡scher:
>> Wolfgang Bauer schrieb am 6/2/2024 13:25:
>>
>>> Vom PC Händler meines Vertrauens, Western Digital WD Green
>>> SATA SSD 2.5"
>>
>> Auweia, das auch noch. Die WD Green sind ziemlich langsam. Die haben
>> zwar einen schnellen Cache von ein paar GB Größe, sodass bei üblichem
>> Betrieb in einem Desktop oder Notbuch die geringe Geschwindigkeit
>> nicht auffällt, aber wenn beim Kopieren großer Datenmengen der Cache
>> voll wird, wird es ziemlich zäh.
>> Genau das hast du bei deiner unnötigen Verschieberei der Partition
>> erlebt.
>>

> ja - ich hatte mir auch letzten Monat eine WD Green SN350 NVMe bestellt.
>
> Und da steht drauf "Built for light and casual use".

Tja, ich habe mir vor ca. einem Monat bei AliExpress für einen
untergeordneten Zweck eine billige KingSpec NVMe SSD bestellt und
erwartet, dass wie bei der WD Grün und einer vor Jahren
gekauften KingSpec mSATA SSD bei großen Datenmengen die Geschwindigkeit
einbricht. Tut sie aber nicht. Manchmal ist man mit nicht so bekannten
Marken besser dran :-)

> Wenn ich das vorher gewusst hätte ...

Hättest du mich halt gefragt ;-)
Die mSATA KingSpec war einige Jahre in einem kleinen, passive gekühlten
Industrie-PC drin, den ich unter Xubuntu als Server verwendet habe. Die
geringe Geschwindigkeit war da völlig wurscht, auf der KingSpec war im
Wesentlichen eh nur / und /boot/ drauf, da reichte für alle
Schreiboperationen der schnelle Cache mühelos.

--
Gerald

[Gerald E¡scher]

Martin Schnitkemper schrieb am 6/2/2024 16:58:

> Am Di, 06.02.2024 um 14:55 schrieb Wolfgang Bauer:
>

>> zu crashen. https://www.wolfgang-bauer.at/bilder/gparted3.png
>> Sowie ich das verstehe geht das mit verschieben nicht.
>

> ...weil die Partition sda3 offensichtlich eingehängt ist, dazu noch auf
> einem völlig unsinnigen Mountpoint.

Der Mountpoint ist korrekt, der wird bei Ubuntu für den Snap-Firefox
eingerichtet.

> Bernd hatte dir gestern schon geschrieben
>
> | https://gparted.org/livecd.php
>
> und was war deine Antwort darauf?
>
> | Ich mache es von Kubuntu auf der 500GB SSD aus mit gparted.

Wenn Wolfgang für seine (umständlichen) Manipulationen der
Root-Partition das Kubuntu der alten SSD bootet, passt es eh.

Der Snap-Mountpoint sieht bei einem Rechner mit Xubuntu so aus:

gerald@panther:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 4K 1 loop /snap/bare/5
[...]
sda 8:0 0 238,5G 0 disk
├─sda1 8:1 0 200M 0 part
├─sda2 8:2 0 39,1G 0 part
│ ├─mt--128_vg-root 252:0 0 25G 0 lvm /var/snap/firefox/common/host-hunspell
│ │ /
│ └─mt--128_vg-home 252:1 0 14,1G 0 lvm /home
├─sda3 8:3 0 1,5G 0 part /boot
└─sda4 8:4 0 16G 0 part
sr0 11:0 1 1024M 0 rom

Wenn man LVM einrichtet, erspart man sich zukünftige Verrenkungen bei zu
klein gewordenen Partitionen.

--
Gerald

[Marc Haber]

Ich habe mit parted auch schon im laufenden System die root-Partition
gelöscht und in Folge größer wieder neu angelegt (mit dem gleichen
Startsektor, versteht sich).

[Marc Haber]

Martin Schnitkemper <news.trash...@spamgourmet.com> wrote:
>...weil die Partition sda3 offensichtlich eingehängt ist, dazu noch auf
>einem völlig unsinnigen Mountpoint.
>

>Das Veränderungen an eingehängten Partitionen nicht möglich sind und du
>statt dessen von einem Livesystem starten und von dort deine
>Verschiebeaktionen durchführen sollst, wurde dir hier ja schon mehrfach
>erklärt.
>

>Jetzt kasperst du schon zwei Tage herum für so eine simple Aktion wie das
>Vergrößern einer Partition. Wenn du es so wie ich es dir gestern schon
>beschrieben hatte gemacht hättest, wärst du längst mit allem durch.

Vor zwei Jahren hätten wir ihn dafür gesteinigt dass er sofort neu
installiert hat. Irgendwie kann er es nicht richtig machen für unsere
Ansprüche.

[Marc Haber]

Wolfgang Bauer <wolfgan...@mein.gmx> wrote:
>Wenn ich von Kubuntu auf 500GB gparted starte ist die 1TB SSD
>nicht eingehängt.

Ich glaube, dass hier niemand davon ausgegangen ist, dass Du für die
Operation das alte System von der alten Platte nochmal gestartet hast.
Ich verstehe den Gedanken, den Du dabei gehabt haben magst, und er ist
auch richtig so, aber auf DIE Idee wäre ICH im TRAUM nicht gekommen.

[Arno Lutz]

Am 06.02.24 um 18:47 schrieb Marc Haber:

>>> Eine Systemplatte von einem anderen unabhängigen System aus zu verändern,
>>> während sie dort gemountet ist, ist wie die Reparatur eines laufenden Automotors,
>>> während das Auto in der Garage steht. Kann man machen, wenn man sich der
>>> Risiken bewusst ist und weiß, was man tunlichst vermeiden sollte.
>> IMHO wird zum Bearbeiten die Partition ausgehängt!
>> Habs noch nie anders erlebt.
> Ich habe mit parted auch schon im laufenden System die root-Partition
> gelöscht und in Folge größer wieder neu angelegt (mit dem gleichen
> Startsektor, versteht sich).

Ich vermute mal : auf/mit Konsole.

hier mit Suse-
Yast/Partitionierer hängt immer aus und/oder meckert.
GParted macht das, soweit ich weiß, auch.

Gruß
Arno

[Marc Haber]

Arno Lutz <inv...@freakmail.de> wrote:
>Am 06.02.24 um 18:47 schrieb Marc Haber:
>>>> Eine Systemplatte von einem anderen unabhängigen System aus zu verändern,
>>>> während sie dort gemountet ist, ist wie die Reparatur eines laufenden Automotors,
>>>> während das Auto in der Garage steht. Kann man machen, wenn man sich der
>>>> Risiken bewusst ist und weiß, was man tunlichst vermeiden sollte.
>>> IMHO wird zum Bearbeiten die Partition ausgehängt!
>>> Habs noch nie anders erlebt.
>> Ich habe mit parted auch schon im laufenden System die root-Partition
>> gelöscht und in Folge größer wieder neu angelegt (mit dem gleichen
>> Startsektor, versteht sich).
>
>Ich vermute mal : auf/mit Konsole.

Natürlich. Parted. Nicht gparted.

[Diedrich Ehlerding]

Wolfgang Bauer meinte:

> Weil der Platz auf der 500GB SSD mit Kubuntu 23.10 knapp wurde
> habe ich das System auf eine 1TB SSD migriert.
> Jetzt habe ich da 454.57GB nicht belegten Speicherplatz.
> Kann mit dem partitionmanager die 476.31GB erweitern/zuordnen?

Wenn man sowas machen bzw. für die Zukunft nicht ausschließen will, ist
es eine gute Idee, keine Partitionen, sondern lvm-Volumes zu verwenden.
Die kann man sowohl im laufenden Betrieb auf andere Platten verschieben
als auch vergrößern (und viele Filesysteme lassen sich auch onlne
vergrößern, wenn einmal das zugrundeliegene lv vergrößert worden ist).
Ja, habe ich mit produktiven Systemen gemacht, sowohl auf ein anderes
Plattensystem umgezpgen als auch einzelne Volumes vergrößert, ohne
Betriebsunterbrechung.

Nur kann man das leider nicht nachträglich tun ; man muss also
rechtzeitig daran denkebn. (Redhat legte mindestens früher mal alles in
logical volumes; ich habe aber lange kein Redhat mehr in den Fingern
gehabt).
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Marc Haber]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>Wenn man sowas machen bzw. für die Zukunft nicht ausschließen will, ist
>es eine gute Idee, keine Partitionen, sondern lvm-Volumes zu verwenden.

Amen. Das braucht halt entweder Softwareunterstüzung oder mehr Ahnung.

gparted kann mit LVM nicht umgehen.

>Die kann man sowohl im laufenden Betrieb auf andere Platten verschieben
>als auch vergrößern (und viele Filesysteme lassen sich auch onlne
>vergrößern, wenn einmal das zugrundeliegene lv vergrößert worden ist).

Dann hat man das Problem mit dem Vergrößern von PVs. Okay, seltener.

>Ja, habe ich mit produktiven Systemen gemacht, sowohl auf ein anderes
>Plattensystem umgezpgen als auch einzelne Volumes vergrößert, ohne
>Betriebsunterbrechung.

Ja, das ist in der Tat hübsch.

>Nur kann man das leider nicht nachträglich tun ; man muss also
>rechtzeitig daran denkebn. (Redhat legte mindestens früher mal alles in
>logical volumes; ich habe aber lange kein Redhat mehr in den Fingern
>gehabt).

Nachträglich geht auch, braucht halt für das dd der raw partition in
die LV ein Rescuesystem, herumprökeln in der fstab und mit dem
Bootmanager. Mache ich heutzutage von Zeit zu Zeit wenn ich ein System
von BIOS auf UEFI umstelle (die EFI-Partition muss viel größer sein
als die bios-grub partition war). Nicht dass solche Operationen nötig
wären, aber machen tu ich sie trotzdem manchmal.

[Diedrich Ehlerding]

Marc Haber meinte:

>>Wenn man sowas machen bzw. für die Zukunft nicht ausschließen will,
>>ist es eine gute Idee, keine Partitionen, sondern lvm-Volumes zu
>>verwenden.
>
> Amen. Das braucht halt entweder Softwareunterstüzung oder mehr Ahnung.
>
> gparted kann mit LVM nicht umgehen.

Wenn man lvm hat, braucht man kein gparted.

>>Die kann man sowohl im laufenden Betrieb auf andere Platten
>>verschieben als auch vergrößern (und viele Filesysteme lassen sich
>>auch onlne vergrößern, wenn einmal das zugrundeliegene lv vergrößert
>>worden ist).
>
> Dann hat man das Problem mit dem Vergrößern von PVs. Okay, seltener.

Nö. PVs vergrößert man nicht, man fügt einfach weitere PVs zur VG hinzu.
Man braucht mit LVM eigentlich gar keine Partitionen - statt /dev/sdx1
kann man auch gleich die ganze Platte /dev/sdx zum PV machen. (OK, das
gilt nur für Platten, von denen man nicht booten will, die EFI-Partition
braucht man auf der Bootplatte.)

>>Nur kann man das leider nicht nachträglich tun ; man muss also

>>rechtzeitig daran denken. (Redhat legte mindestens früher mal alles

>>in logical volumes; ich habe aber lange kein Redhat mehr in den
>>Fingern gehabt).
>
> Nachträglich geht auch, braucht halt für das dd der raw partition in
> die LV ein Rescuesystem, herumprökeln in der fstab und mit dem
> Bootmanager.

Ich meinte "ohne umherkopieren". Auch das mag sehr eventuell vielleicht
unter Umständen möglicherweise irgendwie gehen, wenn vor und hinter den
Partitionen, die man übernehmen will, noch Platz für Metadaten ist,
indem es durch händisches Editieren einer vgcfgbackup-Textdatei die
bisherigen Partitionsgrenzen und -größen als Start und Ende von LVs
einträgt und das dann dem LVM mit vgcfgrestore einfüttert. Aber das ist
nur was für Masochisten. Ich habe einmal in einer Notsituation remoite
bei einem Kunden in so etwas herumeditieren müssen, das war ... äh ...
challenging und blutdrucksteigernd.

[Rupert Haselbeck]

Marc Haber schrieb:

> Ich habe mit parted auch schon im laufenden System die root-Partition
> gelöscht und in Folge größer wieder neu angelegt (mit dem gleichen
> Startsektor, versteht sich).

Der RasPi, bzw. dessen Config-Skript, erledigt das Vergrößern der
gemounteten Root-Partition mittels fdisk (und anschließendem resize2fs).

MfG
Rupert

[Marc Haber]

Ich habe mir fdisk damals, als es noch kein GPT konnte, abgewöhnt. Und
so richtig benutzt habe ich es eigenltich nie, bin von cfdisk direkt
zu parted umgestiegen, und wenn ich eine grafische Oberfläche habe
benutze ich tatsächlich gparted.

[Wolfgang Bauer]

Diedrich Ehlerding schrieb:

> Wolfgang Bauer meinte:

>> Weil der Platz auf der 500GB SSD mit Kubuntu 23.10 knapp wurde
>> habe ich das System auf eine 1TB SSD migriert.
>> Jetzt habe ich da 454.57GB nicht belegten Speicherplatz.
>> Kann mit dem partitionmanager die 476.31GB erweitern/zuordnen?

> Wenn man sowas machen bzw. für die Zukunft nicht ausschließen will, ist
> es eine gute Idee, keine Partitionen, sondern lvm-Volumes zu verwenden.

> Nur kann man das leider nicht nachträglich tun ; man muss also
> rechtzeitig daran denkebn.

Das verstehe ich, es muß aber nunmal nachträglich gemacht werden.
Auf meinem Kubuntu sind viele Anwendungen installiert und konfiguriert.
Das müßte ich dann bei 'vorher' alles neu machen.

Freundliche Grüße
Wolfgang
--
Natürlich bin ich ein Morgenmensch. Ich mache immer alles Morgen.

[Marc Haber]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>Marc Haber meinte:
>>>Wenn man sowas machen bzw. für die Zukunft nicht ausschließen will,
>>>ist es eine gute Idee, keine Partitionen, sondern lvm-Volumes zu
>>>verwenden.
>>
>> Amen. Das braucht halt entweder Softwareunterstüzung oder mehr Ahnung.
>>
>> gparted kann mit LVM nicht umgehen.
>
>Wenn man lvm hat, braucht man kein gparted.

Das stimmt nicht, man muss ja die Partitionen anlegen in denen die PV
dann liegt. Oder machst Du pvcreate /dev/sda? Wie bootest Du von
sowas?

Bei virtuellen Maschinen kann man durchaus mal den Container (also
meist eine LV auf dem Host) resizen, dann muss man innerhalb des
Containers auch wieder eine Partition vergrößern um dann die da drin
liegende PV zu vergrößern.

Aber auch meine physikalischen Rechner haben mindestens drei
Partitionen: die erste ist die EFI-Partiton, die zweite /boot¹, die
dritte dann die PV in der das eigentliche System liegt. Bei
vollverschlüsselten Platten gerne noch eine vierte in der ein Teil des
Schlüssels liegt.

>>>Die kann man sowohl im laufenden Betrieb auf andere Platten
>>>verschieben als auch vergrößern (und viele Filesysteme lassen sich
>>>auch onlne vergrößern, wenn einmal das zugrundeliegene lv vergrößert
>>>worden ist).
>>
>> Dann hat man das Problem mit dem Vergrößern von PVs. Okay, seltener.
>
>Nö. PVs vergrößert man nicht, man fügt einfach weitere PVs zur VG hinzu.

Das finde ich unschön. Mache ich eigentlich nie.

>Man braucht mit LVM eigentlich gar keine Partitionen - statt /dev/sdx1
>kann man auch gleich die ganze Platte /dev/sdx zum PV machen. (OK, das
>gilt nur für Platten, von denen man nicht booten will, die EFI-Partition
>braucht man auf der Bootplatte.)

Könnte man. Mache ich nicht, ist nur ein Sonderfall mehr mit dem man
auf die Nase fliegen kann.

>>>Nur kann man das leider nicht nachträglich tun ; man muss also
>>>rechtzeitig daran denken. (Redhat legte mindestens früher mal alles
>>>in logical volumes; ich habe aber lange kein Redhat mehr in den
>>>Fingern gehabt).
>>
>> Nachträglich geht auch, braucht halt für das dd der raw partition in
>> die LV ein Rescuesystem, herumprökeln in der fstab und mit dem
>> Bootmanager.
>
>Ich meinte "ohne umherkopieren".

Dann sind wir uns wieder einig.

>Auch das mag sehr eventuell vielleicht
>unter Umständen möglicherweise irgendwie gehen, wenn vor und hinter den
>Partitionen, die man übernehmen will, noch Platz für Metadaten ist,

Brrrr. Kann man machen, muss man aber nicht.

>Aber das ist nur was für Masochisten.

Genau.

>Ich habe einmal in einer Notsituation remote

>bei einem Kunden in so etwas herumeditieren müssen, das war ... äh ...
>challenging und blutdrucksteigernd.

Sowas macht man einmal, nie wieder, und erzählt die Kriegsgeschichte
den Rest seines Lebens.

[Diedrich Ehlerding]

Marc Haber meinte:

> Das stimmt nicht, man muss ja die Partitionen anlegen in denen die PV
> dann liegt. Oder machst Du pvcreate /dev/sda? Wie bootest Du von
> sowas?

Ich habe beruflich mit sowas zu tun gehabt. Klar, die Bootplatte
braucht, u.a. wegen EFI, Partitionen; das schrieb ich doch auch schon.
Aber alles, was nicht EFI ist, wird zum PV. Und externe Platten (die zB
von einem Cluster beidseitig zugänglich sein müssen) habe ich da immer
ohne Partition betrieben.

Gerade im Cluster hat einb Volumemanager den unschätzbaren Vorteil, dass
die LV-Deviceknoten automagisch auf allen Clusterknoten gleich heißen,
und dass man bei einigermaßen sinnvoller BNamensvergabe auch gleich
sieht, was wo gemountet werden muss. .

[Marc Haber]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>Marc Haber meinte:
>
>> Das stimmt nicht, man muss ja die Partitionen anlegen in denen die PV
>> dann liegt. Oder machst Du pvcreate /dev/sda? Wie bootest Du von
>> sowas?
>
>Ich habe beruflich mit sowas zu tun gehabt. Klar, die Bootplatte
>braucht, u.a. wegen EFI, Partitionen; das schrieb ich doch auch schon.
>Aber alles, was nicht EFI ist, wird zum PV.

Ich habe auf nicht-VMs noch ein abgetrenntes /boot, weil man dann
grml-rescueboot verwenden kann (der grml-bootprozess findet sein .iso
nicht auf einer LV).

>Und externe Platten (die zB
>von einem Cluster beidseitig zugänglich sein müssen) habe ich da immer
>ohne Partition betrieben.

Das kann man sicher machen. Mein Bauchgefühl sagt aber eher, mach das
nicht, und wenn es nur ist um die weniger versierten Kollegen¹ nicht
aufs Glatteis zu führen.

>Gerade im Cluster hat einb Volumemanager den unschätzbaren Vorteil, dass
>die LV-Deviceknoten automagisch auf allen Clusterknoten gleich heißen,
>und dass man bei einigermaßen sinnvoller BNamensvergabe auch gleich
>sieht, was wo gemountet werden muss. .

gegen LVM hab ich auch nichts.

Und für beständige Namen ist /dev/disk/by-* gewachsen. Aber ja, auch
das ist advanced und benötigt Kollegen die um die Ecke denke können.
Nicht alles, was für unsereins einfach erscheint, ist für jemand
anderen auch einfach.

Grüße
Marc

¹ das sind immer die Pechvögel die es in der Bereitschaft erwischt und
die sich dann nicht trauen einen Senior aus dem Bett zu klingeln.

[Christian Garbs]

Mahlzeit!

Arno Lutz <inv...@freakmail.de> wrote:
> Am 06.02.24 um 18:47 schrieb Marc Haber:

>>>> Eine Systemplatte von einem anderen unabhängigen System aus zu verändern,
>>>> während sie dort gemountet ist, ist wie die Reparatur eines laufenden Automotors,
>>>> während das Auto in der Garage steht. Kann man machen, wenn man sich der
>>>> Risiken bewusst ist und weiß, was man tunlichst vermeiden sollte.

>>> IMHO wird zum Bearbeiten die Partition ausgehängt!
>>> Habs noch nie anders erlebt.

>> Ich habe mit parted auch schon im laufenden System die root-Partition
>> gelöscht und in Folge größer wieder neu angelegt (mit dem gleichen
>> Startsektor, versteht sich).

> Ich vermute mal : auf/mit Konsole.

Das kannst Du auch unter X machen, wenn Du fdisk in einem xterm
aufrufst. Dabei kann man sich zwar in den Fuß schießen, aber wenn man
aufpasst, kann eigentlich gar nichts schiefgehen: Man verschiebt ja
nur die "Grenzen" der Parition (also das Ende weiter nach hinten), für
das Dateisystem und laufende Anwendungen ändert sich dabei exakt gar
nichts.

Im besten Fall kommt hinterher sowieso die Warnung, dass jetzt zwar
die Partitionstabelle angepasst ist, der Kernel aber noch die alte
verwendet ;-)

Falls die Meldung nicht kommt (oder man nachhilft oder neu bootet),
lässt man resize2fs über die geänderte Partition laufen und kann ab
dann den zusätzlichen Speicher auch nutzen. Das geht online,
d.h. auch dieser Schritt ist im laufenden System ohne Unmount möglich.

(Und mit LVM kann man im laufenden Betrieb noch viel mehr jonglieren.
Ich habe erst nach vielen Jahren bemerkt, dass lvresize auch direkt
resize2fs aufrufen kann, was einem insbesondere bei Verkleinerungen
das Gerechne erspart. Kleiner machen geht allerdings nur offline,
d.h. ungemounted.)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Fun game: try to post a YouTube comment so stupid that people realize
you must be joking. (Hint: this is impossible)
from xkcd.com

[Diedrich Ehlerding]

Marc Haber meinte:

>>Gerade im Cluster hat einb Volumemanager den unschätzbaren Vorteil,
>>dass die LV-Deviceknoten automagisch auf allen Clusterknoten gleich
>>heißen, und dass man bei einigermaßen sinnvoller BNamensvergabe auch
>>gleich sieht, was wo gemountet werden muss. .
>
> gegen LVM hab ich auch nichts.
>
> Und für beständige Namen ist /dev/disk/by-* gewachsen.

Ja, die sind rebootfest; aber die hardwarebasierten (/dev/disk/by-
id/...) sind wenig benutzerfreundlich, da muss man zB Filesystemlabel
erzeugen. Das ist auch nix für Otto Normaldau.

[Marc Haber]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>Marc Haber meinte:
>
>>>Gerade im Cluster hat einb Volumemanager den unschätzbaren Vorteil,
>>>dass die LV-Deviceknoten automagisch auf allen Clusterknoten gleich
>>>heißen, und dass man bei einigermaßen sinnvoller BNamensvergabe auch
>>>gleich sieht, was wo gemountet werden muss. .
>>
>> gegen LVM hab ich auch nichts.
>>
>> Und für beständige Namen ist /dev/disk/by-* gewachsen.
>
>Ja, die sind rebootfest; aber die hardwarebasierten (/dev/disk/by-
>id/...) sind wenig benutzerfreundlich, da muss man zB Filesystemlabel
>erzeugen. Das ist auch nix für Otto Normaldau.

Ja. Tiefe Operationen an komplexem Massenspeicherlayout sind jenseits
des Normalusers

Grüße
Marc

[Christian Garbs]

Mahlzeit!

Marc Haber <mh+usene...@zugschl.us> wrote:

> Partitionen: die erste ist die EFI-Partiton, die zweite /boot¹, die

E_DANGLING_FOOTNOTE_REFERENCE

Lös bitte den Cliffhanger auf :)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Hinweis: die Information steckt primär im schwarzen Teil des
Schwarz/Weiß-Musters auf Deinem Bildschirm, wird als solche jedoch
nur in der spezifischen Abgrenzung gegen Weiß deutlich. (E. Mönkeberg)

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>
>> Partitionen: die erste ist die EFI-Partiton, die zweite /boot¹, die
>
>E_DANGLING_FOOTNOTE_REFERENCE
>
>Lös bitte den Cliffhanger auf :)

upps. Das schrieb ich an anderem Ort schon: Wenn /boot im LVM liegt,
funktioniert grml-rescueboot nicht.

[Christian Garbs]

Mahlzeit!

Diedrich Ehlerding <diedrich....@t-online.de> wrote:

> Gerade im Cluster hat einb Volumemanager den unschätzbaren Vorteil,
> dass die LV-Deviceknoten automagisch auf allen Clusterknoten gleich
> heißen, und dass man bei einigermaßen sinnvoller BNamensvergabe auch
> gleich sieht, was wo gemountet werden muss. .

Ich habe das Naming dafür genutzt, meine Backup-Platten eindeutig zu
labeln. Die gesamte Platte (ohne Partitionen) ist jeweils eine VG mit
genau einem PV und ein paar LVs.

Dazu ein kleines Shellskript, dass mir nach Anstecken der Platten per
USB alle LVs automatisch an eine definierte Stelle mounted. Der
Mountpoint ist abhängig von der VG und alle Platten haben einen
gemeinsamen VG-Präfix. So muss ich nicht mit udev hantieren oder
irgendwelche Platten-UUIDs in Skripte schreiben.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Der Karpfenteich darf kein hechtfreier Raum sein!

[Ulli Horlacher]

Christian Garbs <mi...@cgarbs.de> wrote:

> Ich habe das Naming dafür genutzt, meine Backup-Platten eindeutig zu
> labeln. Die gesamte Platte (ohne Partitionen) ist jeweils eine VG mit
> genau einem PV und ein paar LVs.
>
> Dazu ein kleines Shellskript, dass mir nach Anstecken der Platten per
> USB alle LVs automatisch an eine definierte Stelle mounted. Der
> Mountpoint ist abhängig von der VG und alle Platten haben einen
> gemeinsamen VG-Präfix. So muss ich nicht mit udev hantieren oder
> irgendwelche Platten-UUIDs in Skripte schreiben.

Viel zu umstaendlich.
Das haettest du auch mit Labels erreicht, ohne LVM.


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/

[gregor herrmann]

On Tue, 06 Feb 2024 18:47:29 +0100, Marc Haber wrote:

> Ich habe mit parted auch schon im laufenden System die root-Partition
> gelöscht und in Folge größer wieder neu angelegt (mit dem gleichen
> Startsektor, versteht sich).

vor kurzem entdeckt: growpart (im paket cloud-guest-utils).

gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-

[Diedrich Ehlerding]

Ulli Horlacher meinte:

>> Ich habe das Naming dafür genutzt, meine Backup-Platten eindeutig zu
>> labeln. Die gesamte Platte (ohne Partitionen) ist jeweils eine VG
>> mit genau einem PV und ein paar LVs.
>>
>> Dazu ein kleines Shellskript, dass mir nach Anstecken der Platten per
>> USB alle LVs automatisch an eine definierte Stelle mounted. Der
>> Mountpoint ist abhängig von der VG und alle Platten haben einen
>> gemeinsamen VG-Präfix. So muss ich nicht mit udev hantieren oder
>> irgendwelche Platten-UUIDs in Skripte schreiben.
>
> Viel zu umstaendlich.
> Das haettest du auch mit Labels erreicht, ohne LVM

Dazu hätte er aber Partitionen einrichten müssen - also vorher wissen
müssen, wieviele das sein werden und wie groß die sind. Im Falle von LVs
kann er bei Bedarfg LVs löschen, neu anlegen, vergrößern usw., ohne auf
starre Partitionsgrenzen Rücksicht nehmen zu müssen. Und (worums hier zu
Thread ja gerade ging) problemlos das Ganze auf andere Hardware umziehen
(sogar im laufenden Betrieb).

[Gerald E¡scher]

Marc Haber schrieb am 9/2/2024 13:52:

> Christian Garbs <mi...@cgarbs.de> wrote:
>>Marc Haber <mh+usene...@zugschl.us> wrote:
>>
>>> Partitionen: die erste ist die EFI-Partiton, die zweite /boot¹, die
>>
>>E_DANGLING_FOOTNOTE_REFERENCE
>>
>>Lös bitte den Cliffhanger auf :)
>
> upps. Das schrieb ich an anderem Ort schon: Wenn /boot im LVM liegt,
> funktioniert grml-rescueboot nicht.

Wenn /boot im LVM liegt, zickt auch GRUB in manchen Belangen herum, z.B.
lässt sich der Timeout vom Auswahlmenü nur mit Verrenkungen auf eine
andere Zeit als dem Default von 30 s einstellen.

--
Gerald

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:
>Ich habe das Naming dafür genutzt, meine Backup-Platten eindeutig zu
>labeln. Die gesamte Platte (ohne Partitionen) ist jeweils eine VG mit
>genau einem PV und ein paar LVs.

Bei meinen Backupplatten habe ich mir den LVM gekniffen, das ist mir
zu viel riss mit vgscan und vgchange. Und vor allen Dingen mit dem
vgchange vor dem Rausziehen der Platte.

[Christian Garbs]

Mahlzeit!

Marc Haber <mh+usene...@zugschl.us> wrote:

> Christian Garbs <mi...@cgarbs.de> wrote:

>>Ich habe das Naming dafür genutzt, meine Backup-Platten eindeutig zu
>>labeln. Die gesamte Platte (ohne Partitionen) ist jeweils eine VG mit
>>genau einem PV und ein paar LVs.
>
> Bei meinen Backupplatten habe ich mir den LVM gekniffen, das ist mir
> zu viel riss mit vgscan und vgchange. Und vor allen Dingen mit dem
> vgchange vor dem Rausziehen der Platte.

Das macht das selbstgebaute mount-/unmount-Skript gleich mit. Als ich
das damals geschrieben habe, habe ich diverse neue Dinge gelernt
(u.a. genau das vgchange).

Jetzt habe ich ein Skript, wo ich das abgucken kann, weil ich das
alles schon wieder vergessen habe ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Eine Moschee ist kein extrem lange Heavy-Metal-Session,
sondern eine Art islamische Kirche.

[Ulli Horlacher]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> Ulli Horlacher meinte:
>
>>> Ich habe das Naming dafür genutzt, meine Backup-Platten eindeutig zu
>>> labeln. Die gesamte Platte (ohne Partitionen) ist jeweils eine VG
>>> mit genau einem PV und ein paar LVs.
>>>
>>> Dazu ein kleines Shellskript, dass mir nach Anstecken der Platten per
>>> USB alle LVs automatisch an eine definierte Stelle mounted. Der
>>> Mountpoint ist abhängig von der VG und alle Platten haben einen
>>> gemeinsamen VG-Präfix. So muss ich nicht mit udev hantieren oder
>>> irgendwelche Platten-UUIDs in Skripte schreiben.
>>
>> Viel zu umstaendlich.
>> Das haettest du auch mit Labels erreicht, ohne LVM
>
> Dazu hätte er aber Partitionen einrichten müssen

Man kann filesystem auch direkt auf der disk einrichten ohne
Partitionierung.

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Christian Garbs <mi...@cgarbs.de> wrote:
>>Ich habe das Naming dafür genutzt, meine Backup-Platten eindeutig zu
>>labeln. Die gesamte Platte (ohne Partitionen) ist jeweils eine VG mit
>>genau einem PV und ein paar LVs.
>
> Bei meinen Backupplatten habe ich mir den LVM gekniffen, das ist mir
> zu viel riss mit vgscan und vgchange. Und vor allen Dingen mit dem
> vgchange vor dem Rausziehen der Platte.

Weil vergisst man das, muss man rebooten.

[Diedrich Ehlerding]

Ulli Horlacher meinte:

>>>> VG mit genau einem PV und ein paar LVs.

^^^^^^^^^^^^

>>>>
>>>> Dazu ein kleines Shellskript, dass mir nach Anstecken der Platten
>>>> per USB alle LVs automatisch an eine definierte Stelle mounted.
>>>> Der Mountpoint ist abhängig von der VG und alle Platten haben einen
>>>> gemeinsamen VG-Präfix. So muss ich nicht mit udev hantieren oder
>>>> irgendwelche Platten-UUIDs in Skripte schreiben.
>>>
>>> Viel zu umstaendlich.
>>> Das haettest du auch mit Labels erreicht, ohne LVM

^

>>
>> Dazu hätte er aber Partitionen einrichten müssen
>
> Man kann filesystem auch direkt auf der disk einrichten ohne
> Partitionierung.

Ja, schon. EIN Filesystem pro Platte. Es ging aber erstens um mehrere,
und andererseits darum, die Datenmigration von einer auf die andere
Platte zu erleichtern, möglichst im laufenden Betrieb.