Fedora 18

da daten im swap unverschlüüselt liegen, sollte man swap unbedingt verschlüsseln, wenn der rest des systems verschlüsselt ist. manche distris verwenden für swap zufällige schlüssel, die nur bis zum nächsten start gültig sind. dann wird swap mit neuem schlüssel generiert. suspend-to-disk kann man dann allerdings nicht nutzen.

/ und /home wurden absichtlich auf dieselbe partition gelegt, da du so flexibler beim belegen des speicherplatzes bist. wenn du neu installieren willst, legst du ein neues subvolume an und löschst das alte /home bleibt dabei erhalten
 
yatpu schrieb:
/ und /home wurden absichtlich auf dieselbe partition gelegt, da du so flexibler beim belegen des speicherplatzes bist. wenn du neu installieren willst, legst du ein neues subvolume an und löschst das alte /home bleibt dabei erhalten
Zum Vergrößern anklicken....
Hallo yaptu, das war ja meine Frage, ob zumindestens die Funktionalität nun so ist, als wenn ich zwei Partitionen hätte. Es geht mir nur um Neuinstallationen. Wenn die Neuinstallation eines Subvolumes genauso unkompliziert wie die einer Partition funktioniert, ist es mir wurscht. Und stimmt, so bin ich bei der Root-Partition nicht auf eine Grenze festgelegt. --- Allerdings: hat der Installer "korrekt" gearbeitet? War mein (nicht erfüllter) Plan nur in meinem Kopf? Was, wenn ich aus irgendwelchen Gründen wirklich verschiedene Partitionen habe möchte?

Die Frage ist auch, ob man Root verschlüsselt. Sicherheitsfreaks sagen sicherlich "natürlich!", aber macht es das System nicht signifikant langsamer? (Auch hier hat der Installer meine Wahl ignoriert.)
 
was genau wolltest du denn eigentlich haben?
sollte nur /home verschlüsselt werden und / nicht? in dem falle hätte der installer in der tat deinen wunsch ignoriert, da der / und /home auf dieselbe partition gelegt hat. ich gehe davon aus, dass der installer einfach noch sehr verbuggt ist und hier falsche prioritäten gesetzt hat.
eine komplette verschlüsselung merkt man natürlich nur bei hdd-lastigen dingen wie softwareinstallationen. programmladezeiten sind z.t. auch etwas langsamer. ich weiß allerdings nicht, ob es bei cpu mit aes-ni anders ist. ich hab hier bislang nur cpus ohne aes-ni. die sequenzielle leserate ging dadurch deutlich nach unten (die leistung bei verteilten zugriffen mit sicherheit noch mehr). der c2d sp9500 im t400s mit 2,4 ghz kam auf 150 mb/s bei meinen ssds.
 
Ich habe die verschiedenen Listings, die ich gepostet habe, bzw. die Struktur des Dateisystems immer noch nicht ganz verstanden.

In /etc/fstab steht zwar, dass es Subvolumes root und home gibt, eingehängt in / bzw. /home. Aber müsste es nicht eher so aussehen, wie SammyHP es gestern gepostet hat, nämlich dass / und /home zwei Subvolumes eines gemeinsamen Volumes sind? Wie genau würde ich denn jetzt das root-Subvolume löschen und erneuern, ohne dabei das Home-Subvolume zu verletzen? Und die Frage für die Praxis (Upgrade auf bzw. Neuinstallation einer Linuxversion) wäre noch, ob mir mit Installern das gewünschte Verhalten gelingen wird.
 
Mit Installern: Keine Ahnung, deswegen ist btrfs auch noch beta. ;)

Manuell geht's so: http://linux.die.net/man/8/btrfs

Du brauchst die subvolumes aber nicht löschen und neu anlegen, du kannst es bei der Installation auch einfach nur leer machen (was mit den Installern vermutlich nicht geht.
 
Wie ist das denn eigentlich, wenn der SSD-Controller AES-256 beherrscht? Kann man dies unter Linux nutzen? Und wenn ja, braucht man dann überhaupt noch sowas wie LUKS?
 
für die interne verschlüsselung musst du das ata-passwort setzen. da die hersteller afaik keine details zur umsetzung der verschlüsselung preisgeben, würde ich eher auf luks setzen, bzw beides parallel benutzen
 
So, ich habe nochmal neu installiert, zwar F19 pre-alpha, aber ansonsten ganz konservativ ext4 unverschlüsselt, getrennte / und /home Partition. Gegen btrfs hätte ich nichts gehabt, aber so wie es gelaufen ist (mit dem Installer), war ich nicht zufrieden. Die Performanz mit LUKS kam mir doch deutlich schlechter vor. Ich habe das insbesondere heute bei der Neuinstallation gemerkt. Zudem fand ich die zusätzliche Passwort Eingabe nervig, auch wenn mir klar ist, dass sie nötig ist. Muss ich halt weiter auf meine SSD aufpassen... :rolleyes:
 
Fed. 19

Hallo Dirk.
Ich lade mir auch gerade die
fed.19 alpha
herunter und wollte mal fragen
ob der Grub in Fed.19 denn jetzt auch auf
BTRFS
installiert werden kann oder ob man immer noch eine
bootpartition braucht ?
Es soll als meine einzige distri auf meinen X31;-)!
Danke , l.g. s.berlin
 
Hallo s.berlin,

nun, ich habe ja von Btrfs wieder Abstand genommen. Aber wenn ich mich recht erinnre, habe ich gelesen, dass die /boot-Partition Ext4 sein muss bzw. nicht Btrfs. Wahrscheinlich hat der Installer das auch garnicht zugelassen, weiss nicht genau. Ob es auch Alternativen ohne /boot-Partition gibt, weiss ich nicht.
 
Der BUG in Fedora 18 (bleibt bei der Sprachauswahl hängen, betrifft Notebooks mit UMTS) kann man mit einem 'touch /etc/sysconfig/network-scripts/ifcfg-wwan0' umgehen.
Ich habe mir angewöhnt Fedora auf / und /boot zu installieren und alles andere hinterher manuell zu machen, ist halt teilweise aufwändiger aber bei dem A...-Installer für mich die beste Lösung.
 
Wie oft installierst du denn? :D

supermin (febootstrap) und 3 Minuten später biste fertig.
 
Hy!
Ich wollte fedora 19 auf meinem x31 installieren ;-((( !
Die Installation lief auch durch,
allerdings lande ich nach dem reboot immer in der
(glaube es heißt )
Grub Shell
Fedora starten geht damit nicht,
deswegen habe ich
das projekt bis ich eine Lösung gefunden habe
erstmaaal auf eis gelegt ;-)

danke, .berlin
 
Es ist eh sinnvoller Fedora 17 zu installieren, alle Updates einspielen und dann per fedup ein Upgrade auf 18 zu machen.

Dass man so einen kaputten Installer ausliefert, ist echt krass.
 
Moinsen,

hat sonst noch wer seit dem heutigen Kernel Upgrade (3.8.9-200) jemand probleme mit dem Wlan?
Bei mir verliert er nun ständig die verbindung und muss einen reconnect machen (was manchmal fehl schlägt) und teilweise hab ich auch sehr langsame übertragungsgeschwindigkeiten...
Fahre jetzt testweise seit ner knappen stunde und bisher stabil ^^... daher meine Vermutung dass das Problem mit dem Kernel zusammenhängt
 
Schlechte SSD Performanz

Ich habe neulich festgestellt, dass die SSD unter Fedora 18 von den Werten her eine schlechte Performanz zeigt.

Folgende Werte mit
Code: 
hdparm -t /dev/sda

Code: 
X220 i7 Fedora 18 Intel 320 SSD: ca. 190 MB/s
X220 i5 Mint 13 Intel 320 SSD: 265 MB/s
X230 i7 Fedora 19 840 pro: 515 MB/s
Der erste Wert ist vergleichsweise schlecht. Der Wert bei der 840 pro (SATA3 6 Gb/s) ist okay, wenngleich leicht unter dem Erwartungswert (540 MB/s). Aber im Vergleich zu Mint 13 ist der Wert bei Fedora 18 (bei identischer SSD) doch deutlich schlechter. (Ich weiss, dass man das im Alltag kaum merkt.)

Hat jemand eine Idee, woran das liegen könnte, woran man schrauben könnte?

Neulich bei Fedora 19 bei einem "älteren" Kernel (3.9.0-RC5 oder so), waren die Werte der 840 pro auch *deutlich* schlechter (um die 300 MB/s), das lag wohl an der Debug-Option des Kernels. Aber das sollte bei F18 (Kernel 3.8.8 und 3.8.9) nicht der Fall sein.

NACHTRAG: Nur so nebenbei: das X220 hat ja auch ein SATA 6 Gb/s Interface. Eine Tatsache, die man weder dem tabook noch dem Wiki entnehmen kann.
 
Zuletzt bearbeitet:
190 MB/sec hatte bei mir hdparm noch nie bei der Intel 320 ausgespuckt. Und ich hab mehrere Werte seit 2011 vorliegen, aktuell 259.16 MB/sec, Kernel 3.7.9-205. 'time dd if=/dev/zero of=/testfile bs=1M count=3000 conv=fdatasync,notrunc' zeigt 220MB/s. Mfg kalibari
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben