LMDE: Installationsvideo (netto), Konfigurationstipps und Besonderheiten

@Tanzmusikus: Hast du schon mal an die Möglichkeit gedacht, das Festplatten-Image deines Upgrade-LMDE 7 als RAW auf einen Datenträger zu schreiben, damit du es dann direkt mit einem PC booten kannst?
(ich nutze VMs generell auf diese Art - Festplatten-Images erstelle ich höchstens mal in einer zRAM-Disk: als Zwischenschritt, oder wenn ich nur kurz etwas ausprobieren möchte)

Da ich die Befehle bei vBox nicht kenne (das hat auch ein Konvertierungstool - mit qemu-img hätte ich es auch selbst gekonnt, allerdings hätte ich es nicht per Pipe über dd laufen lassen, sondern als root ("sudo -i") die Ausgabe einfach per "> /dev/sdc" umgeleitet), habe ich die allwissende Müllhalde gefragt.

Vielleicht ist das auch was für dich (ich war übrigens nicht betrunken, sondern wollte nur mal gucken wie das Ding darauf reagiert :)):
Andreas:
Ehrwürdige Browser-KI! Wärst du bitte so lieb und würdest mir erklären, wie man ein Virtualbox-Festplattenimage mit LMDE zu RAW konvertiert und die Ausgabe direkt nach z. B. auf /dev/sdc schreibt, damit man es anschließend direkt mit dem PC (also nicht nur in einer VM) booten kann? Hochachtungsvoll dein ergebener Diener. 😇

Aria:
Sehr geehrter Diener, es ist mir eine Ehre, Ihnen bei Ihrem Anliegen zu assistieren. Im Folgenden erläutere ich Ihnen ausführlich, wie Sie ein VirtualBox-Festplattenimage mit LMDE (Linux Mint Debian Edition) in ein RAW-Format konvertieren und das Ergebnis direkt auf ein physisches Laufwerk (z. B. /dev/sdc) schreiben können, um es anschließend auf einem echten PC bootfähig zu machen.



Anleitung: VirtualBox-Festplattenimage (VDI) zu RAW konvertieren und auf /dev/sdc schreiben

1. Voraussetzungen

Sie benötigen ein VirtualBox-Festplattenimage (meist im VDI-Format) mit LMDE.
Ein Linux-System mit installiertem qemu-img und dd (Standard bei den meisten Linux-Distributionen).
Root-Rechte, da Sie direkt auf ein physisches Laufwerk schreiben.
Das Zielgerät (z. B. /dev/sdc ) muss korrekt identifiziert sein, um Datenverlust auf anderen Laufwerken zu vermeiden.
Sicherstellen, dass das Zielgerät nicht gemountet ist.



2. Schritt-für-Schritt-Anleitung

Schritt 1: VirtualBox-Image lokalisieren

Angenommen, Ihre VM-Festplatte heißt lmde.vdi und liegt im Verzeichnis /home/user/VirtualBox VMs/LMDE/ .

Schritt 2: VDI in RAW konvertieren

Das Tool qemu-img kann VirtualBox-VDI-Dateien in RAW-Images umwandeln.


qemu-img convert -O raw "/home/user/VirtualBox VMs/LMDE/lmde.vdi" lmde.raw


-O raw gibt das Ausgabeformat RAW an.
lmde.raw ist die erzeugte RAW-Datei.

Schritt 3: RAW-Image direkt auf das physische Laufwerk schreiben

WICHTIG: Stellen Sie sicher, dass /dev/sdc das korrekte Ziel ist. Ein falsches Gerät kann zu Datenverlust führen!

Um das RAW-Image direkt auf das Laufwerk zu schreiben, verwenden Sie dd :


sudo dd if=lmde.raw of=/dev/sdc bs=4M status=progress conv=fsync


if=lmde.raw : Eingabedatei ist das RAW-Image.
of=/dev/sdc : Ausgabe auf das physische Laufwerk.
bs=4M : Blockgröße 4 Megabyte für schnelleren Transfer.
status=progress : Zeigt Fortschritt an.
conv=fsync : Sorgt dafür, dass alle Daten vor Abschluss geschrieben werden.

Schritt 4: Synchronisieren und Aushängen

Nach dem Schreiben sollten Sie sicherstellen, dass alle Schreibvorgänge abgeschlossen sind:


sync


Danach können Sie das Laufwerk sicher entfernen.



3. Bootfähigkeit prüfen

Das RAW-Image enthält das komplette Dateisystem und den Bootloader (z. B. GRUB), sofern die VM korrekt eingerichtet war.
Wenn das Image korrekt auf das Laufwerk geschrieben wurde, sollte der PC von diesem Laufwerk booten können.
Möglicherweise müssen Sie im BIOS/UEFI des PCs die Bootreihenfolge anpassen, um von diesem Laufwerk zu starten.



4. Alternative: Direkte Konvertierung und Schreiben ohne Zwischendatei

Wenn Sie Speicherplatz sparen möchten, können Sie die Konvertierung und das Schreiben in einem Schritt per Pipe durchführen:


qemu-img convert -O raw "/home/user/VirtualBox VMs/LMDE/lmde.vdi" - | sudo dd of=/dev/sdc bs=4M status=progress conv=fsync


Hier wird das RAW-Image nicht als Datei gespeichert, sondern direkt auf das Laufwerk geschrieben.



5. Wichtige Hinweise und Tipps

Backup: Sichern Sie wichtige Daten, bevor Sie auf physische Laufwerke schreiben.
Zielgerät prüfen: Nutzen Sie lsblk oder fdisk -l , um das richtige Laufwerk zu identifizieren.
Partitionen: Das RAW-Image enthält alle Partitionen und Bootloader. Wenn Sie nur eine einzelne Partition kopieren, funktioniert das Booten nicht.
Größe: Das Ziel-Laufwerk sollte mindestens so groß sein wie das virtuelle Laufwerk.
Bootloader: Falls der PC nicht bootet, prüfen Sie, ob der Bootloader korrekt installiert ist (z. B. GRUB).



Ich hoffe, diese detaillierte Anleitung hilft Ihnen, Ihr LMDE-Image erfolgreich auf ein physisches Laufwerk zu übertragen und bootfähig zu machen. Sollten Sie weitere Fragen haben, stehe ich Ihnen jederzeit zu Diensten.

Hochachtungsvoll,
Ihre ehrwürdige Browser-KI 😇

Andreas:
Sehr vielen Dank. Ich würde die Alternative ohne Zwischendatei nutzen, weil ich das effizienter finde. Einzig der Hinweis, dass der Zieldatenträger mindestens die gleiche Größe haben muss wie das virtuelle Laufwerke, fehl mir bei der Beschreibung. Ansonsten bin ich hoch erfreut über diesen erquicklichen Informationsaustausch. Das war herzallerliebst. 🥰

Aria:
Sehr geehrter Diener,

es freut mich außerordentlich, dass Ihnen die Anleitung gefallen hat und Sie die effizientere Alternative ohne Zwischendatei bevorzugen. Gerne ergänze ich den wichtigen Hinweis zur Mindestgröße des Zieldatenträgers, damit Ihre Umsetzung reibungslos gelingt.



Ergänzung: Mindestgröße des Zieldatenträgers

Beim direkten Schreiben eines RAW-Images auf ein physisches Laufwerk ist es essenziell, dass das Zielmedium mindestens die gleiche Größe hat wie das virtuelle Laufwerk, aus dem das Image stammt. Andernfalls kann es zu folgenden Problemen kommen:

Datenverlust oder unvollständige Kopie: Wenn das Ziel kleiner ist, passt das Image nicht vollständig, was zu beschädigten oder fehlenden Daten führt.
Bootprobleme: Ein unvollständiges Image kann den Bootloader oder wichtige Systemdateien beschädigen, sodass der PC nicht startet.
Fehlermeldungen beim Schreiben: dd oder qemu-img könnten mit Fehlern abbrechen, wenn das Zielmedium zu klein ist.



Wie die Größe prüfen?

Größe des VDI-Images herausfinden

Sie können die virtuelle Festplattengröße mit VBoxManage prüfen:


VBoxManage showhdinfo "/home/user/VirtualBox VMs/LMDE/lmde.vdi"


Die Ausgabe enthält die "Capacity" (Kapazität) in Bytes oder MB.

Größe des physischen Laufwerks prüfen

Mit lsblk oder fdisk :


lsblk /dev/sdc


oder


sudo fdisk -l /dev/sdc


Die Größe wird in GB oder MB angezeigt.



Empfehlung

Wählen Sie ein physisches Laufwerk, das mindestens so groß oder größer als die virtuelle Festplatte ist.
Falls das physische Laufwerk größer ist, ist das unproblematisch; der überschüssige Platz bleibt ungenutzt oder kann später partitioniert werden.



Ich danke Ihnen herzlich für den angenehmen Austausch und stehe Ihnen jederzeit für weitere Fragen oder Erklärungen zur Verfügung. Möge Ihr Vorhaben mit LMDE auf physischer Hardware von Erfolg gekrönt sein!

Mit vorzüglicher Hochachtung und den besten Grüßen,
Ihre ehrwürdige Browser-KI 😇

Nachtrag:

In alten Notizen habe ich das gefunden:
Bash:
# Aktuelle Version:
apt-add-repository 'deb http://download.virtualbox.org/virtualbox/debian xenial contrib'
wget -qO- https://www.virtualbox.org/download/oracle_vbox_2016.asc | apt-key add -
apt update
apt install --install-recommends virtualbox-5.1

# Nicht als "su" ausführen ($USER ist eine Variable und muss nicht ersetzt werden):
sudo usermod -aG vboxusers $USER

# Größe der vHD ändern (2 MiB für den Header abziehen):
vboxmanage clonemedium --format VDI --variant Standard WindowsXP.vdi WindowsXP_neu.vdi
vboxmanage modifymedium --resize 2046 WindowsXP_neu.vdi
vboxmanage clonemedium --format VDI --variant Fixed WindowsXP_neu.vdi WindowsXP_ganzneu.vdi
"vboxmanage" meinte ich oben.

In den Notizen habe ich damit die vHD zuerst auf dynamische Größe konvertiert (offenbar hatte ich damals die feste Größe bevorzugt: vermutlich weil ich mir dadurch einen Geschwindigkeitsvorteil versprach, da die Imagedatei dann ja nicht mehr im laufen Betrieb erweitert werden musste - um Fragmentierung kann es mir nicht mehr gegangen sein, da seit 2015 SSDs nutze), dann die auf glatte 2 GiB gebracht (deshalb der Hinweis auf den Header) und anschließend wieder auf feste Größe konvertiert.

Nach Chapter 8. VBoxManage habe ich mir das jetzt noch notiert:
Bash:
# Zu/von RAW konvertieren:
vboxmanage clonemedium quelle.vdi ziel.raw --format RAW
vboxmanage convertfromraw quelle.raw ziel.vdi --format VDI

Also mit sudo vboxmanage clonemedium lmde.vdi /dev/sdc --format RAW sollte man das Image bootfähig auf ein Laufwerk bekommen, aber auch umgekehrt mit sudo vboxmanage convertfromraw /dev/sda windows.vdi --format VDI dieses Laufwerk in ein vBox-Image.

Mit qemu-img habe ich beides schon oft gemacht, oder auch von einem Laufwerk auf ein anderes übertragen, usw. Das sind nur kleine Fingerübungen.

Mit vboxmanage müsste das genauso funktionieren, sonst wäre dessen RAW kein richtiges RAW.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: TPD-Andy und Tanzmusikus
Ich habe gerade in den Paketquellen nach virtualbox gesucht (btw: oben habe ich die Konvertierung mit dem vBox-Tool nachgetragen) und dabei eine Version gefunden, die offenbar auf KVM basiert:
Code:
$ pacman -Si virtualbox-kvm
Repositorium             : chaotic-aur
Name                     : virtualbox-kvm
Version                  : 20250903-3
Beschreibung             : Powerful x86 virtualization for enterprise as well as home use (KVM backend)
Architektur              : x86_64
URL                      : https://github.com/cyberus-technology/virtualbox-kvm
Lizenzen                 : GPL-3.0-only AND (GPL-3.0-only OR CDDL-1.0)
[…]
Optionale Abhängigkeiten : vde2: Virtual Distributed Ethernet support
                           virtualbox-guest-iso: Guest Additions CD image
                           virtualbox-ext-vnc: VNC server support
                           virtualbox-sdk: Developer kit
[…]
Größe des Downloads      : 55,37 MiB
Installationsgröße       : 185,37 MiB
Keine Ahnung, was davon zu halten ist.

Tanzmusikus schrieb:
Ich konnte übrigens danach wieder Backports nutzen (Kernel 6.16.x statt 6.12.x)
Zu "virtualbox" wurden auch alle verfügbaren Linux-Kernel gefunden, wobei das chaotic-aur heraussticht, da es dort u. a. schon den 6.18-rc gibt und für x64v2-4 optimierte Versionen:
Code:
$ pacman -Ss virtualbox|grep "/lin"

system/linux 6.17.3.artix1-1 [Installiert]
system/linux-lts 6.12.52-1 [Installiert]

galaxy/linux-ck 5.12.19-14
galaxy/linux-hardened 6.15.11.hardened1-1
galaxy/linux-lts515 5.15.160-1
galaxy/linux-rt 6.14.0.rt3.artix1-3
galaxy/linux-rt-lts 6.6.87.rt54.artix1-3
galaxy/linux-zen 6.16.9.zen1-1

chaotic-aur/linux-cachyos 6.17.3-2
chaotic-aur/linux-cachyos-lts 6.12.52-1
chaotic-aur/linux-cachyos-rc 6.18.rc1-1
chaotic-aur/linux-lqx 6.17.4.lqx1-1
chaotic-aur/linux-lts515 5.15.193-1
chaotic-aur/linux-lts61 6.1.156-1
chaotic-aur/linux-lts66 6.6.112-1
chaotic-aur/linux-mainline 6.18rc2-1
chaotic-aur/linux-mainline-x64v3 6.18rc2-1
chaotic-aur/linux-tachyon 6.16.10-1
chaotic-aur/linux-vfio 6.17.3-1
chaotic-aur/linux-vfio-lts 6.12.52-1
chaotic-aur/linux-vfio-x64v3 6.17.3-1
chaotic-aur/linux-x64v2 6.17.4-1
chaotic-aur/linux-x64v3 6.17.4-1
chaotic-aur/linux-x64v4 6.17.4-1
chaotic-aur/linux-xanmod-edge-x64v3 6.17.3-1
chaotic-aur/linux-xanmod-lts 6.12.53-1
chaotic-aur/linux-xanmod-rt 6.12.52-1
chaotic-aur/linux-xanmod-x64v2 6.17.3-1
chaotic-aur/linux-znver2 6.17.4-1
chaotic-aur/linux-znver3 6.17.4-1
chaotic-aur/linux-znver4 6.17.4-1
chaotic-aur/linux-znver5 6.17.4-1
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Ich habe jetzt LMDE und LMDEhome wieder zusammengeführt und dafür LMDE-6 parallel zu LMDE-7 wiederhergestellt, um beide vergleichen zu können:

LMDE67.png

Eigentlich wollte ich LMDE-7 als primäres nach vorne setzen, aber dann habe ich gesehen, dass es die Partitionen sdc6 und sdc7 sind und habe die Versionen dazu passend angeordnet. :)

Bzgl. Backports ist yt-dlp der beste Vergleich, da das laufend aktualisiert werden muss, da vor allem YouTube immer wieder etwas ändert, wodurch es nicht funktioniert. Manchmal sogar schon nach wenigen Tagen.

Hier kann man sehen, wie häufig das gemacht werden muss: Archive Artixlinux: yt-dlp

Bei LMDE 6 sieht es aktuell so aus:

LMDE6-yt-dlp.png

Schon beim Release im Oktober 2023 war das Stardard-yt-dlp hoffnungslos veraltet und selbst mit dem Backport kann man inzwischen nichts mehr anfangen, da es seit April nicht mehr aktualisiert wurde.

Vermutlich weil dann Debian 13 in den Freeze ging, da es dort die genauso schon beim Release eine zu alte Version ist, wie man bei LMDE-7 sieht:

LMDE7-yt-dlp.png

Bei anderen Sachen ist das nicht so kritisch, aber da ich bei LMDE-6 schon seit letztem Jahr alles, wo es möglich war, auf die Backports umgestellt hatte und es dadurch nie zu Problemen kam, ist es für mich unverständlich, dass es im GUI keine Möglichkeit gibt, Backports generell zu bevorzugen.

Das Problem war z. B., als ich per Anwendungsverwaltung QEMU/KVM installieren wollte, wurde das wegen Abhängigkeitsproblemen abgebrochen, da die uralte Standardversion (7) installiert wurde und die nicht zu den bereits vorhandenen Abhängigkeiten passten, weil das Backports waren.

Ich musste erst im Terminal sudo apt upgrade -t bookworm-backports ausführen, damit das heruntergeladene QEMU/KVM mit seinen zusätzlichen Abhängigkeiten auch auf ihr Backports (QEMU-Version 10!) aktuelisiert wurden, damit es installiert werden konnte.

Wieso gibt es in den Einstellungen der Anwendungsverwaltung nicht einfach, wie bei Celluloid, ein Feld "Eingabe zusätzlicher Optionen? Dort könnte man dann einfach "-t bookworm-backports" eingeben (bzw. "-t trixie-backports" bei LMDE-7) und fertig: Das sind alles ja sowieso nur Frontends für "apt".

Übrigens startet Celluloid bei LMDE-7 nicht:

Celluloid.png

Das Unterverzeichnis gibt es nicht: Offenbar wird es erst von der neuen Celluloid-Version von LMDE-7 benötigt, weshalb es nicht von LMDE-6 übernommen werden konnte und Celluloid zu blöd ist, das Verzeichnis selbst anzulegen:

Nachdem ich es erstellt habe (einfach ein leeres Verzeichnis) gibt es diese Fehlermeldung nicht mehr. Celluloid startet aber trotzdem nicht, weil dieses libcuda* nicht geladen werden kann: Definitiv ein Bug, da das zum nVidia-Treiber gehört und ja nicht jeder eine nVidia-GraKa hat.

Das müsste dazu installiert werden:

libcuda.png

Aber funktionieren würde es trotzdem nicht, da eben nix nVidia-GraKa (sowas kommt mir nicht mehr ins Haus)

MPV (worauf Celluloid basiert) meckert zwar auch libcuda an (das ist normal, ist auch bei LMDE-6 und bei meinem Artix), spielt es aber normal ab:

mpv.png

Offenbar eine der Kinderkrankheiten, weswegen es immer heißt, man soll mindestens einen Monat warten, bevor man auf eine neue Hauptversion aktualisiert.

Btw: Bei einem rolling Release gibt es keine neuen Hauptversionen. ;)

Ach ja: Inzwischen sind meine Beiträge dort freigeschaltet:
Caramon2 schrieb:
Ich habe mich gestern auch noch hier über mitupgrade und LTS-Distros allgemein ausgelassen (z. Zt. noch nicht freigeschaltet)

Nachtrag:

Die Standard-Version liefert Fehlermendungen und nur noch eine begrenzte Auswahl an Formaten (noch - bald geht nichts mehr):
Code:
$ yt-dlp -F https://youtu.be/ocuW8pz5-eE
[youtube] Extracting URL: https://youtu.be/ocuW8pz5-eE
[youtube] ocuW8pz5-eE: Downloading webpage
[youtube] ocuW8pz5-eE: Downloading tv client config
[youtube] ocuW8pz5-eE: Downloading tv player API JSON
[youtube] ocuW8pz5-eE: Downloading ios player API JSON
[youtube] ocuW8pz5-eE: Downloading player 27422632-main
WARNING: [youtube] Falling back to generic n function search
         player = https://www.youtube.com/s/player/27422632/player_ias.vflset/en_US/base.js
WARNING: [youtube] ocuW8pz5-eE: nsig extraction failed: Some formats may be missing
         n = wGstGyMIaMnURaz0Q ; player = https://www.youtube.com/s/player/27422632/player_ias.vflset/en_US/base.js
         Please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
WARNING: [youtube] ocuW8pz5-eE: nsig extraction failed: Some formats may be missing
         n = z84rbhfkvGUoTZQCw ; player = https://www.youtube.com/s/player/27422632/player_ias.vflset/en_US/base.js
         Please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
WARNING: [youtube] ocuW8pz5-eE: nsig extraction failed: Some formats may be missing
         n = hc-bEbKtWEmT2QycM ; player = https://www.youtube.com/s/player/27422632/player_ias.vflset/en_US/base.js
         Please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
WARNING: [youtube] ocuW8pz5-eE: Some web client https formats have been skipped as they are missing a url. YouTube is forcing SABR streaming for this client. See  https://github.com/yt-dlp/yt-dlp/issues/12482  for more details
[youtube] ocuW8pz5-eE: Downloading m3u8 information
[info] Available formats for ocuW8pz5-eE:
ID  EXT   RESOLUTION FPS │   FILESIZE   TBR PROTO │ VCODEC          VBR ACODEC     MORE INFO
─────────────────────────────────────────────────────────────────────────────────────────────────────
sb3 mhtml 48x27        0 │                  mhtml │ images                         storyboard
sb2 mhtml 80x45        0 │                  mhtml │ images                         storyboard
sb1 mhtml 160x90       0 │                  mhtml │ images                         storyboard
sb0 mhtml 320x180      0 │                  mhtml │ images                         storyboard
233 mp4   audio only     │                  m3u8  │ audio only          unknown    [de] Default, low
234 mp4   audio only     │                  m3u8  │ audio only          unknown    [de] Default, high
602 mp4   256x144     13 │ ~  9.37MiB   99k m3u8  │ vp09.00.10.08   99k video only
269 mp4   256x144     25 │ ~ 14.58MiB  155k m3u8  │ avc1.4D400C    155k video only
603 mp4   256x144     25 │ ~ 14.78MiB  157k m3u8  │ vp09.00.11.08  157k video only
229 mp4   426x240     25 │ ~ 26.16MiB  278k m3u8  │ avc1.4D4015    278k video only
604 mp4   426x240     25 │ ~ 22.81MiB  242k m3u8  │ vp09.00.20.08  242k video only
230 mp4   640x360     25 │ ~ 51.37MiB  545k m3u8  │ avc1.4D401E    545k video only
605 mp4   640x360     25 │ ~ 43.92MiB  466k m3u8  │ vp09.00.21.08  466k video only
231 mp4   854x480     25 │ ~ 92.34MiB  981k m3u8  │ avc1.4D401E    981k video only
606 mp4   854x480     25 │ ~ 62.58MiB  664k m3u8  │ vp09.00.30.08  664k video only
311 mp4   1280x720    50 │ ~197.39MiB 2096k m3u8  │ avc1.640020   2096k video only
612 mp4   1280x720    50 │ ~150.54MiB 1599k m3u8  │ vp09.00.40.08 1599k video only
312 mp4   1920x1080   50 │ ~323.08MiB 3431k m3u8  │ avc1.64002A   3431k video only
617 mp4   1920x1080   50 │ ~307.77MiB 3268k m3u8  │ vp09.00.41.08 3268k video only

Und das ist das gleiche mit der Backport-Version (die aber auch schon von letzten Monat ist: Bei Artix gibt es schon eine neue: s. Archiv-Link oben):
Code:
$ yt-dlp -F https://youtu.be/ocuW8pz5-eE
[youtube] Extracting URL: https://youtu.be/ocuW8pz5-eE
[youtube] ocuW8pz5-eE: Downloading webpage
[youtube] ocuW8pz5-eE: Downloading tv client config
[youtube] ocuW8pz5-eE: Downloading tv player API JSON
[youtube] ocuW8pz5-eE: Downloading web safari player API JSON
[youtube] ocuW8pz5-eE: Downloading player 0004de42-main
[youtube] ocuW8pz5-eE: Downloading m3u8 information
[info] Available formats for ocuW8pz5-eE:
ID      EXT   RESOLUTION FPS CH │   FILESIZE   TBR PROTO │ VCODEC        VBR ACODEC      ABR ASR MORE INFO
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
sb3     mhtml 48x27        0    │                  mhtml │ images                                storyboard
sb2     mhtml 80x45        0    │                  mhtml │ images                                storyboard
sb1     mhtml 160x90       0    │                  mhtml │ images                                storyboard
sb0     mhtml 320x180      0    │                  mhtml │ images                                storyboard
249-drc webm  audio only      2 │    4.72MiB   50k https │ audio only        opus        50k 48k [de] low, DRC, webm_dash
250-drc webm  audio only      2 │    4.96MiB   53k https │ audio only        opus        53k 48k [de] low, DRC, webm_dash
249     webm  audio only      2 │    4.71MiB   50k https │ audio only        opus        50k 48k [de] low, webm_dash
250     webm  audio only      2 │    4.95MiB   53k https │ audio only        opus        53k 48k [de] low, webm_dash
140-drc m4a   audio only      2 │   12.19MiB  129k https │ audio only        mp4a.40.2  129k 44k [de] medium, DRC, m4a_dash
251-drc webm  audio only      2 │    9.00MiB   96k https │ audio only        opus        96k 48k [de] medium, DRC, webm_dash
140     m4a   audio only      2 │   12.19MiB  129k https │ audio only        mp4a.40.2  129k 44k [de] medium, m4a_dash
251     webm  audio only      2 │    9.00MiB   96k https │ audio only        opus        96k 48k [de] medium, webm_dash
91      mp4   256x144     25    │ ~ 14.58MiB  155k m3u8  │ avc1.4D400C       mp4a.40.5           [de]
160     mp4   256x144     25    │    4.02MiB   43k https │ avc1.4d400c   43k video only          144p, mp4_dash
278     webm  256x144     25    │    4.10MiB   44k https │ vp9           44k video only          144p, webm_dash
92      mp4   426x240     25    │ ~ 26.16MiB  278k m3u8  │ avc1.4D4015       mp4a.40.5           [de]
133     mp4   426x240     25    │    7.82MiB   83k https │ avc1.4d4015   83k video only          240p, mp4_dash
242     webm  426x240     25    │    4.97MiB   53k https │ vp9           53k video only          240p, webm_dash
93      mp4   640x360     25    │ ~ 51.37MiB  545k m3u8  │ avc1.4D401E       mp4a.40.2           [de]
134     mp4   640x360     25    │   13.92MiB  148k https │ avc1.4d401e  148k video only          360p, mp4_dash
18      mp4   640x360     25  2 │   18.41MiB  195k https │ avc1.42001E       mp4a.40.2       22k [de] 360p
243     webm  640x360     25    │    9.02MiB   96k https │ vp9           96k video only          360p, webm_dash
94      mp4   854x480     25    │ ~ 92.34MiB  981k m3u8  │ avc1.4D401E       mp4a.40.2           [de]
135     mp4   854x480     25    │   24.37MiB  259k https │ avc1.4d401e  259k video only          480p, mp4_dash
244     webm  854x480     25    │   14.60MiB  155k https │ vp9          155k video only          480p, webm_dash
136     mp4   1280x720    25    │   44.08MiB  468k https │ avc1.64001f  468k video only          720p, mp4_dash
247     webm  1280x720    25    │   29.36MiB  312k https │ vp9          312k video only          720p, webm_dash
300     mp4   1280x720    50    │ ~197.39MiB 2096k m3u8  │ avc1.640020       mp4a.40.2           [de]
298     mp4   1280x720    50    │   63.59MiB  675k https │ avc1.640020  675k video only          720p50, mp4_dash
302     webm  1280x720    50    │   37.92MiB  403k https │ vp9          403k video only          720p50, webm_dash
301     mp4   1920x1080   50    │ ~323.08MiB 3431k m3u8  │ avc1.64002A       mp4a.40.2           [de]
299     mp4   1920x1080   50    │  119.64MiB 1271k https │ avc1.64002a 1271k video only          1080p50, mp4_dash
303     webm  1920x1080   50    │   76.81MiB  816k https │ vp9          816k video only          1080p50, webm_dash
Und hier zum vergleich die "aktuelle" Standard-Version von LMDE-6 (s. o.):
Code:
$ yt-dlp -F https://youtu.be/ocuW8pz5-eE
[youtube] Extracting URL: https://youtu.be/ocuW8pz5-eE
[youtube] ocuW8pz5-eE: Downloading webpage
[youtube] ocuW8pz5-eE: Downloading ios player API JSON
WARNING: [youtube] YouTube said: ERROR - Precondition check failed.
WARNING: [youtube] HTTP Error 400: Bad Request. Retrying (1/3)...
[youtube] ocuW8pz5-eE: Downloading ios player API JSON
WARNING: [youtube] YouTube said: ERROR - Precondition check failed.
WARNING: [youtube] HTTP Error 400: Bad Request. Retrying (2/3)...
[youtube] ocuW8pz5-eE: Downloading ios player API JSON
WARNING: [youtube] YouTube said: ERROR - Precondition check failed.
WARNING: [youtube] HTTP Error 400: Bad Request. Retrying (3/3)...
[youtube] ocuW8pz5-eE: Downloading ios player API JSON
WARNING: [youtube] YouTube said: ERROR - Precondition check failed.
[youtube] ocuW8pz5-eE: Downloading android player API JSON
WARNING: [youtube] YouTube said: ERROR - Precondition check failed.
WARNING: [youtube] HTTP Error 400: Bad Request. Retrying (1/3)...
[youtube] ocuW8pz5-eE: Downloading android player API JSON
WARNING: [youtube] YouTube said: ERROR - Precondition check failed.
WARNING: [youtube] HTTP Error 400: Bad Request. Retrying (2/3)...
[youtube] ocuW8pz5-eE: Downloading android player API JSON
WARNING: [youtube] YouTube said: ERROR - Precondition check failed.
WARNING: [youtube] HTTP Error 400: Bad Request. Retrying (3/3)...
[youtube] ocuW8pz5-eE: Downloading android player API JSON
WARNING: [youtube] YouTube said: ERROR - Precondition check failed.
WARNING: [youtube] Unable to download API page: HTTP Error 400: Bad Request (caused by <HTTPError 400: 'Bad Request'>); please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
WARNING: [youtube] Unable to download API page: HTTP Error 400: Bad Request (caused by <HTTPError 400: 'Bad Request'>); please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
[youtube] ocuW8pz5-eE: Downloading player 27422632
WARNING: [youtube] ocuW8pz5-eE: nsig extraction failed: You may experience throttling for some formats
         n = m96QHmZN-xrPvBNnb ; player = https://www.youtube.com/s/player/27422632/player_ias.vflset/en_US/base.js
[info] Available formats for ocuW8pz5-eE:
ID  EXT   RESOLUTION FPS CH │  FILESIZE  TBR PROTO │ VCODEC      ACODEC    ASR MORE INFO
───────────────────────────────────────────────────────────────────────────────────────────────────
sb3 mhtml 48x27        0    │                mhtml │ images                    storyboard
sb2 mhtml 80x45        0    │                mhtml │ images                    storyboard
sb1 mhtml 160x90       0    │                mhtml │ images                    storyboard
sb0 mhtml 320x180      0    │                mhtml │ images                    storyboard
18  mp4   640x360     25  2 │  18.41MiB 195k https │ avc1.42001E mp4a.40.2 22k [de] 360p, THROTTLED
 
Zuletzt bearbeitet:
Ich nutze ClipGrab sowie FreeTube unter Linux (EndeavourOS) & Windows 10.
Da gibt's alle paar Wochen ein "yt-dlp"-Update.
 
Ein Bekannter ist vom 4k Video.Downloader Plus so begeistert, dass er sich eine Lizenz gekauft hat.

Mit gefällt am yt-dlp, dass man alles auf einem Blick hat, jede Spur gezielt laden kann und es ist per Befehlszeilen-Option richtiggehend programmierbar.
 
Nach der anfänglichen Aufregung und nachdem ich es jetzt besser einschätzen kann, mein aktuelles Fazit:

Für mich ist LMDE zwar nichts, da ich gerne Kontrolle habe, aber für jemanden, der/die/das seinen/ihren PC einfach nur nutzen möchte, halte ich es weiterhin für eine sehr gute Wahl und M. E. ist der bestmögliche Einstieg in Linux.

Auch wenn die Installation leicht anspruchsvoller sein kann als bei der Ubuntu-Editon. Dafür ist man dann aber unabhängig von den Planungen und Machenschaften von Canonical, wodurch sich das mehr als auszahlt und man muss nur alle zwei Jahre eine neue Version installieren, statt alle 6 Monate, wenn man bei der Ubuntu-Edition u. a. den aktuellen Cinnamon nutzen möchte.

Nachtrag:

Anleitungen für das reguläre LinuxMint und auch Ubuntu können normalerweise auch für LMDE genutzt werden, solage es keine PPAs betrifft, da die Ubuntu-only sind.

Die Opera-KI hat das gut zusammengefasst:
Nutzung von Tutorials und PPAs bei Linux Mint und LMDE

Tutorials: Da LMDE und reguläres Linux Mint sehr ähnlich sind, lassen sich die meisten Anleitungen und Tutorials, die für Linux Mint geschrieben wurden, auch problemlos auf LMDE anwenden. Die grundlegenden Bedienkonzepte, Desktop-Umgebungen und viele Softwarepakete sind identisch oder sehr ähnlich.

PPAs (Personal Package Archives):

PPAs sind eine Besonderheit von Ubuntu und damit auch von regulärem Linux Mint, da sie auf Ubuntu basieren.

LMDE, das auf Debian basiert, unterstützt PPAs nicht, da Debian ein anderes Paketmanagement-System und andere Paketquellen nutzt.

PPAs können zwar zusätzliche Software oder neuere Versionen bereitstellen, sind aber oft aus unbekannten oder nicht verifizierten Quellen, was Sicherheitsrisiken und Stabilitätsprobleme verursachen kann.
Aus diesem Grund ist es tatsächlich empfehlenswert, PPAs mit Vorsicht zu nutzen oder ganz zu vermeiden, insbesondere wenn man Wert auf ein stabiles und sicheres System legt.

Fazit

Die fehlende Unterstützung von PPAs in LMDE ist kein großer Nachteil, sondern kann sogar als Vorteil gesehen werden, da es das System potenziell sicherer und stabiler macht. Die meisten Linux Mint Tutorials sind trotzdem anwendbar, was LMDE zu einer guten Alternative macht, wenn man eine Debian-basierte Distribution bevorzugt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
Moin. :)

Ich wurde wach, konnte nicht mehr einschlafen, also habe ich mir gedacht: "Guck doch mal, ob das deutsche LMDE-7 inzwischen aktualisiert wurde…" - Ja, schon vorgestern und da noch niemand einen neuen Fehler gemeldet hat, habe ich gut 1/3 meines Rest-Traffics dafür geopfert: s. Anhang

Ich habe es dann gleich online in KVM gebootet, um zu kontrollieren ob die Internetverbindung jetzt funktioniert:

KVM-online.png

Da es damit keine Probleme gab, habe ich es erst mal gesichert und anschließend eine Testinstallation gestartet:

Den LMDE-Ventoy-ESP-Fail gibt es wie erwartet weiterhin:
(auf die schnelle mit der vorgegebenen Partitionierung getestet: bei einer "richtigen" Installation natürlich nicht ext4 nutzen, sondern (wie in meinen Anleitungen beschrieben: s. u.) btrfs, damit Timeshift "echte" Snapshots nutzen kann)

LMDE-Ventoy-ESP-Fail.png

Dabei wurde es sogar im BIOS-Modus gebootet, wo keine ESP benötigt wird, da der nichts damit anfangen kann. - Im UEFI-Modos will der Installer sogar beide ESP in /boot/efi einhängen, was überhaupt nicht möglich ist.

Das hatte ich schon 2022 bei LMDE 5 gemeldet: Erst im LMU-Forum, aber weil die sich blöd angestellt haben, direkt beim Clement (die eMail-Adresse hatte ich von meiner Spende), er hatte sogar geantwortet und nach weiteren Details gefragt, aber geändert wurde offensichtlich gar nichts. - Übrigens gibt es den gleichen Bug auch beim ganz anderen Installer von MX-Linux (den auch CommodoreOS nutzt): Das ist offenbar ein "Debian-Ding".

Wenigstens brauche ich deshalb meine Installationsanleitungen nicht ändern. ;)
 

Anhänge

  • LMDE-7-de-DL.jpg
    LMDE-7-de-DL.jpg
    277,8 KB · Aufrufe: 33
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
Ich hatte gerade in anderen Kontext die Idee zu dem Spruch: "Die beste Art Probleme zu lösen, ist sie gar nicht erst zu verursachen." - Aber das passt auch gut dazu, weshalb ich kein Windows nach XP mehr produktiv einsetze.

Ich sage schon seit Jahren: Wenn Windows, dann ausschließlich offline (dann ist es nicht mal mehr für Microsoft "angreifbar") und am besten in einer VM unter Linux. - Tatsächlich läuft es in dieser Kombination stabil und zuverlässig: Ich kann mich nicht erinnern, dass ich damit schon mal einen BSOD hatte.

Während mit bei nativer Nutzung sogar schon mal ein BSOD abgestürzt ist:

20030824-134920 - Blue Screen.jpg
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: TPD-Andy
Da ich gestern noch knapp über 2 GiB Traffic hatte und ich es schon länger nicht mehr getestet habe, hatte ich begonnen das reguläre LinuxMint zu laden und mir eben den Rest geholt.

Die englische Version, weil es die deutsche nur über Sourceforge gibt und ich bezweifle, dass dort ein Resume am nächsten Tag noch möglich ist:

aria2c -{x,s}3 https://ftp-stud.hs-esslingen.de/pub/Mirrors/linuxmint.com/stable/22.2/linuxmint-22.2-cinnamon-64bit.iso

Auch dessen Installer, der immer noch sehr zäh zu bedienen ist und weiterhin nur ein winziges Fenster zur Zuordnung der Partitionen hat (natürlich nicht skalierbar - in der VM geht es noch, aber auf einem richtigen PC, mit mehreren Laufwerken ist das ein echter Krampf), spinnt wegen der ESP:

LM22.2.png

Ich hatte es im BIOS-Modus gebootet und das Ziellaufwerk war MBR-partitioniert, so dass diese Forderung gleich doppelt bescheuert ist.

Ich habe das ignoriert, nach über 10 Min. war die Installation endlich abgeschlossen und nachden ist es gebootet hatte, als erstes den zRAM-Bug getestet ("update-initramfs" hat zRAM immer als Resume-Device (also eine RAM-Disk für S2D! - Wie bekloppt ist das!) genutzt, so dass Ubuntu & Co. beim booten immer hängen blieben, weil es das da ja noch gar nicht gab), durch den alle auf Ubuntu 18.04 und 20.04 (dann hatte ich keine Lust mehr) basierenden Distribution betroffen waren, was einer der Hauptgründe für mich war, von Ubuntu % Co. die Finger zu lassen: Inzwischen lässt sich das nicht mehr reproduzieren und (oh Wunder) endlich wird auch nicht mehr ein zRAM-Device für jeden Kern erstellt: Das war so dämlich! zRAM war nur im allerersten Kernel (3.13) nur Singlethread: Schon ab Kernel 3.14 (von März 2014) wurden Multicores unterstützt! Aber Ubuntu hatte das selbst 6 Jahre später immer noch nicht mitbekommen.

Anderes, was was mit Ubuntu und Derivate, im Gegensatz zu LMDE und allen anderen getesteten Distributionen, nicht funktioniert hat, werde ich später noch testen. Aber für den Moment habe ich er mal genug. :)
 
Ich habe das reguläre LinuxMint 22.2 jetzt mal neben Windows installiert.

Dafür biete der Installer extra eine Option:

LM-Win-Inst_0.png

und die Speicherplatzaufteilung kann man dann beliebig verschieben:

LM-Win-Inst_1.png

Aber einerseits nur sehr ungenau (z. B. glatte 40,0 GB für Windows geht nicht - dass es auf dem Shot 54,0 GB sind, war Zufall: Ich habe das Screenshot-Tool dafür auf 4 Sek. und mit Mauszeiger gestellt und dann einfach verschoben, damit der Mauszeiger sich entsprechend ändert) und außerdem nur eine Partition: Weder kann man eine separate Home-Partition erstellen und noch nicht mal eine Swap-Partition.

Egal, ist ja nur ein Test also weiter:

LM-Win-Inst_2.png

Bekloppt: Bei LinuxMint wird einem Timeshift förmlich aufgezwungen, das nur vernünftig mit BTRFS-Snapshots arbeitet, aber trotzdem soll es mit ext4 formatiert werden, was man auch nicht ändern kann.

Also bin ich 2x zurück und habe "Etwas Anders" gewählt (s. o.), aber "Weiter" war ausgegraut!

Ich gehe noch einen weiter zurück und dann wieder vor, aber aber "Weiter" war immer noch ausgegraut. - Erst nach ca. einer halben Minute ließ es sich anklicken.

Hier wird deutlicher als vorhin, wie unpraktisch dieser kleine Bereich für die Partitionierung ist:

LM-Win-Inst_3.png

Und vor allem lahm: Nachdem ich die Partition für Linux mit btrfs hinzugefügt habe (Windows wurde oben schon verkleinert), dauerte es 6 Sek., bevor das übernommen wurde, und dann war die Anzeige wieder nach oben gesprungen. Will man mehrere Partitionen erstellen, passiert das jedes Mal.

Dann auf "Jetzt installieren", die Installation lief durch, währenddessen habe ich GParted gestartet um die vom Installer geänderte Partitonierung zu kontrollieren und das ist immer noch der gleiche Murks wie 2015, als ich von Windows XP zu LinuxMint wechselte:

LM-Win-Inst_4.png
LM-Win-Inst_5.png

Der letzte Sektor der Windows-Partition ist nicht ungerade, was er sein müsste, damit die Linux-Partition (bei korrektem Alignment) nahtlos folgen kann, sondern es gibt sogar eine Lücke von fast 2000 Sektoren.

Dafür ist die Gesamtzahl der Sektoren der Windows-Partition ungerade, was überhaupt nicht sein darf, weil das nicht auf glatte MiB (2048 Sektoren) aufgeht:

LM-Win-Inst_6.png

Es ist schon fast ein Wunder, dass wenigstens das Alignment der Linux-Partition passt.

Da die Installation immer noch lief, habe ich schon mal die bisher gemachten Screenshot zugeschnitten und als es dann fertig war und ich rebooten konnte, kam nicht mal ein grafisches Bootmenü:

LM-Win-Inst_7.png

Das ist LinuxMint 22.2! - Keine nagelneue Version, sondern schon das 2. Point-Release und damit seit einem ganzen Jahr "gepflegt"!!!

Als erstes habe ich getestet ob Windows überhaupt noch bootet (ja) und auch LinuxMint bootete.

Dann habe ich es platt gemacht und das gleiche mit dem gerade erst erschienenen LMDE 7 wiederholt (wieder mit der ursprünglichen Windows-Installation übers ganze Laufwerk):

Dessen Installer versucht gar nicht erst etwas an der Partitionierung zu ändern, sondern verweist auf GParted: Unten recht im schön großen, skalierbaren und vor allem sofort reagierenden Fenster (nicht immer wieder bis zu einer halben Minute Wartezeit):

LM-Win-Inst_8.png

Windows hatte ich auf glatte 40 GiB (40960 MiB) verkleinert und da GParted automatisch an glatte MiB ausrichtet, gab es auch keine Lücken.

Wahrend die Installation lief, habe ich die neue Screenshots bearbeitet und als ich dann rebooten konnte, sah das Bootmenü so aus:

LM-Win-Inst_9.jpg

Mein Fazit:

Entweder man will seinem PC nutzen, oder man installiert sich ein Ubuntu-Derivat…
 
Um das reguläre LinuxMint 22.2 und LMDE 7 direkt miteinander vergleichen zu können, habe ich beide auf einer leeren 120 GB SSD installiert (GPT in BIOS-Modus). Die Partitionierung habe ich vorab per GParted erstellt und die NTFS-Partition brauche ich für spätere Tests mit ntfs-3g und ntfs3.

Zuerst LinuxMint 22.2, weil es das ältere ist, dann LMDE 7 (beide auf btrfs, wegen der Timeshift-Snapshots):

LMvsLMDE.png
(Ach ja: Nervig am Installer von regulären LinuxMint (also dem von Ubuntu) finde ich auch, dass er die Swap neu formatiert: Zwar mit der selben UUID (so dass wenn eine schon installierte Linux-Distribution die nutzt, sie die Swap zumindest noch findet), aber der vorher vergebene Name ("Swap") ist dann weg: Auch das war schon 2015 so. - Vor allem: Wenn diese hypothetisch installierte Linux-Distribution in den Ruhestand runtergefahren wurde (der wird in der Swap gespeichert): Ist das weg, alle von der Distribution geöffneten Dateien vermutlich korrupt und alle nicht gespeicherten Daten verloren…)

Das merkwürdige: Anschließend war LinuxMint 22.2 nicht im Boot-Menü von LMDE 7!

Also habe ich LMDE 7 gebootet und sudo update-grub ausgeführt, aber auch dann wurde LinuxMint 22.2 nicht gefunden.

Dabei wird der OS-Prober eindeutig ausgeführt:

update-grub.png

Ich installiere Grub mit boot-directory auf LinuxMint 22.2, um das zu booten und dort sudo update-grub auszuführen, aber das findet dann LMDE-7 nicht! - Häh!?

Ich mache ich LinuxMint 22.2 platt und installiere es nochmal neu (weil das so lange dauert, schreibe ich das hier schon mal), ob es wenigstens bei der Installation LMDE 7 findet … nein! - Nachmal: HÄH!?

Was ist das denn?

Bei den Test neulich haben beide problemlos das vorinstallierte Windows gefunden, aber wieso finden die sich nicht gegenseitig?

Bekloppt.

Ich habe keine Lust mehr…



Ich habe die SSD komplett platt gemacht und es nochmal wiederholt, diesmal aber auf xfs, also ohne diesen Snapshot-Mist (während der LinuxMint 22.2 Installation habe ich mir Frühstück gemacht - während die LMDE 7 Installation nicht mal gereicht hat, es vollständig zu essen) und da hat es auf Anhieb funktioniert:

xfsGrub.jpg

Also lag es offenbar an diesem verfluchten @-Kram: Damit hat man nichts als Ärger.

Nachtrag: Meine LMDE-6-Testinstallation und das daraus hervorgegange LMDE-7 sind beide auf btrfs installiert (mit zStd-Komprimierung), aber mit der herkömmlichen Verzeichnisstruktur, also ohne @-Kram/Snapshots: Die haben beide keine Probleme sich gegenseitig zu erkennen. Also an btrfs liegt es nicht.

Nachtrag #2: Ich habe es nochmal mit zwei parallelen LMDE-7-Installationen nachgestellt: Auch die erkennen sich gegenseitig nicht, wenn sie mit diesem @-Kram/Snapshots installiert wurden: Egal ob ich diese behämmerte Partitionierung des Installers der regulären Ubuntu-Edition mit der unnützen ESP (im BIOS-Mode!) nachstelle, oder es ganz klassisch mit MBR und nur den beiden primären Partitionen für die beiden LMDEs partitioniere:

Egal was ich mache: Wird es auf btrfs installiert, wobei der Installer ungefragt diesen @-Kram einrichtet, wird es vom jeweils anderen LinuxMint (egal ob Ubuntu- oder Debian-Edition) nicht erkannt und man kann es nicht mehr booten.



Caramon2 schrieb:
die NTFS-Partition brauche ich für spätere Tests mit ntfs-3g und ntfs3
Da beide (LMUE links, LMDE rechts) immer noch standardmäßig ntfs-3g nutzen:

ntfs-3g.png

wollte ich hiermit (/etc/udev/rules.d/99-ntfs3.rules) ntfs3 erzwingen:
Code:
# ==1: mount filesystem to a shared directory (/media/VolumeName)
# ==0: mount filesystem to a private directory (/run/media/$USER/VolumeName)

SUBSYSTEM=="block",ENV{ID_FS_TYPE}=="ntfs",ENV{ID_FS_TYPE}="ntfs3",ENV{UDISKS_FILESYSTEM_SHARED}="0"
aber:

ntfs3.png

Bei LMDE 6 hat das noch funktioniert:

LMDE-6.jpg

Dass man ntfs-3g standardmäßig nutzt, ist ja noch OK, da es zwar viel langsamer ist, aber ntfs3 unter gewissen Umständen Probleme machen kann. Aber dass man es gar nicht nutzen kann, ist für mich ein no-go.

Ein Glück, dass ich Artix-Linux als Produktivsystem nutze.

Das ist übrigens ein weiterer Grund, der gegen Ubuntu-Derivate spricht: Dort hat diese udev-Rule noch nie funktioniert. (d. h. seit dem ntfs3 im Kernel ist)

Bei Artix nutze ich ntfs3 dagegen schon, seit dem ich es Feb. '21 im AUR gefunden habe (damals hatte ich mir die udev-Rule gesucht). Also sogar schon bevor es offiziell im Kernel war:
Das ist einem neuen NTFS-Kernel-Treiber namens "NTFS3" zu verdanken, den das Anfang November (2021) erwartete Linux 5.15 mitbringen wird.
https://www.heise.de/news/Linux-Ker...uers-NTFS-Dateisystem-integriert-6183326.html
 
Zuletzt bearbeitet:
Caramon2 schrieb:
Ich gehe noch einen weiter zurück und dann wieder vor, aber aber "Weiter" war immer noch ausgegraut. - Erst nach ca. einer halben Minute ließ es sich anklicken.
Dazu fällt mir gerade ein, dass ich neulich neulich unter bestmöglichen Bedingungen die Standardinstallation beider Versionen vergleichen habe:
  • Host auf "performance", damit Taktwechsel nicht bremsen
  • ISO und vHD in /tmph/ (s. o.) für maximale Geschwindigkeit

LinuxMint Ubuntu-Edition (immer die Gesamtdauer):
  • Livesysterm gebootet: 0:49 Min.
  • Installer gestartet: 1:17 Min. (der braucht eine halbe Min. zum starten)
  • schnellstmöglich durchgeklickt, bis die Installation läuft: 2:13 Min.
  • Installation fertig: 10:08 Min.
LinuxMint Debian-Edition (dto.):
  • Livesysterm gebootet: 0:41 Min.
  • Installer gestartet: 0:45 Min. (4 Sek.)
  • schnellstmöglich durchgeklickt, bis die Installation läuft: 1:21 Min.
  • Installation fertig: 6:46 Min.

Obwohl im BIOS-Modus gebootet, hat die Ubuntu-Edition eine ESP und eine BIOS-Boot-Partition erstellt, außerdem nutzt sie eine (langsame) Swap-Datei:

LMUE-Part.png

Zum Vergleich die Standard-Partitionierung Debian-Edition:

LMDE-Part.png

Was aber auch nicht gerade optimal ist:

Wie neulich schon geschrieben, wird einem bei LinuxMint Timeshift förmlich aufgezwungen, was aber nur mit btrfs-Snapshots vernünftig funktioniert. - Nutzt man aber btrfs mit diesem @-Kram (für Timeshift-Snapshots erforderlich), wird es aber nicht mehr von der jeweils anderen Edition erkannt (s. o.). - Was für ein Murks.

ntfs3 "darf" man inzwischen nicht mal mehr bei der Debian-Edition nutzen ( s. o.), Celluloid lässt sich beim upgrade-LMDE-7 weiterhin nicht mehr starten, wodurch ich idie Einstellungen nicht zurücksetzen kann, da es keine Konfig-Datei dafür gibt und ich ja nicht ins GUI komme. Und wer weiß was da noch alles ist, wovon ich nichts mitbekomme, da es ja nur eine Testinstallation ist, mit der ich nicht arbeite, sondern die ich nur zum aktualisieren boote und höchstens mal ein Bisschen drin rum klicke.

Ganz zu schweigen davon, dass der LMDE-Installer bei einer Neuinstallation zwingend die Systempartition formatiert, so dass es ziemlicher Blödsinn ist, alles auf eine Partition zu packen, weil dann auch alle Benutzerdaten gelöscht werden.
 
Caramon2 schrieb:
Dass man ntfs-3g standardmäßig nutzt, ist ja noch OK, da es zwar viel langsamer ist, aber ntfs3 unter gewissen Umständen Probleme machen kann. Aber dass man es gar nicht nutzen kann, ist für mich ein no-go.
Nochmal der Reihe nach:

Oben funktionierte ntfs3 weder beim jeweils frisch installierten (ohne Internetverbindung und Aktualisierungen) LinuxMint 22.2, noch LMDE 7.

Dann habe ich die "/etc/udev/rules.d/99-ntfs3.rules" bei meiner alten LMDE 6 Testinstallation hinzugefügt und ntfs3 funktionierte noch, obwohl ich die Installation weiter aktuell halte und alles, wo es möglich war, auf die Backports aktualisiert ist.

Dieses LMDE 6 habe ich neulich mit dem mint-upgrade-tool auf LMDE 7 aktualisiert (und seit dem auch aktuell gehalten), aber auch bei dem funktioniert ntfs3 nicht: Weder mit dem aktuellen 6.12er Kernel, noch dem aktuellen 6.16-Backport-Kernel.

Dabei ist mir übrigens aufgefallen, dass noch der Kernel 6.1 installiert war, den das mint-upgrade-tool (u. a.) unbedingt installieren musste, weil es von den Backports nichts wissen wollte. - Wer weiß, wie viel unnützer Müll es da noch gibt.

Wegen solcher Dateileichen habe ich nie etwas von solchen Upgrades gehalten: Schon Windows hatte ich deswegen immer mal wieder frisch installiert und selbst wenn mir damals das mint-upgrade-tool (17.3->18) die Installation nicht für mit irreparabel zerschossen hätte, hätte ich es anschließend platt gemacht und frisch installiert: Mit einem zugemüllten System (Dateileichen, schleichende Fehler, usw. - die es mit dem "toten" Kernel, dem "kaputten" Celluloid und wer weiß was noch alles, jetzt schon gibt), würde ich mich nicht wohl fühlen.

Wenn eine neue Hauptversion, dann immer frisch installieren, oder ein rolling Release nutzen, das solche Fisimatenten gar nicht erst macht: Das wird kontinuierlich aktualisiert und es wird nie eine neue Version geben.

Nachtrag:

Der 120 GB SSD habe ich per blkdiscard vollständig gelöscht und das LinuxMint-22.2-ISO vernichtet (gesichert hatte ich es gar nicht erst). Damit verschwende ich keine Zeit mehr.
 
Zuletzt bearbeitet:
Update:
Caramon2 schrieb:
Egal was ich mache: Wird es auf btrfs installiert, wobei der Installer ungefragt diesen @-Kram einrichtet, wird es vom jeweils anderen LinuxMint (egal ob Ubuntu- oder Debian-Edition) nicht erkannt und man kann es nicht mehr booten.
Mehr Details in dem Beitrag.

Btw:

Der letzte Teil der Umstieg zu Linux Reihe wurde jetzt auch veröffentlicht:

Sicherheit für Linux: Braucht man VPN und Virenschutz? (5/5)

Bzg. Backups hat er ein Interessentes Konzept:
  1. die kompletten Benutzerdaten sichert er mit einem nachinstallierten Backup-Programm auf einem ext. Laufwerk
  2. das System sichert er per Timeshift mit der rsync-Methode
Für 2. kann man auch ein externes Laufwerk wählen (dann muss man wie er die automatischen Snapshots deaktivieren und manuell sichern, da das Laufwerk natürlich nicht permanent angeschlossen sein sollte), dann hätte man dort eine Komplettsicherung und könnte sein System auch auf einem neuen Rechner schnell wiederherstellen, z. B. falls der alte plötzlich verreckt ist.

Aber natürlich nicht nur ein ext. Laufwerk, da auch das kaputt gehen kann (vorzugsweise natürlich gerade dann, wenn man es am dringendsten braucht - kennt man ja…), sondern mindestens zwei, besser drei, auf die man reihum sichert, damit man auch auf unterschiedliche Stände zurückgreifen kann: z. B. um eine Datei wiederherstellen zu könnte, die schon bei der letzten Sicherung gelöscht war und deshalb auch aus der Sicherung entfernt wurde.

Die rsync-Methode funktioniert mit jedem Dateisystem, so dass man btrfs nicht braucht und sich auch nicht mit diesem @-Kram herumärgern muss.

Monatlich, wie er es empfiehlt, finde ich aber viel zu wenig: Überlegt euch mal, wie viel ihr in einem Monat macht, was dazu kommt, was geändert/erweitert wird, usw.: Das wäre alles weg, falls der GAU unmittelbar vor der nächsten Sicherung passiert.

Ich aktualisierte mein Produktivsystem immer am Wochenende und wenn dabei nichts auffälliges schief geht, mache ich anschließend gleich eine Komplettsicherung (mit selbst geschriebenen Skripten). Das hat sich bewährt.

Außerdem sichere ich on demand nach jeder gravierenden Änderung, um sie in "trockenen Tüchern" zu haben. - Natürlich nur wenn es wie gewünscht funktioniert, ansonsten stelle ich die letzte Sicherung wiederher. Auch das hat sich bewährt.

Nachtrag:

Obwohl man bei Timeshift nur das Sicherungslaufwerk, nicht aber den Sicherungsordner ändern kann, gibt keine Konflikte, wenn man mehrere Installationen dort sichert (das ist LMDE-6):

Timeshift.jpg

Ich hatte das unter LMDE-6 eingerichtet und es gesichert, dann LMDE-7 gebootet und das auch dort gemacht und anschließend wieder bei LMDE-6, um zu kontrollieren, ob auch mit der anderen LMDE-Version dazwischen dann nur die Änderungen übertragen werden: Ja.

Also soweit scheint das gut zu funktionieren.

Dann habe ich LMDE heruntergefahren und die Sicherungspartition gelöscht, um ein nicht angeschlossenes Sicherungslaufwerk zu simulieren. Auch das hat Timeshift nicht weiter irritiert (diesmal LMDE-7):

Timeshift.png

Da es die UUID zur Identifikation nutzt, wird es auch keine Probleme geben, wenn das ext. Laufwerk z. B. erst als drittes Laufwerk angeschlossen wird und es nicht /dev/sdb sondern /dev/sdc ist.

Blöd ist nur, dass man nicht mehrere Sicherungslaufwerke definieren kann, obwohl es ja nun ziemlich dämlich laufen könnte (s. o.), wenn man nur eins hat.

Entweder muss man dann immer in den Einstellungen das aktuelle als Ziel bestimmen:

Timeshift-p.png

Oder man formatiert alle Sicherungslaufwerke mit der selben UUID: Da sämtliche Sicherungsinformationen im dortigen "timeshift"-Ordner gespeichert werden (nicht lokal), sollte Timeshift kein Problem damit haben, dass die Laufwerke unterschiedliche Sicherungsstände beinhalten.

Man muss dann nur darauf achten, dass man immer nur ein Sicherungslaufwerk angeschlossen hat, weil das sonst zu Konflikten führt.

Aber alles in allem erscheint mir das wesentlich bessere, sicherer und zuverlässiger, als sich auf btrfs-Snapshots zu "verlassen".

Wenn z. B. das Dateisystem des Systems beschädigt wird (was mir bei btrfs schon häufiger passiert ist), also gerade wenn man eine Sicherung braucht, sind auch die btrfs-Snapshots mit betroffen: btrfs-Snapshots sind KEINE Sicherungen!

Die darf man allerhöchstens als eine Art Undo-Funktion ansehen. - Genau wie die damit vergleichbaren Wiederherstellungspunkte von Windows: Die habe ich nach einer Neuinstallation immer gleich deaktiviert, da in meinen Augen eine nutzlose Verschwendung von Plattenplatz.
 
Zuletzt bearbeitet:
Caramon2 schrieb:
Bzgl. Backports ist yt-dlp der beste Vergleich, da das laufend aktualisiert werden muss, da vor allem YouTube immer wieder etwas ändert, wodurch es nicht funktioniert. Manchmal sogar schon nach wenigen Tagen.

Hier kann man sehen, wie häufig das gemacht werden muss: Archive Artixlinux: yt-dlp

Bei LMDE 6 sieht es aktuell so aus:

[] [IMG]https://www.computerbase.de/forum/attachments/lmde6-yt-dlp-png.1667853/[/IMG] [/]
Schon beim Release im Oktober 2023 war das Stardard-yt-dlp hoffnungslos veraltet und selbst mit dem Backport kann man inzwischen nichts mehr anfangen, da es seit April nicht mehr aktualisiert wurde.
Ich habe gerade das LMDE 6 Livesystem (Stand Okt. '23) gebootet: Schon da war schon yt-dlp 2023.07.06 vorinstalliert: Das wurde in der Standad-Version also niemals(!) aktualisiert. - Obwohl es schon beim Release veraltet war und Probleme mit YouTube hatte.

Also zumindest bei yt-dlp (Abhängigkeit von mpv, worauf Celluloid basiert) ist man zwingend auf den Backport angewiesen.

Ansonsten sollte man Backports nur dort nutzen, wo man sie wirklich braucht, da jedes Backport beim Upgrade zur nächstem LMDE-Version erst wieder auf die normale Version zurück installiert werden muss: s. o. - Das macht im Endeffekt zwar keine Probleme (anders als ich es bisher von solchen Upgrades kannte), ist aber nervig. (s. o. ;))

Caramon2 schrieb:
Übrigens startet Celluloid bei LMDE-7 nicht:

[IMG]https://www.computerbase.de/forum/attachments/celluloid-png.1667856/[/IMG]
Das Unterverzeichnis gibt es nicht: Offenbar wird es erst von der neuen Celluloid-Version von LMDE-7 benötigt, weshalb es nicht von LMDE-6 übernommen werden konnte und Celluloid zu blöd ist, das Verzeichnis selbst anzulegen:

Nachdem ich es erstellt habe (einfach ein leeres Verzeichnis) gibt es diese Fehlermeldung nicht mehr. Celluloid startet aber trotzdem nicht, weil dieses libcuda* nicht geladen werden kann: Definitiv ein Bug, da das zum nVidia-Treiber gehört und ja nicht jeder eine nVidia-GraKa hat.
Diese Fehlermeldungen kommen auch beim LMDE 7 Livesystem und wenn es installiert und aktualisiert ist, trotzdem startet dort Celluloid. Also liegt es nicht daran.

Dann bleiben eigentlich nur noch die von mir gesetzten "zusätzliche mpv-Optionen" (neben hwdec auch Frameraten-Interpolation, usw.), woran sich die neue Version stößt, aber da es keine eigene Konfigurationsdatei nutzt und es irgendwo anders speichert, könnte ich die nur in den Einstellungen des GUIs entfernen, was aber nicht geht, da das GUI ja eben nicht mehr startet… :freak:

Also besser man ändert gar nichts an solchen Voreinstellungen: Hätte ich Celluloid auf Standard gelassen, würde es vermutlich noch funktionieren.

Gibt es dagegen eine Konfigurationsdatei, wie z. B. die ~/.config/mpv/mpv.conf, kann man ruhig "optimieren", da es sich ja jederzeit wieder ändern, oder sie sich einfach löschen lässt (s. man mpv für die Dokumentation):
Code:
hwdec
gpu-api=opengl
deinterlace=auto
scale=spline36
idle=once

interpolation
tscale=oversample
video-sync=display-resample-vdrop

osd-duration=2000
osd-on-seek=msg-bar
osd-bar-align-y=-.985
osd-bar-w=93
osd-bar-h=1
osd-blur=1

autofit-larger=99%x95%
audio-channels=auto
cache-pause-initial=yes

Caramon2 schrieb:
Bzg. Backups hat er ein Interessentes Konzept:
  1. die kompletten Benutzerdaten sichert er mit einem nachinstallierten Backup-Programm auf einem ext. Laufwerk
  2. das System sichert er per Timeshift mit der rsync-Methode
Für 2. kann man auch ein externes Laufwerk wählen (dann muss man wie er die automatischen Snapshots deaktivieren und manuell sichern, da das Laufwerk natürlich nicht permanent angeschlossen sein sollte), dann hätte man dort eine Komplettsicherung und könnte sein System auch auf einem neuen Rechner schnell wiederherstellen, z. B. falls der alte plötzlich verreckt ist.
Nachdem ich darüber geschlafen habe, halte ich das für die vernünftigste Art LMDE zu installieren und zu nutzen:

Alles möglichst standardmäßig, damit bei Fragen in Foren nicht von falschen Voraussetzungen ausgegangen wird, einzig eine separate Home-Partition halte ich, wie schon beschrieben, für notwendig, da der LMDE-Installer die Systempartition zwingend formatieren will. - Das sollte man bei Fragen erwähnen.

Meine beiden Testinstallationen (LMDE 6+7) habe ich deshalb platt gemacht und LMDE 7 frisch installiert *), um daran dann meine Anleitungen anzupassen und durchzuspielen. - Inzwischen habe ich ja einen Überblick, was man bzgl. Upgrade, paralleler Installationen und Konfigurationsänderungen beachten muss.

Die in #73 sind damit obsolet: Man kann es natürlich trotzdem auf btrfs+Snapshots installieren, aber ich rate aus den letztens beschriebenen Gründen davon ab.


*) Aus "historischen" Gründen habe ich diesmal grün auf (fast) schwarz gewählt:

LMDEgrün.jpg

In der höheren Handelsschule haben wir damals (1986-88) an originalen IBM-XTs gelernt: Mit zwei Diskettenlaufwerken, keiner Festplatte, mit MS-Word, MS-Multiplan und MS-Charts, auf einem Grün-Monitor.

Im Informatik-Unterricht wurden sogar noch Lochkarten und Lochstreifen behandelt. ;)
 
Ich habe gerade zwei kleine Tools als Flatpak installiert (wegen der riesengroßen Downloads, Aktualisierungen und Plattenbelegung (auch in den Sicherungen) nutze ich die nicht), um bzgl. sinnvoller Partitionsgrößen zu sehen, wo die gespeichert werden: Ich hatte gedacht, wie Wine-Anwendungen im Benutzerorder, da Benutzrechte für die Installation reichen. - Zur systemweiten Installation braucht man ja sudo.

Aber die kommen trotzdem auf die Systempartition: Heruntergeladen werden die nach /var/tmp/ und installiert in /var/lib/flatpak/.

Diese beiden kleinen Tools hatte ich installiert:

Flatpak_1.png

und dieser ganze Ramsch wird dafür benötigt:

Flatpak_2.png

Zum Vergleich: Die komplette LMDE 7 Installation belegte vorher gerade mal 6,04 GiB (6,5 GB)!

Nicht mal nur einmalig, sondern ich habe z. B. schon mal in einem YouTube-Video zu Flatpak gesehen, dass z. B. von den jeweiligen *.Platfrom mehrere unterschiedliche Versionen installiert waren, weil das eine Flatpak brauchte z. B. Version 1.0, ein anderes die Version 1.2, usw.

Nachtrag::

Flatpak-Dupes.png
Caramon2 schrieb:
davon waren 40 GiB nur Flatpak. - Da er das sowieso regelmäßig macht, konnte auch flatpak uninstall --unused nichts entfernen, weshalb er dann einige Flapaks entfernt hat, die er nicht mehr braucht: Obwohl es nur wenige waren, hat das mehrere GiB frei gemacht. Flatpaks sind mit ihrem drum herum eben absurd groß!

Also der gleiche Mist wie z. B. bei diesem Visual C++ für Windows: Ich hatte mir mal um eine alte Windows 7 Pro x64 Installation angesehen, weil die immer länger zum starten brauchte und immer langsamer wurde: Dort waren davon an die zehn verschiedene Versionen installiert und auch anderes war in mehreren Versionen installiert.

Ich hatte Flatpak damals schon mal bei LMDE 6 getestet (daher weiß ich das mit den riesengroßen Aktualisierungen), da gab es noch weitere Probleme. - Meinen Erfahrungsbericht hatte ich in mein Google-Drive hochgeladen (ist auch im Eröffnungsbeitrag verlinkt): LMDE (4) Flatpak.pdf

Ich nutze die normalen Systempakete (.deb) und ansonsten AppImages: Die sind sehr viel handlicher und brauchen nicht mal installiert zu werden: Einfach laden, als ausführbar markieren und starten.
 
Zuletzt bearbeitet:
Hier habe ich ein Video angehängt, wie man LMDE 7 neben einem im UEFI installierten Windows 11 installiert: Klick

Quasi wie in meiner alten "parallel zu Windows"-Anleitung, aber ohne Swap und wegen der @kram-Problematik nicht auf btrfs: Nur um mal den Ablauf zu zeigen. - "In echt" würde die Installation auch so funktionieren.
 
Sorry, aber dein Erfahrungsbericht bzgl. Flatpaks ist für die Tonne ...
Ich nutze ganz gerne Flatpaks, weil die einfach Vorteile haben, wenn man aktuelle Programmversionen haben will. Eben da, wo die "normale" Paketverwaltung an ihre Grenzen kommt, weil Abhängigkeiten nicht aufgelöst werden können.
Das ganze Flatpak-System ist sozusagen eine eigene Paketverwaltung parallel und unabhängig zur "normalen" Paketverwaltung.
 
@garfield121: Dass der sehr subjektiv ist, stelle ich ja gleich zu Anfang klar:
Wenn man Flatpak nutzt (hier eine neutralere Beschreibung), sollte man als erstes "Flatseal" installieren, um Kontrolle über die Berechtigungen zu bekommen:
[Screenhot von Flatseal]
Mehr kann ich dazu nicht sagen, weil jedes Mal, wenn ich mich damit beschäftige, es darauf hinausläuft, dass ich mich darüber aufregen muss:
Für mich taugt Flatpak definitiv nichts, was ich dort und hier begründet habe.

Bzgl. normale Paketquellen habe ich gerade eben ein YouTube-Video gesehen:

CachyOS löst die Probleme, die ich mit Debian auf dem Desktop habe. Ein Erfahrungsbericht - Linux-Guides

Bzgl. der Software-Quellen gilt das für alle Arch-Derivate, da die überwiegend die gleichen Paketquellen nutzen, oder man sie von anderen Arch-Distributionen einfach übernehmen kann. EndeavourOS soll ziemlich benutzerfreudlich sein, bei Installation die passenden Treiber vorschlagen, usw.

Ich nutze z. B. Artix-Linux, ein Arch-Derivat ohne systemd (deshalb keine Empfehlung) und habe dort auch die originalen Arch-Paketquellen eingerichtet, das Chaotic-AUR von Garuda und das normale AUR kann ich natürlich auch nutzen.
 
Caramon2 schrieb:
Also der gleiche Mist wie z. B. bei diesem Visual C++ für Windows
Das ist ziemlich abwegig, die berüchtigte Windows "DLL-Hölle" mit Flatpak zu vergleichen.
Wie ich schon erwähnt hatte, Flatpak ist eine eigene Paketverwaltung, die Updates sind oft sogar sehr klein, weil nur die Differenzen heruntergeladen werden, nicht jedes mal die komplette Runtime.
Stichwort OSTree:
https://docs.flatpak.org/en/latest/under-the-hood.html

Der Screenshot von den Flatpak-Paketen zeigt vor allem, das da lange nicht mehr aufgeräumt wurde, dann würden die veraltetetn Runtimes entfernt werden.
Code:
flatpak uninstall --unused
 
Zurück
Oben