MX Linux auf Ventoystick, Browser installieren

[Tanne]

Hallo,

ich wollte MX Linux auf einem Ventoystick ausprobieren (mit Persistenz) und da auch verschiedene Browser ausprobieren (es ist MX-23.3). Hab da aber verschiedene Probleme und hoffe, ihr könnt mir helfen.

1. Zunächst mal das Problem Persistenz. Da kommt beim Hochfahren eine Meldung dass root- und home- persistence nachgefragt ("requested") wurde, aber kein rootfs und homefs file gefunden wurde. Man kann sie jeweils in Defaultgrößen anlegen, das ist 4 bzw. 2,34 GiB. Wofür sind die? (von anderen Distros, die ich mit Ventoy ausprobiert habe, kenne ich das nicht). Werden die dann innerhalb des Ventoy-Persistenzfiles angelegt? Dies ist bei mir 3 GiB groß. Was für Größen wären da empfehlenswert? Ich brauche es nur für den/die Browser, was anderes will ich damit nicht machen.

2. Dann bin ich irritiert, wenn ich nach firefox-esr suche (via sudo apt search, nach sudo apt update), wird Version 115 angezeigt, nicht 128 (am 9.7.24 ist Version 128 rausgekommen). Das iso ist von vorher, aber bekommt man bei apt update bei Browsern nicht die neue Version? Oder muss ich da nur einfach noch Geduld haben?

3. Außerdem wollte ich Brave und Librewolf ausprobieren. Welches muss ich für Librewolf nehmen? Auf der Librewolf-Seite steht eine Anleitung für debian-based Distributionen, konkret steht dabei aber

We only build LibreWolf for Debian 11/12, Ubuntu 20/21/22 and Mint 20.2/20.3/21. If you don't use one of those distros, the above commands will install the Ubuntu 20 build for you which may or may not work.

Geht das?
Neben "debian-based" gibt es noch ein paar andere Distributionen aufgezählt, und die Rubrik "Other Linux", für letzteres gibts Flatpak und AppImage, aber das dürfte mit meinem Platz schwer werden (3GiB).

4. Und bei Brave, kann ich da der Anleitung für Debian für Release Channel Installation folgen? (sieht aus als wäre das ein deb-File)

Ich hab noch nicht viel Erfahrung.

Danke sehr!

 

[BFF]

Hast Du denn das (die Moeglichkeit der Persistenz) auch richtig eingerichtet?

https://www.ventoy.net/en/plugin_persistence.html

Da steht eigentlich alles Noetige dafuer.

 

[Tanne]

Du meinst MX-Persist als Label? Ja, hab ich gesetzt. Und das json-File erstellt (ich denke, ich muss aber noch ein Typo drin haben, hab ich noch nicht gecheckt, weil ich 2 unterschiedliche Persistenzfiles für verschiedene Zwecke haben wollte, das 3 GiB-File hat er beim Starten nicht als Möglichkeit angezeigt, das 10 GiB-File dagegen schon, bei letzterem kam dann die Meldung) Ich hab das analog zu den bisherigen Ventoy-Stick + isos von anderen Distributionen gemacht. Diese Abfrage bzgl. rootfs und homefs scheint spezifisch für MX Linux zu sein, jedenfalls hatte ich das wie gesagt noch nicht und auf der ventoy-Seite steht meines Wissens auch nichts dazu.

 

[Tanne]

Ist kein Typo.

 

[entropie88]

2. Dann bin ich irritiert, wenn ich nach firefox-esr suche (via sudo apt search, nach sudo apt update), wird Version 115 angezeigt, nicht 128 (am 9.7.24 ist Version 128 rausgekommen). Das iso ist von vorher, aber bekommt man bei apt update bei Browsern nicht die neue Version? Oder muss ich da nur einfach noch Geduld haben?

https://www.mozilla.org/en-US/firefox/128.0esr/releasenotes/
Ist der .0 Release ab .2 wechseln die Distributionen im Normalfall. Der 115 wird für die 2 Releases weiter gepflegt.

 

[oicfar]

Optional kannst du es auch im Browser ausprobieren. Ob du das alles da auch machen kannst, kann ich nicht sagen.

 

[Garmor]

Außerdem wollte ich Brave und Librewolf ausprobieren.

Die werden beide im mitgelieferten Tool MX-Paketinstallation angeboten.

 

[Tanne]

@Garmor Prima, das hat (im 2. Anlauf) funktioniert, beim ersten Mal kam eine Fehlermeldung, dass irgendein Paket nicht gefunden wurde, funktioniert hat es dann trotzdem.
Das ist ja toll, was da drin ist in dem Tool
Bin begeistert. Und Librewolf scheint für meinen aktuellen Zweck zu funktionieren.

Ich hab es nur zum Testen ohne Persistenz installiert. Die P. hat weiterhin nicht geklappt. Vielleicht hat ja noch jemand eine Idee. Dass es startet, ist auch schon ein Erfolg, denn vor ein paar Monaten kam da auch eine Fehlermeldung, man solle ich an irgendeinen Menschen bei MX Linux wenden. Hab dann aber noch rausgefunden, dass man dafür eine neue Version von Ventoy braucht.
Wär schon schön, wenn ich Persistenz hinkriege, denn wenn es taugt, will ich lieber das installieren als Ubuntu.

 

[Tanne]

Ich hab rausgefunden, wenn ich die eine Persistenzdatei umbenenne, so dass sie von Ventoy nicht gefunden wird beim booten, wird dafür die andere angezeigt. Ist zwar ein bisschen nervig und dass es so gedacht war, glaub ich auch nicht, aber es ist erstmal ein funktionierender Workaround.
Und wie das mit den Persistenzfiles ist, wird erklärt, wenn der MX Linux-Bildschirm erscheint und man dann (bevor man MX startet) F1 drückt. Es scheint so, als müsste man sich vorab festlegen, wieviel vom vorgesehenen Platz für Persistenz jeweils für root und für home verwendet werden soll. Und man soll auch nicht soviele Änderungen durchführen können, dann muss es "remastered" werden, was immer das heißt.
MX Linux selbst ist auf jeden Fall mal interessant.

 

[Garmor]

Ja, MX arbeitet viel mit Bootoptionen und hat von AntiX viele Tools geerbt. Mit dem Remastern kann man unter anderem auch die initiale Ramdisk neu schreiben, um beispielsweise neuere Kernel zu benutzen, was in den meisten persistenten Systemen nicht möglich ist (Tails kann sich z.B. auch komplett selbst updaten). Daher ist die erste Variante bei den Peristenzoptionen wohl auch, dass / im RAM abgelegt wird, damit Updates erst mittels Remaster ohne Umwege auf den Stick geschrieben werden können.

Bei meinen letzten Versuchen hat das aber nur richtig funktioniert, wenn man den Stick von Anfang an aus einem laufenden MX heraus mit Bordmitteln geschrieben hatte.

 

[7vor10]

Ein Live-System mit MX Linux inklusive Persistenz (damals in Version 21 Wildflower) habe ich mir mal vor rund drei Jahren gebastelt. MX bietet für meinen Geschmack die beste und komfortabelste Methodik, Live-Systeme mit und ohne Persistenz zu generieren. Wobei der Nutzer überdies die Live-Version an seine Wünsche anpassen kann; also Programme und Daten nach eigenen Geschmack dauerhaft hinzufügen darf. Wenn zusätzlich auch noch die Persistenz-Option genutzt wird, hat man zudem die Wahl, bei jedem Neustart entweder in den aktuellen Zustand (mit Persistenz) oder in das usprüngliche (angepasste) Live-System (ohne Persistenz) zu booten.

Man muß sich für all das, aber erstmal in die Materie einlesen (ich habe einige Zeit gebraucht, um alles zu kapieren und experimentell in einer VM nachzustellen).

MX bietet zu diesem Thema umfangreiche Infos.

Daher an dieser Stelle nur noch ein paar Fingerzeige:

• die Methoden für Persistenz sind nicht Linux-universell, sondern distributionsbezogen. Man sollte daher nicht versuchen, zu 'mixen'. Eine ISO mit Persistenz baut man also immer innerhalb der zugehörigen Distribution und befolgt die Regeln des dafür vorgesehenen Generator-Tools
• dasselbe gilt für die Startmethoden des erzeugten Live-Systems
• Tipp 1: erstmal nur ein System ohne explizites Home-Objekt generieren (also nur mit RootFS-Image (Home somit inklusive) in einer Größe von ca. 40 GB bis maximal verfügbaren Speicherplatz)
• Tipp 2: im Boot-Menü von MX im Modus 'p_static_root' starten (bootet mit Persistenz)

Das angepasstes MX-Live-System hatte ich mir auf einem vergleichsweise schnellen USB-Stick geschrieben und auch regelmäßig aktualisiert. Allerdings mußte ich feststellen, dass solche Aktionen zu zeitaufwendig waren. Ich habe den Stick daher nach einiger Zeit wieder aufgegeben und beschränke mich seitdem auf meine MX-Installation auf einer USB3-HDD (wesentlich performter).

Ob man MX auch als persistentes Live-System von einem Ventoy-Datenträger aus betreiben kann, habe ich nie getestet.

 

[BFF]

Ob man MX auch als persistentes Live-System von einem Ventoy-Datenträger aus betreiben kann, habe ich nie getestet.

Kann man.
Deswegen hatte ich ja ganz weit oben gefragt ob Du das fuer das Ventoy auch richtig gemacht hast.

 

[7vor10]

Deswegen hatte ich ja ganz weit oben gefragt ob Du das fuer das Ventoy auch richtig gemacht hast.

Falscher Adressat
Ich bin nicht der Threadstarter. Das ist @Tanne.

 

[Tanne]

Gerade erst gesehen, dass ich meinen Beitrag zwar geschrieben, aber noch nicht abgeschickt hatte.

MX bietet für meinen Geschmack die beste und komfortabelste Methodik, Live-Systeme mit und ohne Persistenz zu generieren.

Ich habe an Ventoy nichts auszusetzen. Nur dass man da nicht jede Distribution mit Persistenz hinkriegt (oder es ist komplizierter - Debian), manche krieg ich gar nicht zum Starten (OpenSUsE Leap). Ubuntu und Mint funktionierten tadellos. Und jetzt mit MX halt weiß ich noch nicht so genau...

Wobei der Nutzer überdies die Live-Version an seine Wünsche anpassen kann; also Programme und Daten nach eigenen Geschmack dauerhaft hinzufügen darf.

Das geht mit Ventoy mit Persistenz auch.

usprüngliche (angepasste) Live-System (ohne Persistenz)

Ah, das ist offenbar nochmal was anderes: Man kann die Liveversion abändern, aber bei der konkreten Nutzung ist es wie ein Livesystem, aber eben incl. der ursprünglichen Abänderung?

Das wäre für mich ein weiterer Anwendungsfall: Ich mache Online-Banking nämlich immer per Live-USB-Stick, aber hätte dafür gerne einen anderen Browser. Da müsste ich schauen, wie es da mit Sicherheitsaktualisierungen bei MX läuft (bisher hab ich für den Zweck alle paar Monate ein anderes iso genommen, was grad neu rauskam, so gesehen ein kleines bisschen distrohopping)

Daher an dieser Stelle nur noch ein paar Fingerzeige

Das ist die Frage, ob das nur für Deine Methode gilt oder auch für ventoy.

Kann man.
Deswegen hatte ich ja ganz weit oben gefragt ob Du das fuer das Ventoy auch richtig gemacht hast.

Ich denke, oder siehst Du da Probleme? Bzw. hast Du eine Idee, wieso je nach Benennung des Persistenzfiles mal das eine, mal das andere angezeigt wird, aber nicht beide?

@Garmor: Ich verstehe Deine Antwort noch nicht so. Ich muss erstmal rausfinden, was es mit Remastern so grundsätzlich auf sich hat, was der Begriff bedeutet.

 

[7vor10]

Das ist die Frage, ob das nur für Deine Methode gilt oder auch für ventoy.

Von den 4 Punkten, die ich unter dem Stichwort 'Fingerzeige' abgelegt hatte, sind die ersten beiden nur allgemeine Aussagen. Die letzten beiden (Tipps) hingegegen beziehen sich ausschließlich auf die Methodik, wie sie MX handhabt.

Ein Live-Medium (mit Persistenzoption) setzt sich grob gesagt aus nachfolgend genannten Teilen zusammen:

• linuxfs: Image, welches das gepackte Live-System enthält
• rootfs: Image, das die persistenten Daten des Wurzelverzeichnis ('/') aufnimmt (inklusive '/home', wenn kein extra homefs kreiert wurde)
• homefs: separates Image für die persistenten Daten des '/home'-Pfads (optional, ansonsten vereint mit rootfs)
• Platz für unabhängige Partition (d.h. diese Partition kann zusätzlich noch für universellen Datenaustausch mit anderen (Linux-)OSen genutzt werden

Das Image linuxfs kann durch das MX-eigene Bearbeitungs-Tool nachträglich mit eigenen Programmen und Daten ergänzt werden. Du kannst auf diese Weise sozusagen dein eigenes ISO-Image von MX erstellen (Remaster). Diese Modifikationen stehen Dir also unabhängig von Persistenz immer zur Verfügung. Das linuxfs ist also das eigentliche Live-Medium, und Live-Systeme sind im Betrieb generell 'Read Only'.

Soll aber ein Datenträger mit einem Live-System ähnlich wie eine Installation funktionieren, bedarf es der Ergänzung mit persistenten Speicher (rootfs und optional homefs). Nur so kann man beispielsweise das Live-Medium mit Sicherheits-Updates aktuell halten oder neue Programme und Dateien hinzufügen oder ändern.

Im Prinzip funktioniert das Ganze ähnlich wie eine VM mit Snapshots. Wird nämlich ein Snapshot gesetzt, wird alles, was im Moment schon vorhanden war, auf 'Read only' gesetzt und die nachfolgenden Schreibzugriffe landen im Snapshot-Objekt. Nur dass Virtualisierungsprogramme beliebig viele Snapshot-Unterebenen unterhalten dürfen, während ein Live-Datenträger nur eine einzige Ebene bereithält. Du kannst also nur zwischen dem aktuellen Zustand des Mediums und dem ursprünglichen wählen (das ISO 'ab Werk' oder so wie Du es angepasst hattest). Du kannst aber nicht auf irgendeinen zwischenzeitlichen Zustand zurücksetzen.

Natürlich erscheinen diese Image-Bestandteile im laufenden Betrieb des Live-Systems als eine Einheit. Im persistenten Modus sehen Nutzer und laufende Programme nur den aktuellen Zustand eines Speicherblocks. Wenn Du beispielsweise im persistenten Modus ein Programm löscht, das im Live-System integriert war, ist es scheinbar endgültig weg. Wenn Du aber das Live-System ohne Persistenz startest, ist es wieder da. Weil es nämlich im unveränderbaren Teil (linuxfs) residiert. Um es auch dort zu löschen, mußte Du das Bearbeitungs-Tool bemühen.

Logischerweise geht diese Bearbeitung nur in einer anderen Instanz. Zum Beispiel kann man ein in einer VM installiertes MX nutzen, um eine modifizierte Fassung des Live-Mediums zu erstellen. So habe es auch ich gemacht. Eine VirtualBox-VM kreiert und darin die originale MX-ISO als Installationsmedium genutzt. Die VM habe ich dann schrittweise nach meinen Wünschen angepasst (Konfiguration, zusätzliche Datenobjekte, ergänzende Programme, Sicherheitsaktualisierungen). Den erreichten Zustand der VM habe ich dann als finalen Schritt vom Bearbeitungs-Tool in einen boot-fähigen USB-Stick mit Persistenz (nur rootfs) gießen lassen. Desweiteren diente der Stick als Basis für eine Festplatteninstallation des angepassten MX. Letztere nutze ich noch heute. Nur der Stick war mir auf Dauer immer noch zu langsam.

Ich stöbere gerade in meinen Protokollnotizen von damals und habe dabei diese Passage gefunden, die ich hier mal unverändert einkopiere:
Startmechanismus der angepassten Live-Installation mit Persistenz und Aufbau des Live-Sticks:
- Start:
- Aufruf des UEFI-BIOS und Auswahl des Sticks mit Startoption 'UEFI Partition 3'
- im Grub-Menü stets folgende Optionen vor Start setzen:
- Persistenzoption = p_static_root (wenn Booten mit Persistenz, sonst nur RO-Live-Session)
- Sprache = Deutsch (optional)
- Zeit = Windows (optional)
- Aufbau (des Sticks):
- Partition 1: USB-DATA (12 GB, 7,9 GB frei)
- Partition 2: MX21_my (49 GB, 34 GB frei):
- /live/boot-dev/antiX/linuxfs (4,1 GB) :enthält das individuelle RO-(my-)Live-System (Image-Disk)
- /live/boot-dev/antiX/rootfs (43 GB, 37 GB frei) :enthält die in das Live-System gespiegelte Persistenz-Objekte (Image-Disk)
- Partition 3: Live-UEFI (51 MB, gesperrt für Benutzer)

Übrigens, man kann ein solches angepasstes Live-Medium statt auf einen Stick auch auf eine (USB3-)Disk erzeugen. Im Unterschied zu einer normalen Installation bleibt dann verdeckt auch der ursprüngliche ISO-Inhalt erhalten. Das heißt, man kann dann auch von da mit und ohne Persistenz starten. Diese Variante mit einem Live-System auf Platte habe ich allerdings nicht probiert.

 

[Tanne]

Hallo 7vor10,

vielen Dank für Deine umfassende Antwort. Da werde ich irgendwann mal rumprobieren mit einem eigenen Stick dafür (wenn ich bei MX bleibe). Aktuell hab ich aber nur den Ventoy-Stick und brauch den auch Anfang der Woche.

Aber da wurde ich ja auch nach rootfs und homefs gefragt, von daher wird man das, was Du schreibst, vermutlich auch dafür verwenden können.

rootfs: Image, das die persistenten Daten des Wurzelverzeichnis ('/') aufnimmt (inklusive '/home', wenn kein extra homefs kreiert wurde)

Heißt das dann, wenn ich bei der Frage nacht rootfs z.B. 5 GiB angebe und nichts für homefs, dann können in diesen 5 GiB sowohl installierte Programme angelegt als auch Dateien von home gespeichert werden, es würde beides persistent bleiben? Und wenn die 5 GiB aufgebraucht sind mit was auch immer, dann bleibt für alles danach (egal ob installierte Programme oder Dateien) kein Platz mehr (bzw. wird dann vermutlich ins RAM geschrieben und wenn man ausstellt, ist es wieder weg)?!

 

[7vor10]

Aber da wurde ich ja auch nach rootfs und homefs gefragt, von daher wird man das, was Du schreibst, vermutlich auch dafür verwenden können.

Du kannst das leicht überprüfen, wenn Dein per Ventoy mit Persistenz versehenenes MX-Live die unten genannten Ordnerpfade enthält (s.a. linke Spalte im Dolphin-Explorer):

• /live/boot-dev/antiX/linuxfs ;das eigentliche MX-Live als gepacktes RO-System
• /live/boot-dev/antiX/rootfs ;das Image, welches die persistenten Objekte aufnimmt (inklusive Home-Objekte, wenn kein extra homefs kreiert)

Die Images lassen sich mit einem Packprogramm öffnen. Dann sollten unter rootfs alle neuen und geänderten Objekte auffindbar sein, unabhängig davon, in welchem Modus das Live-System gestartet wurde. Wenn das Live-System mit voller Persistenz gebootet wird (p_static_root), überlagern die Objekte in rootfs die originalen Inhalte an gleicher Stelle.

Wie Du schon richtig erkannt hast, werden Schreibzugriffe in einer laufenden Sitzung zunächst in das RAM umgeleitet. Läuft die Session im persistenten Modus, werden die Schreibdaten beim Beenden in das rootfs-Image zurückgeschrieben, sodass in der nächsten Sitzung der erreichte Zustand weiterhin verfügbar ist, ganz wie bei einer normalen Installation.

Heißt das dann, wenn ich bei der Frage nacht rootfs z.B. 5 GiB angebe und nichts für homefs, dann können in diesen 5 GiB sowohl installierte Programme angelegt als auch Dateien von home gespeichert werden, es würde beides persistent bleiben?

Ja, so ist es.
Wobei allerdings 5 GB sehr knapp bemessen sein dürften. Vor allem, wenn das persistente System (wie ein installiertes) regelmäßig mit Sicherheits-Updates versorgt werden soll. Keine Ahnung, wieviel Speicher der vorgesehene Stick bietet (bzw. noch frei hat), aber 10 bis 20 GB sollten es mindestens schon sein.

Was genau passieren würde (Fehlermeldung), wenn der zugewiesene Speicherplatz für rootfs irgendwann aufgebraucht sein sollte, weiß ich auch nicht. Jedenfalls würde der Speicherplatz nicht dynamisch weiterwachsen.

Übrigens, wie ich gelesen habe, sind von etwaigen System-Updates Kernel-Upgrades ausgeschlossen. MX Linux stellt aber auch dafür ein Tool bereit, mit dem das nachträglich möglich ist. In der Zeit, wo ich den Live-Stick betrieben hatte, war freilich so etwas nie nötig gewesen (es gab also nur normale Updates).

Für den Fall, dass später einmal Zeit, Interesse oder gar Notwendigkeit bestünde, nenne ich hier mal die beiden beiden Hauptwerkzeuge, die MX selbst für diese Zwecke bietet (s.a. MX-Handbuch auf dem Image):

• MX Snapshot: erzeugt ein ISO-Abbild eines laufenden MX-Systems. Die selbstgenerierte ISO enthält alle nachträglich aufgespielten Programme, Datenobjekte, Konfigurationsanpassungen und System-Updates. Wahlweise läßt sich das ISO entpersonalisiert erstellen (also ohne Benutzerordner wie bei originalen ISOs) oder zusätzlich inklusive der aktuellen Benutzerordner (samt Passwörter und nutzerbezogene Konfigurationsanpassungen).
• USB-Live Maker: erzeugt einen startfähigen (USB-)Datenträger auf der Grundlage einer (modifizierten) MX-ISO. Es empfiehlt sich, dieses MX-eigene Tool zu verwenden anstatt universeller Kreatoren wie Rufus oder Balena Etcher. Denn der USB-Live Maker ist für MX optimiert (Persistenz, zusätzliche Datenpartition, etc.).

 

[Tanne]

Vielen lieben Dank für Deine Antwort. Du hast das gut erklärt

Das, wofür ich schnell eine Lösung brauchte, hat jetzt eh nicht funktioniert (das zu installierende Programm braucht systemd, das soll man bei MX beim booten einstellen können, aber das ist mit Stick, insbesondere Ventoy, dann vermutlich wieder alles anders. Jedenfalls hab ich nichts gefunden und um da jetzt rumtüfteln zu können, fehlt mir erstmal die Zeit. Aber dann weiß ich, wo ich nächstes Mal ansetzen muss)

Die Images lassen sich mit einem Packprogramm öffnen. Dann sollten unter rootfs alle neuen und geänderten Objekte auffindbar sein, unabhängig davon, in welchem Modus das Live-System gestartet wurde.

Ahhhh super! Das hab ich mich nämlich immer gefragt, wie das geht.

Keine Ahnung, wieviel Speicher der vorgesehene Stick bietet (bzw. noch frei hat), aber 10 bis 20 GB sollten es mindestens schon sein.

Ja, da hast Du recht. Eigentlich will ich das auch nicht solange machen, aber wie das dann so ist mit den Improvisationen, die dann viel länger herhalten müssen... Wie lange hast Du das denn gemacht mit einem persistenten Stick?

Übrigens, wie ich gelesen habe, sind von etwaigen System-Updates Kernel-Upgrades ausgeschlossen.

Irgendwann ist es wohl besser, gleich ein neues iso runterzuladen und alle Änderungen (installierte Programme usw.) dann dort nochmal durchzuführen. Dann wird das iso auch nicht immer größer... (wenn man die Kommandozeilenbefehle sammelt, geht das ganz schnell, Sachen, die man via Programm oder Oberfläche macht, natürlich nicht)

 

[7vor10]

Wie lange hast Du das denn gemacht mit einem persistenten Stick?

So ein knappes Jahr etwa.
Gedacht war er zunächst als Quelle für eine Installation von MX 21 auf Platte. Die ursprüngliche ISO aus dem Internet kam dafür nicht mehr in Frage, denn ich wollte natürlich meine individuellen Anpassungen, die ich bereits in das modifizierte Live-System integriert hatte, nicht nochmals innerhalb der Installation ein weiteres Mal vornehmen.

In zweiter Linie war der Stick als erweitertes Notfallsystem gedacht. 'Erweitert' deswegen, weil er ja jeweils auf demselben Entwicklungsstand war wie das installierte MX. Vielleicht hätte ich dieses Parallelsystem noch heute, wenn nicht der Wartungsaufwand mit der Zeit zu groß geworden wäre. System-Updates auf dem Stick dauerten nämlich rund vier bis fünfmal so lange wie auf dem installierten MX! Man muß bedenken, dass laufende Betriebssysteme während eines Updates Unmengen von kleinen bis sehr kleinen Dateien schreiben müssen, was zu einem krassen Performance-Einbruch führt.

Um das zu vermeiden, bräuchte man einen Stick aus dem Hochklassesegment. So einer bewegt sich aber preislich in Richtung 100 Euro. Für das Geld (oder weniger) bekäme man aber schon eine noch schnellere portable USB3-HDD. Hat zudem mehr Speicherplatz und ist fast genauso handlich wie ein Stick (weil ohne extra Stromkabel zu betreiben).

Natürlich stellt sich dann aber die Frage, warum man MX nicht gleich normal darauf installiert, statt als Live-System zu verankern. Der einzige Grund, der mir auf die Schnelle einfällt, ist die Anforderung für ein besonders robustes Systems. Denn angenommen, das Live-System mit Persistenz wäre irgendwann mal vermurkst, sei es durch Verschulden des Nutzers oder eines Programms oder gar einer Malware-Infiltration. Dann startet man einfach wieder ohne Persistenz und ist den Müll mit einem Schlag wieder los. (Das Persistenz-Objekt läßt sich bei Bedarf vor dem Löschen noch nach zu behaltenden Dateien filtern.) Das ist mit weniger Aufwand verbunden als die Restauration mittels Timeshift-Programmen.

irgendwann ist es wohl besser, gleich ein neues iso runterzuladen und alle Änderungen (installierte Programme usw.) dann dort nochmal durchzuführen.

Das würde aber bedeuten, die diesbezüglichen Komfortfunktionen von MX zu verschenken. Denn das möchte man ja gerade vermeiden, immer wieder von vorne anfangen zu müssen.

Übrigens gibt es neben MX Snapshot und USB-Live Maker noch ein weiteres Tool zur Modifikation von (Live-)Systemen mit MX:
- Remaster CC
Während MX Snapshot auf der Basis des laufenden Systems ein angepasstes ISO-File auf einen verfügbaren Datenträger kopiert (um als Basis eines neu aufzusetzenden Systems zu dienen), schreibt Remaster die Änderungen direkt in das Live-Image (linuxfs) der aktuellen Live-Session. Beim nächsten Boot startet das Live-System dann dauerhaft mit allen Anpassungen. Das heißt, die Änderungen, die zuvor nur im persistenten Image (rootfs) lagerten, gehören nunmehr ebenfalls zum eigentlichen Live-System (unabhängig von Persistenz). Alle nachfolgenden Modifikationen landen dann wieder im neu sich aufbauenden rootfs-Image (bei Betrieb mit Persistenz).

Ohne das vorzügliche Offline-Handbuch von MX (liegt jedem Quellmedium von MX bei) hätte ich wohl bis heute keine Ahnung von diesem mächtigen Features. Es lohnt sich also, da mal genauer reinzuschauen. Und auch die sonstigen Hilfs-Features sind sehr einsteigerfreundlich gehalten.

systemd, das soll man bei MX beim booten einstellen können, aber das ist mit Stick, insbesondere Ventoy, dann vermutlich wieder alles anders.

Ich kann das auch bei mir nachvollziehen.
Auf meinem Notebook mit UEFI hat der Grub-Bootloader von Ubuntu derzeit die höchste Priorität. Aus seiner Liste kann ich wahlweise Kubuntu, Windows 10 oder MX 21 zum Start auswählen. MX 21 hat aber auch seinen eigenen Bootloader. Um mit diesem zu starten, muß ich nach Einschalten des Rechners die F12-Taste drücken, um direkt Zugriff auf das UEFI-Boot-Menü zu bekommen. Bei Auswahl von MX startet zunächst dessen BootManager mit zusätzlichen Optionen wie Booten mit oder (standardmäßig) ohne 'Systemd'. MX Linux gehört nämlich zu den wenigen Linux-Distributionen, die es dem User überlassen, ob er das in der Linux-Welt nicht unumstrittene 'Systemd' benutzen möchte oder nicht.


Ja, falls noch Rückfragen bestehen, ich bin ab dem darauffolgenden Wochenende wieder online.

 

[Tanne]

Hallo,

Natürlich stellt sich dann aber die Frage, warum man MX nicht gleich normal darauf installiert, statt als Live-System zu verankern.

Also bei mir sind es 2 Gründe:

• für einen speziellen Anwendungsfall, wo nichts anderes auf dem System sein soll (werde mir aber noch überlegen das doch jeweils auf dem Livestick ohne Persistenz zu machen)
• zum genaueren Austesten, wie gut es mir gefällt, wo ich aber auch schaue, ob ich alle Programme draufkriege, die ich möchte. Bin da aber eigentlich optimistisch. Und auch zum Testen, wie es mit Treibern klappt (hast Du da Erfahrungen im Vergleich zu anderen Distris?) Erstmal nur einen sehr alten Drucker (später will ich mir noch einen guten Dokumentenscanner kaufen).

Ohne das vorzügliche Offline-Handbuch von MX

Ja, das ist echt super, gut erklärt, großer Pluspunkt für MX in meinen Augen.

Bei Auswahl von MX startet zunächst dessen BootManager mit zusätzlichen Optionen wie Booten mit oder (standardmäßig) ohne 'Systemd'.

Hast Du da vielleicht ein Bild, wo man diese Option findet? Ich hatte neulich im Handbuch geschaut, aber so genau stand das nicht beschrieben. Ich bin dann alle Optionen durch, die mir geboten wurden und habe aber nichts gefunden.