Linux Mint Debian Cinnamon Installation (Netto)

Caramon2 schrieb:
Wenn Windows zu sehr nevt, dann nutzt man eben die alleinige Installation und macht es platt.
Ich dachte, du stehst zu beiden Seiten und nicht wie ein einseitiger Nerd.
Von meiner Seite falsch gedacht. Nun, viel Spaß bei deiner auch immer Sache.
 
  • Gefällt mir
Reaktionen: Caramon2
Ich habe auf meiner Platte Hinweise zu Linux und Debian-Derivate + Windows und Ubuntu-Derivate gefunden, die ich vor knapp 2 Jahren geschrieben hatte: Ich habe sie etwas überarbeitet und in #73 angehängt.

Da es hier unübersichtlich geworden ist und es ursprünglich sowieso nur zeigen sollte wie schnell und einfach sich "Linux" installieren lässt (s. Video im Eröffnungsbeitrag), plane ich einen neuen Thread und sammle es erst mal dort.

Ich werde das durchnummerieren:

0 ist der Ventoy-Stick (für 1a braucht man den nicht)
1 die LMDE-Installation: 1a in VM, 1b neben Windows, 1c alleine
2 Grundkonfiguration
3 Verschönerungsbeispiele
4 Flatpak

1a und 2-4 werden die aus meinen #1 verlinkten Drive-Ordner sein, über die ich vorher aber nochmal drüber sehen will.



Ich habe dabei auch noch meine "Grundlegende Windows-Optimierungen" gefunden. Falls es jemanden interessiert:
 

Anhänge

  • Gefällt mir
Reaktionen: TPD-Andy und Tanzmusikus
Das habe ich gerade für einen Bekannten zusammengestellt:

Hier ein Vergleich der Cinnamon-Versionen:

LinuxMint 14 von 2012:
https://www.linuxmintusers.de/index.php?action=media;sa=media;in=888

LinuxMint 17.1, das 2015 mein Einstieg war:
https://www.linuxmintusers.de/index.php?action=media;sa=media;in=2037

So sieht LinuxMint 22.2 (Sept. 2025) aus:
https://www.linuxmintusers.de/index.php?action=media;sa=media;in=8855

Das ist im Vergleich dazu LMDE 6 von September 2023:
https://www.linuxmintusers.de/index.php?action=media;sa=media;in=7715

Und hier LMDE 7 von Otk. 2025:
https://www.linuxmintusers.de/index.php?action=media;sa=media;in=8903

Ich möchte damit zeigen, dass Cinnamon eine sichere Sache ist: Man muss sich, im Gegensatz zu Windows, nicht mit jeder neuen Version mehr oder weniger gravierend umgewöhnen, es wird einem nichts aufgezwungen und es wird auch nichts lang bewährtes eingeschränkt oder entfernen.

Evolution statt Revolution und die Freiheit es auch umfassend dem eigenen Bedarf anpassen zu können. - Im Eröffnungsbeitrag ist dazu mehreres verlinkt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: SirSinclair, TPD-Andy und Tanzmusikus
Das ist cool. Ab 10 Min. zeigt er z. B. wie man Webapps (u. a. Outlook) einrichtet:

Büro-Software für Linux Mint - E-Mails, Office, PDFs & Software (Teil 3⧸5)

Er zeigt das zwar mit dem regulären LinuxMint-Cinnamon, aber mit LMDE-Cinnamon funktioniert das natürlich auch.

Nachtrag:

Dort empfiehlt Jean für gegenüber LibreOffice bessere MSO-Kompatibilität das deutsche, aber nicht quelloffene FreeOffice:

https://www.freeoffice.com/de/download/

Das gibt es auch für Windows (+ Mac und Android/iOS), so dass man ausprobieren kann, ob es reicht, bzw. man ggfs. nicht vollständig kompatible Office-Dokumente schon mal anpassen kann, damit es bei einem Wechsel zu Linux keine Probleme mehr damit gibt.

Ebenfalls bzgl. einer guten MSO-Kompatibilität wird das quelloffene OnlyOffice genannt, dass sogar noch für Windows XP gepflegt wird:

https://www.onlyoffice.com/de/download-desktop.aspx
 
Zuletzt bearbeitet: (Tippfehler)
  • Gefällt mir
Reaktionen: TPD-Andy und Tanzmusikus
Üblicherweise wird empfohlen mindestens einen Monat mit dem Upgrade zu warten, um mögliche Kinderkrankheiten zu überspringen:

LMDE 7 „Gigi“ ist fertig: Linux Mint jetzt mit Debian 13 Basis

How to Upgrade LMDE 6 to LMDE 7

alternativ (etwas detaillierter):

How to Upgrade to LMDE 7 from LMDE 6: A Step-by-Step Guide

Ich habe das noch nie bei LMDE gemacht *) und werde es am WE ausprobieren.

*) als ich damit damals (da war mintupgrade noch kein GUI-Tool) LinuxMint 17.3 auf LinuxMint 18 aktualisieren wollte, wurde die Installation für mir irreparabel beschädigt, egal wie ich es versucht habe (ich hatte natürlich eine Sicherung, so dass ich wieder zurück konnte).

Nachtrag:

Die originale Anleitung von LinuxMint ist wesentlich spartanischer:

How to upgrade to LMDE 7

Enthält aber einen für mich sehr wichtigen Hinweis:
If you have other ways of rolling back the upgrade and restoring your system to the way it was before, you can skip the system snapshots requirement by disabling it in the preferences.
Ich hatte schon gedacht, ich müsste tatsächlich dieses blöde Timeshift einrichten, und einen "Snapshot" erstellen, obwohl ich von allen meinen Installationen sowieso mehrstufige Komplettsicherungen auf mehreren Datenträgern habe.

Zum Glück denkt da jemand mit.

Außerdem steht dort:
Temporary files are left behind during the upgrade. Please read 5.1.6. The temporary-files directory /tmp is now stored in a tmpfs (Titel von mir hinzugefügt) of the Debian 13 release notes for information on this issue and how to remove these files.
Ach, auch schon?

Ich mache das schon seit vielen Jahren, auch bei den LMDE-Testinstallationen.

Kurz:

Dadurch wird /tmp/ im RAM gemountet und aus dem laufenden System kommt man nicht mehr an den Inhalt (fall vorhanden) von /tmp/ auf dem Datenträger nicht mehr heran. Kann es also nicht mehr löschen.

Die beschreiben da eine umständliche Art, um dann doch noch daran zu kommen: Ich würde einfach das Livesystem booten und als Systemverwaltung den Inhalt vom /tmp/ des installierten Systems löschen. - Wichtig: Nur den Inhalt! Das Verzeichnis "tmp" muss bestehen bleiben, da das dann als Mountpunkt dient.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
Caramon2 schrieb:
How to Upgrade LMDE 6 to LMDE 7
Genau das habe ich gesucht !!
D a n k e !!!

Hab LMDE6 in der Familie als TV-PC in Betrieb ... & für mich zum Testen/Überprüfen in der VM (VirtualBox).
Nun werde ich mal das Upgrade in der VM testen (Sicherung vorher ist angelegt).
 
  • Gefällt mir
Reaktionen: Caramon2
Tanzmusikus schrieb:
Genau das habe ich gesucht !!
Ich habe oben noch was hinzufügen und das YouTube-Video (LMDE 4→5) gelöscht, da es inzwischen etwas anders abläuft.
 
Mal schauen, ob das Upgrade in der VM diesmal durchläuft ... oder wieder stehen/hängenbleibt. 😳
 
Tanzmusikus schrieb:
ob das Upgrade in der VM diesmal durchläuft
Ich hatte gerade die Idee, dass vielleicht die Gasterweiterung stört: Die generiert ja ein Kernel-Modul, wozu die Distribution und die Kernelversion bekannt sein müssen: Das für Debian 12 generierte wird also für Debian 13 und dessen viel neueren Kernel nicht mehr passen und vielleicht hakt es deswegen.

Wegen solcher Probleme nutze ich vBox schon lange nicht mehr, sondern stattdessen KVM, weil das je wie der Name schon sagt, gleich mit dabei ist und immer passt.

Da ich ein reines AMD-System habe, habe ich nicht mal dmks und die Linux-Header installiert, weil alles auf Anhieb läuft. Einschließlich 3D Hardware-Beschleunigung in der VM, wie ich im hier angehängten Video zeige: Klick

Da es für dich vermutlich nicht so einfach ist auf KVM umzusteigen, deinstalliere doch wenigstens erst mal den vBox-Kram beim VM-LMDE und versuche es dann nochmal.

Btw:

Mit KVM kann man übrigens auch richtig installierte BS (auch Windows) direkt vom Laufwerk in der VM booten. Hier habe ich sogar mein Linux, während ich es genutzt habe, sich selbst in KVM booten lassen (habe ich neulich gerade erst wieder gebraucht): Klick
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Ach du bist ein Schatz. 😊👍
Ich hab stundenlang probiert ... und in der 3. Phase hing LMDE dann immer.

Das mit KVM muss ich mir unbedingt mal anschauen. Ich kam bisher nicht dazu.
 
  • Gefällt mir
Reaktionen: Caramon2
Tanzmusikus schrieb:
Ich hab stundenlang probiert ... und in der 3. Phase hing LMDE dann immer.
Also hat es tatsächlich am vBox-Kram gelegen?

Das mit dem "Zum Glück denkt da jemand mit." war wohl etwas voreilig: Dass man eine Linux-Distribution in einer VM testet, ist ja nun nichts außergewöhnliches und dabei ist vBox ja nun sogar (im CB-Dialekt ;)) der "Klassenprimus". - Das muss man doch wohl berücksichtigen!

Ich habe LMDE eben auch schon mal auf dem aktuellen Stand gebracht, gesichert und mintupgrade ausprobiert: Das erscheint mir ziemlich dilettantisch:
  1. obwohl auf dem aktuellen Stand, wurden die komplette apt-Datenbank nochmal neu geladen: Der Traffic ist mir momentan egal, da noch 13 GiB Rest, aber das hat bei meiner Internetverbindng (Mobilfunk, momentan offenbar ziemlich ausgelastet) 2 Min. gedauert.
  2. dann musste unbedingt der os-prober installiert werden: Wieso? Das LMDE stellt nicht den Bootloader und da trotz GRUB_DISABLE_OS_PROBER=true in /etc/default/grub der os-prober ausgeführt wird (das soll er nicht: das LMDE soll nur sich selbst finden), musste ich ihn deinstallieren! - Was soll diese beschissene Bevormundung: sogar doppelt: 1. dass er immer ausgeführt wird, obwohl er es ausdrücklich nicht soll und 2. dass er installiert sein muss!
  3. also mintupgrade beenden, os-prober installieren, mintupgrade wieder starten - und schon wieder wird die komplette apt-Datenbank neu geladen: Diesmal hat es sogar 3 Min. gedauert
  4. und dann kam das beste: Um halbwegs aktuell zu sein, hatte ich bei allem wo es möglich war, es als backport installiert (geht in einem Rutsch einfach mit sudo apt upgrade -t bookworm-backports) - die sollten alle wieder in der uralten Version instaliert werden:
LMDEupgrade.png

Abgesehen davon, das mir das vielleicht sonst was zerschießt, hätte ich dann keine Internetverbindung mehr: Mein PC ist per WLAN mit dem Internet verbunden und der WLAN-Stick wird vom Kernel 6.1 noch gar nicht unterstützt!

Ich habe schon wieder von diesem versionsbasierten Schrott die Schnauze voll!

NIE WIEDER !!!!!! (ich meine als mein Produktivsystem)

Ich nutze schon seit Anfang 2020 Artix-Linux: Ein auf Arch basierendes rolling Release, das systemd nicht nutzt (ich nutze runit): Das ist zuverlässig und stabil: Es muss niemals eine neue Version installiert werden, weil es immer aktuell ist und mit sowas bescheuertem wie oben werde ich dort niemals zu tun bekommen.

So, das musste erst mal raus: Da es eine gute Argumentationshilfe ist, kann ich es in Zukunft verlinken, wenn mir wieder jemand erzählen will, wie stabil die ach so tollen LTS-Distros sind.

Schon vom regulären LinuxMint (17.1-18.3) war ich zuletzt so bedient, dass mit vollkommen klar war: In Zukunft nur noch rolling Releases. - Das bestätigt sich immer wieder.

Eine pflegeleichte variante könnte openSUSE Slowroll werden, wenn wenn sich dort die z. Zt. umfangreicheren Änderungen (kein YAST mehr, usw.) etwas gesetzt haben: Nächstes Jahr werde ich es mir wieder ansehen.

Mit Mintupgrade werde ich mich demnächst nochmal in Ruhe beschäftigen, um es wenigstens mal gemacht zu haben, aber sonderlich vertrauen würde ich der neuen Version nicht:

Da das schon zu Anfang so viel Murks ist, wer weiß wie viel Altlasten und schleichende Fehlerquellen man anschließend hat?

Ich was schon immer für platt machen und die neue Version frisch installieren: Dann kann man sicher sein, dass man ein sauberes System hat und man verschwendet u. U. nicht haufenweise Zeit damit, dass man immer wieder von vorne anfangen muss, weil schon wieder irgendwas nicht gepasst hat, bei zweifelhaften Ende…

Deshalb empfehle ich immer jeweils eigene Partitionen für System und Home: Die System kann man beliebig platt machen, ohne dass irgendwelche Benutzerdaten und Einstellungen verloren gehen.

Mint bietet sogar ein Tool, dass eine Liste der zusätzlich installierten Anwendungen exportiert, womit man diese nach der Neuinstallation in einem Rutsch wieder nachinstallieren kann. - Das habe ich allerdings auch noch nicht getestet. - Wie gesagt: Bei einem rolling Release hat man mit sowas überhaupt nichts mehr zu tun.

@Tanzmusikus: Lasse dir mit KVM noch Zeit. Da mein Spiele-Thread eher als eine Art Schmierzettel gedacht war und ist, was man damit alles machen kann und was ist selbst noch dazu entdecke, wollte ich sowieso noch einen KVM-Einsteiger-Thread erstellen.

Das mache ich dann auf Basis von LMDE 7, da die Standard-QEMU-Version vonj LMDE 6 (nicht die Backport-Version) uralt ist: s. Anhang

Um das nachzusehen, hatte ich es gerade mit KVM und diesem Skript gebootet:
Bash:
#!/bin/bash
if [ $# == 0 ];then echo "vms /dev/sd? …";exit;fi
cl="qemu-system-x86_64 -nodefaults -enable-kvm -cpu host -smp cores=4 -m 4G -vga none -device virtio-vga-gl -display sdl,gl=on -audio sdl,model=hda -boot menu=on"
while [ $# -gt 0 ]
do cl=$cl" -drive file=/dev/sd$1,if=virtio,aio=io_uring,snapshot=on,format=raw"
shift;done
$cl

"vms c" = mit "snapshot=on" von /dev/sdc (Schreibzugriffe werden nur im RAM gepuffert - vorhin beim "in sich selbst" Link hatte ich genauer erklärt)
 

Anhänge

  • KVM.jpg
    KVM.jpg
    303,1 KB · Aufrufe: 17
  • Gefällt mir
Reaktionen: Tanzmusikus
Caramon2 schrieb:
Also hat es tatsächlich am vBox-Kram gelegen?
Ja, VBoxGuestAdditions deinstalliert & 3D-Beschleunigung deaktiviert (sowie +12 GB Festspeicher erweitert) ... und das Upgrade auf LMDE7 GiGi (alias Debian 13 Trixi) hat funktioniert. Danke nochmals für deinen Tipp.

Ich kann jetzt sogar Fastfetch (statt Neofetch) aus der Repository von Debian laden. :daumen:
 
@Tanzmusikus: An der 3D-Beschleunigung wird es vermutlich nicht gelegen haben, da die VM sie ohne Gasterweiterung sowieso nicht nutzen kann. Genug freier Platz waren auch meine Bedenken, da ich die Testinstallationen rel. knapp partitioniert habe (s. mein "Super-SoS"), aber soweit ist ist es ja gar nicht erst gekommen.

Ich finde es wirklich total bescheuert, dass man erst alle Backports zurück auf die uralten Standard-Versionen installieren muss, nur um dann gleich im nächsten Schritt die neuen Versionen von Debian 13 drüber zu installieren: Welcher (censored) denkt sich solchen ineffizienten Mist aus?

Wieso wird nicht einfach gefragt, ob man zurücksetzen, oder auf eigene Gefahrt (ist es ja sowieso) ohne das weiter machen will? - Es ist doch sowieso gesichert: Falls es nicht funktioniert, stellt man die Sicherung wiederher und versucht es auf die umständliche Methode.

Ich hasse solche Bevormundungen: Ich nutze Linux, weil ich weg davon wollte!

Ich habe mich gestern auch noch hier über mitupgrade und LTS-Distros allgemein ausgelassen (z. Zt. noch nicht freigeschaltet) und nachdem ich darüber geschlafen habe, habe ich folgendes beschlossen:

1. Dem mintupgrade traue ich nicht mehr: Die doktorn schon seit gut 10 Jahren daran herum (LinuxMint 18 kam im Sommer 2016) und es ist trotzdem immer noch so ein Murks.

Da ich zum gravierenden Bug des LMDE-Installers schon bei LMDE 5 sogar direkten Kontakt mit Clement Lefebvre hatte, es den bei LMDE 6 aber immer noch gab (LMDE 7 konnte ich noch nicht testen, da ich noch auf die deutsche Version von LinuxMintUsers.de warte, aber da wird es sicherlich auch nicht anders sein), wird sich daran wohl auch nichts mehr ändern.

2. Der eigentliche Plan war, zuerst die "saubere" Testinstallation ("LMDEorg" vom SoS) zu aktualisieren, um dann eine Referenz zu haben, falls es bei der Aktualisierung der mehr zum Produktivsystem und weitere Tests ausgebauten Testinstallation ("LMDE" - das hatte ich beim Screenshot in der VM gebootet) zu Problemen kommt.

Da ich mintupgrade inzwischen sowieso abgeschrieben habe, weil ich auf jeden Fall die Backports weiter nutzen werde, damit auch LMDE 7 wenigstens halbwegs aktuell bleibt, hat sich das erledigt und ich werde die "LMDEorg"-Partition entfernen, "LMDE" vergrößern, aber 1 GiB freilassen. Dort werde ich dann die Homepartition dafür erstelle, um das nachzustellen, was ich gestern zum plattmachen und die neue Version frisch installieren geschrieben habe.

3. vorher werde ich aber versuchen, ob mintupgrate "LMDE" wirklich aktualisieren kann, wenn ich das zurück installieren der Standard-Versionen zulasse, oder was für ein Quatsch dann vielleicht noch kommt… - Großartig viel Zeit und Traffic (und Nerven) werde ich damit aber nicht verschwenden, da es ja sowieso keine Priorität mehr hat:

Was nützt mir ein Upgrade-Tool, dass offenbar bedingt, dass man LMDE nur standardmäßig nutzen darf und dadurch ähnlich eingeschränkt und unflexibel ist, wie bei Windows? - Dafür bin ich nicht auf Linux umgestiegen.

Nachtrag:

Das mache ich dann in der VM, da ich dort auch mit Kernel 6.1 eine Internetverbindung habe.

Statt des "vms"-Skripts ("nodefaults" = kein Netzwerk und damit Internetverbindung und "snapshot=on" = es wird nicht dauerhaft geschrieben) nutze ich das "vm"-Skript, das bis auf dass es beiden nicht enthält, gleich ist.

Außerdem habe ich noch ein "vmn"-Skript, das "nodefaults" enthält: Wenn ich etwas ändern möchte, aber keine Internetverbindung brauche (die hat der PC ja sowieso nur, wenn ich den AP des Handys aktiviere).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: @mo
Caramon2 schrieb:
LMDE 7 konnte ich noch nicht testen, da ich noch auf die deutsche Version von LinuxMintUsers.de warte
Inzwischen ist es da: Gestern war in dem Thread (oben auf der Hauptseite) "14.10.2025: Linux Mint Debian 7 veröffentlicht" nur der Hinweis auf die originale Veröffentlichung der englischen Version, jetzt wird man auf den Thread "Linux Mint Debian 7 Cinnamon veröffentlicht (Codename „Gigi“)" umgeleitet. - Offenbar von heute früh: "lmde-7-cinnamon-64bit-de-20251018-0342.iso"

Vermutlich gibt es deshalb noch keine Kommentare, weil das noch niemanden aufgefallen ist. - Die warte ich noch ab, ob es wirklich OK ist, weil ich 2,8 GiB nicht umsonst laden möchte.

Hier eine Aufstellung aller bisher veröffentlichter Versionen (bzgl. Datum und Größe):
Code:
lmde-2-cinnamon-64bit.iso  2015-04-06  1.5G
lmde-2-cinnamon-64bit.iso  2017-03-10  1.4G
lmde-3-cinnamon-64bit.iso  2018-08-28  1.6G
lmde-4-cinnamon-64bit.iso  2020-03-15  1.9G
lmde-5-cinnamon-64bit.iso  2022-03-11  1.9G
lmde-6-cinnamon-64bit.iso  2023-09-22  2.5G
lmde-7-cinnamon-64bit.iso  2025-09-07  2.8G

Vom regulären LinuxMint gab es im gleichen Zeitraum diese Versionen:
  • 18.1
  • 18.2
  • 18.3
  • 19
  • 19.1
  • 19.2
  • 19.3
  • 20
  • 20.1
  • 20.2
  • 20.3
  • 21
  • 21.1
  • 21.2
  • 21.3
  • 22
  • 22.1
  • 22.2
Das meine ich damit, dass LMDE pflegeleichter ist: Alles wofür man die reguläre Version auf einen neuen Pointrelease aktualisieren muss, gibt es bei LMDE als ganz normales Update: Man muss sich um nichts kümmern. Einzig die Hauptversionen muss man mit mintupgrade aktualisieren.

Das versuche ich gleich mit meiner "LMDE" Testinstallation. - "LMDEorg" habe ich eben entfernt und LMDE eine separate Home-Partition spendiert:

nSoS.png

Das aufwändigste daran war, das Sicherungsskript anzupassen, da ich die zwei Partitionen in die Unterverzeichnisse "linux" und "home" sichere (mit meinem Produktionssystem: Das funktioniert nicht aus dem laufenden LMDE heraus!):
Bash:
#!/bin/bash
if [ ! -d /run/media/$USER/LMDE     ];then udisksctl mount -b /dev/disk/by-label/LMDE     || exit;fi
if [ ! -d /run/media/$USER/LMDEhome ];then udisksctl mount -b /dev/disk/by-label/LMDEhome || exit;fi
cd Sicherungen && sync -f . || exit

zs=4 # Anzahl der Sicherungsstufen

espeak-ng -vde -a50 "Bitte Passwort" & sudo mv LMDE_$zs LMDE_A 2>/dev/null

for ((z=$zs;z>=0;z--));do mv LMDE_$z LMDE_$((z+1)) 2>/dev/null;done
if [ ! -d LMDE_A ];then mkdir LMDE_0;else mv LMDE_A LMDE_0;fi

time sudo rsync -vaxH --del --link-dest=../../LMDE_1/linux/ --exclude '.cache/*' --exclude '/home/*' --exclude '/tmp/*' --exclude '/media/*' --exclude '/var/tmp/*' --exclude '/var/log/*' --exclude '*.log' --exclude '*.old' --exclude '*_old' ../../LMDE/ LMDE_0/linux/ && time sudo rsync -vaxH --del --link-dest=../../LMDE_1/home/ --exclude '.cache/*' --exclude '*.log' --exclude '*.old' --exclude '*_old' ../../LMDEhome/ LMDE_0/home/ && touch LMDE_0
time sync -f .

if [ -z "$tm" ];then espeak-ng -vde -a50 "Datensicherung abgeschlossen" & read -p "[Enter]";fi

Übrigens: es ist zwar auf btrfs installiert, aber nur weil ich die zStd-Komprimierung nutze (höhere Stufen als 2 bringen fast gar nichts und bremsen nur). Mit dem Snapshot-Kram ärgere ich mich nicht mehr herum:
Code:
# <file system>                  <mount point> <type> <options>          <dump> <pass>
proc                                      /proc proc  defaults                0 0
UUID=9905b248-6ea1-4fc2-8f34-979d0bbe044f /     btrfs noatime,compress=zstd:2 0 0
UUID=cb913057-65e6-4247-bc52-50ac2fd46a6f /home btrfs noatime,compress=zstd:2 0 0
memory                                    /tmp  tmpfs nosuid,size=90%         0 0

Nachtrag:

Um die Backports zurückzunehmen, mussten zum Glück nur ca. 400 MiB geladen werden (es wurden weder Größe noch Anzahl genannt): s. Anhang

Der andere Traffic ging wieder für das komplette laden der sowieso aktuellen apt-Datenbank drauf: Das hatte diesmal "nur" 1,5 Min. gedauert.



Na klasse: Anschließend geht es wieder von vorne los, mintupgrade wurde nicht neu gestartet, aber trotzdem wird die gerade erst komplett neu geladene apt-Datenbank schon wieder komplett neu geladen! - Welcher Schwachkopf hat diesen Blödsinn zu verantworten!? :(

Interessanterweise wurden die Sachen zwar alle einschließlich Kernel 6.1 installiert, ich brauchte aber nicht rebooten, so dass immer noch der Kernel 6.12 genutzt wird, also der WLAN-Stick weiter genutzt werden könnte (s. o.).

Aktueller Stand:

aktsim.png

Das wird dauern…

Den Bildschirmschoner habe ich bei beiden (Host und VM) schon deaktiviert: Ich mache mir jetzt erst mal was zu essen. :)



Nach ca. 40 Min. Download ist er jetzt schon seit ca. 12 Min. am aktualisieren (auf SSD! - apt ist so laaahm…):

akt.png

Nach 43 Min. ist der immer noch dabei:

akt2.png

Nach 40 Min. Download und 56 Min. Installation war das Upgrade tatsächlich erfolgreich abgeschlossen: s. Anhang (ich hatte währenddessen ein vorher heruntergeladenes YouTube-Video im Fenstermodus angesehen, um am linken Rand das Upgrade in Auge behalten zu können)

Es steht dort zwar, dass man rebooten soll (vielleicht damit es keine Konflikte mit der unter der Haube vollständig ausgetauschen Softwarebasis gibt), aber wenn man das direkt machen will, gibt es eine Fehlermeldung, dass das Aktualisierungswerkzeug noch läuft und nicht gesicherte Daten verloren gehen können. - Man könnte das zwar "ignorieren", aber ich habe lieber abgebrochen, mintupgrade und anschließend das Terminal normal beendet und dann erst rebootet.

Im Bootmenü war immer noch alles da:

fertig1.png

Und gebootet noch alles wie vorher, sogar die installierten Erweiterungen wurden beibehalten (beim bewegen/skalieren lasse ich Fenster durchscheinend anzeigen - s. im Eröffnungsbeitrag verlinkte Verschönerungsbeispiele):

fertig2.jpg

Nach den ganzen anfänglichen Murks bin ich (bisher - ich muss es mit noch genauer ansehen) echt positiv überrascht! :)

Synaptic war auch bei mir nicht mehr installiert, befindet sich aber noch in den Paketquellen, so dass es mit sudo apt install synaptic nachinstalliert werden kann (sicherlich auch per Anwendungsverwaltung): Auch dabei waren dann die Einstellungen noch so, wie ich sie vorher gesetzt hatte. Also wurde nicht mal der root-Ordner zurückgesetzt. - Anders als wenn man die Systempartition löscht und LMDE 7 frisch installiert: Dann ist natürlich auch der root-Order "frisch" und man müsste ihn aus der letzten Sicherung wiederherstellen.

Etwas merkwürdig ist: Firefox, Thunderbird und LibreOffice hatte ich deinstalliert, da ich die bei der Testinstallation nicht brauche und beim Upgrade wurden FF+TB nicht wieder neu installiert, aber LibreOffice schon: In der Version 25.2.3.2 und merkwürdigerweise in englisch (ich sehe mir später an weshalb).

Jetzt habe ich erst mal genug davon und mache mir einen schönen Abend. :)
 

Anhänge

  • Mintupgrade.jpg
    Mintupgrade.jpg
    284 KB · Aufrufe: 21
  • fertig.jpg
    fertig.jpg
    293,7 KB · Aufrufe: 18
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
Ja, das dauert(e) ...
Hatte der LMDE-VM extra 6 statt 4 "CPUs" für das Upgrade zur Verfügung gestellt.
Ich konnte übrigens danach wieder Backports nutzen (Kernel 6.16.x statt 6.12.x). :daumen:

Demnächst folgt dann das Upgrade von LMDE6 zu 7 auf dem TV-PC meiner Familie.
Sollte mit dem alten Sockel 775er System eigentlich genauso problemlos funktionieren.
Mal schauen ...
 
Tanzmusikus schrieb:
Hatte der LMDE-VM extra 6 statt 4 "CPUs" für das Upgrade zur Verfügung gestellt.
Mir ist erst währenddessen eingefallen, dass das VM-Skript nur 4 Kerne meines Octacores nutzt, aber es waren beim Host fast immer sogar nur 25% CPU-Last (s. o. fertig.jpg), also mit 2 Kernen wäre es auch nicht langsamer gewesen: apt ist eben ziemlich lahm. - Nur eopkg von Solus ist noch langsamer und das sogar deutlich!

Tanzmusikus schrieb:
Ich konnte übrigens danach wieder Backports nutzen (Kernel 6.16.x statt 6.12.x). :daumen:
So weit bin ich noch nicht: Erst mal sichern, dann genau angeucken, ggfs. unnötiges rausschmeißen, wieder sichern und erst dann kommt das "optimieren". :-)

Momentan belegt es trotz Komprimierung über 1 GiB mehr als vorher (s. o.):

SoS2.png

Tanzmusikus schrieb:
Demnächst folgt dann das Upgrade von LMDE6 zu 7 auf dem TV-PC meiner Familie.
Sollte mit dem alten Sockel 775er System eigentlich genauso problemlos funktionieren.
Mal schauen ...
Solange es nichts exotisches gibt, spricht nichts dagegen. :)
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Beim ausmisten habe ich gestern gesenen, dass die wine-32-bit-libs installiert waren (über 600 MB), obwohl Wine gar nicht installiert war. Das hatte es von LMDE6 übernommen, wo das gleiche war (ca. 500 MB - es wurde also als neue Version installiert) und als ich es bei LMDE 7 mit sudo apr purge *wine* restlos deinstallieren wollte, passierte gar nichts: Offenbar werden die ":i386"-Pakete trotz "*" nicht berücksichtigt.

Daher stammt das wahrscheinlich: Ich hatte im Frühjahr bei LM;DE 6 testweise Wine installiert und da ich gründlich bin, es anschließend mir der Befehlszeile deinstalliert, weil ich davon ausging, das "wine" alles erfasst und weil "purge" gründlicher als "remove" ist, was die Anwendungsverwaltung nutzen würde (ganz davon abgesehen, dass man dort gar nichts davon sieht, was wirklich passiert, nur einen nichtssagenden Fortschrittsbalken). - Falsch gedacht… - Wobei ich aber auch nicht verstehe, weshalb sudo apt autoremove purge (das lasse ich vor jeder Sicherung ausführen) es dann nicht entfernt hat, weil es doch eigentlich eine verweiste Abhängigkeit gewesen sein sollte.

(LMDE 7 hat übrigen das neue apt 3, was parallele Downloads unterstützt und dadurch schneller sein soll, außerdem soll es übersichtlicher sein. - Naja, wenn man nichts besseres (aka pacman ;)) kennt, mag einem das vielleicht so vorkommen…)

Also habe ich es dann per Synaptic "vollständig" entfernt (entspricht "apt purge") und dann auch gleich die installierten Pakete absteigend nach Größe sortiert (beim neuen Synaptic feht übrigens das Schnellsuchfeld), um ggfs. weitere große Dateileichen zu finden.

Das ist übrigens ein anschauliches Beispiel dafür, weshalb von solchen Upgrades nichts halte, sondern platt machen und frisch installieren bevorzuge: Das ist viel schneller (s. Netto-Installation am Eröffnungsbeitrag) und wäre sicherlich auch viel schneller wieder auf den richtigen Stand gebracht, als das stundenlange herumprobieren, bis mintupgrade endlich funktioniert + die fast 2 Std. die das Upgrade dann dauerte + die noch unbestimmte Zeit für die Nachbereitung, bis man es wirklich wieder so hat, wie man es haben möchte: Ich weiß noch nicht, was vielleicht sonst noch fehlt, oder weg kann, weil ich es gar nicht brauche.

Rolling Releases sind so viel angenehmer: Das installiert man ein Mal, richtet es sich ein und dann bleibt es so, bis auf dass die installierten Pakete aktuell gehalten werden, wobei sich natürlich gelegentlich etwas verändert: Hier ein Bisschen, das nächste Mal dort ein Bisschen usw. - Eine Art schleichender Prozess…

Aber niemals ändert sich alles auf einen Schlag, werden wichtige Anwendungen ungefragt entfernt, oder nicht benötigtes ungefragt dazu installiert, wie es bei LTS-Distros bei jedem Upgrade der Hauptversion alle ca. zwei Jahre ist: Da man plötzlich alles, was in diesen zwei Jahren geändert wurde, auf einen Schlag vor den Latz geknallt bekommt. - Durch die Debian-Backport kann man das zumindest etwas abmildern.

Btw:

Zur Unterscheidung von LMDE 6 habe ich mir LMDE 7 jetzt so eingerichtet (das eine Fenster halte ich, damit man mehr vom Hintergrund sieht - ich hatte übrigens schon bei LMDE 6 alle Mint-Hintergründe mit sudo apt install mint-backgr* installiert (sollte man bei jeder neuen Cinnamon-Version wiederholen, damit deren neue HiGru als ausdrücklich installiert gekennzeichnet werden - sonst werden sie bei der nächsten Cinnamon-Version als Abhängikeit der alten wieder deinstalliert), was mintupgrade auch übernommen hat):

LMDE7.jpg

Überhaupt nicht gefallen haben mir aber die neuen GNOME 48 Apps (darauf hat LinuxMint keinen Einfluss), insbes. der Systemmonitor:

Bei dem wird inzwischen unten auch die Datenträgerauslastung angezeigt, die für mich nur unnötige Platzverschwendung ist, sich aber nicht deaktivieren lässt (nur einklappen - was inzwischen wenigstens gespeichert wird: als das afair bei GNOME 44 dazukam, war es bei jedem Start wieder offen und da es auch noch andere Probleme gab, nutze ich bei Artix weiterhin den von GNOME 40 (s. o.), da waren die noch OK - dto. gnome-disks):

SysMon.png

Aber es wurde noch "besser": Da bei "Prozesse" die angezeigten Spalten nicht mehr passten, öffnete ich die Einstellungen:

Gnome-SysMon.png

Zuerst mal riesengroß (mich erinnert das an Playmobil) und als ich die Einstellungen zur Seite ziehen wollte, um die Einstellungsänderungen kontrollieren zu können, wurde der Systemmonitor mitgezogen: Er blieb immer hinter den Einstellungen! - Die man übrigens nicht mal größer ziehen kann, um mehr Optionen zu sehen.

Außerdem merkt er sich nicht mehr die letzte Position (unten rechts - s. Beitrag #95), sondern öffnet sich immer wieder an der Standardposition.

Wieso machen die sowas?

Das ist weder effizient, noch durch das unnötige hin und her scrollen ergonomisch und muss auch nicht von Kleinkindern mit noch nicht voll entwickelter Feinmotorik bedient werden können.

Zum Vergleich: Die Einstellungen vom GNOME 40 sind nur oben für Grobmotoriker:

Gnome40-SysMon.png

GNOME entwickelt sich immer mehr zur Seuche und ist inzwischen ohne systemd (was sich wie ein Krebsgeschwür immer tiefer ins System frisst) nicht mal mehr funktionsfähig.

Mich überrascht es nicht, das System 76 großen Aufwand in ihren Rust-Desktop investiert, um endlich weg von GNOME zu kommen: Länger hätten die wirklich nicht warten dürfen…

Aus gleichen Grund hieß es auch mal, das Solus mit ihrem Budgie-Desktop weg von GNOME wollten (aber keine komplette Neuentwicklung, sondern sie wollten auf eine andere Basis umsteigen), aber dazu habe ich schon lange nichts mehr gehört.

Ich bin gespannt, wann/ob es sowas zu Cinnamon zu hören gibt: Das basiert ja auch auf GNOME.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
Ich hatte gestern die deutsche ISO von LMDE7 Cinnamon per Ventoy auf meinem AM4-PC ausprobiert.
Leider war die Nutzung des Internets gar nicht möglich.

Weder mit dem NIC meines Boards "Intel i211" noch mit einem USB3-LAN Adapter mit Realtek-Chip als auch über mein Notebook in 2 verschiedene LAN- und WLAN-Netze können keine Daten ausgetauscht werden. Laut Netzwerk-Menü werden alle NICs erkannt sowie die WLAN-Verbindungen in beiden Routern (inkl. IPs) angezeigt.

Es kann eigentlich nur noch die LMDE7-DE-ISO selbst das Problem sein (SHA256sum wurde erfolgreich geprüft).
Würdest du das mal gegenprüfen? Dann melde ich es im Linux Mint Forum.
 
  • Gefällt mir
Reaktionen: Caramon2
Tanzmusikus schrieb:
Würdest du das mal gegenprüfen? Dann melde ich es im Linux Mint Forum.
Ungerne, da 2,8 GiB, nur um sie vielleicht gleich wieder zu löschen und die gefixte Version später nochmal laden zu müssen, mir zu viel sind: Ich habe gestern schon fürs Upgrade insgesamt knapp 3 GiB verbraten und der restliche Traffic muss noch für fast 2 Wochen reichen.

Schreib das besser direkt dort, damit die es gleich kontrollieren können: Was würde es ändern, ob es bei mir (AM3-PC) vielleicht funktioniert, oder auch nicht?
Ergänzung ()

@Tanzmusikus: Zumindest das Upgrade-LMDE 7 kann meinen WLAN-Stick (ID 0bda:c811 Realtek Semiconductor Corp. 802.11ac NIC) noch nutzen und bekommt eine Internetverbindung. - Mir ist aufgefallen, dass ich es bisher nur in der VM online hatte.

Da ich bei LMDE 6 KVM installiert hatte und mintupgrade das auch übernommen hat, habe ich es jetzt umgedreht: Ich habe von LMDE 7 aus mein Produktivsystem in der VM gebootet, um dieses hier zu schreiben (bei den Testinstallationen nutze ich keine sensiblen Daten, habe bei LMDE also auch kein Computerbase eingerichtet).

Anbei wie das aussieht und hier die genutzte Befehlszeile:
Bash:
sudo qemu-system-x86_64 -run-with user=$USER -enable-kvm -cpu host -smp cores=4 -m 4G -vga none -device virtio-vga-gl -display sdl,gl=on -drive file=/dev/sda,if=virtio,aio=io_uring,snapshot=on,format=raw -drive file=/dev/sdb,if=virtio,aio=io_uring,snapshot=on,format=raw

/dev/sdb ist für den Datenaustausch mit dem Host und "sudo" muss ich benutzen, damit KVM die Laufwerke direkt ansprechen kann (beim Produktivsystem gehöre ich stattdessen zur Gruppe "disk" - Vorsicht: s. mein KVM-Thread!). Durch "-run-with user=$USER" wechselt es aber sofort nach dem einbinden der Laufwerke (also noch bevor es die VM bootet) auf normale Benutzerrechte.

Nachtrag:

Boah, ich habe mich gerade erschreckt: Als ich bei LMDE unten links auf den SysMon sah, dachte ich, es hätte (direkt gebootot und online) im Hintergrund über 600 MiB Traffic gezogen! - Zum Glück war es nur der Datenträgerdurchsatz… - Puhhh!

Das habe ich erst mal eingeklappt: Ich hoffe das bleibt so.
 

Anhänge

  • LMDE-KVM.jpg
    LMDE-KVM.jpg
    286 KB · Aufrufe: 18
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
Zurück
Oben