[Ubuntu in VirtualBox]

[Klaus Gawol]

Hallo,

zum Kennenlernen habe ich das aktuelle Ubuntu unter VisualBox
installiert. Dabei wurde automatisch eine virtuelle Festplatte mit 8 GB
angelegt.

Beim Versuch ein Programm zu installieren wurde von Ubuntu zu wenig
Speicher gemeldet. Angeblich seien nur noch 360 MB verfügbar.

Daraufhin habe ich die virtuelle Festplatte auf 16 GB erweitert. Danach
die gleiche Fehlermeldung - wieder nur noch 360 MB verfügbar.

Ich steh' auf dem Schlauch. :(

Gruß Klaus

[Marc Haber]

Klaus Gawol <Klaus...@gmx.de> wrote:
>Daraufhin habe ich die virtuelle Festplatte auf 16 GB erweitert. Danach
>die gleiche Fehlermeldung - wieder nur noch 360 MB verfügbar.

Hast Du auch die Partition und das Dateisystem vergrößert? Was sagen
parted und df?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Michael Limburg]

Klaus Gawol schrieb:

Hallo

> zum Kennenlernen habe ich das aktuelle Ubuntu unter VisualBox

Ich vermute mal, daß Virtualbox gemeint ist.

> Daraufhin habe ich die virtuelle Festplatte auf 16 GB erweitert. Danach
> die gleiche Fehlermeldung - wieder nur noch 360 MB verfügbar.
>
> Ich steh' auf dem Schlauch. :(

Möglichweise ist der zugewiesene Arbeitsspeicher gemeint, nicht
der verfügbare Platz auf der virtuellen Festplatte.

MfG

[Ulli Horlacher]

Klaus Gawol <Klaus...@gmx.de> wrote:

> Beim Versuch ein Programm zu installieren wurde von Ubuntu zu wenig
> Speicher gemeldet. Angeblich seien nur noch 360 MB verfügbar.

Die EXAKTE Fehlermeldung waere von Vorteil!
"Herr Doktor, es tut mir angeblich irgendwo da unten weh, was soll ich
tun?!"

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

[Volker Gringmuth]

Klaus Gawol wrote:

>Beim Versuch ein Programm zu installieren wurde von Ubuntu zu wenig
>Speicher gemeldet. Angeblich seien nur noch 360 MB verfügbar.

Arbeitsspeicher oder Festplattengröße?


vG

[Klaus Gawol]

Am 16.12.2015 um 15:26 schrieb Marc Haber:
> Klaus Gawol <Klaus...@gmx.de> wrote:
>> Daraufhin habe ich die virtuelle Festplatte auf 16 GB erweitert. Danach
>> die gleiche Fehlermeldung - wieder nur noch 360 MB verfügbar.
>
> Hast Du auch die Partition und das Dateisystem vergrößert? Was sagen
> parted und df?
>
> Grüße
> Marc
>

VirtualBox sagt:
Massenspeicher: Ubuntu.vdi (normal 16.00 GB)

home sagt:
Freier Speicherplatz: 383,9 MB

df sagt:
Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
udev 364672 0 364672 0% /dev
tmpfs 76248 5252 70996 7% /run
/dev/sda1 7350760 6579456 374864 95% /
tmpfs 381220 80 381140 1% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 381220 0 381220 0% /sys/fs/cgroup
cgmfs 100 0 100 0% /run/cgmanager/fs
none 133307336 25129148 108178188 19% /media/sf_Austausch
tmpfs 76248 44 76204 1% /run/user/1000
/dev/sr0 57620 57620 0 100%
/media/klaus/VBOXADDITIONS_5.0.10_104061

[Marc Haber]

Klaus Gawol <Klaus...@gmx.de> wrote:
>Am 16.12.2015 um 15:26 schrieb Marc Haber:
>> Klaus Gawol <Klaus...@gmx.de> wrote:
>>> Daraufhin habe ich die virtuelle Festplatte auf 16 GB erweitert. Danach
>>> die gleiche Fehlermeldung - wieder nur noch 360 MB verfügbar.
>>
>> Hast Du auch die Partition und das Dateisystem vergrößert? Was sagen
>> parted und df?
>>
>> Grüße
>> Marc
>>
>VirtualBox sagt:
>Massenspeicher: Ubuntu.vdi (normal 16.00 GB)
>
>home sagt:
>Freier Speicherplatz: 383,9 MB
>
>df sagt:
>Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
>udev 364672 0 364672 0% /dev
>tmpfs 76248 5252 70996 7% /run
>/dev/sda1 7350760 6579456 374864 95% /

Du hast also mindestens das Dateisystem _nicht_ vergrößert.

[Helmut Hullen]

Hallo, Marc,

Du meintest am 17.12.15:

>>> Hast Du auch die Partition und das Dateisystem vergrößert? Was
>>> sagen parted und df?

[...]

>> df sagt:
>> Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
>> udev 364672 0 364672 0% /dev
>> tmpfs 76248 5252 70996 7% /run
>> /dev/sda1 7350760 6579456 374864 95% /

> Du hast also mindestens das Dateisystem _nicht_ vergrößert.

???
Wie vergrössere ich ein Dateisystem?
Bisher ging ich davon aus, dass Partitionen vergrössert werden, und dass
das Dateisystem für die gesamte Partition gilt. Einziges mögliches
Hindernis: die Partition ist für das jeweilige Dateisystem zu gross
(z.B. bei vfat).

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

[Marc Haber]

Hel...@Hullen.de (Helmut Hullen) wrote:
>Wie vergrössere ich ein Dateisystem?

Das weißt Du ganz genau.

>Bisher ging ich davon aus, dass Partitionen vergrössert werden, und dass
>das Dateisystem für die gesamte Partition gilt.

Du hast also noch nie z.B. resize2fs benutzen müssen?

[Klaus Gawol]

Am 17.12.2015 um 10:19 schrieb Martin Schnitkemper:

> ✉ Am Donnerstag, 17. Dezember 2015 08:30 schrieb Helmut Hullen:
>
>> Wie vergrössere ich ein Dateisystem?
>> Bisher ging ich davon aus, dass Partitionen vergrössert werden, und dass
>> das Dateisystem für die gesamte Partition gilt.
>

> Wenn in der Überschrift der Ausgabe von "df" von einem "Dateisystem" die
> Rede ist und in der Spalte darunter "/dev/sda1" angezeigt wird sollte jeder
> (außer dir) verstehen, was damit gemeint ist.
>
> Wenn dir die Formulierung zu missverständlich erscheint kannst du sie gerne
> unter bug-co...@gnu.org als Fehler melden.

Hallo Martin, du hast sicherlich recht mit deiner Bemerkung und Erklärung.

Doch wenn man von Windows her kommt, dann versteht man unter
'Dateisystem' ohne langes Überlegen so etwas die NTSF oder Ext3. Und so
etwas kann man nicht 'vergrößern'.

Genauso würde ich '/dev/sda1' sofort als Laufwerk oder Partition
verstehen, keinesfalls aber als Dateisystem.

Hier gehen also die Bezeichnungen weit auseinander, was sicherlich das
gegenseitig Verstehen erschwert.

Um nun das 'Dateisystem' zu vergrößern, fand ich im Netz den Tipp, dass
dies durch Eingabe von 'sudo resize2sf -p /dev/gerätename' möglich sei.
Versuche ich aber als Gerätename mit '/dev/sda2', dann erhalte ich die
Fehlermeldung: 'Es kann kein gültiger Dateisystem-Superblock gefunden
werden.'

[Klaus Gawol]

Am 17.12.2015 um 12:34 schrieb Martin Schnitkemper:

> ✉ Am Donnerstag, 17. Dezember 2015 12:04 schrieb Klaus Gawol:
>
>> Versuche ich aber als Gerätename mit '/dev/sda2', dann erhalte ich die
>> Fehlermeldung: 'Es kann kein gültiger Dateisystem-Superblock gefunden
>> werden.'
>

> Wenn ich mich recht erinnere wolltest Du doch

>
> | /dev/sda1 7350760 6579456 374864 95% /
>

> vergrößern.

Ja, weil ich beim Installieren von Software den Hinweis vom System
bekam, dass zu wenige Platz vorhanden sei. Ich nehme also an, dass der
Platz von sda1 (nicht sda2 wie ich oben angab) zu gering ist.

[Klaus Gawol]

Ergänzung: Das Hauptproblem liegt darin, dass Ubuntu in einer virtuellen
Umgebung läuft, denn sonst würde ich einfach Gparted verwenden.

[Marc Haber]

Klaus Gawol <Klaus...@gmx.de> wrote:
>Am 17.12.2015 um 12:34 schrieb Martin Schnitkemper:

Du hast sda vergrößert und damit unpartitionierten Platz erzeugt.
Jetzt kannst Du erstmal selbst entscheiden, ob Du eine neue Partition
und ein neues Dateisystem erzeugen möchtest und deses vielleicht
irgendwo einhängen möchtest[1], oder ob Du zunächst die Partition, in
der Dein root-Dateisystem liegt, vergrößern möchtest um damit Platz
für die Vergrößerung des eigentlichen Dateisystems zu schaffen.

Grüße
Marc


[1] früher war der kanonische Weg, /usr auf eine eigene Partition zu
verschieben, aber das war den systemd-Autoren zu kompliziert und
deswegen geht das heutzutage nicht mehr komplikationslos

[Helmut Hullen]

Hallo, Marc,

Du meintest am 17.12.15:

>> Wie vergrössere ich ein Dateisystem?

> Das weißt Du ganz genau.

Ja. Ich vergrössere Partitionen. Keine Dateisysteme.

>> Bisher ging ich davon aus, dass Partitionen vergrössert werden, und
>> dass das Dateisystem für die gesamte Partition gilt.

> Du hast also noch nie z.B. resize2fs benutzen müssen?

Nein. Ich pflege erst mal die Dateien zu sichern, dann die Partition zu
ändern, darauf ein Dateiystem anzulegen (kann gleich sein, aber auch
anders) und dann die Dateien aus dem Backup draufzuspielen. Geht
schznell und sicher.

[Helmut Hullen]

Hallo, Klaus,

Du meintest am 17.12.15:

>>> Wie vergrössere ich ein Dateisystem?
>>> Bisher ging ich davon aus, dass Partitionen vergrössert werden, und
>>> dass das Dateisystem für die gesamte Partition gilt.

>> Wenn in der Überschrift der Ausgabe von "df" von einem "Dateisystem"
>> die Rede ist und in der Spalte darunter "/dev/sda1" angezeigt wird
>> sollte jeder (außer dir) verstehen, was damit gemeint ist.
>>
>> Wenn dir die Formulierung zu missverständlich erscheint kannst du
>> sie gerne unter bug-co...@gnu.org als Fehler melden.

> Hallo Martin, du hast sicherlich recht mit deiner Bemerkung und
> Erklärung.

> Doch wenn man von Windows her kommt, dann versteht man unter
> 'Dateisystem' ohne langes Überlegen so etwas die NTSF oder Ext3. Und
> so etwas kann man nicht 'vergrößern'.

Das gilt nicht nur bei Windows, das gilt auch bei Linux, und auch bei
anderen Betriebssystemen. Siehe auch

https://de.wikipedia.org/wiki/Dateisystem

Dateisystem und Datenträger sind nun mal verschiedene Dinge. Sie
beschreiben verschiedenes.

Aber wenn ich darauf hinweise, noch dazu bei einem Vielschreiber, ...

[Helmut Hullen]

Hallo, Martin,

Du meintest am 17.12.15:

>> Versuche ich aber als Gerätename mit '/dev/sda2', dann erhalte ich
>> die Fehlermeldung: 'Es kann kein gültiger Dateisystem-Superblock
>> gefunden werden.'

> Wenn ich mich recht erinnere wolltest Du doch

> | /dev/sda1 7350760 6579456 374864 95% /

> vergrößern.

Also eine Partition.

[Juergen P. Meier]

begin 1 followup to Klaus Gawol <Klaus...@gmx.de>:

> Am 17.12.2015 um 10:19 schrieb Martin Schnitkemper:

>> ? Am Donnerstag, 17. Dezember 2015 08:30 schrieb Helmut Hullen:
>>
>>> Wie vergrössere ich ein Dateisystem?

Unter Linux: resizefs

>>> Bisher ging ich davon aus, dass Partitionen vergrössert werden, und dass
>>> das Dateisystem für die gesamte Partition gilt.

Ein Dateisystem wird auf eine Partition eingepasst. Wenn es aber
einmal angelegt ist, und du die partition verbgroesserst, musst du das
mit dem einpassen natuerlich neu machen.
Wenn du das ganze verkleinern willst, musst du auch zuerst das
Dateisystem schrumpfen, dann erst kannst du die Partition verkleinern.

> Doch wenn man von Windows her kommt, dann versteht man unter
> 'Dateisystem' ohne langes Überlegen so etwas die NTSF oder Ext3. Und so

Richtig.

> etwas kann man nicht 'vergrößern'.

Aeh, flasch.

Sowohl NTFS als auch ext3fs kann man vergroessern und auch
verkleinern. Aber das geht nicht automatisch. Weder bei Windows noch
bei Linux.

> Genauso würde ich '/dev/sda1' sofort als Laufwerk oder Partition
> verstehen, keinesfalls aber als Dateisystem.

Richtig.

> Um nun das 'Dateisystem' zu vergrößern, fand ich im Netz den Tipp, dass
> dies durch Eingabe von 'sudo resize2sf -p /dev/gerätename' möglich sei.
> Versuche ich aber als Gerätename mit '/dev/sda2', dann erhalte ich die
> Fehlermeldung: 'Es kann kein gültiger Dateisystem-Superblock gefunden
> werden.'

Wo liegt denn dein e2fs bzw. e3fs? Auf SDA2?

Beispiel klassische Partionierung (kein LVM)

Merke: Bei VM wird virtuell eine Festplatte (/dev/sda) simuliert.
Darauf befinden sich idR. partitionen (fester groesse!, z.B. /dev/sda1
von 50 GByte).
Wenn du auf VM-Ebene die virtuelle Platte vergroesserst, dann hat
/dev/sda mehr Bloecke (wird laenger), das hat aber erstmal keinen
Einfluss auf die Partitionierung (/dev/sda1 ist unveraendert).
Du musst also erstmal die Partition vergroessern.
Erst jetzt kannst du dich daran machen, auch das Dateisystem auf
dieser Partition zu vergroessern, das geht mit resizefs.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

[Juergen P. Meier]

Klaus Gawol <Klaus...@gmx.de>:

> Am 17.12.2015 um 13:45 schrieb Klaus Gawol:
>> Am 17.12.2015 um 12:34 schrieb Martin Schnitkemper:

>>> ? Am Donnerstag, 17. Dezember 2015 12:04 schrieb Klaus Gawol:
>>>
>>>> Versuche ich aber als Gerätename mit '/dev/sda2', dann erhalte ich die
>>>> Fehlermeldung: 'Es kann kein gültiger Dateisystem-Superblock gefunden
>>>> werden.'
>>>
>>> Wenn ich mich recht erinnere wolltest Du doch
>>>
>>> | /dev/sda1 7350760 6579456 374864 95% /
>>>
>>> vergrößern.
>>
>> Ja, weil ich beim Installieren von Software den Hinweis vom System
>> bekam, dass zu wenige Platz vorhanden sei. Ich nehme also an, dass der
>> Platz von sda1 (nicht sda2 wie ich oben angab) zu gering ist.
>>
> Ergänzung: Das Hauptproblem liegt darin, dass Ubuntu in einer virtuellen
> Umgebung läuft, denn sonst würde ich einfach Gparted verwenden.

Du hast eine simulierte Festplatte. Du kannst also ganz normal gparted
verwenden um die Partition zu vergroessern.

[Edzard Egberts]

Klaus Gawol wrote:
> Ergänzung: Das Hauptproblem liegt darin, dass Ubuntu in einer virtuellen
> Umgebung läuft, denn sonst würde ich einfach Gparted verwenden.

Das geht wie bei einem richtigen PC:

Erst mit "VirtualBox -> Ändern -> Massenspeicher" eine "CD" einbinden,
z.B. eine "Rescue-CD.iso" oder eine Live-CD.

Dann mit "VirtualBox -> Ändern -> System" die Boot-Reihenfolge so
einstellen, dass diese "CD" gestartet wird und starten.

Dann läuft das in das CD-Betriebssystem hoch und von da aus kannst Du
Deine virtuelle Festplatte editieren, z.B. mit gparted.

[Marc Haber]

Klaus Gawol <Klaus...@gmx.de> wrote:
>Am 17.12.2015 um 13:45 schrieb Klaus Gawol:
>> Am 17.12.2015 um 12:34 schrieb Martin Schnitkemper:

>>> ? Am Donnerstag, 17. Dezember 2015 12:04 schrieb Klaus Gawol:
>>>
>>>> Versuche ich aber als Gerätename mit '/dev/sda2', dann erhalte ich die
>>>> Fehlermeldung: 'Es kann kein gültiger Dateisystem-Superblock gefunden
>>>> werden.'
>>>
>>> Wenn ich mich recht erinnere wolltest Du doch
>>>
>>> | /dev/sda1 7350760 6579456 374864 95% /
>>>
>>> vergrößern.
>>
>> Ja, weil ich beim Installieren von Software den Hinweis vom System
>> bekam, dass zu wenige Platz vorhanden sei. Ich nehme also an, dass der
>> Platz von sda1 (nicht sda2 wie ich oben angab) zu gering ist.
>>
>Ergänzung: Das Hauptproblem liegt darin, dass Ubuntu in einer virtuellen
>Umgebung läuft, denn sonst würde ich einfach Gparted verwenden.

Warum tust Du es nicht einfach?

[Marc Haber]

Hel...@Hullen.de (Helmut Hullen) wrote:
>Nein. Ich pflege erst mal die Dateien zu sichern, dann die Partition zu
>ändern, darauf ein Dateiystem anzulegen (kann gleich sein, aber auch
>anders) und dann die Dateien aus dem Backup draufzuspielen. Geht
>schznell und sicher.

Achso. Keine weiteren Fragen.

[Thomas Heuving]

Klaus Gawol schrieb am Thu, 17 Dec 2015 12:04:55 +0100:
>
> Genauso würde ich '/dev/sda1' sofort als Laufwerk oder Partition
> verstehen, keinesfalls aber als Dateisystem.
>
> Hier gehen also die Bezeichnungen weit auseinander, was sicherlich das
> gegenseitig Verstehen erschwert.
>
> Um nun das 'Dateisystem' zu vergrößern, fand ich im Netz den Tipp, dass
> dies durch Eingabe von 'sudo resize2sf -p /dev/gerätename' möglich sei.
> Versuche ich aber als Gerätename mit '/dev/sda2', dann erhalte ich die
> Fehlermeldung: 'Es kann kein gültiger Dateisystem-Superblock gefunden
> werden.'

In deiner df-Auflistung war auch nur /dev/sda1 drin; /dev/sda2 wirst
du also nicht vergrößert bekommen.

Tschüß
--
Thomas Heuving

[Juergen P. Meier]

Thomas Heuving <heu...@gmx.de>:

Vergroessern von klassischen Partitionen geht auch nur dann, wenn sie
linear wachen /koennen/, d.h. der freie Platz unmittelbar an diese
Partition anschliesst.

In allen anderen faellen haette man vorher auf LVM gehen muessen.

Eigentlich sollte man immer LVM verwenden. Immer.

[Helmut Hullen]

Hallo, Juergen,

Du meintest am 17.12.15:

>>>> Bisher ging ich davon aus, dass Partitionen vergrössert werden,
>>>> und dass das Dateisystem für die gesamte Partition gilt.

> Ein Dateisystem wird auf eine Partition eingepasst. Wenn es aber
> einmal angelegt ist, und du die partition verbgroesserst, musst du
> das mit dem einpassen natuerlich neu machen.

Nicht ich passe ein, das macht "mkfs" selbst.

> Wenn du das ganze verkleinern willst, musst du auch zuerst das
> Dateisystem schrumpfen, dann erst kannst du die Partition
> verkleinern.

Echt? Bei meinen Versuchen mit "gparted" habe ich nie diese zwei
Schritte machen müssen - das hat "gparted" selbst erledigt.

>> etwas kann man nicht 'vergrößern'.

> Aeh, flasch.

> Sowohl NTFS als auch ext3fs kann man vergroessern und auch
> verkleinern. Aber das geht nicht automatisch. Weder bei Windows noch
> bei Linux.

Vielleicht bei LVM. Weil da (soweit ich das verstanden habe) keine
Partitionsgrenzen berücksichtigt werden müssen.

> Wenn du auf VM-Ebene die virtuelle Platte vergroesserst, dann hat
> /dev/sda mehr Bloecke (wird laenger), das hat aber erstmal keinen
> Einfluss auf die Partitionierung (/dev/sda1 ist unveraendert).
> Du musst also erstmal die Partition vergroessern.
> Erst jetzt kannst du dich daran machen, auch das Dateisystem auf
> dieser Partition zu vergroessern, das geht mit resizefs.

Eben - Sonderfall LVM. Hat nichts mit der Konfiguration des Erstfragers
zu tun.

[Christoph 'Mehdorn' Weber]

Hallo!

* Juergen P. Meier <nospa...@jors.net>:

>>> ? Am Donnerstag, 17. Dezember 2015 08:30 schrieb Helmut Hullen:

>>>> Wie vergrössere ich ein Dateisystem?
> Unter Linux: resizefs

Ist das ein Tippfehler für resize2fs oder gibt es ein tolles
Meta-Tool, das je nach Dateisystem die richtige Variante wählt,
z.B. xfs_growfs für XFS, den passenden Remount für jfs, ...?
(Mein apt kennt es jedenfalls nicht.)

> Wenn es aber einmal angelegt ist, und du die partition
> verbgroesserst, musst du das mit dem einpassen natuerlich neu
> machen.

Apropos Partition vergrößern: Wie macht man das am sichersten?

Bisher lösche ich meist die Partition im fdisk und lege sie dann
wieder an, aber wenn man fdisk im falsche Modus betreibt und es
die erste Partiton ist, dann legt man ggf. mit anderem Alignment
an und das System findet danach das Dateisystem nicht mehr.

- sfdisk-Dumps erstellen, bearbeiten, einlesen?
- parted auf Sektoren umstellen und resize wählen?

(Mit parted hab ich eher schlechte Erfahrungen: entweder meckert
es, daß es keinen oder eingeschränkten Support für das Dateisystem
hat und will die Partition gar nicht anfassen, oder ich hab
überlappende Partitionen, weil ich Megabytes habe runden lassen
bzw. mich beim Sektor vertue und es das anstandlos frißt, daß
dabei die Partition in eine andere hineinwächst.)

Christoph

--
telnet ist vollkommen ueberladen. Das kann Mail, News, HTTP
und so weiter. Unix-Philosophie ist, dass man ein Tool fuer
genau eine Aufgabe benutzt. telnet ist was fuer Windows-Leute.
(Christian Garbs)

[Juergen P. Meier]

Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de>:

> * Juergen P. Meier <nospa...@jors.net>:
>>>> ? Am Donnerstag, 17. Dezember 2015 08:30 schrieb Helmut Hullen:
>
>>>>> Wie vergrössere ich ein Dateisystem?
>> Unter Linux: resizefs
>
> Ist das ein Tippfehler für resize2fs oder gibt es ein tolles
> Meta-Tool, das je nach Dateisystem die richtige Variante wählt,

So sollte es sein, ja. So wie "mkfs" und "fsck".

> Apropos Partition vergrößern: Wie macht man das am sichersten?
>
> Bisher lösche ich meist die Partition im fdisk und lege sie dann
> wieder an, aber wenn man fdisk im falsche Modus betreibt und es
> die erste Partiton ist, dann legt man ggf. mit anderem Alignment
> an und das System findet danach das Dateisystem nicht mehr.

Richtig.

> - sfdisk-Dumps erstellen, bearbeiten, einlesen?
> - parted auf Sektoren umstellen und resize wählen?

Oder mit fdisk passend umgehen und auf sektorweise umschalten und sich
alle parameter richtig merken :)

Aber das alles sollte man eh vergessen und nur noch mit LVM arbeiten.
DAs erleichtert einem so vieles.

[Marc Haber]

Hel...@Hullen.de (Helmut Hullen) wrote:
>> Sowohl NTFS als auch ext3fs kann man vergroessern und auch
>> verkleinern. Aber das geht nicht automatisch. Weder bei Windows noch
>> bei Linux.
>
>Vielleicht bei LVM. Weil da (soweit ich das verstanden habe) keine
>Partitionsgrenzen berücksichtigt werden müssen.

Dass Du's nicht verstanden hast ist evident, ja.

>> Wenn du auf VM-Ebene die virtuelle Platte vergroesserst, dann hat
>> /dev/sda mehr Bloecke (wird laenger), das hat aber erstmal keinen
>> Einfluss auf die Partitionierung (/dev/sda1 ist unveraendert).
>> Du musst also erstmal die Partition vergroessern.
>> Erst jetzt kannst du dich daran machen, auch das Dateisystem auf
>> dieser Partition zu vergroessern, das geht mit resizefs.
>
>Eben - Sonderfall LVM.

Unsinn.

>Hat nichts mit der Konfiguration des Erstfragers
>zu tun.

Doch.

[Marc Haber]

Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de> wrote:
> Apropos Partition vergrößern: Wie macht man das am sichersten?

Ich mache das jedes Mal mit einem gehörigen Kloß im Hals mit parted
nacah "unit s" mit Sektornummern, und habe das vorher angefertigte
Backup bisher nie gebraucht.

Es gibt hoffentlich elegantere Methoden.

[Marc Haber]

"Juergen P. Meier" <nospa...@jors.net> wrote:
>Aber das alles sollte man eh vergessen und nur noch mit LVM arbeiten.
>DAs erleichtert einem so vieles.

Bis man mal bereut dass man die PV direkt auf sdx angelegt hat oder
die PV doch nicht in Maximalgröße gehabt hätte.

Wie man's macht, man macht's verkehrt.

Grüße
Marc, der auf LVM eigentlich nur in kleinen VMs verzichtet

[Helmut Hullen]

Hallo, Marc,

Du meintest am 17.12.15:

>>> Sowohl NTFS als auch ext3fs kann man vergroessern und auch
>>> verkleinern. Aber das geht nicht automatisch. Weder bei Windows
>>> noch bei Linux.
>>
>> Vielleicht bei LVM. Weil da (soweit ich das verstanden habe) keine
>> Partitionsgrenzen berücksichtigt werden müssen.

> Dass Du's nicht verstanden hast ist evident, ja.

Ach - bei LVM müssen Partitionsgrenzen berücksichtigt werden?

[Helmut Hullen]

Hallo, Marc,

Du meintest am 17.12.15:

>> Apropos Partition vergrößern: Wie macht man das am sichersten?

> Ich mache das jedes Mal mit einem gehörigen Kloß im Hals mit parted
> nacah "unit s" mit Sektornummern, und habe das vorher angefertigte
> Backup bisher nie gebraucht.

> Es gibt hoffentlich elegantere Methoden.

Klar - ein übersichtliches und sicheres Verfahren hatte ich ja gerade
genannt: Backup, Partition(en) neu einrichten, Dateisystem(e) anlegen,
Backup zurückspielen.

Geht sogar schneller als mit "parted" oder "gparted". Meistens (allemal
bei den Linux-Rechnern hier zuhause) habe ich zudem ein aktuelles
Backup, so dass der erste Schritt recht schnell geht.

[Marc Haber]

Hel...@Hullen.de (Helmut Hullen) wrote:
>Du meintest am 17.12.15:
>>>> Sowohl NTFS als auch ext3fs kann man vergroessern und auch
>>>> verkleinern. Aber das geht nicht automatisch. Weder bei Windows
>>>> noch bei Linux.
>>>
>>> Vielleicht bei LVM. Weil da (soweit ich das verstanden habe) keine
>>> Partitionsgrenzen berücksichtigt werden müssen.
>
>> Dass Du's nicht verstanden hast ist evident, ja.
>
>Ach - bei LVM müssen Partitionsgrenzen berücksichtigt werden?

Die Originalfrage unter Hinzunahme eines irrelevanten
Nebenschauplatzes verkomplizieren und die Diskussion dann über
Verwirrung zu gewinnen versuchen mag bei Deiner Zielgruppe ziehen.
Hier nicht.

[Marc Haber]

Hel...@Hullen.de (Helmut Hullen) wrote:
>Klar - ein übersichtliches und sicheres Verfahren hatte ich ja gerade
>genannt: Backup, Partition(en) neu einrichten, Dateisystem(e) anlegen,
>Backup zurückspielen.

Unfug! Kann man zwar so machen, aber sinnvoll ist es im Jahr 2015
nicht.

>Geht sogar schneller als mit "parted" oder "gparted".

Beweis durch Behauptung? Sportlich.

[Helmut Hullen]

Hallo, Marc,

Du meintest am 17.12.15:

>>>>> Sowohl NTFS als auch ext3fs kann man vergroessern und auch
>>>>> verkleinern. Aber das geht nicht automatisch. Weder bei Windows
>>>>> noch bei Linux.

>>>> Vielleicht bei LVM. Weil da (soweit ich das verstanden habe) keine
>>>> Partitionsgrenzen berücksichtigt werden müssen.

>>> Dass Du's nicht verstanden hast ist evident, ja.

>> Ach - bei LVM müssen Partitionsgrenzen berücksichtigt werden?

> Die Originalfrage unter Hinzunahme eines irrelevanten
> Nebenschauplatzes verkomplizieren und die Diskussion dann über
> Verwirrung zu gewinnen versuchen mag bei Deiner Zielgruppe ziehen.
> Hier nicht.

Sagt der, der glaubt, ein Dateisystem vergrössern zu können ...
Nebenschauplatz. Mit den von Dir genannten Folgen.

"Nur nicht gleich sachlich werden, es geht ja auch persönlich!" (Anton
Kuh)

[Helmut Hullen]

#Hallo, Marc,

Du meintest am 17.12.15:

>> Klar - ein übersichtliches und sicheres Verfahren hatte ich ja
>> gerade genannt: Backup, Partition(en) neu einrichten, Dateisystem(e)
>> anlegen, Backup zurückspielen.

> Unfug! Kann man zwar so machen, aber sinnvoll ist es im Jahr 2015
> nicht.

Für welche zu erfindenden Inhalte von "sinnvoll"?

>> Geht sogar schneller als mit "parted" oder "gparted".


> Beweis durch Behauptung? Sportlich.

Habe ich mehrfach ausprobiert - leider habe ich vergessen, die Zeiten
duch einen vereidigten Sachverständigen unter notarieller Aufsicht und
gerichtsfest ermitteln zu lassen.

[Helmut Hullen]

Hallo, Marcus,

Du meintest am 18.12.15:

>> Klar - ein übersichtliches und sicheres Verfahren hatte ich ja
>> gerade genannt: Backup, Partition(en) neu einrichten, Dateisystem(e)
>> anlegen, Backup zurückspielen.
>>
>> Geht sogar schneller als mit "parted" oder "gparted". Meistens
>> (allemal bei den Linux-Rechnern hier zuhause) habe ich zudem ein
>> aktuelles Backup, so dass der erste Schritt recht schnell geht.

> Sind Deine Rechner noch aus den Zeiten, als 1GB Platten aktuell
> waren?

Nein - meine beobachteten Zeiten gelten für Partitionen zwischen 10 und
etwa 150 GByte, querbeet.

> Ich hab z.B. keine Rechner, wo der Weg über Backups nicht
> mindestens ganz viele Stunden dauern würde.

So grosse Plattenstapel habe ich auch, derzeit bis etwa 20 TByte.

Folgt daraus irgendeine Kompetenz bezüglich der Zeiten, die das
Vergrössern oder verkleinern von Partitionen erfordert?

> Da bastel ich ehrlich gesagt lieber 15 Minuten länger mit fdisk/gdisk
> rum, wenn's sein muß. Backup kann man im Notfall immer noch zücken.

Wenn's nur 15 Minuten wären ...

Backup habe ich fast immer sowieso aktuell vorliegen, dauert also wenig
bis nichts.
"fdisk" oder "gdisk" dauert beim Löschen der alten und Definieren der
neuen Partitition(en) wenige Minuten.

Dateisystem ("mkfs") draufpacken dauert wenige Minuten, hängt vor allem
von der Partitionsgrösse ab, aber auch vom jeweiligen Dateisystem.

Und dann kommt die Zeit fürs Zurückspielen des Backup - die hängt vor
allem von dessen Grösse ab, aber auch von den beteiligten Geräten.

-----------------

Wenn ich hingegen "parted" oder "gparted" benutze: da müssen (ebenfalls)
die alten Daten "irgendwo" gesichert werden, bevor die Partitionsgrenzen
gändert werden. Und auch da müssen die gesicherten Daten irgendwann auf/
in die geänderte Partition zurückgespielt werden. Sind die gleichen
Teilschritte wie bei meinem Weg, aber sie dauern erheblich länger.
Gefühlt etwa doppelt so lange bei Änderungen im 50-GB-Bereich.

Dateisysteme: Vfat, NTFS, ext2 bis ext4.

[Marc Haber]

Hel...@Hullen.de (Helmut Hullen) wrote:
>Folgt daraus irgendeine Kompetenz bezüglich der Zeiten, die das
>Vergrössern oder verkleinern von Partitionen erfordert

Freilich.

>> Da bastel ich ehrlich gesagt lieber 15 Minuten länger mit fdisk/gdisk
>> rum, wenn's sein muß. Backup kann man im Notfall immer noch zücken.
>
>Wenn's nur 15 Minuten wären ...

Jupp, normalerweise geht es signifikant schneller.

>Wenn ich hingegen "parted" oder "gparted" benutze: da müssen (ebenfalls)
>die alten Daten "irgendwo" gesichert werden, bevor die Partitionsgrenzen
>gändert werden. Und auch da müssen die gesicherten Daten irgendwann auf/
>in die geänderte Partition zurückgespielt werden.

Parted ist von der Funktionalität her etwa mit fdisk zu vergleichen,
das ist also kein Unterschied. Gparted habe ich nie gesehen.

Benutzt man die Tools zum Resizen eines Filesystems, ist der Worst
Case (!) der folgende Prozess:

(1) Backup
(2) In rescuesystem booten
(3) fsck des betroffenen Dateisystems
(4) Partition resizen
(5) wenn partout notwendig, nochmal ins rescuesystem booten
(6) resizefs
(7) Produktionssystem booten

Dies ist konkret auf die aktuelle Situation bezogen:

(a) virtuelle Maschine
(b) nur ein Dateisystem [daher das letzte auf der virtuellen Platte]
(c) virtuelle Platte wurde in der Virtualisierung vergrößert
(d) kein LVM

Mit LVM fällt die Anforderung (b) weg; und wenn es sich nicht um das
Root-Filesystem handelt, muss man mit einiger Wahrscheinlichkeit nicht
mal in ein Rescuesystem booten sondern es reicht wenn man das
betroffene Filesystem zugriffsfrei stellt (also ggf ein paar Dienste
anhält). Im Best case ist nichtmal das notwendig sondern man resized
einfach online.

Ja, das ist kompliziert und hochgradig situationsabhängig, und auch
ich würde vermutlich daran verzweifeln, müsste ich das allgemeingültig
und laientauglich ohne Wissen um das Zielsystem zusammenschreiben. Mit
hinreichender Kompetenz ist das aber alles kein Hexenwerk und
unabhängig von der Datenmenge auf aktuellen Systemen in wenigen
Minuten machbar. Dafür ist man ja Profi.

> Sind die gleichen
>Teilschritte wie bei meinem Weg, aber sie dauern erheblich länger.
>Gefühlt etwa doppelt so lange bei Änderungen im 50-GB-Bereich.

Protokoll or it didn't happen.

[Helmut Hullen]

Hallo, Marc,

Du meintest am 18.12.15:

> Ja, das ist kompliziert und hochgradig situationsabhängig, und auch
> ich würde vermutlich daran verzweifeln, müsste ich das
> allgemeingültig und laientauglich ohne Wissen um das Zielsystem
> zusammenschreiben. Mit hinreichender Kompetenz ist das aber alles
> kein Hexenwerk und unabhängig von der Datenmenge auf aktuellen
> Systemen in wenigen Minuten machbar. Dafür ist man ja Profi.

Und so etwas empfiehlst Du Laien? Toll!

Es gab mal einen Professor, der eine ganze Zeitschrift darauf aufbaute,
komplizierte Vorgänge auch Laien (auf dem jeweiligen Gebiet)
verständlich zu machen.

[Helmut Hullen]

Hallo, Marc,

Du meintest am 18.12.15:

> Jupp, normalerweise geht es signifikant schneller.

[...]

> Dies ist konkret auf die aktuelle Situation bezogen:

> (a) virtuelle Maschine
> (b) nur ein Dateisystem [daher das letzte auf der virtuellen Platte]
> (c) virtuelle Platte wurde in der Virtualisierung vergrößert
> (d) kein LVM

Insbesondere VM ist natürlich ein Sonderfall.
"nur 1 Dateisystem klingt nach "nur 1 Partition" - die muss ausserhalb
von virtuellen Maschinen weder vergrössert noch verkleinert werden.

Du verallgemeinerst einen Sonderfall.

[Klaus Gawol]

Am 17.12.2015 um 14:56 schrieb Juergen P. Meier:
> Klaus Gawol <Klaus...@gmx.de>:
>> Am 17.12.2015 um 13:45 schrieb Klaus Gawol:
>>> Am 17.12.2015 um 12:34 schrieb Martin Schnitkemper:
>>>> ? Am Donnerstag, 17. Dezember 2015 12:04 schrieb Klaus Gawol:
>>>>
>>>>> Versuche ich aber als Gerätename mit '/dev/sda2', dann erhalte ich die
>>>>> Fehlermeldung: 'Es kann kein gültiger Dateisystem-Superblock gefunden
>>>>> werden.'
>>>>
>>>> Wenn ich mich recht erinnere wolltest Du doch
>>>>
>>>> | /dev/sda1 7350760 6579456 374864 95% /
>>>>
>>>> vergrößern.
>>>
>>> Ja, weil ich beim Installieren von Software den Hinweis vom System
>>> bekam, dass zu wenige Platz vorhanden sei. Ich nehme also an, dass der
>>> Platz von sda1 (nicht sda2 wie ich oben angab) zu gering ist.
>>>
>> Ergänzung: Das Hauptproblem liegt darin, dass Ubuntu in einer virtuellen
>> Umgebung läuft, denn sonst würde ich einfach Gparted verwenden.
>
> Du hast eine simulierte Festplatte. Du kannst also ganz normal gparted
> verwenden um die Partition zu vergroessern.

Offenbar stimmt das nicht so ganz, denn bei einer Partitionierung, sie
sieht momentan so aus:
sda1 ext4 = 7,25 GiB
sda2 extended = 766,00 MiB
sda5 linux-swap = 766,00 MiB
unzugeordnet = 8,00 GiB
lässt GParted kein Vergrößern oder Verschieben von sda2 zu.

[Gernot Griese]

Logisch, /dev/sda2 ist auch eine erweiterte Partition innerhalb derer
die Swap-Partition /dev/sda5 liegt. Du müsstest erst Swap deaktivieren,
dann kannst du /dev/sda5 und /dev/sda2 löschen. Danach kannst du
/dev/sda1 vergößern und dahinter eine neue Swap-Partition anlegen.

Gernot

--
Probleme einige Updates werden heruntergeladen, oder versuchen Sie es
später erneut. Wenn Sie, dass diese, starten Sie Durchsuchen des Webs
oder Kontaktaufnahme mit dem Support, um Hilfe zu erhalten angezeigt
behalten. Dieser Fehlercode vielleicht: (0x80240009) [M$, Windows 10]

[Klaus Gawol]

Sehr gut! Endlich die erlösende Antwort. Das hat sofort geklappt. Danke
Gernot.

[Ralph Angenendt]

Well, Helmut Hullen <Hel...@Hullen.de> wrote:
> Es gab mal einen Professor, der eine ganze Zeitschrift darauf aufbaute,
> komplizierte Vorgänge auch Laien (auf dem jeweiligen Gebiet)
> verständlich zu machen.

Warum sachlich bleiben, wenn man auch persönlich werden kann, gelle?

Ralph
--
His goal in life was to be an echo

[Gernot Griese]

Gern geschehen. Hättest du gleich die genaue Partitionierung angegeben,
hättest du nicht so lange zu probieren brauchen.

[Marc Haber]

Gernot Griese <ggr...@gmx.de> wrote:
>Gern geschehen. Hättest du gleich die genaue Partitionierung angegeben,
>hättest du nicht so lange zu probieren brauchen

Genau. Google, catb, smart questions. Lesen und verstehen. So ist
allen geholfen.

[Christoph 'Mehdorn' Weber]

Hallo!

* Helmut Hullen <Hel...@Hullen.de>:

> Insbesondere VM ist natürlich ein Sonderfall.
> "nur 1 Dateisystem klingt nach "nur 1 Partition" - die muss ausserhalb
> von virtuellen Maschinen weder vergrössert noch verkleinert werden.

Warum sollte das so sein? Ich habe hier öfter mal mit
System-Images zu tun, die ich per dd auf ein Medium spiele und
danach die Partitionierung ans Ziel anpasse, weil man z.B. gerade
auf eine größere Platte umgezogen ist. Es kommt öfter vor, daß da
nur ein Dateisystem drauf ist -- gelegentlich sind es auch zwei,
wenn der Bootloader das so braucht(e).

Und beim Erstellen der Images verkleinere ich die meist, bevor
ich sie wegsicher, damit man sie ggf. auf kleinen Datenträgern
wiederherstellen kann. Aktuell kommt das gelegentlich beim Wechsel
von (unnötig) großen Platten -- aber die waren beim Kauf eben so --
auf (ausreichend große) kleinere SSDs vor.

(Zudem sind die Dateien auch kleiner, falls man sie auf einem
Dateisystem zwischenlagern muß, was das Konzept "sparse files"
nicht kennt.)

Christoph

--
"Wo sind denn hier die Sonderzeichen fuer die roemischen Ziffern?"
"Du must alt festhalten und dann auf dem Nummernblock 73 fuer
ein 'I' und 86 fuer ein 'V' tippen..."
(Thomas Fernandez)

[Helmut Hullen]

Hallo, Christoph,

Du meintest am 18.12.15:

>> Insbesondere VM ist natürlich ein Sonderfall.
>> "nur 1 Dateisystem klingt nach "nur 1 Partition" - die muss
>> ausserhalb von virtuellen Maschinen weder vergrössert noch
>> verkleinert werden.

> Warum sollte das so sein? Ich habe hier öfter mal mit
> System-Images zu tun, die ich per dd auf ein Medium spiele und
> danach die Partitionierung ans Ziel anpasse, weil man z.B. gerade
> auf eine größere Platte umgezogen ist. Es kommt öfter vor, daß da
> nur ein Dateisystem drauf ist -- gelegentlich sind es auch zwei,
> wenn der Bootloader das so braucht(e).

Auf nur 1 Partition? Oder pro Partition nur 1 Dateisystem?

> Und beim Erstellen der Images verkleinere ich die meist, bevor
> ich sie wegsicher, damit man sie ggf. auf kleinen Datenträgern
> wiederherstellen kann. Aktuell kommt das gelegentlich beim Wechsel
> von (unnötig) großen Platten -- aber die waren beim Kauf eben so --
> auf (ausreichend große) kleinere SSDs vor.

Ja - diese Basteleien kenne ich auch. Aber auch da dürfte pro Partition
nur 1 Dateisystem sein. Mit dem Sonderfall, dass (z.B. nach Anwendung
von resize2fs") das Dateiosystem nicht die gesamte Partition ausfüllt,
sondern irgendwo ein undefinierter ("free") Rest bleibt.

[Diedrich Ehlerding]

Helmut Hullen meinte:

>> Du hast also noch nie z.B. resize2fs benutzen müssen?
>
> Nein. Ich pflege erst mal die Dateien zu sichern, dann die Partition zu
> ändern, darauf ein Dateiystem anzulegen (kann gleich sein, aber auch
> anders) und dann die Dateien aus dem Backup draufzuspielen. Geht
> schznell und sicher.

Das meinst du jetzt aber hoffentlich nicht ernst!

Filesysteme wie ext[234]fs und xfs sind problemlos online vergrößerbar.
Schon seit vielen Jahren. Du vergrößerst die Partition (oder das LVM-
Volume; dieser Fall ist noch viel einfacher als das Partitionen-
Vergrößern), und dann das Filesystem. Nein, das ist in keiner Weise mehr
experimentell. Ja, das habe ich auch mit professionell eingesetzten
Systemen (irgendwelche SAP-systeme) schon gemacht. Ja, die liefen
hinterher immer noch völlig problemlos.

Diedrich
--
pgp-Key (RSA) 1024/09B8C0BD
fingerprint = 2C 49 FF B2 C4 66 2D 93 6F A1 FF 10 16 59 96 F3
HTML-Mail wird ungeleſen entſorgt.

[Helmut Hullen]

Hallo, Diedrich,

Du meintest am 18.12.15:

>>> Du hast also noch nie z.B. resize2fs benutzen müssen?

>> Nein. Ich pflege erst mal die Dateien zu sichern, dann die Partition
>> zu ändern, darauf ein Dateiystem anzulegen (kann gleich sein, aber
>> auch anders) und dann die Dateien aus dem Backup draufzuspielen.

>> Geht schnell und sicher.

> Das meinst du jetzt aber hoffentlich nicht ernst!

Doch - natürlich. Das Verfahren ist übersichtlich, sicher und schnell.

> Filesysteme wie ext[234]fs und xfs sind problemlos online
> vergrößerbar. Schon seit vielen Jahren. Du vergrößerst die Partition
> (oder das LVM- Volume; dieser Fall ist noch viel einfacher als das
> Partitionen- Vergrößern), und dann das Filesystem.

Diese zwei Schritte macht mein Verfahren auch, und "gparted" macht sie
sauber passend abgestimmt - da brauche ich weder "fdisk" noch
"resize2fs".

Ach ja - ich musste des öfteren auch vfat- oder NTFS-Partitionen ändern
...

> Nein, das ist in
> keiner Weise mehr experimentell. Ja, das habe ich auch mit
> professionell eingesetzten Systemen (irgendwelche SAP-systeme) schon
> gemacht. Ja, die liefen hinterher immer noch völlig problemlos.

Wie ich schon mal erwähnte: meine Experimente mit "gparted" an
Partitionen von etwa 50 GByte und einigen Dateisystemen zeigten, dass
dieser Weg deutlich länger dauerte.

Insbesondere erspare ich mir den Umstandswauwau, die Grössen sowohl für
"fdisk" als auch für "resize2fs" aneinander anzupassen.

LVM ist was anderes - das hat(te) der Erstfrager nicht eingerichtet.

Und wenn der Rechner nicht lange vom LAN abgetrennt sein soll: aus dem
Backup auf eine weitere Platte spielen (am gleichen oder einem anderen
Rechner), und dann die Platten vertauschen (da gibt es einige
Varianten).

----------------

Du scheinst eine Beschreibung zu liefern, die für einen Server im
Firmennetz zugeschnitten ist. Der Erstfrager schien Hilfe für seinen
(einzigen?) Rechner zuhause zu suchen - da gibt es etliche Unterschiede.
Auch was die Linux-Kenntnisse betrifft.

[Diedrich Ehlerding]

Helmut Hullen meinte:

> Ach ja - ich musste des öfteren auch vfat- oder NTFS-Partitionen ändern

NTFS-Partitionen wirft man einem Wiindows vor. Das kann NTFS resizen. Auch
schon lange, mindestens seit Windows 2003. Wie gesagt, ein uralter Hut.

> Insbesondere erspare ich mir den Umstandswauwau, die Grössen sowohl für
> "fdisk" als auch für "resize2fs" aneinander anzupassen.

Ah ja. Ich meinerseits delegiere diese schwierige Berechnung ggf an ein
dafür geeignetes Tool:

| $ man resize2fs
|
| NAME
| resize2fs - ext2/ext3/ext4 file system resizer
|
| SYNOPSIS
| resize2fs [ -fFpPM ] [ -d debug-flags ] [ -S RAID-stride ]
| device [size ]
|
| [...]
|
| If _size_ parameter is not specified, it will default to the
| size of the partition.

[Diedrich Ehlerding]

Helmut Hullen meinte:

> Ach ja - ich musste des öfteren auch vfat- oder NTFS-Partitionen ändern

NTFS-Partitionen wirft man einem Windows vor. Das kann NTFS resizen. Auch

schon lange, mindestens seit Windows 2003. Wie gesagt, ein uralter Hut.

> Wie ich schon mal erwähnte: meine Experimente mit "gparted" an
> Partitionen von etwa 50 GByte und einigen Dateisystemen zeigten, dass
> dieser Weg deutlich länger dauerte.

Hint: resize2fs und xfsadmin vergrößern das Filesystem _online_. Du kannst
weiterarbeiten (bzw. das betroffene SAP-System konnte in meinen Fällen
jeweils weiterlaufen) und brauchte keine Downtime. Und eine Unterbrechung
der Länge 0 ist immer kürzer als Backup + fullrestore von einem noch so
schnellen Sicherungsmedium.

> Insbesondere erspare ich mir den Umstandswauwau, die Grössen sowohl für
> "fdisk" als auch für "resize2fs" aneinander anzupassen.

Ah ja. Ich meinerseits delegiere diese schwierige Berechnung ggf an ein
dafür geeignetes Tool:

| $ man resize2fs
|
| NAME
| resize2fs - ext2/ext3/ext4 file system resizer
|
| SYNOPSIS
| resize2fs [ -fFpPM ] [ -d debug-flags ] [ -S RAID-stride ]
| device [size ]
|
| [...]
|
| If _size_ parameter is not specified, it will default to the
| size of the partition.

[Helmut Hullen]

Hallo, Diedrich,

Du meintest am 18.12.15:

>> Wie ich schon mal erwähnte: meine Experimente mit "gparted" an
>> Partitionen von etwa 50 GByte und einigen Dateisystemen zeigten,
>> dass dieser Weg deutlich länger dauerte.

> Hint: resize2fs und xfsadmin vergrößern das Filesystem _online_. Du
> kannst weiterarbeiten (bzw. das betroffene SAP-System konnte in
> meinen Fällen jeweils weiterlaufen) und brauchte keine Downtime. Und
> eine Unterbrechung der Länge 0 ist immer kürzer als Backup +
> fullrestore von einem noch so schnellen Sicherungsmedium.

Mag bei einzelnen Rechnern in einem Firmennetz wichtig sein. Bei Otto
Endanwenders (einzigem) Rechner zuhause ist das vielleicht kein
wichtiges Kriterium.

Bei meinen bisherigen Änderungsaktionen (in den letzten 20 Jahren) war
nie wichtig, dass der Rechner während der Änderung online war -
Sicherheit war wichtiger.

[Juergen P. Meier]

begin 1 followup to Klaus Gawol <Klaus...@gmx.de>:

Dann ist sda2 nicht am Ende der platte.

Wie sieht der output von fdisk -l /dev/sda aus?
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

[Diedrich Ehlerding]

Helmut Hullen meinte:

>> Hint: resize2fs und xfsadmin vergrößern das Filesystem _online_. Du
>> kannst weiterarbeiten (bzw. das betroffene SAP-System konnte in
>> meinen Fällen jeweils weiterlaufen) und brauchte keine Downtime. Und
>> eine Unterbrechung der Länge 0 ist immer kürzer als Backup +
>> fullrestore von einem noch so schnellen Sicherungsmedium.
>
> Mag bei einzelnen Rechnern in einem Firmennetz wichtig sein. Bei Otto
> Endanwenders (einzigem) Rechner zuhause ist das vielleicht kein
> wichtiges Kriterium.

Du warst doch derjenige, der behauptet hat, seine Methode "backup+restore"
sei schneller als resize2fs. Das Kriterium "Länge der Downtime" stammt
doch von dir.

Du magst gerne so vorgehen wie du beschreibst; Vorteil ist natürlich
immer: du erzeugst mal wieder eine aktuelle Sicherung. Insofern mag es
sicherer sein. Aber /schneller/ ist es gewiss nicht.

[Helmut Hullen]

Hallo, Diedrich,

Du meintest am 19.12.15:

> Du magst gerne so vorgehen wie du beschreibst; Vorteil ist natürlich
> immer: du erzeugst mal wieder eine aktuelle Sicherung.

Nein - bei den von mir betreuten Systemen wird sowieso täglich
gesichert.

> Aber /schneller/ ist es gewiss nicht.

Wie schon erwähnt - bei meinen Versuchen hat das Ändern der
Partitionsgrösse gefühlt mehr als doppelt so lange gedauert wie der Weg
über Backup, fdisk, mkfs und Restore. Hast Du andere Erfahrungen?

Noch mal: LVM ist ein Sonderfall, der insbesondere bei SoHo-Systemen
sehr selten sein dürfte.
Und wie das bei Virtuellen Systemen ist, könnte noch wieder anders sein
- ich habe meine Erfahrungen mit "echten" Systemen beschrieben.

[Marc Haber]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>Du magst gerne so vorgehen wie du beschreibst; Vorteil ist natürlich
>immer: du erzeugst mal wieder eine aktuelle Sicherung. Insofern mag es
>sicherer sein. Aber /schneller/ ist es gewiss nicht.

Bevor man seinem Dateisystem mit einer so radikalen Methodik zu Leibe
rückt, ist ein aktuelles Backup eh Pflicht.

[Diedrich Ehlerding]

Helmut Hullen meinte:

> Wie schon erwähnt - bei meinen Versuchen hat das Ändern der
> Partitionsgrösse gefühlt mehr als doppelt so lange gedauert wie der Weg
> über Backup, fdisk, mkfs und Restore. Hast Du andere Erfahrungen?
>
> Noch mal: LVM ist ein Sonderfall, der insbesondere bei SoHo-Systemen
> sehr selten sein dürfte.

Worin liegt hinsichtlich resize2fs der wesentliche UNterschied zwischen
einem vergrößerten LVM-Volume und einer vergrößerten Partition?

[Marc Haber]

Hel...@Hullen.de (Helmut Hullen) wrote:
>Noch mal: LVM ist ein Sonderfall, der insbesondere bei SoHo-Systemen
>sehr selten sein dürfte.

Weil die Mainstream-Distributionen dies allesamt als leicht
erreichbare Option in ihren Installern anbieten?

Nicht jede Distribution ist so vorsintflutlich wie das von Dir
üblicherweise verwendete System.

>Und wie das bei Virtuellen Systemen ist, könnte noch wieder anders sein
>- ich habe meine Erfahrungen mit "echten" Systemen beschrieben.

Und Du wirfst _mir_ Abschweifen vor? Schau mal ins Subject.

Grüße
Marc, der diesen Thread wegen Diedrichs Reply angezeigt bekam

[Dietz Pröpper]

Diedrich Ehlerding wrote:

> Helmut Hullen meinte:
>
>> Wie schon erwähnt - bei meinen Versuchen hat das Ändern der
>> Partitionsgrösse gefühlt mehr als doppelt so lange gedauert wie der Weg
>> über Backup, fdisk, mkfs und Restore. Hast Du andere Erfahrungen?
>>
>> Noch mal: LVM ist ein Sonderfall, der insbesondere bei SoHo-Systemen
>> sehr selten sein dürfte.
>
> Worin liegt hinsichtlich resize2fs der wesentliche UNterschied zwischen
> einem vergrößerten LVM-Volume und einer vergrößerten Partition?

Hmm. In dem resize2fs übergebenen Device-Namen? <d,r&h>

--
"Requirements are 100% complete!" Consultant Three-of-Four repeated. After
an uncomfortable pause, he continued, "But they are not yet documented."
(http://thedailywtf.com/Articles/Invasion-of-the-Consultants.aspx)

[Helmut Hullen]

Hallo, Diedrich,

Du meintest am 19.12.15:

>> Noch mal: LVM ist ein Sonderfall, der insbesondere bei SoHo-Systemen
>> sehr selten sein dürfte.

> Worin liegt hinsichtlich resize2fs der wesentliche UNterschied
> zwischen einem vergrößerten LVM-Volume und einer vergrößerten
> Partition?

Da muss nicht vorweg die jeweilige Partition geändert werden.

Einige weitere Informationen:

https://de.wikipedia.org/wiki/Logical_Volume_Manager


In
http://www.admin-magazin.de/Das-Heft/2012/01/Einfuehrung-in-LVM

ist nachzulesen, welche Teilschritte bei diesem Dateisystem zu machen
sind - siehjt nicht sonderlich komfortabel aus.

[Helmut Hullen]

Hallo, Marc,

Du meintest am 19.12.15:

>> Noch mal: LVM ist ein Sonderfall, der insbesondere bei SoHo-Systemen
>> sehr selten sein dürfte.

> Weil die Mainstream-Distributionen dies allesamt als leicht
> erreichbare Option in ihren Installern anbieten?

Das Angebot ist da - das weiss ich. Die Nachfrage scheint im SoHo-
Bereich klein zu sein.

[Diedrich Ehlerding]

Helmut Hullen meinte:

>> Worin liegt hinsichtlich resize2fs der wesentliche UNterschied
>> zwischen einem vergrößerten LVM-Volume und einer vergrößerten
>> Partition?
>
> Da muss nicht vorweg die jeweilige Partition geändert werden.

Der aufwand zum Partition-Vergrößern ist nicht übergroß, wenn denn
dahinter Platz ist. Aber der Enisatzfall, über den wir diskutieren, war
doch genau der, dass die Platte einer VM vegrößert wird oder dass eine
Platte auf eine andere, größere kopiert wird.

>
> Einige weitere Informationen:
>
> https://de.wikipedia.org/wiki/Logical_Volume_Manager

Danke, ich kenne den LVM einigermaßen,.

>
>
> In
> http://www.admin-magazin.de/Das-Heft/2012/01/Einfuehrung-in-LVM
>
> ist nachzulesen, welche Teilschritte bei diesem Dateisystem zu machen
> sind - siehjt nicht sonderlich komfortabel aus.

Ggf. pvcreate und vgextend; dann lvextend. Dann resize2fs oder xfsadmin .
Ja, man mus natürlich wissen, was die jeweils tun. aber es bleibt bei max
4 Kommandos (wenn eine weitere Platte hinzukommt). Dauert ungefähr 5
Minuten - ebensolange wie das Anstöpseln und Mounten deS Backupmediums in
deinem Szenario.

[Ralph Angenendt]

Well, Helmut Hullen <Hel...@Hullen.de> wrote:

> Hallo, Marc,

>> Weil die Mainstream-Distributionen dies allesamt als leicht
>> erreichbare Option in ihren Installern anbieten?
>
> Das Angebot ist da - das weiss ich. Die Nachfrage scheint im SoHo-
> Bereich klein zu sein.

Das weißt du woher?

[Helmut Springer]

Marc Haber <mh+usene...@zugschl.us> wrote:
>>Noch mal: LVM ist ein Sonderfall, der insbesondere bei
>>SoHo-Systemen sehr selten sein dürfte.
>
> Weil die Mainstream-Distributionen dies allesamt als leicht
> erreichbare Option in ihren Installern anbieten?

Ist mW bei einigen Standard, wenn man die Platte verschluesseln
laesst.

--
Best Regards
helmut springer panta rhei

[Helmut Hullen]

Hallo, Ralph,

Du meintest am 20.12.15:

>>> Weil die Mainstream-Distributionen dies allesamt als leicht
>>> erreichbare Option in ihren Installern anbieten?

>> Das Angebot ist da - das weiss ich. Die Nachfrage scheint im SoHo-
>> Bereich klein zu sein.

> Das weißt du woher?

Dass das Angebot da ist? Nachschauen in den Repositorien.

Nachfrage: Du kennst die Bedeutung des Tuworts "scheinen"? Insbesondere
im Vergleich zu "wissen"?

[Christoph 'Mehdorn' Weber]

Hallo!

* Helmut Hullen <Hel...@Hullen.de>:

>> Es kommt öfter vor, daß da nur ein Dateisystem drauf ist --
>> gelegentlich sind es auch zwei, wenn der Bootloader das so
>> braucht(e).
> Auf nur 1 Partition? Oder pro Partition nur 1 Dateisystem?

So wahnsinnig, mehrere Dateisysteme auf eine (nicht-erweiterte)
Partition zu packen, bin ich nicht. Ist auch viel zu pfriemelig,
das jedesmal per Offset-Angabe einzubinden.

Nein, meist haben die Systeme lediglich eine Partition mit
Dateisystem für "/", mehr nicht. (Separates /var oder /var/log
lohnt bei vielen Systemen nicht, und meist geh es eher Richtung
Server, sodaß ein Extra-/home ebenfalls unnötig wäre.)

In manchen Fälle braucht man eben noch eine zweite Partition, wo
nur der Bootloader rumlungert, sei es nun U-Boot oder neuerdings
auch mal UEFI. Aber die liegt typischerweise am Anfang und es
lohnt eh nicht, das kleine Ding extra zu schrumpfen, wenn man die
Images eindampft.

> Mit dem Sonderfall, dass (z.B. nach Anwendung von resize2fs")
> das Dateiosystem nicht die gesamte Partition ausfüllt, sondern
> irgendwo ein undefinierter ("free") Rest bleibt.

Daher benutze ich es meist zweimal. Da ich zu faul bin (und
Rechenfehler noch dazu fatal sein könnten), schrumpfe ich das
Dateisystem erst sehr großzügig (meist auf das mögliche Minimum),
danach die Partition, lasse sie aber etwas größer, und lasse
resize2fs das Dateisystem dann wieder auf die neue Partitionsgröße
aufblasen.

Christoph

--
Fuer Schulen und das Gesundheitssystem ist die NASA auch nicht zustaendig. --
Ja, aber deren Budget faellt auch nicht einfach so vom Himmel. --
Wenn man an Challenger, Columbia & Co denkt, kann man das so net sagn.
(Peter J. Holzer, Szomraky Stefan, Andreas Granig)

[Christian Garbs]

Mahlzeit!

Klaus Gawol <Klaus...@gmx.de> wrote:

> Hallo Martin, du hast sicherlich recht mit deiner Bemerkung und
> Erklärung.
>
> Doch wenn man von Windows her kommt, dann versteht man unter
> 'Dateisystem' ohne langes Überlegen so etwas die NTSF oder Ext3.

Genau: das sind Dateisysteme.

> Und so
> etwas kann man nicht 'vergrößern'.

Doch :-) Und nicht nur vergrößern, sondern auch verkleinern.
Dafür gibt es die Befehle ntfsresize(8) und resize2fs(8).

> Genauso würde ich '/dev/sda1' sofort als Laufwerk oder Partition
> verstehen, keinesfalls aber als Dateisystem.

Auch die Definition ist korrekt.


Der Unterschied in der Denke zwischen Windows und Linux dürfte
lediglich der sein, dass man unter Linux (und anderen Unixen) die
Partitionsgröße unabhängig vom Dateisystem ändern kann/muss:

Vergrößern:

1. Partition (oder allgemein das "Block device", z.B. das Logical
Volume, das Raid-Volume oder eine Image-Datei irgendwo auf der
Platte) vergrößern
2. Dateisystemgröße auf die Größe der Partition erhöhen (die Tools
suchen sich meist automatisch die maximal mögliche Größe, das
passt dann direkt)


Verkleinern:

1. Dateisystem verkleinern (sinnvollerweise auf den minimalen Umfang,
so dass es danach 100% voll ist)
2. Partition verkleinern (OBACHT: nicht kleiner machen, als den noch
vom Dateisystem belegten Platz, sonst ist's kaputt)
3. Dateisystem nochmal wachsen lassen auf die Partitionsgröße

So mache ich das jedenfalls immer, das spart mir irgendwelches
rumgerechne. Wer gut mit dem Taschenrechner ist, kommt auch ohne
Schritt 3 aus, wenn er in Schritt 1 eine passende neue Größe angibt.


Gruß
Christian
--
....Christian.Garbs.....................................http://www.cgarbs.de
Tomorrow's computers some time next month.
-- DEC

[Ralph Angenendt]

Well, Helmut Hullen <Hel...@Hullen.de> wrote:

> Du meintest am 20.12.15:
>>>> Weil die Mainstream-Distributionen dies allesamt als leicht
>>>> erreichbare Option in ihren Installern anbieten?
>
>>> Das Angebot ist da - das weiss ich. Die Nachfrage scheint im SoHo-
>>> Bereich klein zu sein.
>
>> Das weißt du woher?
>
> Dass das Angebot da ist? Nachschauen in den Repositorien.

Dass die Nachfrage klein ist. Was denn sonst.

> Nachfrage: Du kennst die Bedeutung des Tuworts "scheinen"? Insbesondere
> im Vergleich zu "wissen"?

Ja. Du weißt es nicht, streust es aber dennoch mal ein, weil du auch mal
was gesagt haben wolltest.

Hilft niemandem, trägt nix zur Frage bei, aber es gibt immerhin mal
wieder Threaddrift.

[Helmut Springer]

Ralph Angenendt <ihr....@strg-alt-entf.org> wrote:
> Hilft niemandem, trägt nix zur Frage bei, aber es gibt immerhin
> mal wieder Threaddrift.

Da er eine eindeutige MSID erzeugt, kann man subthreads problemlos
runterscoren...

[Helmut Hullen]

Hallo, Ralph,

Du meintest am 20.12.15:

>> Nachfrage: Du kennst die Bedeutung des Tuworts "scheinen"?
>> Insbesondere im Vergleich zu "wissen"?

> Ja. Du weißt es nicht, streust es aber dennoch mal ein, weil du auch
> mal was gesagt haben wolltest.

Nein - weil ich nun mal vermute, dass XFS im SoHo-Bereich nur schwach
vertreten ist.

Möchtest Du denn auch in diesem Thread mal wieder zur Person
diskutieren?

[Ralph Angenendt]

Well, Helmut Hullen <Hel...@Hullen.de> wrote:

> Hallo, Ralph,
> Du meintest am 20.12.15:
>>> Nachfrage: Du kennst die Bedeutung des Tuworts "scheinen"?
>>> Insbesondere im Vergleich zu "wissen"?
>
>> Ja. Du weißt es nicht, streust es aber dennoch mal ein, weil du auch
>> mal was gesagt haben wolltest.
>
> Nein - weil ich nun mal vermute, dass XFS im SoHo-Bereich nur schwach
> vertreten ist.

LVM. Nicht XFS. Nicht die Threads verwechseln.

> Möchtest Du denn auch in diesem Thread mal wieder zur Person
> diskutieren?

Nein, das überlasse ich dir. Über deinen Diskussionsstil, über den
diskutier ich.

[Juergen P. Meier]

Hullen <Hel...@Hullen.de>:

> Wie schon erwähnt - bei meinen Versuchen hat das Ändern der
> Partitionsgrösse gefühlt mehr als doppelt so lange gedauert wie der Weg
> über Backup, fdisk, mkfs und Restore. Hast Du andere Erfahrungen?

Ja. Ein resizefs mit e2{3}fs von 200GByte auf 300GByte mit 180GByte
belegt dauert keine 5 Minuten. SAS Platte (HW RAID-1)

Backup dauert laenger. Restore auch.

> Noch mal: LVM ist ein Sonderfall, der insbesondere bei SoHo-Systemen
> sehr selten sein dürfte.

Bullshit.

LVM ist der Standard fuer flexible Systeme und JEDEM ohne
Einschraenkung zu empfehlen. Insbesondere auch Soho wo man durchaus
mal oefters bastelt, so wie du in diesem Thread. Mit LVM haettest du
diese Probleme garnicht gehabt.

[Frank Streitz]

Am 23.12.2015 um 09:00 schrieb Juergen P. Meier:
>> Noch mal: LVM ist ein Sonderfall, der insbesondere bei SoHo-Systemen
>> > sehr selten sein dürfte.
> Bullshit.
>
> LVM ist der Standard fuer flexible Systeme und JEDEM ohne
> Einschraenkung zu empfehlen. Insbesondere auch Soho wo man durchaus
> mal oefters bastelt, so wie du in diesem Thread. Mit LVM haettest du
> diese Probleme garnicht gehabt.

Wieviele ONUs kennst Du denn, die LVM benutzen?

[Jan Heitkötter]

Am 23.12.2015 um 09:00 schrieb Juergen P. Meier:

>> Noch mal: LVM ist ein Sonderfall, der insbesondere bei SoHo-Systemen
>> sehr selten sein dürfte.
>
> Bullshit.

Zustimmung. Zumindest die mir bekannten "großen" Distributionen (Debian
und Derivate, Fedora, OpenSUSE) richten LVM ein, wenn man bei der
Installation "System verschlüsseln" auswählt. Und bei den Installern
wird LVM als Option unabhängig von der Verschlüsselung mehr oder weniger
prominent angeboten.

Jan

[Marc Haber]

"Juergen P. Meier" <nospa...@jors.net> wrote:
>LVM ist der Standard fuer flexible Systeme und JEDEM ohne
>Einschraenkung zu empfehlen. Insbesondere auch Soho wo man durchaus
>mal oefters bastelt, so wie du in diesem Thread. Mit LVM haettest du
>diese Probleme garnicht gehabt.

Helmut hat in diesem Thread keine Probleme; der OP war jemand anders.
Helmut hat sich nur eingemischt und zuerst behauptet, man könne
Dateisysteme grundsätzlich nicht resizen, dann seine Aussage implizit
auf komplett auspartitionierte Hardware-Platten eingeschränkt und
damit für diesen Thread irrelevant gemacht weil der OP eine Vm mit
Image-File verwendet, und diskutiert seitdem darüber, ob man im
Mainstream LVM verwendet oder nicht.

Die Signal-zu-HullenNoise-Ratio beträgt geschätzt 1:10.

Grüße
Marc

[Juergen P. Meier]

Frank Streitz <fskei...@web.de>:

Von den SoHo-Systemen, die ich kenne laufen 75% mit LVM.

Das ist immerhin eine ueberwiegende Mehrheit.

[Helmut Hullen]

Hallo, Juergen,

Du meintest am 23.12.15:

>>> LVM ist der Standard fuer flexible Systeme und JEDEM ohne
>>> Einschraenkung zu empfehlen. Insbesondere auch Soho wo man durchaus
>>> mal oefters bastelt, so wie du in diesem Thread. Mit LVM haettest
>>> du diese Probleme garnicht gehabt.
>>
>> Wieviele ONUs kennst Du denn, die LVM benutzen?

> Von den SoHo-Systemen, die ich kenne laufen 75% mit LVM.

> Das ist immerhin eine ueberwiegende Mehrheit.

Von den -zig SoHo-Systemen, die ich kenne, läuft keines mit LVM ...

[Helmut Hullen]

Hallo, Marc,

Du meintest am 23.12.15:

> Helmut hat in diesem Thread keine Probleme;
>

Dein Hullen-Filter taugt nichts, weder der im Rechner noch der im Kopf.

[Frank Streitz]

Am 23.12.2015 um 10:14 schrieb Helmut Hullen:
>>> Wieviele ONUs kennst Du denn, die LVM benutzen?
>> > Von den SoHo-Systemen, die ich kenne laufen 75% mit LVM.
>> > Das ist immerhin eine ueberwiegende Mehrheit.
> Von den -zig SoHo-Systemen, die ich kenne, läuft keines mit LVM ...

Ich wüßte jetzt auch bei den ONUs, die ich kenne, nicht ein System, das
mit LVM läuft. Jedenfalls nicht, wenn sie es selbst eingerichtet haben.



Gruß, Frank

[gregor herrmann]

On Wed, 23 Dec 2015 09:13:47 +0100, Frank Streitz wrote:

> Wieviele ONUs kennst Du denn, die LVM benutzen?

einige. die die beim debian-installer gesagt haben "verschluessel das
mal"; mit LUKS kommt LVM mit.

gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: Page&Plant: Upon A Golden Horse

[Alexander Goetzenstein]

Hallo,

Am 24.12.2015 um 02:37 schrieb gregor herrmann:
> mit LUKS kommt LVM mit.

ist das bei Ubuntu zwingend, und warum?


--
Gruß
Alex

[Juergen P. Meier]

Frank Streitz <fskei...@web.de>:

Neuere Distributionen verwenden per default LVM. Damit hat automatisch
jeder ONU der so eine Distribution nutzt auch automatisch LVM zuhause.

[Jan Heitkötter]

Am 24.12.2015 um 09:34 schrieb Alexander Goetzenstein:
>> mit LUKS kommt LVM mit.
>
> ist das bei Ubuntu zwingend,

Zumindest ist es das, was dir der Installer unter Debian und Ubuntu
einrichtet.


> und warum?

Der Grund mag darin liegen, dass man meist nicht nur /, sondern auch
swap verschlüsseln möchte und ggf. weitere separate Dateisysteme wie
/home. Und das geht ziemlich einfach per verschlüsseltem LVM, weil da
nur das Physical Volume verschlüsselt werden muss und man sich innerhalb
der Volume Group keine Gedanken um die Verschlüsselung der einzelnen
Logical Volumes machen muss.

Natürlich kann man manuell andere Wege beschreiten, bspw. nur /
verschlüsseln und die weiteren Passphrases in der /etc/crypttab ablegen.

Frohes Fest

Jan

[Marc Haber]

Jan Heitkötter <usenet...@heitkoetter.net> wrote:
>Natürlich kann man manuell andere Wege beschreiten, bspw. nur /
>verschlüsseln und die weiteren Passphrases in der /etc/crypttab ablegen.

systemd macht das signifikant schwerer, weil der Debianismus
keyscript= nicht unterstützt wird.

Der systemd-Upstream sagt "nicht unsere Baustelle, das ist ein
Debianismus". Die systemd-Maintainer in Debian sagen "Schade, Schade,
Schade". Und der Anwender schaut in die Röhre.

[Helmut Springer]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Der systemd-Upstream sagt "nicht unsere Baustelle, das ist ein
> Debianismus". Die systemd-Maintainer in Debian sagen "Schade,
> Schade, Schade". Und der Anwender schaut in die Röhre.

Nachdem grub LUKS unterstuetzt sollte man mE ohnehin dort aufsetzen
und das unverschluesselte /boot loswerden. Dann waere auch boot von
einem Medium (stick, SD card, whatever) einfacher zu integrieren...

[Marc Haber]

Warum wäre das dann einfacher? Trojanisierbar sind beide Wege (tauscht
man halt den grub aus oder integriert ein trojan.mod) sowieso.

Grüße
Marc, der seit Jahr und Tag von einem Stick bootet

[Helmut Springer]

Marc Haber <mh+usene...@zugschl.us> wrote:
>>Nachdem grub LUKS unterstuetzt sollte man mE ohnehin dort
>>aufsetzen und das unverschluesselte /boot loswerden. Dann waere
>>auch boot von einem Medium (stick, SD card, whatever) einfacher zu
>>integrieren...
>
> Warum wäre das dann einfacher? Trojanisierbar sind beide Wege
> (tauscht man halt den grub

Dazu muesstest Du Zugriff auf das verwendete Bootmedium haben, und
davon kann es mehr als eines geben.

> aus oder integriert ein trojan.mod) sowieso.

Aenderungen auf der verschluesselten Platte setzen ein Brechen der
Verschluesselung voraus.

Bei Zugriff eines Angreifers auf das laufende System und die
unverschluesselte Daten ist der boot process offensichtlich nicht
mehr Dein Hauptproblem...

[Marc Haber]

Helmut Springer <delta+...@lug-s.org> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>>>Nachdem grub LUKS unterstuetzt sollte man mE ohnehin dort
>>>aufsetzen und das unverschluesselte /boot loswerden. Dann waere
>>>auch boot von einem Medium (stick, SD card, whatever) einfacher zu
>>>integrieren...
>>
>> Warum wäre das dann einfacher? Trojanisierbar sind beide Wege
>> (tauscht man halt den grub
>
>Dazu muesstest Du Zugriff auf das verwendete Bootmedium haben, und
>davon kann es mehr als eines geben.

Es reicht ja wenn einmal von einem trojanisierten Bootmedium gebootet
wurde.

>
>> aus oder integriert ein trojan.mod) sowieso.
>
>Aenderungen auf der verschluesselten Platte setzen ein Brechen der
>Verschluesselung voraus.

Du trojanisierst das Bootmedium und loggest den Key in dem Moment mit,
in dem die Dateisysteme aufgeschlossen werden. Voila.

Grüße
Marc

[Helmut Springer]

Marc Haber <mh+usene...@zugschl.us> wrote:
>>> Warum wäre das dann einfacher? Trojanisierbar sind beide Wege
>>> (tauscht man halt den grub
>>
>>Dazu muesstest Du Zugriff auf das verwendete Bootmedium haben, und
>>davon kann es mehr als eines geben.
>
> Es reicht ja wenn einmal von einem trojanisierten Bootmedium
> gebootet wurde.

Es reicht idR immer ein erfolgreicher Angriff, weswegen man den
eben erschwert.

>>Aenderungen auf der verschluesselten Platte setzen ein Brechen der
>>Verschluesselung voraus.
>
> Du trojanisierst das Bootmedium und loggest den Key in dem Moment
> mit, in dem die Dateisysteme aufgeschlossen werden. Voila.

Marc, Du musst mir wirklich nicht das Offensichtliche erklaeren,
dass ich nichtmal angezweifelt habe.