uefi - secure boot - ssd
Hallo Leute, ich muss heute Abend einen neuen PC zusammenbauen und (natürlich) openSuse darauf installieren. Das Motherboard ist ein ASUS Z87-Plus, laut Beschreibung mie UEFI Bios. Da das jetzt das erste Mal ist, dass ich mit einem UEFI Bios zu tun, und ich heute abend dort vermutlich kein Internet habe, möchte ich sicherheitshalber jetzt fragen ob / was ich beachten soll. Vorallem in Hinblcik auf secure boot, keys, usw... Außerdem ist das mein ersten Kontakt mit einem SSD. Auf das SSD soll das System (Idee dahinter ist, dass der Rechner möglichst schnell bootet). /home und /srv und swap kommen auf eine "traditionelle" HD. Da war doch noch etwas mit "einen Teil der SSD reservieren" ?? Wie war das nochmal ? Danke für Eure Tips !! Norbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Mittwoch, 9. April 2014, 10:36:04 schrieb Norbert Zawodsky:
;) An und für sich ist das Problemlos, nur mit meinen ASUS Board's hapert es. Auf alle Fälle das letzte Bios mitnehmen !! Bei den P8XX funktioniert die Secure Boot Installation (noch) nicht ;). Bei den P9xx kann ich die 13.1 nicht installieren :-(. da hängt sich der Installer auf. Dein Z87 dürfte auf Basis des P9 sein, hoffentlich klappt es bei Dir. (anderer Chipsatz) SSD: da fällt mit nur ein nicht die ganze Platte mit Partitionen füllen so 10% unpartitioniert frei halten, soll der internen Verwaltung gut tun. -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.04.2014 10:58, schrieb Günther J. Niederwimmer:
Aber, erinnere ich mich richtig? Wenn ich das secure boot nicht brauche, kann ich es auch abschalten? Und ganz "traditionell wie früher" installieren?? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Mittwoch, 9. April 2014, 11:06:55 schrieb Norbert Zawodsky:
JA, aber wie gesagt bei meinen ASUS Boards geht es mit dem P8xxx nur ohne Sekure Boot, beim W9xxx gar nicht zu installieren, da kommt dann ein "mkinitrd" Fehler Du wirst es ausprobieren müssen ;). ASUS verwendet so was "WIndows UEFI" ist mit secure boot "other OS" is ohne secure boot -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Wed, 09 Apr 2014 10:36:04 +0200 schrieb Norbert Zawodsky <norbert@zawodsky.at>:
Da das jetzt das erste Mal ist, dass ich mit einem UEFI Bios zu tun,
Bei den meisten Systemen lässt sich das noch wählen. Die ersten Schritte mit EFI sollten sicher auf einem eigenen "Spielsystem" stattfinden.
Seit systemd & Co. starten die meisten Systeme sowieso ziemlich schnell. Wenn es ein Desktop-System ist, würde ich auf jeden Fall /home auf die SSD packen, weil das Laden und Speichern der Desktop-Konfiguration sonst all die Zeit verschlingt, die Du mit dem rapiden Boot gewonnen hast. Falls swap wirklich erforderlich sein könnte, dann sollte es auf die SSD. Andere, weniger genutzte Dateien wie /usr können getrost auf der HDD bleiben, /boot sowieso. Insbesondere würde ich das System auf alle Fälle komplett mit LVM und einer gemeinsamen VG installieren (ausser /boot) und möglichst vom PV-space einiges ungenutzt lassen. Damit bist Du flexibel, einerseits LV für subtrees später noch anzulegen, falsche LV-Größen einfach (und häufig genug live inkl. Dateisystem) zu korrigieren und LV zwischen HDD und SSD zu verschieben. Das mit dem "reservieren" ist etwas irreführend. In der Hauptsache geht es um eine Reduzierung des Aufwands für garbage collection um als frei markierte cluster tatsächlich zu löschen. Eine gering gefüllte SSD wird sehr viel häufiger die Chance haben, dass ein "erasable block" keine Nutzdaten mehr enthält, die auf einen anderen Block kopiert werden müssen, bevor er gelöscht werden kann. Eine gefüllte SSD wird hingegen häufiger neue Blöcke gewinnen müssen und dafür jeweils ad hoc (= Performance-Verlust) Cluster durch Kopie zusammenfassen müssen. Man nennt die bewusst reduzierte Nutzung overprovisioning. Etwas bringt jede SSD von Haus aus mit, z.B. +10% der Nettokapazität, aber das verhindert nur den Nahezu-Kollaps einer SSD bei full disk. Eine Strategie kann z.B. sein, dass Du die Hälfte der SSD mit einem PV (LVM) belegst und den Rest ungenutzt lässt. Die PV kannst Du dann vollständig nutzen, der SSD-Controller wird hingegen maximal eine 50% gefüllte SSD "sehen" und den Rest als Spielraum nutzen und Dir mit anhaltend guter Performance danken. Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.04.2014 13:26, schrieb Tobias Crefeld:
Danke für Deine vielen Tips. ich verwende Linus schon viele Jahre (seit suse 7.x), aber es gibt wieder mal etwas, womit ich noch nie zu tun hatte. Neben UEFI und SSD gehört auch LVM dazu. LVM ist also auch Neuland für mich. Ich habe Deinen Text ein par mal gelesen und ich glaube, ich habe es jetzt "so halbwegs" verstanden. eines verwirrt mich jetzt aber doch: Wie kann ich bei Verwendung von LVM bestimme Verzeichnisse auf bestimmte PV (physische disks) "zuordnen"? Sprich, wie kann ich sicherstellen dass /home tatsächlich auf de SSD zu liegen kommt. Ich dachte immer, dass LVM genau das "abkapselt". Beispiel (der Einfachheit und Lesbarkeit halber nehme ich die "alten" Bezeichnungen "sda" usw... ): Ich habe 1 SSD, z.B. /dev/sda und eine klassische HD, z.B. /dev/sdb ZU aller erst mal auf der jungfreulichen SSD einen Teil "reservieren". Dazu gabs hier auf der Liste vor einiger Zeit mal einen Post. ich hoffe, ich finde ihn... Dann eine Partition für /boot, also /dev/sda1 --> /boot Dann, Du würdes swap auf die SSD legen? Ich dachte, die SSDs sollte man möglichst wenig beschreiben. .. Aber o.k. /dev/sda2 --> swap Jetzt wirds interessant. /dev/sda3 wird das 1. PV /dev/sdb1 wird das 2. PV Und dann? Beide PV auf eine VG zusammenfassen? Oder wie? Ich glaube, ich sehe im Moment gerade den Wald vor lauter Bäumen nicht... Grüße, Norbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Norbert Zawodsky wrote: [...]
Auf die Gefahr jetzt hier eine Menge Widerspruch zu ernten: Für den Heimgebrauch habe ich schlicht die ganze SSD (abzüglich ein wenig swap) genommen. Warum ein separates /boot? Und warum ein FS für /, /usr, /var, ...? So 'ne 250GB SSD kostet nicht mehr die Welt und ist für alles "systeminterne" mehr als ausreichend. Meine SSD ist damit auch nicht mal zu 40% ausgelastet - trotz grossem Squid cache. Ich habe NUR die echten "Massendaten" ausserhalb der SSD. Und dort tatsächlich LVM (auf raid-devices; nicht direkt auf physischen Platten). Dieses Zeugs kannst Du dann "irgendwo" in dein Filesystem reinhängen. Ich würde auch nicht unbedingt mehrere Platte via LVM zusammenfassen; was überlasse ich dem Raid "unten drunter" und präsentiere LVM nur ein PV. Ob man sich lvm/raid antun will muss jeder selber entscheiden - ich persönlich möchte nicht mehr ohne. Just my 2 cents Andreas
Am 09.04.2014 15:16, schrieb Kyek, Andreas, Vodafone DE:
* für meine Frau, eigentlich nur email + surfen * für mich email, surfen, ein wenig programmieren (kdevelop), etwas "von zu Hause arbeiten" (dafür muss dann aber in einer vm ein win paralell laufen. Daher stärkerer Prozessor und viel RAM) * für uns alle "Medienserver" (fotos, film, musik) per dlna Die "wichtigen" Daten liegen am Firmenserver zu dem ich über openvpn verbunden bin. Da speziell der "Medien" Teil viel Platz braucht finde ich die Idee mit LVM absolut gut. Blos fehlt mir die LVM Erfahrung. Da sind noch einige Fragezeichen hinter dem Wort "wie" ... Norbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Norbert Zawodsky wrote:
Ja - und nein. Du kannst bei LVM beim lvcreate neben der VG, in der dein LV angelegt werden soll auch ein/mehrere PVs angeben. Damit könntest du erreichen, das bestimmte LVs nur auf bestimmten PVs liegen. [...]
Im Klartext: Ich habe nur "/" und swap auf der SSD - keine separaten FS für irgendetwas ausser den Massendaten.
Für ein ähnliches Anwendungsszenario läuft hier mein Server zu Hause - inkl. der 4 virtuellen Maschinen. Und da in den Film/Musik Dateien ein Haufen Arbeit steckt, bis die soweit fertig waren und ausserdem die gesammelten Fotos für mich/uns schon wichtig sind ist mein Datengrab ein Raid5. Das Problem beim zusammenfassen mehrerer PVs in eine VG liegt IMO darin, das die VG "defekt" ist sobald nur ein PV ausfällt. Und da man "normalerweise" auch nicht spezifiziert auch welchem PV innerhalb der VG ein LV angelegt werden soll sind i.d.R. auch die Filesysteme alle defekt:-( Daher "unten drunter" ein Raid5; das ganze Raid ein PV. Dann könnte auch mal eine Platte ausfallen ohne das alle Daten weg sind. Mit mdadm kann man auch das Raid nachträglich vergrössern; damit kann man die VG vergrössern. LVs kann man sowieso vergrössern und moderne FS kann man im laufende Betrieb ebenfalls vergrössern. Und meine SSD enthält nur das System - die wichtigsten Config-Verzeichnisse kopiert ein cron-Job in ein Backup im Datengrab. So ein System ist einigermassen schnell aufgesetzt (wenn man die ganzen config's noch hat).
Die "wichtigen" Daten liegen am Firmenserver zu dem ich über openvpn verbunden bin.
Das erzähl mal meiner Frau, das ihre Daten nicht wichtig sind :-)
IMO lohnt es sich, _vor_ dem aufsetzen darüber nachzudenken. Andreas
Am 10.04.2014 06:23, schrieb Kyek, Andreas, Vodafone DE:
Jedenfalls vielen Dank! Wertvolle Tips !! -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Wed, 09 Apr 2014 14:46:37 +0200 schrieb Norbert Zawodsky <norbert@zawodsky.at>:
(seit suse 7.x), aber es gibt wieder mal etwas, womit ich noch nie zu tun hatte. Neben UEFI und SSD gehört auch LVM dazu.
LVM bringt eine gewisse Einstiegsschwelle mit sich. Habe das auch länger vor mir hergeschoben. Initial macht es die Angelegenheit ja erstmal komplizierter, weil es eine weitere block-device Schicht zwischen Filesystem und Partition, RAID oder Hardware-Device einschiebt. Und man sollte es schon halbwegs umfassend verstehen, wenn man mal ein System mit LVM reparieren will.
Das ist ein valider Einwand. In größeren Umgebungen würde ich pro PV-Typ eine eigene Volume Group verwenden. Aber das nimmt halt die Flexibilität, weil man PVs nicht über VG-Grenzen verschieben kann. Die Partitionierer-GUIs unterstützen das m.W. nicht. Man kann es aber ggf. hinterher mit pvmove passend verschieben oder man gibt es auf der Kommandozeile (lvcreate) an, welche PV verwendet werden soll.
Würde ich bereits als LV anlegen. Eigentlich nur sda1 = /boot, sda2 = PV, sdb1 = PV.
Und dann? Beide PV auf eine VG zusammenfassen? Oder wie?
Das Thema VG kannst Du eigentlich vergessen. Jede LV und PV gehört halt zu einer VG, die ganz zu Anfang "kreiert" werden muss. Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (4)
-
Günther J. Niederwimmer -
Kyek, Andreas, Vodafone DE -
Norbert Zawodsky -
Tobias Crefeld