Test Drei externe SSDs im Test: Lexar SL500 Portable vs. Kingston XS2000 & XS1000

Clark79 schrieb:
Empfehlungen für jeweilige Cases
Was ASM2364 und 20Gbps angeht - fast alle Usb3.2 Gen2x2 Cases seit Anfang. Ja, es gibt seit einem halben Jahr auch Gen2x2-Brückenchips von JMicron und Realtek - alle zusätzlich mit SATA-Unterstützung (was kaum einen Sinn ergibt, denn so einen Case kauft man mit Fleiß um eine NVMe-SSD zu nutzen. Kein B-Key/Sata (was bei 20Gbps-Cases immer noch zu 99% ist) -> Asmedia = leicht zu erkennen.
Und was ASM235CM angeht -> vor allem von Ugreen in allen letzten Modellen eingesetzt. Bestes Gehäuse für 2,5"-SATA mit dieser Brücke -> Ugreen CM300. Habe paar Stück ganz günstig bei Release geschnappt, sind jetzt aber mind. doppelt so teuer und Alu muss nicht unbedingt sein - SATA-SSDs überhitzen nicht wirklich.
Also kannst getrost eine billigere Plastik-Variante nehmen, Innereien sind momentan identisch (früher in den gleichen Cases wurden ältere Chips eingesetzt - also keine Ladenhüter in kleinen Shops kaufen - am besten einfach im Online-Shop des Herstellers, es gibt oft Sales). Geschwindigkeiten sind kaum schlechter, als intern über SATA (schlechte Bewertungen sind meist von Noobs mit alten PCs am USB3.0 entstanden), hier als Beispiel mit einer 870Evo:
1716994029369.png
 
  • Gefällt mir
Reaktionen: Benjamin_Blume und Clark79
Jo Lexar ist eben das neue Samsung!
 
  • Gefällt mir
Reaktionen: Benjamin_Blume
Ich habe mir vorgestern die 2 TB XS1000 bestellt: Ausschlaggebend war für mich das kompakte Gehäuse, da sie sogar in die kleine USB-Stick-Tasche vorne rechts bei Jeans passt.

Ich werde sie LUKS-verschlüsselt formatieren, da sie als zusätzliche Sicherung aller meiner Daten (ca. 1 TB) gedacht ist, die ich jederzeit aktualisieren kann und einfach mitnehme, wenn ich die Wohnung verlasse:

Egal was in meiner Abwesenheit hier passiert (z. B. Wohnungsbrand: da ich in der Dachwohnung wohne, ist es egal in welcher es beginnt), ich habe meine Daten sicher dabei und da ich es als bootfähige Kopie meines Produktivsystem erstellen werde, kann ich es sofort an jedem x84-64 PC booten, der im BIOS-Modus/CSM von USB booten kann.

Ich komme so über meine gewohnte Arbeitsumgebung sofort z. B. an meine Versicherungsunterlagen, Kontodaten, Passwörter, usw.
 
Ich habe die 2 TB XS1000 gebencht und komme auf andere Ergebnisse: Offenbar wurde sie etwas überarbeitet.

Die Lesegeschwindigkeit ist über die gesamte Kapazität ziemlich konstante 804-805 MB/s, aber schreiben tut sie nur mit schwankenden 530-550 MB/s.

Dafür war der SLC-Cache erst nach 372 GiB voll. - Ich vermute, dass vorher schon etwas vom SLC-Cache geschrieben wurde, wodurch er zwar etwas langsamer war, dafür aber deutlich länger reichte. Bei 472 GiB habe ich abgebrochen, da ich sie nicht unnötig "quälen" wollte.

Auch sank die Schreibgeschwindigkeit nicht schlagartig auf den langsamen Wert (wie bei allen anderen bisher von mir getesteten SSDs), sondern etwas verzögert.

Anbei eine Tabelle mit den ermittelten Werten + Diagramm des Einbruchs ab 372 GiB und wie ich gebencht habe.
 

Anhänge

Caramon2 schrieb:
Ich habe mir vorgestern die 2 TB XS1000 bestellt:
Und schon kaputt!

Heute bin ich endlich dazu gekommen sie einzurichten, aber nachdem ca. ein halbes TB drauf kopiert war, brach es plötzlich ab und die SSD war nicht mehr ansprechbar.

Ich reboote den PC, aber beim POST bleibt er hängen. - Das gleiche nach einem Hardreset.

Ich ziehe die SSD ab + Hardreset und der PC fährt hoch.

Ich schließe die SSD wieder an, alles scheint in Ordnung zu sein: Die Systempartition lässt sich normal öffnen, xfs meldet clean mount, alles scheint noch da zu sein, aber als ich sie trimmen will, hagelt es im parallel laufenden "dmesg -w" Fehlermeldungen.

Die Partition lässt sich aber noch normal aushängen, ich reboote nochmal, aber der PC bleibt mit der SSD (egal an welchem der beiden USB3-Controller des Board sie angeschlossen ist) wieder beim POST hängen (auch kurz ausschalten + Steckdosenleiste aus) ändert nichts.

Schließe ich sie nach dem booten an, wirkt alles normal, aber die verschlüsselte Homepartition kann ich zwar entsperren, aber nicht einhängen: Da die SSD sich ja beim drauf kopieren verabschiedet hat, will xfs das Jounal wiederherstellen, was aber nicht möglich ist:

Auf die komplette SSD lässt sich nur readonly zugreifen: Nicht mal ein Secure-Erase ist noch möglich!

Nur manuell mit der Mount-Option "norecover" kann ich die Homepartition einhängen (daher weiß ich wie viel drauf kopiert wurde).

Gut dass die Homepartition verschlüsselt ist, sonst wäre das echt ein Problem, weil meine sämtlichen Daten vom PC schon drauf sind (Bankverbindung, Kontoauszüge, Passwörter, usw.): Die könnte ich so doch nicht zurück schicken!

Der Fehler passierte beim kopieren des Videoarchivs. - Von einer 1 TB HD, die durchschnittlich ca. 150 MB/s liefert: Die SSD war beim schreiben also alles andere als am Anschlag und fühlte sich auch nur lauwarm an.

Morgen - d. h. heute werde ich bei Reichelt anrufen, was die dazu sagen: Übrigens meine erste Bestellung dort. Fängt also richtig gut an. :)
 
Moin.

Da sie intern vielleicht doch zu heiß wurde (SMART lässt sich leider nicht auslesen) und erst länger abkühlen musste, habe ich es eben nochmal versucht.

PC gebootet und die SSD erst dann angeschlossen, dabei keine Auffälligkeiten:
Code:
[   49.424534] usb 9-1.3: new SuperSpeed USB device number 4 using xhci_hcd
[   49.448985] usb 9-1.3: New USB device found, idVendor=0951, idProduct=1780, bcdDevice= 1.00
[   49.448997] usb 9-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   49.449003] usb 9-1.3: Product: XS1000
[   49.449008] usb 9-1.3: Manufacturer: Kingston
[   49.449012] usb 9-1.3: SerialNumber: 50026B72833E9A65
[   49.488949] usbcore: registered new interface driver usb-storage
[   49.504234] scsi host6: uas
[   49.504430] usbcore: registered new interface driver uas
[   49.507049] scsi 6:0:0:0: Direct-Access     Kingston XS1000           1000 PQ: 0 ANSI: 6
[   49.528289] sd 6:0:0:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[   49.597269] sd 6:0:0:0: [sdc] Write Protect is on
[   49.597279] sd 6:0:0:0: [sdc] Mode Sense: 03 00 80 08
[   49.598262] sd 6:0:0:0: [sdc] No Caching mode page found
[   49.598271] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[   49.675627]  sdc: sdc1 sdc2 sdc3
[   49.675987] sd 6:0:0:0: [sdc] Attached SCSI disk
Dann wollte ich die Partitionstabelle ("#" = als root) überschreiben:
Code:
# lw=/dev/sdc;dd if=/dev/zero of=$lw oflag=direct status=progress bs=1M count=1
dd: '/dev/sdc' konnte nicht geöffnet werden: Das Dateisystem ist nur lesbar
Dto. bei blkdiscard ("-fv" = force+verbose)
Code:
# blkdiscard -fv $lw
blkdiscard: /dev/sdc kann nicht geöffnet werden: Das Dateisystem ist nur lesbar
Und beim Secure-Erase hatte ich natürlich auch nichts anderes erwartet:
Code:
# hdparm -I $lw|grep -ie frozen -e trim
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       *    Data Set Management TRIM supported (limit unknown)

# hdparm --security-set-pass NULL $lw 
security_password: ""

/dev/sdc:
 Issuing SECURITY_SET_PASS command, password="", user=user, mode=high
The running kernel lacks CONFIG_IDE_TASK_IOCTL support for this device.
SECURITY_SET_PASS: Invalid argument
"dmesg" zeigte:
Code:
[  191.094277] sd 6:0:0:0: [sdc] tag#26 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT 
[  191.094291] sd 6:0:0:0: [sdc] tag#26 CDB: ATA command pass through(16) 85 0a 06 00 00 00 01 00 00 00 00 00 00 40 f1 00
[  191.094341] xhci_hcd 0000:02:00.0: ERROR Transfer event for unknown stream ring slot 5 ep 1
[  191.094354] xhci_hcd 0000:02:00.0: @00000000bfffc540 00000000 00000000 1a000020 05028000
[  191.110890] scsi host6: uas_eh_device_reset_handler start
[  191.188193] usb 9-1.3: reset SuperSpeed USB device number 4 using xhci_hcd
[  191.213718] scsi host6: uas_eh_device_reset_handler success
Der eigentliche Secure-Erase hat dann natürlich auch nicht funktioniert:
Code:
# hdparm --security-erase NULL $lw
security_password: ""

/dev/sdc:
 Issuing SECURITY_ERASE command, password="", user=user
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Als es nach fast einer halben Stunde immer noch nicht weiter ging, habe ich die SSD wieder abgezogen:
Code:
The running kernel lacks CONFIG_IDE_TASK_IOCTL support for this device.
SECURITY_ERASE: Invalid argument
"dmesg":
Code:
[ 1929.856488] usb 9-1.3: USB disconnect, device number 4
[ 1929.856681] xhci_hcd 0000:02:00.0: ERROR Transfer event for unknown stream ring slot 5 ep 1
[ 1929.856688] xhci_hcd 0000:02:00.0: @00000000bfffc7e0 00000000 00000000 1a000000 05028000
[ 1929.856971] sd 6:0:0:0: [sdc] tag#25 uas_zap_pending 0 uas-tag 1 inflight: CMD 
[ 1929.856979] sd 6:0:0:0: [sdc] tag#25 CDB: ATA command pass through(16) 85 0a 06 00 00 00 01 00 00 00 00 00 00 40 f4 00
Nach dem wieder anschließen war alles wie diese Nacht.

Die Systempartition ließ sich öfnen, die verschlüsselte Homepartition zwar entsperren, dann aber wieder nicht öffnen, da das "recovery" nicht umgesetzt werden konnte:
Code:
[ 2071.418507] XFS (sdc2): Mounting V5 Filesystem 3bab5d41-420e-4104-bcdc-83dee87beccf
[ 2071.434528] XFS (sdc2): Ending clean mount

[ 2087.152219] Key type encrypted registered

[ 2089.457562] XFS (dm-0): Mounting V5 Filesystem aa99f57f-a14f-4d38-824b-01154de5f098
[ 2089.499641] XFS (dm-0): recovery required on read-only device.
[ 2089.499648] XFS (dm-0): write access unavailable, cannot proceed.
[ 2089.499650] XFS (dm-0): log mount/recovery failed: error -30
[ 2089.499725] XFS (dm-0): log mount failed

LWa.png
LWb.png
 
  • Gefällt mir
Reaktionen: massaker
Um nichts zu übersehen, habe ich die Allwissende Müllhalde™ (aka das Internet - kennt jemend noch die Fraggles) gefragt. Genauer gesagt die "Browser-KI" vom Android-Opera, das tatsächlich einige interessante Möglichkeiten geliefert hat, aber alle erfolglos.

Also mit an Sicherheit grenzender Wahrscheinlichkeit :) tatsächlich ein Hardware-Defekt:
Andreas:
Weshalb ist meine Kingston XS 1000 plötzlich immer schreibgeschutzt und lässt sich nicht mal mehr löschen?
Aria:
Es gibt mehrere mögliche Gründe, warum deine Kingston XS 1000 plötzlich schreibgeschützt ist und sich nicht mehr löschen lässt. Hier sind einige häufige Ursachen und mögliche Lösungen:

Mögliche Ursachen

Physischer Schreibschutz: Überprüfe, ob der USB-Stick einen physischen Schreibschutzschalter hat, der aktiviert sein könnte.
Dateisystemfehler: Das Dateisystem könnte beschädigt sein, was zu Schreibschutzproblemen führt.
Viren oder Malware: Schadsoftware könnte den Schreibschutz aktivieren, um die Daten zu schützen.
Betriebssystemeinstellungen: Manchmal können die Einstellungen des Betriebssystems den Schreibschutz aktivieren.

Mögliche Lösungen

1. Überprüfen des Schreibschutzschalters:

Wenn vorhanden, stelle sicher, dass der Schalter auf "entsperrt" steht.
2. Formatieren des USB-Sticks:

Versuche, den USB-Stick zu formatieren. Dies kann jedoch alle Daten löschen.
Gehe zu "Dieser PC", klicke mit der rechten Maustaste auf den USB-Stick und wähle "Formatieren".
3. Überprüfung auf Viren:

Scanne den USB-Stick mit einem aktualisierten Antivirenprogramm.
4. Verwendung von Diskpart (Windows):

Öffne die Eingabeaufforderung als Administrator.
Gib diskpart ein, dann list disk , um deine Laufwerke anzuzeigen.
Wähle den USB-Stick mit select disk X (ersetze X durch die Nummer deines USB-Sticks).
Gib attributes disk clear readonly ein, um den Schreibschutz zu entfernen.
Test an einem anderen Computer:

Schließe den USB-Stick an einen anderen Computer an, um zu prüfen, ob das Problem weiterhin besteht.

Wenn die oben genannten Schritte das Problem nicht lösen, könnte es sein, dass der USB-Stick defekt ist. In diesem Fall wäre es ratsam, den Kundendienst von Kingston zu kontaktieren.
Andreas:
1. ist nicht vorhanden. 2. geht nicht weil schreibgeschützt (nicht mal ein secure-erase funktioniert). 3. es gibt auf meinem System keine Schädlinge und es sind auch keine anderen Laufwere betroffen. 4. ich nutze Linux
Aria:
Danke für die zusätzlichen Informationen! Hier sind einige spezifische Schritte, die du unter Linux ausprobieren kannst, um den Schreibschutz auf deiner Kingston XS 1000 zu umgehen:

Mögliche Lösungen für Linux

1. Überprüfen des Schreibschutzstatus:

Öffne ein Terminal und führe den folgenden Befehl aus, um den Status des Laufwerks zu überprüfen:

lsblk -o NAME,SIZE,RO

Achte darauf, ob das Laufwerk in der Spalte "RO" (Read-Only) als "1" angezeigt wird.
Versuch, den Schreibschutz aufzuheben:

2. Du kannst die hdparm -Befehlszeile verwenden, um den Schreibschutz zu überprüfen oder zu ändern:

sudo hdparm -r0 /dev/sdX

Ersetze /dev/sdX durch den entsprechenden Gerätenamen deiner SSD.
Verwendung von parted :

3. Starte parted im Terminal:

sudo parted /dev/sdX

Gib dann den Befehl print ein, um die Partitionstabelle anzuzeigen.
Überprüfe die Statusinformationen und versuche, den Schreibschutz zu entfernen.
Datenrettung und Neuformatierung:

4. Falls die oben genannten Schritte nicht funktionieren, könntest du versuchen, mit ddrescue oder testdisk eine Datenrettung durchzuführen, bevor du einen letzten Versuch unternimmst, den USB-Stick zu formatieren:

sudo ddrescue /dev/sdX /path/to/image.img /path/to/logfile.log

Danach kannst du mit gparted oder mkfs eine neue Partition erstellen.
Hardware-Defekt prüfen:

5. Wenn alle oben genannten Schritte nicht funktionieren, könnte es ein Hardware-Defekt sein. In diesem Fall ist es ratsam, Kontakt mit dem Kingston-Support aufzunehmen.

Bitte führe die Befehle vorsichtig aus, insbesondere wenn du mit dd oder parted arbeitest, da falsche Eingaben zu Datenverlust führen können.
Andreas:
1. Zeigt beim betreffenden Laufwerk und sämtlichen Partitionen RO=1 an.
2. (sudo hdparm -r0 /dev/sdc*) will beim Laufwerk und den Partitionen RO=0 setzen, es bleibt aber alles auf RO=1.
3. zeigt eine Warnung, dass das Laufwerk nicht zum schreiben geöffnet werden kann und deshalb nur lesbar geöffnet wird. Es gibt keine Option, den Schreibschutz zu ändern.
4. ist egal, da keine Daten gerettet werden müssen und die Formatierung funktioniert nicht, da readonly.
scheint am wahrscheinlichsten, da das Laufwerk neu ist und es passierte, während ich erstmals meine Daten drauf kopiert habe: Nach ca. 500 GB.
Dann fing es an sich im Kreis zu drehen: neue Firmware flashen (die es nicht gibt und wegen Schreibschutz vermutlich sowieso nicht möglich wäre), oder das Laufwerk auseinander bauen (das winzige Ding, was sich vermutlich nicht mal zerstörungsfrei öffene lässt) und versuchen es selbst zu reparieren (klar), usw.

Heute bin ich nicht dazu gekommen Reichelt anzurufen, aber da erst letzten Do. geliefert, eilt es ja noch nicht.

Zumindest bin ich jetzt sicher, dass es nichts mehr gibt was ich vielleicht testen soll, das ich nicht schon getestet habe, oder fundiert ausschließen kann. :)
 
Ich bin heute erst dazu gekommen bei Reichelt anzurufen:

Bzgl. dass alle meine Daten drauf sind (Bankverbindungen, Versicherungen, Passwörter für alle meine Konten wie eBay, PayPal, usw.) und ich sie nicht mehr löschen kann (auch ein Secure-Erase funktioniert nicht), gab es nur zwei Möglichkeiten:

1. ich schicke sie trotzdem ein: Sowohl Reichelt als auch der Hersteller sind bei Datenträgern dazu verpflichtet das vertraulich zu behandeln.

2. ich behalte sie und bleibe auf den Kosten sitzen (was ich mir nicht leisten kann)

Da ich die Home-Partition verschlüsselt erstellt hatte (davon hatte ich gegenüber Reichelt nichts gesagt) und niemand ohne unverhältnismäßig großen Aufwand an die Daten kommen kann, habe ich mich natürlich für 1. entschieden.

Dass ich die SSD physisch zerstöre (mit dem Bohrer durch den Speicherchip) ist keine Option, da es dann nicht mehr als Garantiefall anerkannt wird.

Fazit:

Nutzt Verschlüsselung, wo immer es sinnvoll ist. - Man weiß nie was vielleicht passiert.
 
  • Gefällt mir
Reaktionen: Blackland und massaker
@massaker: Danke für dein "gefällt mir". Dadurch ist mir aufgefallen, dass ich gar nichts zur neuen XS1000 geschrieben hatte. :)

Dafür jetzt einschließlich "Bauanleitung":

Die Reklamation hat anstandslos geklappt, aber da sie nicht mehr lieferbar war, habe nicht gleich eine neue bekommen. Die neue hat das Aufspielen der Daten überlebt (zweimal, da ich sie seit dem nochmal komplett neu aufgesetzt habe) und sie zeigt auch keine anderen Auffälligkeiten. Die Leistungsdaten waren wie bei der ersten.

Ursprünglich wollte ich die SSD als "SoS" erstellen (s. hier), aber ich hatte mir inzwischen überlegt, dass es keine gute Idee wäre meine Hauptdatensicherung überall zu booten wo ich das SoS brauche.

Deshalb habe ich sie per Ventoy bootfähig gemacht: Hauptsache ich komme an meine Daten und kann das System bei Bedarf wiederherstellen. - Ist das Livesystem schon auf dem Sicherungsmedium, brauche ich keinen extra USB-Stick.

XS1000.png


Ventoy.png

Wie ich meine Sicherungen durchführe, hatte ich hier beschrieben und mit Video gezeigt.

LMDE habe ich vorausgewählt, da es für alte PCs deutlich kompatibler ist: Die neue SSD funktioniert auch an USB 2, aber ich habe es trotzdem bei der Ventoy-Variante belassen,

Artix würde ich zur Wiederherstellung nutzen, da der Kernel und damit auch die Dateisystemtreiber viel aktueller sind.

Das Hirens PE-Windows ist für den Fall, dass ich doch nochmal ein Windows reparieren soll: Es ist eine alte Version (Download aus meinem Google-Drive), da die "aktuelle" (auch schon uralte) doppelt so groß ist, aber trotzdem vieles fehlt oder verbuggt ist. Das wurde nie behoben. […] Oh, letztes Jahr gab es sogar mehrere neue Versionen, die aber aber fast 3x so groß sind. Das ist mir Windows nicht wert, also kann ich nichts zu denen sagen.

Die Partition mit den ISOs ("System Volume Information" kommt von Windows, weil es für Linux leider immer noch kein fsck.ntfs gibt - wie war das noch mit "Microsoft loves Linux"?):

ISOs.png



Hier gibt es das aktuelle Ventoy

Ich nutze die Kommandozeilenversion, da man auf eine bestehende Partitionierung aufsetzen kann: So kann ich die Größe der Partition für die ISOs genau bestimmen und den Rest (d. h. unabhängig von der Größe des Laufwerks) für die Sicherungspartition nutzen. - Beim Ventoy-GUI kann man dagegen nur an Ende Platz frei lassen, muss also für jedes Laufwerk ausrechnen wie viel, um vorne für die ISOs z. B. eine 8 GiB Partition zu bekommen.

Wichtig: Statt des voreingestellten exFAT nutze ich ntfs-16k, da exFAT nach meinen Erfahrungen das mit Abstand schlechteste aller dafür nutzbaren Dateisysteme ist: Es ist praktisch nur ein geringfügig erweitertes FAT64, das aber nicht mal mehr eine FAT-Kopie hat, also noch unsicherer ist. Außerdem lässt sich eine exFAT-Partition weder vergrößern noch verkleinern, was mit NTFS überhaupt kein Problem ist: Mit 16k Cluster ist es am effizientesten (auch schneller als exFAT) und erlaubt auch keine Komprimierung, womit Ventoy nicht klar kommt: Die kann dann also nicht mal versehentlich oder durch ein "übereifriges" Optimierungstool aktiviert werden.

Außerdem nutze ich GPT, da man bei sgdisk das Alignment für vorne und hinten festlegen kann. Das ist wichtig, da die Größe der Sicherungspartition glatt durch 4kiB teilbar sein muss (--sector-size 4096):
(Achtung: Das Ziellaufwerk wird vollständig gelöscht! Also nicht das falsche Laufwerk erwischen.)
Code:
# bootbare Sicherungsplatte (im Verzeichnis des entpackten Ventoys durchführen):

# Ziellaufwerk festlegen und löschen (X anpassen + es darf keine Partition des Laufwerks eingehängt sein):
lw=/dev/sdX
sudo sgdisk -Z $lw
sudo dd if=/dev/zero of=$lw oflag=direct bs=1M count=1 && sudo blkdiscard -v $lw

# Benennung und Partitionierung:
n1=Livesysteme
n2=BackupXS
vt=8 ; va=$(($vt*1024-33))   # vt = Beginn der Sicherungspartition in GiB

sudo sgdisk -n0:0:+$va\M -t0:0x0700 $lw
sudo mkntfs -FIfc16384 -L $n1 $lw"1"
sudo ./Ventoy2Disk.sh -i -n $lw
sudo sgdisk -Ia8 -n0:0:0 -h1:2 -pO $lw

# Ventoy-Konfiguration erstellen:
sudo mount $lw"1" /mnt/ && mkdir -v /mnt/ventoy && nano /mnt/ventoy/ventoy.json && sudo umount /mnt/

# Das zw. d. "---" einfügen, mit Strg+O + [Enter] speichern und mit Strg+X verlassen:
---
{
    "control":[
        { "VTOY_DEFAULT_MENU_MODE": "1" },
        { "VTOY_SECONDARY_BOOT_MENU": "0" },
        { "VTOY_MENU_TIMEOUT": "30" },
        { "VTOY_DEFAULT_KBD_LAYOUT": "GERMAN" },
        { "VTOY_MENU_LANGUAGE": "de_DE" },
        { "VTOY_DEFAULT_SEARCH_ROOT": "/ventoy" },
        { "VTOY_DEFAULT_IMAGE": "/ventoy/LMDE-6-x64_de.iso" }
    ]
}
---
# Die Livesysteme mit in den "ventoy"-Ordner kopieren.

# Verschlüsselte Sicherungspartition erstellen:
sudo cryptsetup luksFormat $lw"3" -qy --sector-size 4096
sudo cryptsetup --allow-discards --persistent open $lw"3" ctmp
sudo mkfs.xfs -L $n2 -i nrext64=0 -m rmapbt=1 /dev/mapper/ctmp && sudo mount /dev/mapper/ctmp /mnt/ && sudo chmod 777 /mnt/ && sudo xfs_scrub /mnt/ && sudo umount /mnt/ && sudo cryptsetup close ctmp
Nachtrag: Wenn man dort nur ein Livesysteme hat und als VTOY_DEFAULT_IMAGE einträgt, kann man VTOY_MENU_TIMEOUT auf 0 setzen: Dann wird es ohne Menü sofort gebootet.

Viel Spaß beim ausprobieren! :)

Und nicht vergessen: Backups sind durch nichts zu ersetzen, außer durch mehr Backups. ;)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Blackland, massaker und Clark79
Zurück
Oben