staging.inyokaproject.org

Mit einer Standardinstallation in 64 Bit ist /boot nach autoremove 151 MiB groß, notfalls muss man vor einem Upgrade alle alten Kernels manuell löschen.

Das würde ja bedeuten: vor dem Upgrade komplett alle Kernel löschen, die man hat?

stfischr schrieb:

lionlizard schrieb:

Das ist meine Belegung von /boot

und ein absoluter Spezialfall. Wer unbedingt 3 Versionen von jedem Kernel vorhalten will, dem sollte klar sein, dass er nicht die minimale Partitionsgröße wählen kann (da steht ca 5 Kernel).

Ich habe keine 3 Versionen vom Kernel. Ich habe ein Efi-System und zusätzlich einen Lowlatency Kernel installiert. Signierte und unsignierte Kernel werden gleichzeitig automatisch installiert, und ich habe extra noch den dritten Kernel deinstalliert, bevor ich das ganze hier gezeigt habe. Meine /boot ist deshalb 477 MB groß, weil ich bei 200 MB regelmäßig Probleme bekam, wenn der Kernel aktualisiert wurde (obwohl ich regelmäßig geputzt habe).

In /boot? Glaube ich nicht, Link?

https://forum.ubuntuusers.de/topic/aktualisierungsverwaltung-nicht-genug-platz-au/

@all So, ihr dürft mich jetzt schlagen, aber ich habe für Swap den Wert eingetragen, der auch im Artikel Swap genannt wird - ein Link dorthin war ja eh schon gesetzt: Ram+20-30%. Und ich habe einen Hinweis eingefügt, dass man die Größen ggf. im Forum diskutieren sollte.

Die 200 MB für /boot hatte ich auf 500 MB geändert - das habe ich aber wieder zurück genommen, da dieser Wert sich ja auf das - unveränderte - Beispiel bezieht. Lediglich den empfohlenen Maximalwert habe ich auf 2 GB erhöht.

lionlizard schrieb:

Ich habe keine 3 Versionen vom Kernel. Ich habe ein Efi-System und zusätzlich einen Lowlatency Kernel installiert. Signierte und unsignierte Kernel werden gleichzeitig automatisch installiert, und ich habe extra noch den dritten Kernel deinstalliert, bevor ich das ganze hier gezeigt habe. Meine /boot ist deshalb 477 MB groß, weil ich bei 200 MB regelmäßig Probleme bekam, wenn der Kernel aktualisiert wurde (obwohl ich regelmäßig geputzt habe).

Nun, dann würde ich Vorschlagen, man macht ein Minimum für BIOS und eins für UEFI. Damit man bequem arbeiten kann sollten 4 Kernel + 128 MiB (laut deinem Link für Aktualisierung) geplant werden. Macht bei mir grob 300 MiB Minimum.

Interessant wäre mal die Größe von /boot einer UEFI-Standardinstallation nach einem autoremove. Kann das jemand mal posten? Da fehlt mir jegliche Erfahrung, anscheinend braucht UEFI mehr Platz.

@all So, ihr dürft mich jetzt schlagen, aber ich habe für Swap den Wert eingetragen, der auch im Artikel Swap genannt wird - ein Link dorthin war ja eh schon gesetzt: Ram+20-30%. Und ich habe einen Hinweis eingefügt, dass man die Größen ggf. im Forum diskutieren sollte.

Es macht zumindest Sinn das im Wiki einheitlich zu regeln, am liebsten natürlich nur an einer Position, sonst driftet es bei jeder Änderung wieder auseinander.

Was ich in meinem Vorschlag schon angedeutet habe, macht es keinen Sinn "RAM + %" anzugeben, denn bei 32 GiB + 30% wären dass dann 41 GiB Swap, keine Chance, dass man so viel für StD braucht, der Systemstart wäre dann ebenfalls ne Geduldsprobe. Ich würde da schon die empfohlene Swapgröße + RAM nehmen, mit dem Hinweis, dass auch weniger möglich ist, je nach Nutzungsverhalten (siehe free unter maximallast).

jms3000 schrieb:

Das passt jetzt aber nicht mehr in meine swap, weil die nur 8000 MiB hat (und das sind eben keine 8GiB). Wenn mein RAM also voll ist, geht kein suspend-to-disk mehr.

StD geht auch mit weniger Swap, da caches und buffer nicht gespeichert werden müssen. Hast du das mal getestet?

Empfohlen 512MiB??? Wenn ich Android-Studio, Chrome und MySQl-Workbench laufen habe, da hatte ich 4GiB im RAM und 3GiB im Swap! Warum soll das denn langsam sein?

Also 3 GiB von der Festplatte zu lesen, kannst du mir nicht erzählen, dass das schnell geht, selbst ne gute SSD würde da mindestens 6 Sekunden für brauchen (ohne das Auslagern der anderen Anwendungen in diesem Moment zu betrachten). Hast du die Anwendungen gleichzeitig verwendet (mit Alt + Tab gewechselt) oder nur einmal gestartet und nicht mehr benutzt?

jms3000 schrieb:

Das würde ja bedeuten: vor dem Upgrade komplett alle Kernel löschen, die man hat?

😀 das sollte man nicht tun. Nur alle derzeit nicht verwendeten Kernel. Dann sollten sogar 200 MiB reichen.

An Alle:

Bevor wir jetzt jeden Wikieintrag 5 Mal verändern. Mir geht es in erster Linie darum, dass wir uns auf sinnvolle Werte für min/max/empf einigen, Formatierung und graphische Aufbereitung im Wiki kommt dann später.

Die Werte für "empfohlen" sollen für eine Ubuntu (Unity) Standardinstallation reichen, bei der man 2 bis 3 Mal im Jahr Systempflege betreibt.

"Min" sollte mit einigen Einschränkungen und regelmäßiger Pflege gut funktionieren. Besser wären hier vielleicht die Hintergründe zu erklären, z.B. 1 Kernel braucht 50 MiB mit regelmäßigem autoremove hat man max 4 Kernel gleichzeitig, die Installation eines neuen Kernels braucht ~ 128 MiB.

"Max" hier wären entsprechende Anwendungsfälle interessant, wer hat wie viel mit welchen Programmen/Installationen benötigt, wird so viel jemals gebraucht? Siehe auch 41 GiB Swap.

Bei StD könnte ein Link auf den entsprechenden Artikel reichen, denn standardmäßig ist das ja sowieso nicht aktiviert.

Edit: und wir sollten immer bedenken, dass viele Nutzer zum ersten Mal in ihrem Leben mit Partitionierung konfrontiert werden, da sie bisher nur eine gekaufte Windowsinstallation genutzt haben.

Also 3 GiB von der Festplatte zu lesen, kannst du mir nicht erzählen, dass das schnell geht, selbst ne gute SSD würde da mindestens 6 Sekunden für brauchen (ohne das Auslagern der anderen Anwendungen in diesem Moment zu betrachten). Hast du die Anwendungen gleichzeitig verwendet (mit Alt + Tab gewechselt) oder nur einmal gestartet und nicht mehr benutzt?

Erstens ist es eine SSD, zweitens werden die 3GB swap ja nicht auf einmal rausgeschrieben oder eingelesen. Und dann kommt ja ins swap, was man grade nicht so braucht. Es gibt ja viele Teile vom System, die werden fast nie benutzt.

Das System wäre schlecht beraten, wenn es ausgerechnet Browser-Daten raus-swapt, die ich gerade verwendet habe.

Meine Nutzung ist gemischt. Mal MySQl-WB, mal im Internet nachschauen, dann kommt eine Mail... Aber auch wenn ich mal nichts in der MySql-Workbench mache, schliesse ich die nicht, denn da habe ich 6 Tabs offen mit SQLs, an denen ich beim nächsten Mal weitermachen will.

Hallo,

So, ihr dürft mich jetzt schlagen, aber ich habe für Swap den Wert eingetragen, der auch im Artikel Swap genannt wird - ein Link dorthin war ja eh schon gesetzt: Ram+20-30%. Und ich habe einen Hinweis eingefügt, dass man die Größen ggf. im Forum diskutieren sollte.

Nägel mit Köpfen sind immer gut ☺

Was ich in meinem Vorschlag schon angedeutet habe, macht es keinen Sinn "RAM + %" anzugeben,

Da ist was dran...

Ich würde da schon die empfohlene Swapgröße + RAM nehmen, mit dem Hinweis, dass auch weniger möglich ist

+1

Frage, da ich ja wenig im Supportforum unterwegs bin: kommen öfters Supportfragen, wo dann am Ende rauskommt, dass SWAP zu klein bemessen ist? AFAIK nein. Das /boot zu klein ist kommt ja schon mal öfters, oder?

Gruß, noisefloor

Frage, da ich ja wenig im Supportforum unterwegs bin: kommen öfters Supportfragen, wo dann am Ende rauskommt, dass SWAP zu klein bemessen ist?

Da stellt sich mir die Frage: wie macht es denn das Installationsprogramm, wenn man nicht manuell partitioniert?

noisefloor schrieb:

Frage, da ich ja wenig im Supportforum unterwegs bin: kommen öfters Supportfragen, wo dann am Ende rauskommt, dass SWAP zu klein bemessen ist? AFAIK nein. Das /boot zu klein ist kommt ja schon mal öfters, oder?

Gute Frage, ich kann mich an keinen Fall entsinnen. Normalerweise schafft das OS den gleichen Workflow auch mit einem GB Swap weniger, es werden dann halt die Caches/Buffer früher geleert/reduziert.

jms3000 schrieb:

Da stellt sich mir die Frage: wie macht es denn das Installationsprogramm, wenn man nicht manuell partitioniert?

Irgendwas zwischen 0,5 bis 4 GiB, abhängig von verfügbarem Plattenplatz und installiertem RAM. Da es Opensource ist, müsste man theoretisch an den Algorithmus ran kommen, wenn man wüsste wie das Installerpaket heißt ...

Wirkliche Empfehlungen zu Swap sind allerdings schwer, da die Größe vom Nutzerverhalten abhängig ist. Das hat jms3000 bereits gezeigt. Die Aussage: "Mehr schadet nie" ist hier wohl angebracht.

Mann könnte als allgemeine Empfehlung den Standardswap nachträglich mit swapspace kombinieren, um den Platz nur wenn wirklich nötig zu belegen. Hat den Vorteil, dass es nachträglich mit einer Terminalzeile erledigt ist und man sich um die Größe keinen Kopf machen muss. Meinungen?

Was ich jetzt noch nicht probiert hab: kann suspend-to-disk auch in eine Swap-Datei schreiben (wenn es keine Swap-Partition gibt)? Und kann es dann auch rein resume aus dieser Datei machen, auch wenn die in Btrfs liegt?

jms3000 schrieb:

Was ich jetzt noch nicht probiert hab: kann suspend-to-disk auch in eine Swap-Datei schreiben (wenn es keine Swap-Partition gibt)?

Ich meine Ja, habs aber noch nie probiert.

Und kann es dann auch rein resume aus dieser Datei machen, auch wenn die in Btrfs liegt?

Das Dateisystem muss von Grub unterstützt werden, sollte bei BTRFS mittlerweile der Fall sein.

jms3000 schrieb:

Und kann es dann auch rein resume aus dieser Datei machen, auch wenn die in Btrfs liegt?

Btrfs unterstützt derzeit gar keine Swap-Dateien, siehe auch btrfs FAQ - Does btrfs support swap files? 🇬🇧.

mrkramps schrieb:

jms3000 schrieb:

Und kann es dann auch rein resume aus dieser Datei machen, auch wenn die in Btrfs liegt?

Btrfs unterstützt derzeit gar keine Swap-Dateien, siehe auch btrfs FAQ - Does btrfs support swap files? 🇬🇧.

Oha, danke Mr Kramps!

Auf https://wiki.ubuntuusers.de/Manuelle_Partitionierung/#Vorueberlegungen steht nocht, dass GRUB2 BTRFS nicht unterstützt. Ich nehme an, das ist hinfällig? Allerdings stehen hier http://superuser.com/questions/931298/grub2-boot-as-btrfs-subvolume ein paar komische Sachen, da kann ich nicht einschätzen, ob das noch gilt? Oder bezieht sich das nur auf grubby, was bei Ubuntu nicht verwendet wird?

Hallo,

die Anhänge datentraegerverw 1.png und laufwerkgroesse.png sind verweist. Spricht etwas dagegen, die zu löschen?

Viele Grüße
Beforge

PS: Die Links funktionieren, auch wenn sie aus irgendeinem Grund grau sind.

Beforge schrieb:

Hallo,

die Anhänge datentraegerverw 1.png und laufwerkgroesse.png sind verweist. Spricht etwas dagegen, die zu löschen?

Das sind eh uralte Screenshots aus einem Windows 2000 oder nicht? 😊

Sieht so aus. Würde ich daher rausschmeißen.

/erl. 27.06.2018