[E1] Festplattenplatz geht zur Neige ... immer mehr libs?

[Helmut Backhaus]

Hallo zusammen,
ich habe oben genanntes Problem, hier am Beispiel meines Nextcloud Servers.

Ich habe eigentlich überall auf meinen E1 Servern ein root von ~5G. Das
wird aber seit neustem überall knapp. Wie es aussieht vermehren sich die
"libs" sprunghaft. Oder täuscht mein Eindruck?

e1nextcloud # df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 795M 1.5M 793M 1% /run
/dev/xvda3 4.3G 3.3G 849M 80% /
/dev/xvdb1 4.8G 1.8G 2.9G 38% /data
/dev/xvda1 92M 26M 60M 31% /boot
tmpfs 398M 0 398M 0% /run/user/0

e1nextcloud # du -h --max-depth=1 /usr/lib
16K /usr/lib/bfd-plugins
16K /usr/lib/rpm
8.0K /usr/lib/sysctl.d
4.0K /usr/lib/sasl3
4.0K /usr/lib/modules-load.d
4.0M /usr/lib/ImageMagick-7.1.0
64K /usr/lib/tmpfiles.d
12K /usr/lib/modprobe.d
4.0K /usr/lib/isdn
8.0K /usr/lib/gio
16K /usr/lib/tc
812K /usr/lib/openldap
30M /usr/lib/apache2
3.8M /usr/lib/ImageMagick-7.0.10
48K /usr/lib/sysusers.d
107M /usr/lib/perl5
160K /usr/lib/gawk
44K /usr/lib/krb5
508M /usr/lib/gcc
76K /usr/lib/gettext
263M /usr/lib/mysql
6.7M /usr/lib/gconv
264K /usr/lib/texinfo
4.0K /usr/lib/zoneinfo
56K /usr/lib/cui-addons
15M /usr/lib/locale
8.0M /usr/lib/udev
2.1M /usr/lib/ast
92K /usr/lib/sa
8.0K /usr/lib/ghostscript
812K /usr/lib/girepository-1.0
1.3M /usr/lib/security
84K /usr/lib/geoip
116K /usr/lib/apr-util-1
76K /usr/lib/pkgconfig
4.4M /usr/lib/ImageMagick-6.9.10
56K /usr/lib/engines-1.1
17M /usr/lib/ldscripts
4.0K /usr/lib/environment.d
8.1M /usr/lib/systemd
4.3M /usr/lib/php8
4.0K /usr/lib/motd.d
32K /usr/lib/kernel
38M /usr/lib/python3.8
12K /usr/lib/coreutils
2.5M /usr/lib/dracut
116K /usr/lib/engines-1.0
276K /usr/lib/gdk-pixbuf-2.0
6.1M /usr/lib/guile
4.0K /usr/lib/binfmt.d
1.3G /usr/lib


Hieraus ergibt sich, das es auf root jetzt sehr *eng* wird.
Jetzt stelle ich mir die Frage ob ich den ganzen Bereich /usr auf eine
Separate Festplatte auslagern soll?

Stellt das ein Problem da?

Es handelt sich hier im Beispiel um eine VM unter XEN.

Dies hier ist nur ein Beispiel, zugegeben, dass extremste ;)


Gruß,
Helmut

[Fridrich B.]

Wäre ich Programmierer würde ich sagen ja, das kann passieren. Denn neue
Funktionen gehen oft nur über neue libs.

Manchmal macht sich ein Paketupdate dann mit 3-5 anderen neuen Paketen
bemerkbar, anstatt wie früher nur sich selbst als update.

Meinen eis1 habe ich bereits vor einiger Zeit auf diese Werte erweiert.

MOUNTPOINT BELEGT FREI
/dev 0 % of 1.5G 1.5G
/dev/shm 1 % of 1.5G 1.5G
/run 1 % of 1.5G 1.5G
/ 55 % of 4.3G 1.9G


Seither ist Ruhe.
/boot putze ich dann un wann wenn der neue kernel sauber läuft.

Fridrich.

[Helmut Backhaus]

Hallo Fridrich,

Am 04.04.23 um 11:44 schrieb Fridrich B.:

> Am 03.04.2023 um 20:52 schrieb Helmut Backhaus:
>
>>
>> e1nextcloud # df -h
>> Filesystem      Size  Used Avail Use% Mounted on
>> devtmpfs        4.0M     0  4.0M   0% /dev
>> tmpfs           2.0G     0  2.0G   0% /dev/shm
>> tmpfs           795M  1.5M  793M   1% /run
>> /dev/xvda3      4.3G  3.3G  849M  80% /
>> /dev/xvdb1      4.8G  1.8G  2.9G  38% /data
>> /dev/xvda1       92M   26M   60M  31% /boot
>> tmpfs           398M     0  398M   0% /run/user/0
>>
>
>

> Wäre ich Programmierer würde ich sagen ja, das kann passieren. Denn neue
> Funktionen gehen oft nur über neue libs.
>

Da fallen mir noch ganz andere Sätze, die mit "Wäre ich Programmierer"
beginnen ein. Aber ich glaube, dass ist hier nicht das Thema! :-)

> Manchmal macht sich ein Paketupdate dann mit 3-5 anderen neuen Paketen
> bemerkbar, anstatt wie früher nur sich selbst als update.

Jo, dass ist klar ...
Aber mit solchen Ausmaßen?
Ich habe das komische Gefühl, dass die Entwickler das genau wissen (kann
mich aber auch täuschen). Den gestern bei dieser riesen "lib Session"
scheint einiges abgeräumt worden zu sein.

Was mich wirklich stört, ist das "jeder" seine nicht mehr erforderlichen
Brocken liegen lässt. Was, zum Glück, bei Eis nicht sooo oft vorkommt,
zumindest ist mir das noch nicht so gravierend aufgefallen.

Heute sieht es bei mir so aus:

e1nextcloud # df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm

tmpfs 795M 1.5M 794M 1% /run
/dev/xvda3 4.3G 3.1G 1.1G 74% /

/dev/xvda1 92M 26M 60M 31% /boot
/dev/xvdb1 4.8G 1.8G 2.9G 38% /data
tmpfs 398M 0 398M 0% /run/user/0


>

> Meinen eis1 habe ich bereits vor einiger Zeit auf diese Werte erweiert.
>
> MOUNTPOINT     BELEGT         FREI
> /dev         0 %     of  1.5G     1.5G
> /dev/shm     1 %     of  1.5G     1.5G
> /run         1 %     of  1.5G     1.5G
> /         55 % of  4.3G     1.9G
>

Diese Ausgabe sagt mir nicht wirklich etwas, so wie ich das sehe, sind
die ersten 3 Zeilen tmpfs. Die vierte Zeile ist anscheinend root und hat
die gleich Größe wie mein root, oder?

>
> Seither ist Ruhe.
> /boot putze ich dann un wann wenn der neue kernel sauber läuft.
>

Ok, das mache ich auch so.


Was aber bleibt, was ist besser?
Root größer machen oder /usr auf eine eigene Platte?
Machbar ist beides, usr auslagern ist das einfachere.
Zeitdruck ist ja jetzt erst mal raus. Aber ich bin sicher, irgendwann
stehe ich (oder wer anders) wieder vor dem gleichen Problem!


Vielleicht hier doch noch eine Spitze!
(Nicht böse sein, aber darüber bin ich gestern gestolpert)

Auszug aus der Eisfair Doku:
Hardwarevoraussetzungen

- CPU: Pentium 66
- Hauptspeicher: 32 MB, besser 64
- Massenspeicher: mindestens 120 MB Festplatte, später auch
CompactFlashTM
- Sonstiges: Netzwerkkarte zum Anschluss an LAN
- Optional: ISDN- oder weitere Netzwerkkarte zum Anschluss an xDSL


Das lasse ich einfach mal so unkommentiert wirken! ;)


Gruß,
Helmut

[Marcus Röckrath]

Hallo Helmut,

Helmut Backhaus wrote:

>> Manchmal macht sich ein Paketupdate dann mit 3-5 anderen neuen Paketen
>> bemerkbar, anstatt wie früher nur sich selbst als update.

Manchmal werden Pakete auch schlicht in Unterpakete aufgeteilt.

mpg123 war mal ein All-in-One-paket, inzwischen besteht es auch 9 Paketen,
wobei die Gesamtmenge aber die gleiche geblieben ist.

Das liegt auch daran, dass wir vermehrt auf SuSE-SRPMS zum Build greifen,
bei denen dann auch eine Reihe von Binärpaketen aus dem Build herauskommen.

Es ist dann auch sinnvoll, auf eis mit diesen Subpaketen zu arbeiten, weil
sich dann die Abhängigkeiten für den Build anderer Pakete leichter
handhaben lassen, weil sie im Idealfall zu den in den SuSE-spec-Files
gleich sind.

Aber auch viele Projekte werden schlicht größer, da haben wir doch gar
keinen Einfluss drauf, denn wir benutzen ja bestehende Sourcen.

> Ich habe das komische Gefühl, dass die Entwickler das genau wissen (kann
> mich aber auch täuschen). Den gestern bei dieser riesen "lib Session"
> scheint einiges abgeräumt worden zu sein.

Gerade läuft der Wechsel von der glibc 2.33 zu 2.37, womit eine Reihe von
Libs neu übersetz werden (müssen). Die räumen dann natürlich die
Vorversionen ab.

> Was mich wirklich stört, ist das "jeder" seine nicht mehr erforderlichen
> Brocken liegen lässt. Was, zum Glück, bei Eis nicht sooo oft vorkommt,
> zumindest ist mir das noch nicht so gravierend aufgefallen.

Pakete räumen bei uns in der Regel den alten Schrott ab, da bleibt selten
was liegen, was dann in der Regel ein Versehen ist. Mit der konsequenten
Nutzung der Fileliste eines Paketes zur Deinstallation ist
Flüchtichkeitsfehlern ddeutlich abgeholfen.

Wir sind jedoch immer dankbar für Hinweise, wenn etwas liegengeblieben ist.

> Vielleicht hier doch noch eine Spitze!
> (Nicht böse sein, aber darüber bin ich gestern gestolpert)
>
> Auszug aus der Eisfair Doku:
> Hardwarevoraussetzungen
>
> - CPU: Pentium 66
> - Hauptspeicher: 32 MB, besser 64
> - Massenspeicher: mindestens 120 MB Festplatte, später auch
> CompactFlashTM
> - Sonstiges: Netzwerkkarte zum Anschluss an LAN
> - Optional: ISDN- oder weitere Netzwerkkarte zum Anschluss an xDSL
>
> Das lasse ich einfach mal so unkommentiert wirken! ;)

Das war aber von fast 20 Jahren und man installierte das Grundsystem von
einer Diskette.

In der Zwischenzeit ist aber auch vieles an neuen Möglichkeiten
hinzugekommen. Ich meine, eisfair geht so auf die 5000 Pakete zu.

Die Zeit bleibt nicht stehen.

--
Gruß Marcus
[eisfair-Team]

[Helmut Backhaus]

Hallo Marcus,

Am 04.04.23 um 21:13 schrieb Marcus Röckrath:

> Hallo Helmut,
>
> Helmut Backhaus wrote:
>
>>> Manchmal macht sich ein Paketupdate dann mit 3-5 anderen neuen Paketen
>>> bemerkbar, anstatt wie früher nur sich selbst als update.
>
> Manchmal werden Pakete auch schlicht in Unterpakete aufgeteilt.
>
> mpg123 war mal ein All-in-One-paket, inzwischen besteht es auch 9 Paketen,
> wobei die Gesamtmenge aber die gleiche geblieben ist.
>
> Das liegt auch daran, dass wir vermehrt auf SuSE-SRPMS zum Build greifen,
> bei denen dann auch eine Reihe von Binärpaketen aus dem Build herauskommen.
>
> Es ist dann auch sinnvoll, auf eis mit diesen Subpaketen zu arbeiten, weil
> sich dann die Abhängigkeiten für den Build anderer Pakete leichter
> handhaben lassen, weil sie im Idealfall zu den in den SuSE-spec-Files
> gleich sind.
>
> Aber auch viele Projekte werden schlicht größer, da haben wir doch gar
> keinen Einfluss drauf, denn wir benutzen ja bestehende Sourcen.
>

Das ist mir wohl bewusst. Das ist dann eben so ...

>> Ich habe das komische Gefühl, dass die Entwickler das genau wissen (kann
>> mich aber auch täuschen). Den gestern bei dieser riesen "lib Session"
>> scheint einiges abgeräumt worden zu sein.
>
> Gerade läuft der Wechsel von der glibc 2.33 zu 2.37, womit eine Reihe von
> Libs neu übersetz werden (müssen). Die räumen dann natürlich die
> Vorversionen ab.
>

Ok, dann war das gestern der Fall und es ist das "Abräumen" noch nicht
fertig, oder?

>> Was mich wirklich stört, ist das "jeder" seine nicht mehr erforderlichen
>> Brocken liegen lässt. Was, zum Glück, bei Eis nicht sooo oft vorkommt,
>> zumindest ist mir das noch nicht so gravierend aufgefallen.
>
> Pakete räumen bei uns in der Regel den alten Schrott ab, da bleibt selten
> was liegen, was dann in der Regel ein Versehen ist. Mit der konsequenten
> Nutzung der Fileliste eines Paketes zur Deinstallation ist
> Flüchtichkeitsfehlern ddeutlich abgeholfen.
>
> Wir sind jedoch immer dankbar für Hinweise, wenn etwas liegengeblieben ist.
>

Das versuche ich auch immer zu machen!

>> Vielleicht hier doch noch eine Spitze!
>> (Nicht böse sein, aber darüber bin ich gestern gestolpert)
>>
>> Auszug aus der Eisfair Doku:
>> Hardwarevoraussetzungen
>>
>> - CPU: Pentium 66
>> - Hauptspeicher: 32 MB, besser 64
>> - Massenspeicher: mindestens 120 MB Festplatte, später auch
>> CompactFlashTM
>> - Sonstiges: Netzwerkkarte zum Anschluss an LAN
>> - Optional: ISDN- oder weitere Netzwerkkarte zum Anschluss an xDSL
>>
>> Das lasse ich einfach mal so unkommentiert wirken! ;)
>
> Das war aber von fast 20 Jahren und man installierte das Grundsystem von
> einer Diskette.

Das kann ich aber so nicht stehen lassen!
Das ist aus der Doku von Gestern!
https://www.eisfair.org/fileadmin/eisfair/doc/eisfair.pdf

Punkt 1.2 Die Hardwarevoraussetzungen

>
> In der Zwischenzeit ist aber auch vieles an neuen Möglichkeiten
> hinzugekommen. Ich meine, eisfair geht so auf die 5000 Pakete zu.

Richtig, finde den Fehler!
(Sorry für den Sarkasmus)

>
> Die Zeit bleibt nicht stehen.
>

Auch richtig!
Aber mit den Voraussetzungen bekommt man aus meiner Sicht nicht mal mehr
den Kernel zum laufen (Vermutung, nicht probiert).

Mir ist wohl bewusst, dass es an Personal fehlt und dann die Doku hinten
an steht.


Aber zu meiner Frage mit "Festplattenaufteilung und usr" will sich
keiner äußern, oder?
Das soll ich wieder testen und berichten, oder wie?
Schön wäre es ja, zu wissen ob das schon jemand probiert hat?

Danke einstweilen für die Infos!

Gruß,
Helmut

[Holger Bruenjes]

Hallo Helmut

Am 04/04/2023 um 21.52 schrieb Helmut Backhaus:

> Aber zu meiner Frage mit "Festplattenaufteilung und usr" will sich
> keiner äußern, oder?

hmm,auf usr liegt das System, ob das ein gute Idee ist das wech zu
beamen

Holger

[Marcus Röckrath]

Ich habe schonmal Boot auf Kosten von / vergrößert, und zwar mit einer
Live-GParted-CD. Habe ich auch im Wiki beschrieben.

Ich bin nicht so sehr der Freund davon, bei Platzmangel auf / Teile mittels
Links auf andere Partitionen zu verschieben. Ich würde eher die /-Parttiton
vergrößern wollen.

--
Gruß Marcus
[eisfair-Team]

[Helmut Backhaus]

Am 04.04.23 um 22:01 schrieb Holger Bruenjes:

Genau deshalb habe ich gefragt, die Gedanken habe ich mir auch gemacht.

Aber ich würde ein weiteres LVM in das System hängen und da drauf dann
usr legen.

Aber ich denke darüber noch mal nach Danke!

Gruß,
Helmut

[Helmut Backhaus]

Hallo Marcus

Am 04.04.23 um 22:05 schrieb Marcus Röckrath:

Ne, so habe ich das nicht vor!
Nicht irgend wo was ab zwacken!

Ich würde ein zusätzliches LV in das System hängen.

Aber doof ist das alles, ich denke noch mal drüber nach.

Danke!

Gruß,
Helmut

[Kay Martinen]

Am 04.04.23 um 22:21 schrieb Helmut Backhaus:

> Am 04.04.23 um 22:01 schrieb Holger Bruenjes:
>> Hallo Helmut
>>
>> Am 04/04/2023 um 21.52 schrieb Helmut Backhaus:
>>
>>> Aber zu meiner Frage mit "Festplattenaufteilung und usr" will sich
>>> keiner äußern, oder?

Partition vergrößern oder aufteilen! Oder neu installieren auf größerem
Volume. Was anderes kann dir da m.E. keiner Raten.

>> hmm,auf usr liegt das System, ob das ein gute Idee ist das wech zu beamen
>>

Im Vollen Betrieb sicher nicht. Früher hätte ich 'init S' (oder welcher
RL auch immer Singleuser ist) gemacht, vorher den neuen Platz
eingerichtet (fdisk, extX formatieren) und /usr nach /newuser kopiert.
Dann ggf. /usr umbenannt und /newusr nach /usr gemountet. fstab
bearbeitet und einen reboot später sollte man /oldusr leer räumen können.

Aber mit systemd weiß ich nicht ob/wie man da in einen single-user modus
kommt in dem nix läuft außer einer shell.

> Genau deshalb habe ich gefragt, die Gedanken habe ich mir auch gemacht.
>
> Aber ich würde ein weiteres LVM in das System hängen und da drauf dann
> usr legen.

LVM hab ich unter EIS noch nie verwendet. Aber da soll es Möglichkeiten
geben ein volume zu erweitern. Da ein LV aus mehreren PV bestehen kann...

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Kay Martinen]

Am 04.04.23 um 21:52 schrieb Helmut Backhaus:

> Am 04.04.23 um 21:13 schrieb Marcus Röckrath:

>> Helmut Backhaus wrote:
>>> Auszug aus der Eisfair Doku:
>>> Hardwarevoraussetzungen
>>>
>>> - CPU: Pentium 66
>>> - Hauptspeicher: 32 MB, besser 64
>>> - Massenspeicher: mindestens 120 MB Festplatte, später auch
>>> CompactFlashTM
>>> - Sonstiges: Netzwerkkarte zum Anschluss an LAN
>>> - Optional: ISDN- oder weitere Netzwerkkarte zum Anschluss an xDSL
>>>
>>> Das lasse ich einfach mal so unkommentiert wirken! ;)
>>
>> Das war aber von fast 20 Jahren und man installierte das Grundsystem von
>> einer Diskette.

Ist die Eisfair Version 1 schon so lange her? Gab's nicht damals auch
schon eine CD auf der weitere Pakete lagen zum nachinstallieren.

> Das kann ich aber so nicht stehen lassen!
> Das ist aus der Doku von Gestern!

Irgendwann möchte ich das wirklich mal nachprüfen ob ein aktueller
Eisfair noch installierbar ist. Z.b. auf meinem Compaq Prolinea. Den
hatte ich zuletzt mit FLI4L im Einsatz und der hat einen Pentium 75, 48
MB RAM und 2 SMC Ultra und AFAIR eine P-ATA Platte um die 120 MB.

Einer der aktiven Hosts hier der dem am nächsten kommt hat einen Atom
N270 und 1 GB RAM und bootet von 4 GB CF Karte. Bei dem liegt /var aber
auf einer hdd.

Ich hab Ein mal vor Jahren einen Eisfair auf einem Pentium 1 oder 2 mit
ca. 200 MHz installiert, und voll gepackt mit P-ATA Platten. Der fühlte
sich schon arg lahm an. Kann aber auch am Onboard IDE oder den alten
Platten liegen. Und ich hab noch extra drauf geachtet das / und /boot
möglichst auf der schnellsten Platte als Pri-Master liegen und /var auf
Sec.-Master damit die sich nicht gegenseitig die Zeit stehlen.

Ist eigentlich ein Schönes System, das Gehäuse. 2 HE Rackserver mit
genug platz, sogar für ein DDS Tape und LCD Modul in der Front. :-)

[Helmut Backhaus]

Am 04.04.23 um 22:45 schrieb Kay Martinen:

> Am 04.04.23 um 22:21 schrieb Helmut Backhaus:
>> Am 04.04.23 um 22:01 schrieb Holger Bruenjes:
>>> Hallo Helmut
>>>
>>> Am 04/04/2023 um 21.52 schrieb Helmut Backhaus:
>>>
>>>> Aber zu meiner Frage mit "Festplattenaufteilung und usr" will sich
>>>> keiner äußern, oder?
>
> Partition vergrößern oder aufteilen! Oder neu installieren auf größerem
> Volume. Was anderes kann dir da m.E. keiner Raten.
>

Aber ja genau, dass sind so die Fragen die ich mir auch gestellt habe!

>>> hmm,auf usr liegt das System, ob das ein gute Idee ist das wech zu
>>> beamen
>>>
>
> Im Vollen Betrieb sicher nicht. Früher hätte ich 'init S' (oder welcher
> RL auch immer Singleuser ist) gemacht, vorher den neuen Platz
> eingerichtet (fdisk, extX formatieren) und /usr nach /newuser kopiert.
> Dann ggf. /usr umbenannt und /newusr nach /usr gemountet. fstab
> bearbeitet und einen reboot später sollte man /oldusr leer räumen können.
>

Na ja, dass sind VM's unter XEN. Von da her habe ich da schon
Möglichkeiten das nicht im laufenden Betrieb zu machen. Ich hab das auch
schon gemacht.

> Aber mit systemd weiß ich nicht ob/wie man da in einen single-user modus
> kommt in dem nix läuft außer einer shell.
>

Das werde ich dann sehen, aber eigentlich sollte das auch so gehen wie
vor systemd ...

>> Genau deshalb habe ich gefragt, die Gedanken habe ich mir auch gemacht.
>>
>> Aber ich würde ein weiteres LVM in das System hängen und da drauf dann
>> usr legen.
>
> LVM hab ich unter EIS noch nie verwendet. Aber da soll es Möglichkeiten
> geben ein volume zu erweitern. Da ein LV aus mehreren PV bestehen kann...
>

Wie schon geschrieben, dass LV läuft auf dem Host

Aber die Grundfrage, die ich mir stelle, ist passiert mir das öfter?
So kam mir die Idee mit dem Auslagern von /usr .
Dann habe ich es zukünftig einfacher.

Aber ich muss mal sehen und noch mal gründlich drüber nachdenken!
Eure Ausführungen und Anmerkungen helfen dabei aber sehr!

Danke dafür!

Gruß,
Helmut

[Helmut Backhaus]

Hallo Kay,

Am 04.04.23 um 23:03 schrieb Kay Martinen:

> Am 04.04.23 um 21:52 schrieb Helmut Backhaus:
>> Am 04.04.23 um 21:13 schrieb Marcus Röckrath:
>>> Helmut Backhaus wrote:
>>>> Auszug aus der Eisfair Doku:
>>>> Hardwarevoraussetzungen
>>>>
>>>>        - CPU: Pentium 66
>>>>        - Hauptspeicher: 32 MB, besser 64
>>>>        - Massenspeicher: mindestens 120 MB Festplatte, später auch
>>>> CompactFlashTM
>>>>        - Sonstiges: Netzwerkkarte zum Anschluss an LAN
>>>>        - Optional: ISDN- oder weitere Netzwerkkarte zum Anschluss an
>>>> xDSL
>>>>
>>>> Das lasse ich einfach mal so unkommentiert wirken! ;)
>>>
>>> Das war aber von fast 20 Jahren und man installierte das Grundsystem von
>>> einer Diskette.
>
> Ist die Eisfair Version 1 schon so lange her? Gab's nicht damals auch
> schon eine CD auf der weitere Pakete lagen zum nachinstallieren.
>

Nicht drüber nachdenken, sonst fält auf wie alt wir wirklich sind ... :-))

>> Das kann ich aber so nicht stehen lassen!
>> Das ist aus der Doku von Gestern!
>
> Irgendwann möchte ich das wirklich mal nachprüfen ob ein aktueller
> Eisfair noch installierbar ist. Z.b. auf meinem Compaq Prolinea. Den
> hatte ich zuletzt mit FLI4L im Einsatz und der hat einen Pentium 75, 48
> MB RAM und 2 SMC Ultra und AFAIR eine P-ATA Platte um die 120 MB.

Ich hab zwar auch ein "Museum", aber so schlimm dann doch nicht.

>
> Einer der aktiven Hosts hier der dem am nächsten kommt hat einen Atom
> N270 und 1 GB RAM und bootet von 4 GB CF Karte. Bei dem liegt /var aber
> auf einer hdd.
>

Meine Ältesten sind:
- VIA Samuel 2
- AMD Duron(tm) processor

Wobei der erste schon auf der "Abschussliste" steht, der ist so langsam
das man damit nicht mehr wirklich was machen kann.
Der Zweite wird der nächste sein, den ich dann ausmustere ...

> Ich hab Ein mal vor Jahren einen Eisfair auf einem Pentium 1 oder 2 mit
> ca. 200 MHz installiert, und voll gepackt mit P-ATA Platten. Der fühlte
> sich schon arg lahm an. Kann aber auch am Onboard IDE oder den alten
> Platten liegen. Und ich hab noch extra drauf geachtet das / und /boot
> möglichst auf der schnellsten Platte als Pri-Master liegen und /var auf
> Sec.-Master damit die sich nicht gegenseitig die Zeit stehlen.
>
> Ist eigentlich ein Schönes System, das Gehäuse. 2 HE Rackserver mit
> genug platz, sogar für ein DDS Tape und LCD Modul in der Front. :-)
>

Und genau das ist es, das sind zum Teil wirklich super System, Da tut es
einfach "weh" die zu entsorgen ...

Gruß,
Helmut

[Kay Martinen]

Am 04.04.23 um 23:15 schrieb Helmut Backhaus:

> Am 04.04.23 um 22:45 schrieb Kay Martinen:
>> Am 04.04.23 um 22:21 schrieb Helmut Backhaus:
>>> Am 04.04.23 um 22:01 schrieb Holger Bruenjes:

>>>> Am 04/04/2023 um 21.52 schrieb Helmut Backhaus:
>>>>
>>>>> Aber zu meiner Frage mit "Festplattenaufteilung und usr" will sich
>>>>> keiner äußern, oder?

Mehr Details, wie man unten sieht.

>> Partition vergrößern oder aufteilen! Oder neu installieren auf größerem
>> Volume. Was anderes kann dir da m.E. keiner Raten.
>>
>
> Aber ja genau, dass sind so die Fragen die ich mir auch gestellt habe!
>
>>>> hmm,auf usr liegt das System, ob das ein gute Idee ist das wech zu
>>>> beamen
>>>>
>>
>> Im Vollen Betrieb sicher nicht. Früher hätte ich 'init S' (oder welcher
>> RL auch immer Singleuser ist) gemacht, vorher den neuen Platz
>> eingerichtet (fdisk, extX formatieren) und /usr nach /newuser kopiert.
>> Dann ggf. /usr umbenannt und /newusr nach /usr gemountet. fstab
>> bearbeitet und einen reboot später sollte man /oldusr leer räumen können.
>>
>
> Na ja, dass sind VM's unter XEN. Von da her habe ich da schon
> Möglichkeiten das nicht im laufenden Betrieb zu machen. Ich hab das auch
> schon gemacht.

Welche sollten das sein um von Außen in die VM hinein zu greifen. So
verstehe ich dich hierbei.

XEN hab ich nie verwendet oder wirklich durchblickt. Ich verwende
Virtualbox auf dem Desktop und ProxMox VE auf dem Server. Bei letzterem
geht das automagisch mit LVM und den images.

>> Aber mit systemd weiß ich nicht ob/wie man da in einen single-user modus
>> kommt in dem nix läuft außer einer shell.
>>
>
> Das werde ich dann sehen, aber eigentlich sollte das auch so gehen wie
> vor systemd ...

K.A. Was macht systemd aus einem 'tellinit 1'?

>>> Aber ich würde ein weiteres LVM in das System hängen und da drauf dann
>>> usr legen.
>>
>> LVM hab ich unter EIS noch nie verwendet. Aber da soll es Möglichkeiten
>> geben ein volume zu erweitern. Da ein LV aus mehreren PV bestehen kann...
>>
>
> Wie schon geschrieben, dass LV läuft auf dem Host

Das ging aus obigem nicht klar hervor das dir auf dem Host der Platz
ausgeht und nicht in der Gast-VM.

[Marcus Röckrath]

Hallo Helmut,

Helmut Backhaus wrote:

> Aber die Grundfrage, die ich mir stelle, ist passiert mir das öfter?
> So kam mir die Idee mit dem Auslagern von /usr .
> Dann habe ich es zukünftig einfacher.

Und wenn es dann später wieder auf / knapop wird, lagerst du dann /var aus?

Irgendwie wäre ich kein Freund davon. Bleibt / als Ganzes kommt eine
Reserver allen Verzeichnissen zugute, bei einer Aufteilung würde man für
jeden Bereich eine Reserver vorhalten müssen.

Da es ja ein virtuelles System ist, kann man da nicht die virtuelle
Partition/Platte vergrößern?

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Kay,

Kay Martinen wrote:

> Ist die Eisfair Version 1 schon so lange her? Gab's nicht damals auch
> schon eine CD auf der weitere Pakete lagen zum nachinstallieren.

Mein erster eis ist von vor 2003 und das System lief bis zum letzten Sommer;
natürlich ist mal Hardware kaputt gegangen, aber das System ist einfach
umgezogen.

Nach einem Crash im letzten Jahr, wo dann die Kopie auf eine neue Platte
Zicken beim Boot machte, habe ich mal neu installiert.

> Irgendwann möchte ich das wirklich mal nachprüfen ob ein aktueller
> Eisfair noch installierbar ist. Z.b. auf meinem Compaq Prolinea. Den
> hatte ich zuletzt mit FLI4L im Einsatz und der hat einen Pentium 75, 48
> MB RAM und 2 SMC Ultra und AFAIR eine P-ATA Platte um die 120 MB.

Probier es aus, ist die Frage, ob im Kernel eventuell die Unterstützung von
Althardware rausgefallen ist.

--
Gruß Marcus
[eisfair-Team]

[Kay Martinen]

Am 05.04.23 um 08:15 schrieb Marcus Röckrath:

> Kay Martinen wrote:

>> Irgendwann möchte ich das wirklich mal nachprüfen ob ein aktueller
>> Eisfair noch installierbar ist. Z.b. auf meinem Compaq Prolinea. Den
>> hatte ich zuletzt mit FLI4L im Einsatz und der hat einen Pentium 75, 48
>> MB RAM und 2 SMC Ultra und AFAIR eine P-ATA Platte um die 120 MB.
>
> Probier es aus, ist die Frage, ob im Kernel eventuell die Unterstützung von
> Althardware rausgefallen ist.

Tja. Das ist der Punkt bei dem ich eigentlich hoffte das du oder andere
Details nennen könnten. 386 Support ist m.w. Weitgehend futsch, 486 wohl
auch oft und bei Pentium erinnere ich mich an ein "mit MMU schon" aber
ich bin jetzt nicht CPU Firm genug um sagen zu können auf welche es
zutrifft. Und dann war da IMHO noch was mit der Adressunterstützung
(36bit?) da komme ich grad nicht auf das Stichwort/Kürzel,

[Kay Martinen]

Am 05.04.23 um 08:09 schrieb Marcus Röckrath:

> Hallo Helmut,
>
> Helmut Backhaus wrote:
>
>> Aber die Grundfrage, die ich mir stelle, ist passiert mir das öfter?
>> So kam mir die Idee mit dem Auslagern von /usr .
>> Dann habe ich es zukünftig einfacher.
>
> Und wenn es dann später wieder auf / knapop wird, lagerst du dann /var aus?

So weit ich erinnere hatte Eisfair schon mal ein "/boot wird zu klein"
Problem. Und das ganze Zweige des Dateibaums auf separaten Platten
liegen war bei Linux und Unix an sich schon immer etwas das man machen
kann und auch darf - aus den unterschiedlichesten Gründen.

Das sollte man also nicht zu sehr ideologisieren.

> Irgendwie wäre ich kein Freund davon. Bleibt / als Ganzes kommt eine
> Reserver allen Verzeichnissen zugute, bei einer Aufteilung würde man für
> jeden Bereich eine Reserver vorhalten müssen.
>
> Da es ja ein virtuelles System ist, kann man da nicht die virtuelle
> Partition/Platte vergrößern?

So wie ich ihn; mittlerweile; verstand hat er LVM auf dem Host. Offenbar
nicht in der VM. Da ist es eben; denke ich; auch nur EIN imagefile auf
der Platte des Hosts. Ob man das file vergrößeren kann hängt von den
Werkzeugen des Hypervisors ab. Bei XEN den er verwendet weiß ich dazu
nichts. Er meinte ja was von "ein LVM hinzu fügen" was wohl heißt dem LV
ein weiteres PV zuzuordnen oder... da gab's noch was mit extends.

Wenn auf den Medien noch luft ist kann man IMHO erweitern. Irgendwo muß
ein größeres imagefile ja auch hinein passen.

[Marcus Röckrath]

Hallo Kay,

Kay Martinen wrote:

> So weit ich erinnere hatte Eisfair schon mal ein "/boot wird zu klein"
> Problem.

Vor allem auf Systemen der ersten Stunden, zwischenzeitlich wurden im
Installer da auch später mal höhere Werte vorgegeben.

Solange IMHO Platz für zwei Kernel (+ kleine Reserve natürlich) in Boot ist,
kann einem Boot bei Kernelupdates nicht mehr überlaufen, da die neuen
Kernelinstallationsroutinen dann Kernel in ein Backupverzeichnis auf /
verschieben.

--
Gruß Marcus
[eisfair-Team]

[Helmut Backhaus]

Hallo Kay, hallo Marcus,

Am 05.04.23 um 00:14 schrieb Kay Martinen:

> Am 04.04.23 um 23:15 schrieb Helmut Backhaus:
>> Am 04.04.23 um 22:45 schrieb Kay Martinen:
>>> Am 04.04.23 um 22:21 schrieb Helmut Backhaus:
>>>> Am 04.04.23 um 22:01 schrieb Holger Bruenjes:
>
>>>>> Am 04/04/2023 um 21.52 schrieb Helmut Backhaus:
>>>>>
>>>>>> Aber zu meiner Frage mit "Festplattenaufteilung und usr" will sich
>>>>>> keiner äußern, oder?
>
> Mehr Details, wie man unten sieht.
>

Also Auf dem Host bilden XEN und LVM eine Einheit (technisch nicht ganz
richtig aber man kann es so beschreiben).

LVM stellt also den VM's Plattenplatz zur Verfügung, auf welche weise
auch immer. Ich nutze Image-Files nicht so gern und nutze so genannte
Physikalische Laufwerke. Das sind aber jeweils eigenständige LV Volumen
die dann von XEN auf eine Spezielle Art und Weise eingebunden werden.

Ich glaube, wenn ich hier weiter einsteige führt das zu weit.

>>> Partition vergrößern oder aufteilen! Oder neu installieren auf größerem
>>> Volume. Was anderes kann dir da m.E. keiner Raten.
>>>
>>
>> Aber ja genau, dass sind so die Fragen die ich mir auch gestellt habe!
>>
>>>>> hmm,auf usr liegt das System, ob das ein gute Idee ist das wech zu
>>>>> beamen
>>>>>
>>>
>>> Im Vollen Betrieb sicher nicht. Früher hätte ich 'init S' (oder welcher
>>> RL auch immer Singleuser ist) gemacht, vorher den neuen Platz
>>> eingerichtet (fdisk, extX formatieren) und /usr nach /newuser kopiert.
>>> Dann ggf. /usr umbenannt und /newusr nach /usr gemountet. fstab
>>> bearbeitet und einen reboot später sollte man /oldusr leer räumen
>>> können.
>>>
>>
>> Na ja, dass sind VM's unter XEN. Von da her habe ich da schon
>> Möglichkeiten das nicht im laufenden Betrieb zu machen. Ich hab das auch
>> schon gemacht.
>
> Welche sollten das sein um von Außen in die VM hinein zu greifen. So
> verstehe ich dich hierbei.

Ich stoppe die VM und passe das Volumen im LV an.
Das ist aber immer eine recht Fummelei, da die Die Volumen ja noch mal
in 3 Teile portioniert sind (ging halt früher mit Eis nicht anders) und
da kommen dann so Tools wie kpartx usw. zum Einsatz.

>
> XEN hab ich nie verwendet oder wirklich durchblickt. Ich verwende
> Virtualbox auf dem Desktop und ProxMox VE auf dem Server. Bei letzterem
> geht das automagisch mit LVM und den images.
>

VirtualBox nutze ich fast gar nicht mehr, damit hatte ich zu viel
Probleme. Proxmox habe ich hier auch laufen.

Ich bin über Eisxen zu xen gekommen und irgendwie dabei geblieben ...

>>> Aber mit systemd weiß ich nicht ob/wie man da in einen single-user modus
>>> kommt in dem nix läuft außer einer shell.
>>>
>>
>> Das werde ich dann sehen, aber eigentlich sollte das auch so gehen wie
>> vor systemd ...
>
> K.A. Was macht systemd aus einem 'tellinit 1'?
>

Ich auch nicht, wobei ich 'telinit' noch nie genutzt habe 'init' schon.

>>>> Aber ich würde ein weiteres LVM in das System hängen und da drauf dann
>>>> usr legen.
>>>
>>> LVM hab ich unter EIS noch nie verwendet. Aber da soll es Möglichkeiten
>>> geben ein volume zu erweitern. Da ein LV aus mehreren PV bestehen
>>> kann...
>>>
>>
>> Wie schon geschrieben, dass LV läuft auf dem Host
>
> Das ging aus obigem nicht klar hervor das dir auf dem Host der Platz
> ausgeht und nicht in der Gast-VM.
>

Da habe ich mich wohl blöde ausgedrückt!

Das Problem habe ich innerhalb z.Z. einer VM, hier wird der
"Festplatten-Speicher" knapp!
Nicht auf dem Host!

Und hier war/ist die Überlegung der VM nur für /usr eine extra Volumen
zur Verfügung zu stellen


Gruß,
Helmut

[Kay Martinen]

Am 05.04.23 um 21:14 schrieb Helmut Backhaus:

> Hallo Kay, hallo Marcus,
>
> Am 05.04.23 um 00:14 schrieb Kay Martinen:
>> Am 04.04.23 um 23:15 schrieb Helmut Backhaus:
>>> Am 04.04.23 um 22:45 schrieb Kay Martinen:
>>>> Am 04.04.23 um 22:21 schrieb Helmut Backhaus:
>>>>> Am 04.04.23 um 22:01 schrieb Holger Bruenjes:
>>
>>>>>> Am 04/04/2023 um 21.52 schrieb Helmut Backhaus:
>>>>>>
>>>>>>> Aber zu meiner Frage mit "Festplattenaufteilung und usr" will sich
>>>>>>> keiner äußern, oder?
>>
>> Mehr Details, wie man unten sieht.
>>
>
> Also Auf dem Host bilden XEN und LVM eine Einheit (technisch nicht ganz
> richtig aber man kann es so beschreiben).

Stimmt. Kommt mir technisch nicht richtig beschrieben vor.

> LVM stellt also den VM's Plattenplatz zur Verfügung, auf welche weise
> auch immer. Ich nutze Image-Files nicht so gern und nutze so genannte
> Physikalische Laufwerke. Das sind aber jeweils eigenständige LV Volumen
> die dann von XEN auf eine Spezielle Art und Weise eingebunden werden.
>
> Ich glaube, wenn ich hier weiter einsteige führt das zu weit.

Und ich gewinne den Eindruck das du von LVM genau so wenig bescheid
weißt wie ich mir das einbilde. :-)

PV sind m.W. immer Physische Laufwerke. Die kann man unter LVM Kontrolle
in einem oder mehreren LV (Logische Volumes) zusammen fassen. Und von
denen kann man auch wieder mehrere haben. So weit meine Kenntnis davon.
Wenn du also sagst das du kein image sondern ein PV nutzt hieße das m.E.
das du eigentlich kein LVM bräuchtest weil PV=VM-Content und demnach
deine Platte zu klein sein müsste.

> Ich stoppe die VM und passe das Volumen im LV an.
> Das ist aber immer eine recht Fummelei, da die Die Volumen ja noch mal
> in 3 Teile portioniert sind (ging halt früher mit Eis nicht anders) und
> da kommen dann so Tools wie kpartx usw. zum Einsatz.

Was für drei Teile sollen das sein? Meinst du damit evtl. / und /boot
in der jeweiligen VM und evtl. noch /data oder /efi?

>> XEN hab ich nie verwendet oder wirklich durchblickt. Ich verwende
>> Virtualbox auf dem Desktop und ProxMox VE auf dem Server. Bei letzterem
>> geht das automagisch mit LVM und den images.

> VirtualBox nutze ich fast gar nicht mehr, damit hatte ich zu viel
> Probleme. Proxmox habe ich hier auch laufen.

Wie unterschiedlich das doch ist. Ich fand Xen unmöglich kompliziert.
Dagegen sind VB und PVE die einfachste Sache der Welt.

>> K.A. Was macht systemd aus einem 'tellinit 1'?
>>
>
> Ich auch nicht, wobei ich 'telinit' noch nie genutzt habe 'init' schon.

Geht/ging so oder so.

>>>>> Aber ich würde ein weiteres LVM in das System hängen und da drauf dann
>>>>> usr legen.

>>> Wie schon geschrieben, dass LV läuft auf dem Host
>>
>> Das ging aus obigem nicht klar hervor das dir auf dem Host der Platz
>> ausgeht und nicht in der Gast-VM.

> Da habe ich mich wohl blöde ausgedrückt!

Allerdings.

LVM = Logical Volume Manager = Das gesamte Ding/Konzept.
LV = Logical Volume = Ein übergreifender Bereich den man formatiert.
PV = Physical Volume = Die Platten/Teile aus denen das LV ist.

> Das Problem habe ich innerhalb z.Z. einer VM, hier wird der
> "Festplatten-Speicher" knapp!

Okay.

> Nicht auf dem Host!

Du hast dort also noch Nicht zugeordneten Platz den du einem LV zu
schieben kannst?

> Und hier war/ist die Überlegung der VM nur für /usr eine extra Volumen
> zur Verfügung zu stellen

Das ist einigermaßen Mysteriös erklärt von dir. Wenn du Pro VM ein PV
hast und das eine komplette Platte ist dann wird deren Erweitern wohl
nicht gehen. Wenn du pro VM ein LV hast dann kannst du dem freien
Speicher zuordnen. Aber der wäre dann auch für die komplette VM = Deren
"Virtuelle Platte".

Und IN der VM mußt du dann nur das Dateisystem der neuen Größe anpassen.
Dazu brauchst du dann aber m.E. nix extra für /usr ab zwacken. Das würde
nur bits von der einen stelle auf eine andere verschieben - im gleichen
Behälter.

[Heinz-Peter Faasen]

Hallo,

> So weit ich erinnere hatte Eisfair schon mal ein "/boot wird zu klein"
> Problem.

ich bin mir nicht sicher, ob das nicht schon bald wieder droht, denn die
initrd hat sich von 5.15.91 nach 5.15.102 um ~60% aufgebläht. Dadurch
ist /boot jetzt bei fast 85% Auslastung.

> Und das ganze Zweige des Dateibaums auf separaten Platten
> liegen war bei Linux und Unix an sich schon immer etwas das man machen
> kann und auch darf - aus den unterschiedlichesten Gründen.
>
> Das sollte man also nicht zu sehr ideologisieren.

Das hat man "früher" sogar standardmäßig gemacht!
In den Installationsanleitungen gab es ellenlangen Abschnitte, in denen
erläutert wurde, wie man die "richtigen" Partitionsgrößen ermittelt.
Leider passte das aber meist nach einiger Zeit eh nicht mehr, egal,
wieviel Mühe man sich gab. Weil aber das Umpartitionieren bekanntermaßen
nicht risikolos ist, kam man davon ab.

Gruß
Heinz-Peter

[Marcus Röckrath]

Hallo Heinz-Peter,

Heinz-Peter Faasen wrote:

> In den Installationsanleitungen gab es ellenlangen Abschnitte, in denen
> erläutert wurde, wie man die "richtigen" Partitionsgrößen ermittelt.
> Leider passte das aber meist nach einiger Zeit eh nicht mehr, egal,
> wieviel Mühe man sich gab. Weil aber das Umpartitionieren bekanntermaßen
> nicht risikolos ist, kam man davon ab.

Wenn man glaubt, dass nach 20 Jahren noch die damaligen Entscheidungen und
Vorgaben gültig sind, lebt man eher auf einem anderne Planeten. :-))

Solange eine Platte noch nicht voll ist, ist eine Partitonsänderungen (nach
Backup natürlich) mit Gparted kein Hexenwerk.

--
Gruß Marcus
[eisfair-Team]

[Heinz-Peter Faasen]

Hi Marcus,

> Wenn man glaubt, dass nach 20 Jahren noch die damaligen Entscheidungen und
> Vorgaben gültig sind, lebt man eher auf einem anderne Planeten. :-))

es scheinen aber noch einige in der damaligen Denke festzustecken -
deshalb der kurze geschichtliche Abriss.

> Solange eine Platte noch nicht voll ist, ist eine Partitonsänderungen (nach
> Backup natürlich) mit Gparted kein Hexenwerk.

Jein.
In virtuellen Umgebungen ist das nicht immer wirklich trivial und schon
gar nicht narrensicher.
Und zu der Zeit, als diese kleinteiligen Partitionierungen empfohlen
wurden, waren die Modifikationswerkzeuge auch noch nicht wirklich
sicher. Vermutlich auch ein grund, von den damaligen Empfehlungen
abzurücken. Man lernt eben nie aus.... ;-)

Gruß
Heinz-Peter

[Kay Martinen]

Am 06.04.23 um 12:34 schrieb Heinz-Peter Faasen:

> Hi Marcus,
>
>> Wenn man glaubt, dass nach 20 Jahren noch die damaligen Entscheidungen und
>> Vorgaben gültig sind, lebt man eher auf einem anderne Planeten. :-))

> es scheinen aber noch einige in der damaligen Denke festzustecken -
> deshalb der kurze geschichtliche Abriss.

Klingt beides ideologisch. Geht ihr bitte vor die Tür zum
Kloppen/spielen. :-)

Ich hab z.b. auf meinem Vorigen Mini Fileserver / und /boot auf einer CF
und das passt auch jetzt noch - nach systemd. /home habe ich auf einer
Getrennten Platte so wie ich auch unter Windows früher gern die
userverzeichnisse auf einer eigenen Platte hatte. Dann kann man die ggf.
einfach abstöpseln wenn was kritisches an steht.

Und /var ist ein teil der home platte einfach um die CF nicht zu
belasten. Das sind gute und Valide Gründe und es mag/wird weitere geben
- auch heute noch.

>> Solange eine Platte noch nicht voll ist, ist eine Partitonsänderungen (nach
>> Backup natürlich) mit Gparted kein Hexenwerk.
>
> Jein.
> In virtuellen Umgebungen ist das nicht immer wirklich trivial und schon
> gar nicht narrensicher.

Ich hab einen Eis unter Proxmox gehabt dem der Platz ausging. Also hab
ich dem eine weitere virtuelle Disk zugeordnet und in der VM einfach
umbelegt. Schon war wieder genug platz da. Und die separate home-platte
kann man sogar separat sichern. Mit dem in PVE integrierten Backup oder
Snapshot tools. Automatisch!

> Und zu der Zeit, als diese kleinteiligen Partitionierungen empfohlen
> wurden, waren die Modifikationswerkzeuge auch noch nicht wirklich
> sicher. Vermutlich auch ein grund, von den damaligen Empfehlungen
> abzurücken. Man lernt eben nie aus.... ;-)

Nicht zu vergessen das seinerzeit die Platten auch noch groß, laut,
langsam und von geringer Kapazität waren. Da liegt es nahe auf zu teilen
und sich um typische dateigrößen, passende filesysteme oder die
inode-zahl gedanken zu machen - vorher. Nicht jeder hatte etliche SCSI
Platten und heute kann man eh alles auf einem LVM mixen, mit einem ZFS
erschlagen oder auch auf einem Raid bunkern (+ Backup).

Ich denke es kommt auch drauf an die grenzen der Werkzeuge und systeme
zu (er)kennen und dann eben den sicheren weg zu wählen. Oder man nimmt
die schnelle aber riskante abkürzung muß dann aber ggf. mit dem crash
leben lernen.

Früher hätte man z.b. eine partition auch einfach auf ein Tape sichern
können, diese dann modifizieren und vom tape zurück schreiben. Dauert
halt nur länger und nebenbei gwwinnt man noch ein Backup/Snapshot des
inhalts. Falls ein zweiter versuch nötig wird...

Es gibt ja meist mindestens Zwei Wege etwas zu tun. Den sicheren... und
den Falschen. ;-)