Frage Wie schlimm ist es wirklich, Linux auf einer großen Partition zu installieren?


Wir werden CentOS 7 auf unserem neuen Server laufen lassen. Wir haben 6 x 300GB Laufwerke in Raid6 intern auf dem Server. (Die Speicherung erfolgt größtenteils extern in Form einer Raid-Box mit 40 TB.) Das interne Volume erreicht bei einer Formatierung als einzelnes Volume etwa 1,3 TB. Unser Systemadministrator hält es für eine sehr schlechte Idee, das Betriebssystem auf einer großen 1,3-TB-Partition zu installieren.

Ich bin Biologe. Wir installieren ständig neue Software zum Ausführen und Testen, von denen die meisten in / usr / local landen. Da wir aber ungefähr 12 nicht computererfahrene Biologen haben, sammeln wir auch viel Geld in / zu Hause. Unser letzter Server hatte eine Partition mit 200 GB für / und nach 2,5 Jahren war er zu 90% voll. Ich will nicht, dass das wieder passiert, aber ich möchte auch nicht gegen den Expertenrat gehen!

Wie können wir das verfügbare 1.3TB am besten nutzen, um sicherzustellen, dass Speicherplatz verfügbar ist, wann und wo es benötigt wird, aber keinen Wartungs-Albtraum für den Systemadministrator erstellen?


91
2017-09-18 08:12


Ursprung


Verwenden Sie LVM und ändern Sie die Größe nach Belieben - thanasisk
@thanasisk Die Resistierbarkeit ist ein Mythos, da es auf Linux kein Dateisystem gibt, das online geschrumpft werden kann. ext2 hatte in der Antike einen solchen Patch. - peterh
@PeterHorvath - bist du dann glücklich, wenn ich "resize" durch "expand" ersetze? - thanasisk
Es ist ein bisschen unrealistisch zu erwarten, dass alles, was Sie jetzt einrichten, in 2,5 Jahren noch optimal ist! Und die Tatsache, dass unkluge Benutzer ein Durcheinander machen, ist ein Grund mehr, OS von Daten zu trennen. - JamesRyan
@PeterHorvath Ich habe deinen Kommentar mehr als einmal gelesen, nur um es zu verstehen. Sie haben geschrieben, dass Sie sich freuen würden, wenn ein Dateisystem existiert, das erweitert werden könnte, und ich habe auf ein Dateisystem hingewiesen, das das tut. Das ist alles. - gparent


Antworten:


Die primären (historischen) Gründe für die Partitionierung sind:

  • zu Trennen Sie das Betriebssystem von Ihren Benutzer- und Anwendungsdaten. Bis zur Veröffentlichung von RHEL 7 gab es keine Unterstützung Upgrade-Pfad und ein Hauptversionsupgrade würde eine Neuinstallation erfordern und dann zum Beispiel haben /home und andere (Anwendungs-) Daten auf separaten Partitionen (oder LVM-Volumes) ermöglichen Ihnen, die Benutzerdaten und Anwendungsdaten auf einfache Weise zu konservieren und die OS-Partition (en) zu löschen.

  • Benutzer können sich nicht ordnungsgemäß anmelden und Ihr System beginnt auf interessante Weise zu versagen, wenn Sie nicht mehr genügend Speicherplatz haben. Mehrere Partitionen ermöglichen es Ihnen, Festplatten reservierten Speicherplatz für das Betriebssystem zuzuweisen und dieses getrennt von den Bereichen zu halten, in denen Benutzer und / oder bestimmte Anwendungen schreiben dürfen (z. B. /home /tmp/ /var/tmp/ /var/spool/ /oradata/ usw.) , Abschwächung des operationellen Risikos von schlecht benommenen Benutzern und / oder Anwendungen.

  • Quote. Das Festplattenkontingent ermöglicht es dem Administrator, zu verhindern, dass ein einzelner Benutzer den gesamten verfügbaren Speicherplatz belegt, wodurch der Dienst für alle anderen Benutzer des Systems unterbrochen wird. Ein einzelnes Festplattenkontingent wird pro Dateisystem zugewiesen, so dass eine einzelne Partition und somit ein einzelnes Dateisystem nur 1 Festplattenquoum bedeutet. Mehrere (LVM) Partitionen bedeuten mehrere Dateisysteme, die eine genauere Kontingentverwaltung ermöglichen. Abhängig von Ihrem Nutzungsszenario können Sie beispielsweise jedem Benutzer 10 GB in seinem Home-Verzeichnis, 2 TB im Verzeichnis / data auf dem externen Speicher-Array und einen großen gemeinsamen Scratch-Bereich einrichten, in dem jeder Datasets zu groß für sein Home-Verzeichnis ablegen kann und wo die Politik "voll ist voll" wird, aber wenn das passiert, bricht auch nichts.

  • Bereitstellung dedizierte IO-Pfade. Sie verfügen möglicherweise über eine Kombination aus SSDs und rotierenden Festplatten und können diese unterschiedlich einsetzen. Nicht so sehr ein Problem bei einem Allzweck-Server, sondern bei Datenbank-Setups allgemein üblich ist es, auch bestimmte Spindeln (Platten) verschiedenen Zwecken zuzuordnen, um IO-Konflikte zu verhindern, z. separater Datenträger für die Transaktionsprotokolle, separate Datenträger für tatsächliche Datenbankdaten und separate Datenträger für temporären Speicherbereich. .

  • Stiefel Möglicherweise benötigen Sie ein separates Gerät /boot Trennwand. Historisch um BIOS-Probleme mit dem Booten über das 1024 Zylinderlimit hinaus zu adressieren, heutzutage häufiger die Unterstützung verschlüsselter Volumes, Unterstützung bestimmter RAID-Controller, HBAs, die kein Booten von SAN unterstützen oder Dateisysteme, die nicht sofort vom Installer unterstützt werden.

  • Abstimmung Möglicherweise benötigen Sie verschiedene Tuning-Optionen oder sogar komplett andere Dateisysteme.

Wenn Sie harte Partitionen verwenden, müssen Sie es mehr oder weniger zum Zeitpunkt der Installation in Ordnung bringen, und dann ist eine einzelne große Partition nicht die schlechteste, aber es kommt mit einigen der obigen Einschränkungen.

Normalerweise empfehle ich, das Hauptvolume als Partition zu partitionieren einzelnes großes physisches Volume Linux LVM und dann logische Volumes erstellen das passt zu Ihren aktuellen Bedürfnissen und für den Rest Ihres Speicherplatzes, lasse nicht zugewiesen, bis benötigt.

Sie können diese Volumes und ihre Dateisysteme nach Bedarf erweitern (was eine triviale Operation ist, die auf einem Live-System durchgeführt werden kann), oder auch zusätzliche erstellen.

Das Schrumpfen von LVM-Volumes ist trivial, aber oft Das Schrumpfen der Dateisysteme auf ihnen wird nicht sehr gut unterstützt und sollte wahrscheinlich vermieden werden.


103
2017-09-18 09:49



In Bezug auf die Performance-Sache, ich denke, es ist auch Wert darauf hinzuweisen, dass im Falle einer Dateisystem-Datei eine schnelle Antwort erforderlich ist, und "df" wird nützliche Informationen viel schneller zurückgeben als "du -s $ DIRNAME" - symcbean
Ich bin mir nicht sicher, ob ich damit einverstanden bin. "bis ... RH7 ... kein unterstützter Upgrade-Pfad". Ich habe seit einiger Zeit unterstützte Upgrades gemacht und definitiv Systeme RH4-> 5 aufgerüstet nur RH5-> RH6, das meines Wissens einen solchen Weg fehlte - und ich habe das Gefühl, dass RH von ihren Nutzern wegen dieses Mangels umfassend verprügelt wurde. +1 für den Rest einer ausgezeichneten Antwort. - MadHatter
Worauf beziehen Sie sich mit "Bis zur Veröffentlichung von RHEL 7 gab es keinen unterstützten Upgrade-Pfad"? Unterstützt RHEL Upgrades zwischen den Hauptversionen von RHEL 7 und Forward? - Markus Hallmann
Upgrades haben funktioniert, aber laut roter Hut Die allgemeine Politik ist immer noch: Red Hat unterstützt keine direkten Upgrades zwischen den Hauptversionen von Red Hat Enterprise Linux.  und ein wenig Nuance weiter unten Red Hat unterstützt derzeit nur Upgrades von Red Hat Enterprise Linux 6 auf Red Hat Enterprise Linux 7 für spezifische / gezielte Anwendungsfälle und Hier ist das Handbuch überprüfen - HBruijn


Das Konzept der Verwendung mehrerer Partitionen besteht darin, dass ein vollständiger Fehler am falschen Ort nicht dazu führt, dass das gesamte System unerwartet arbeitet.

Betrachten Sie einen Prozess auf der Maschine, der eine Protokolldatei ziemlich schnell füllt, bis kein freier Speicherplatz mehr verfügbar ist. Auf einer Einzelpartitionsmaschine könnte dies dann zum Beispiel verhindern, dass das System neue Daten nach / tmp schreibt. Wenn es einen anderen Prozess gibt, der nach / tmp schreiben möchte, wird er wahrscheinlich mit einem Fehler beendet, was zu unerwartetem Verhalten führt.

Dies kann verhindert werden, wenn Sie verschiedene Partitionen für Orte verwenden, an die normalerweise Benutzer oder Prozesse schreiben (/ home, / var, / tmp).

Ich würde empfehlen, dass Sie Ihren alten Server überprüfen, welche Ordner dazu neigen, groß zu werden. Sie können das in der Befehlszeile mit tun

du -h -d 1 / 2> /dev/null

Sie werden sehen, wo die meisten Daten angesammelt werden, und Ihr nächstes System entsprechend gestalten. Die Option "-d 1" begrenzt die Ausgabe auf nur eine Ebene der Ordnertiefe und macht sie lesbarer.


17
2017-09-18 08:38





Das Hauptproblem mit einer einzelnen großen Partition ist das Füllen des Dateisystems, es ist möglich, dass keine Anmeldung mehr möglich ist.

Der Benutzer root hat seinen Home-Ordner (/root) außerhalb /home deswegen. Wenn das Dateisystem unter bestimmten Umständen voll ist, kann sich auch root nicht einloggen und das System nicht reparieren.

Aus diesem Grund erstellen Sie normalerweise separate Befestigungspunkte für /var, /tmp und /home sich mindestens als root anmelden zu können, um das System zu reparieren, wenn eine der anderen Partitionen voll ist.


12
2017-09-18 08:23



Auf einigen Dateisystemen (ext3 f.e.) können Sie ein wenig reservierten Platz für den root-Benutzer haben, um dieses Verhalten zu verhindern. Sie müssten Quoten verwenden, um das zu verhindern, dasselbe für / tmp, das oft vergessen wird. - Dennis Nolte
@DennisNolte habe ich vergessen /tmp. Danke, ich füge das zu meiner Antwort hinzu. - Uwe Plonus
@DennisNolte der reservierte Speicherplatz wird helfen, aber ich denke, dass die Wartung schwieriger als die Verwendung verschiedener Partitionen ist, da Sie Kontingente richtig einrichten müssen. - Uwe Plonus
Ich denke einen wichtigeren Grund dafür /root draußen sein /home ist das bei einigen Installationen /home wird auf einem Netzlaufwerk sein. Im Falle eines Problems beim Mounten über das Netzwerk bleiben die Dateien von root weiterhin zugänglich. (Dies kann verglichen werden mit, wie es normalerweise einen Texteditor gibt /bin, im Fall /usr wird nicht steigen.) Ich vermute, das ist heutzutage ein üblicheres Szenario als in der Praxis /home den ganzen Weg füllen. - Eliah Kagan


IMHO, mit einer Partition als / ist durchaus sinnvoll.

Sie können jedoch lvm (logischer Datenträger-Manager) verwenden. Verwenden Sie alle Festplatten als lvm-Gruppe, aber erstellen Sie kleine logische Festplatten für /, / home, / usr und was immer Ihr Systemadministrator bevorzugt. Stellen Sie dann etwas Überwachung auf, dass Sie wissen, wenn Ihr System beginnt, voll zu werden, und erweitern Sie die Festplatten, die Sie benötigen. lvresize und resize2fs sind Online-Tools und Sie können Erweiterungen durchführen, ohne den Server neu zu starten. Allerdings können Sie die Anzahl der Festplatten nicht reduzieren, daher müssen Sie relativ klein anfangen und dort erhöhen, wo Sie Bedarf sehen.


10
2017-09-18 08:22





Es gibt minimale Probleme mit dem Linux-Setup für große Einzelpartitionen, aber es hat große Vorteile.

Das Ändern eines Partitionslayouts ist ein bisschen hart und riskant, was oft ohne lange Ausfallzeiten nicht möglich ist.

Sein einziger Vorteil ist, dass Sie einen gewissen Schutz gegen Festplattenprobleme haben. Aber Sie werden diese Probleme finden viel häufig. Stellen Sie sich die Situation vor, wenn eine Ihrer Partitionen voll ist, und Sie können den Speicherplatz auf den anderen Partitionen nicht verwenden, auch wenn sie fast leer sind!

Einige professionelle Systemadministratoren haben eine völlig andere Meinung dazu. Sie sagen, dass mehrere Partitionen Ihr System zuverlässiger machen können und Sie vor der Partitionierung wissen müssen, wie groß Ihre Partitionen sein werden. Meiner Meinung nach kann das einfach nicht gesagt werden, es ist ein schrecklicher Nachteil für die Flexibilität des Systems, und ihre wahre Motivation ist, dass sie einfach sind Ich mag es, mit den Partition Maps zu spielen.

Es gibt ein einfaches System namens lvmDies ermöglicht das "on-the-fly" Verschieben / Ändern der Größe von "Partitionen" (in seiner Terminologie, Volumes). Aber auf einem einzigen lokalen Abteilungsserver wird IMHO normalerweise nicht benötigt.


9
2017-09-18 08:43



Welche Art von masochistischen Admin Likes mit Partitionskarten spielen ??? Der spaßige Teil baut den Kernel, kann ich einen bekommen Amen??? - bishop
Amen! Nun zu dem Argument, dass Admins gerne mit Partitionen spielen, möchte ich dem entgegensetzen, dass Linux wahrscheinlich 100 verschiedene Dateisystemtypen hat und abhängig von den Verwendungsmustern die Auswahl des richtigen filre Systems für eine bestimmte Aufgabe bedeuten kann der Unterschied zwischen einem optimalen System und einem nicht-funktionalen System. Und vielleicht brauchen Sie nur dieses Dateisystem in ein paar Ordnern. Dort. - Lennart Rolland


Es gibt zwei Hauptgründe für die Partitionierung:

  1. Um statische Daten von nicht statischen Daten fernzuhalten
  2. Öffentliche Daten von privaten Daten fernhalten

Der erste Grund ist der offensichtlichste - Sie müssen Bereiche isolieren, die mit Dateien gefüllt werden, die nicht mit Dateien gefüllt sind, und Sie sollten insbesondere / schützen, um ein nicht mehr startbares System zu vermeiden. Im Verzeichnis / var beispielsweise werden normalerweise Protokolldateien gespeichert (var steht für "variable") und deshalb wird / var auf einer separaten Partition von / bereitgestellt.

Der zweite oben genannte Grund ist weniger zitiert (ich habe ihn vor etwa 15 Jahren zum letzten Mal in einem Kurs von Veritas Volume Manager gehört) und ist nur für Systeme relevant, in denen sich viele Leute anmelden und arbeiten.

Es gibt eine Art Kunst effektiv zu parieren, und das ist vielleicht der Grund, warum es Sys Admins gibt, die es ein bisschen zu weit treiben (IMO). Sie müssen nicht nur das Dateisystem wissen, sondern auch den Verwendungszweck. Ich persönlich denke, dass es ein eher altmodischer Ansatz ist, der für die Art und Weise, wie Server heute verwendet werden, immer weniger relevant wird.

Als Softwareentwickler habe ich es besonders satt, dass die Ops-Abteilung virtuelle Maschinen mit gedankenlosen Partitionierungsschemata erstellt, die die Größe von / tmp, / home, / var und / unabhängig vom verfügbaren Festplattenspeicher stark einschränken, aber dann nicht Stellen Sie keine offensichtlichen Optionen wie / usr oder / opt separat bereit. Diese Maschinen werden normalerweise alles, was von dem angeforderten Speicherplatz übrig ist, in ein "/ stuff" Volume schreiben, das unvermeidbar am Ende installiert und sympatriziert wird, aber das ist kaum ein Trost. Das Endergebnis ist, dass wir oft mehr Zeit damit verbringen, Dateien herumzuwechseln und Warn-E-Mails zu verschicken, als wenn wir wirklich arbeiten.

Es gibt nichts an sich "Schlechtes" an einer einzelnen Partition. Auf jedem System sollten Sie Ihre Festplattennutzung proaktiv überwachen und vernünftige Strategien zur Verwaltung verwenden (z. B. Protokollrotation, Quoten für Home-Verzeichnisse). Die einzige wirkliche Frage ist: Wie viele separate Dateisysteme möchten Sie sich kümmern?

Ich würde also sagen: Wenn Sie nicht 100% ig sicher sind, dass Sie das System effektiv für Ihren speziellen Anwendungsfall partitionieren können, partitionieren Sie es nicht.


3
2017-09-18 09:41



Genau. Ok, vielleicht sollte die öffentlich-private Datentrennung durch die Berechtigungen im Dateisystem und in Ihren Diensten erfolgen. - peterh


IMHO, es liegt ganz bei Ihnen. Betrachten Sie zuerst ein paar Dinge, obwohl es ganz etwas relativ ist.

  • Wird dieses System häufig verabreicht?
  • Wird dieses System von einem oder mehreren Benutzern verwendet?
  • Wird dieses System als Desktop oder Server oder beides dienen?

Da man (fast) jedes Verzeichnis als Mountpoint betrachten kann, sollte man auch überlegen, was etwas wachsende Daten enthält und was wachsende Daten enthält.

Sie wären überrascht, wie wenig ein Linux-System (etwas wachsende Daten) benötigt und wie viel von wachsenden Daten konsumiert wird (normalerweise / var / opt / home / srv)

Es hängt auch davon ab, wie Sie die Verwendung für dieses System definieren, die die Partitionierungsanforderungen umreißt. Die Verwendung für LVM enthalten.

Ein typisches Desktop-System würde etwa 20 GB für die Installation einer großen Menge an Software benötigen, da dann der gesamte Rest, der einem dedizierten / home zugewiesen wurde, gut funktioniert. LVM verursacht einen geringen Overhead auf Ihrem System und ist in diesem speziellen Fall nicht von so großem Vorteil. Obwohl die Meinungen abweichen könnten.

Auf einem Server ist es weniger wahrscheinlich, dass installierte Software so dynamisch ist wie bei einem Desktop-System. Es ist auch klüger, tatsächliche Mountpoints für typische Dateisystemkomponenten wie / tmp / var / usr / home / opt / srv zu haben. Die Verwendung von LVM wird hier empfohlen, um nicht zwingend zu sein.

Dies bietet eine große Modularität Ihres Systems, es erlaubt auch dumme Dinge wie das Klonen dieser Partition in eine VM zum Beispiel. Oder Erstellen eines Backups auf Blockebene mit dd.

Basierend auf etwas Erfahrung, hier sind ein paar Notizen. Berücksichtigen Sie auch, dass mehrere Einhängepunkte eine bessere Kontrolle ermöglichen. Wenn Sie einem Einhängepunkt ein schnelles oder langsames Festplattengerät zuweisen, kann dies zu einer großen Differenz führen und die Kosteneffizienz erheblich steigern.

Bergspitze /

  • 1 GB (wenn separate Mountpoints für / var / usr / opt / home / tmp verwendet werden)
  • +10 oder sogar +20 GB bei Verwendung als Desktop-System mit einem separaten / home

bei Verwendung von Mountpoint / Home

  • Weisen Sie allen freien Speicherplatz zu, wenn Sie ihn verwenden, / home ne

bei Verwendung von Mountpoint / opt

Wenn Sie Mountpoint / usr verwenden

  • Das ist schwierig und hängt stark von der installierten Software ab

bei Verwendung von Mountpoint / Var

  • Das ist schwierig und hängt stark von der installierten Software ab
  • zum Beispiel schreiben Datenbanken ihre Daten hier auf Debian-basierten Systemen, wenn nicht alle Linux
  • ein separates / var / tmp zu haben ist nicht unangemessen

Wenn Sie Mountpoint / tmp verwenden

  • betrachte tmpfs existiert und reserviert / tmp dem RAM
  • Beachten Sie, dass einige Anwendungen hier viele Daten schreiben können

2
2017-09-18 14:18





Ich muss vor allem fragen, warum Sie diese Frage hier überhaupt stellen, als Biologe, der sich mit einem scheinbar kompetenten Systemadministrator über die Feinheiten der Festplattenpartitionierung streitet! (Nichts für ungut, nur wirklich wundern, warum Sie Ihrem Systemadministrator nicht vertrauen).

Also, ein paar Beobachtungen:

  • 1,3 TB ist keine große Festplatte mehr. 2 TB ist heutzutage eine mehr oder weniger Standard-SATA-Laufwerksgröße in der Desktop-Welt.

  • Eine Installation von Linux Distro wird wahrscheinlich nicht mehr als 100 GB erfordern. Sicherlich sollte die Größe für / (root) und (swap) leicht als oberer begrenzter Wert durch großzügige Überdimensionierung (für root) oder durch Systemkonfigurationsrichtlinien (swap) bestimmt werden.

  • Der Mount-Punkt für / home sollte auf etwas von Ihrem 40 TB RAID-Server zeigen. Diese Daten, die Home-Verzeichnisse der Benutzer, müssen sich nirgendwo auf diesem Root-Gerät befinden. Wenn Sie sie auf den RAID-Server setzen, erhalten Sie wahrscheinlich einen besseren Schutz. Und es ist wahrscheinlich eine leicht erweiterbare NAS-Einrichtung, während das kleine RAID, das in die Server-Box eingebaut ist, dies wahrscheinlich nicht ist.

  • Sie sollten Ihre spezielle Software wahrscheinlich in eine separate Partition (Einhängepunkt für / usr / local / bin usw.) legen, damit Sie diese bei Betriebssystemupdates und Root-Partitionswischen beibehalten können. Andernfalls besteht die Möglichkeit, dass Sie Ihre "speziellen" Software-Apps nach einem Betriebssystem-Upgrade neu installieren müssen / reparieren / was auch immer.

  • Wenn Sie sich um die Verwaltung Ihres Systems kümmern möchten, würde ich eine andere Frage stellen: Was ist der Notfallwiederherstellungsprozess, nachdem das Gebäude in Brand geraten ist und die Server und RAID-Boxen zerstört sind? Es sei denn, die Daten, die Ihnen wichtig sind, bleiben vollständig in Ihrem Kopf. Dies ist eine Frage, die jeder Benutzer an seine IT / Systemadministratoren richten sollte. Die Strategie sollte Fragen wie "Wie replizieren wir die Hardware, die wir brauchen" und "Wie lange wird es dauern, bis wir wieder in Betrieb sein können" beinhalten. Einige Diskussion über Ihre Server virtualisieren könnten Probleme zu beheben, um Hardware-Abhängigkeiten helfen und Dinge immer wieder und läuft, ohne dass Sie das Betriebssystem neu zu konfigurieren (da es so konfiguriert werden, könnte in einer „weichen“ Geräteumgebung ausführen, die auch nicht ändern, wenn die darunterliegende Hardware ist völlig anders)

  • In ähnlicher Weise möchten Sie vielleicht fragen, wie die Strategie zum Schutz von Benutzerdaten vor Verlust von Programm- und Benutzerfehlerdaten aussieht. Wenn Sie eine leere Datei über dem wirklich tollen Entwurf Ihrer Forschungsarbeit speichern oder wenn Sie einen falschen Befehl eingeben (z. B. rm -rf *), wird der Datenverlust genauso sicher sein wie ein Erdbeben, Feuer oder andere physische Schäden. Die Lösungen für die Wiederherstellung einzelner Dateien unterscheiden sich ein wenig von denen, die für die Wiederherstellung im Katastrophenfall am nützlichsten sind.

  • -

2
2017-09-23 13:10





Dies ermöglicht es, das Betriebssystem unabhängig von den Benutzerdaten zu sichern, wiederherzustellen oder neu zu installieren. Das gibt Ihnen Freiheit, Unabhängigkeit und Sicherheit.

  1. Es ist viel einfacher, auf eine andere Linux-Distribution zu migrieren, wobei die absolute Mehrheit der Benutzerdaten erhalten bleibt.

  2. Buggy-Updates können leicht rückgängig gemacht werden, indem das Backup der Betriebssystempartition angewendet wird (Dual-Boot ist erforderlich). Dieses Backup kann sogar ziemlich alt sein - Sie können es anwenden und später auf die wissentlich stabile Version aktualisieren.

  3. Es ist einfach, zu der vorherigen Version des Betriebssystems zurückzukehren, wenn Sie das kürzlich angewendete "Haupt-Upgrade" nicht mögen (Dual-Boot ist erforderlich).

Für das größte Potenzial dieses Ansatzes sollten Sie auch Dual-Boot konfigurieren (kann auch CentOS / CentOS sein), so dass Sie eine Betriebssystempartition überschreiben können, während Sie das Betriebssystem von einem anderen Betriebssystem ausführen. Sicherlich müssen Sie die Systempartition mindestens alle paar Monate sichern.


2
2017-09-18 11:13



Und warum -1? Würden Sie warten, ohne Wireless für die Fehlerbehebung als professioneller Ansatz? Wurde in drei Wochen gepatcht, BTW. - h22
Ich weiß es nicht, aber kompensiert. Wenn Sie etwas Ähnliches sehen, tun Sie das auch. - peterh