Spielereien mit KVM (Kernelbased Virtual Machine)

[Uridium]

Ist chkdsk/WinXP nicht etwas alt?

Ich hatte mir mal folgendes überlegt:
Man nehme eine Win11 ISO und entferne die 'setup.wim' (5.7GB), so dass nur noch die 'boot.wim' übrig bleibt. Das ISO ist dann 773MB groß. Das bootet man mit qemu und drückt Shift+F10, um die Konsole zu öffnen und benutzt von dort chkdsk.
Weiter getestet habe ich das aber noch nicht und weiß auch nicht wie die Geschwindigkeit ist, bzw. ob man die Laufwerke komfortabel rein bekommt usw. War erst mal nur eine Idee.

mkdir /tmp/win11-{1..2}
sudo mount -o loop Win11_23H2_German_x64v2.iso /tmp/win11-1
rsync -a --chmod=D2775,F664 /tmp/win11-1 /tmp/win11-2 --exclude=install.wim
mkisofs \
  -iso-level 4 \
  -l \
  -R \
  -UDF \
  -D \
  -b boot/etfsboot.com \
  -no-emul-boot \
  -boot-load-size 8 \
  -hide boot.catalog \
  -eltorito-alt-boot \
  -eltorito-platform efi \
  -no-emul-boot \
  -b efi/microsoft/boot/efisys.bin \
  -o /tmp/win11-bootwim-only.iso \
  /tmp/win11-2
sudo umount /tmp/win11-1

 

[Caramon2]

Ist chkdsk/WinXP nicht etwas alt?

Das ist immer noch das aktuelle: NTFS 3.1 – ab Windows XP (NT 5.1)

Einzig die max. Clustergröße wurde inzwischen auf absurde 2 MiB erweitert, weil ntfs nur 32-bit hat und mit aktuellen industriellen Kapazitäten vollkommen überfordert ist.

Damit kann XP natürlich nichts anfangen. - Genauso wie meine Satreceiver (von 2010 und 2015 = das einzige, weswegen ich ntfs noch nutzen muss) und 16k Cluster sind erwiesenermaßen sowie für ntfs bestmöglich.

…

Das andere sehe ich mir heute an, dafür ist es mir heute zu spät.

Mein vollwertiges, schlankes und effizientes VM-XP werde ich zwar nicht ersetzen, aber vielleicht kann ich etwas anderes damit anfangen.

 

[Caramon2]

@Uridium: Gestern war das Wetter zu schön… :-)

"mkisofs" könnte mich wirklich interessieren, aber so wie ich das Video interpretiere, hätte ich damit praktisch nur ein knapp 800 MB großes, "ewig" lange bootendes "DOS-Fenster", womit sich nicht viel anfangen lässt. - Schon meine .cmd-Dateien und Tools darin zu integrieren wäre mir zu aufwändig, falls das überhaupt möglich ist.

Mein VM-XP kann ich dagegen an jedem PC booten (mit der 1:1-Kopie meines Produktivsystems auf einer ext-SSD) und so z. B. per BootIce Windows-Installationen reparieren:

Auch die anderen dort installierten Tools (alles in den 303 MiB des WinXP-Images!) gehören zu Sachen, die ich vielleicht doch irgendwann nochmal brauchen könnte.

Windows XP war, ist und wird es offenbar immer sein, das für mich beste Windows aller Zeiten. - Was nicht heißen soll, dass ich es gut finde: Es ist nur das geringste Übel.

Übrigens:

Da ich auf meinem vorherigen Rechner (Phenom II X6 mit 16 GiB RAM) Windows XP noch nativ installieren konnte, habe ich mal verglichen, wie schnell VideoReDo einen SD-Spielfilm schneidet (Streamcopy von einem USB3-Stick mit 140 MB/s Lesegeschwindigkeit auf eine SSD mit dafür mehr als genügend großen SLC-Cache):

• VM-XP mit 2 Kernen und 2 GiB RAM unter damals noch LinuxMint 18.x: 45 Sek.
• natives Windows XP x64 mit vollem Zugriff auf Kerne und RAM: 1 Min.
• natives Windows 10 1803 mit vollem Zugriff auf Kerne und RAM: 2 Min.

Als Windows 10 64-bit war 2,5x langsamer, als ein popeliges XP-Home in einer VM unter Linux! - Reproduzierbar!

Ein gutes Beispiel für "Neuer muss nicht besser bedeuten."

Vorletztes Jahr habe ich das gleiche gemacht, nur ohne natives XP (da es für den AMD FX-8350 keinen XP-Treiber gibt), dafür mit nativen Win 10 und 11 je 22H2, 32 GiB RAM und inzwischen auch einer SSD als Quelle:

Alle Windows (10-1803 und beide 22H2) waren gleich schnell (also war Windows inzwischen nicht noch langsamer geworden) und ca. 2,2x langsamer als das (seit dem X6 unveränderte) VM-XP: Mit einer SSD als Quelle kommen aktuelle Windowsen offenbar besser zurecht.

Ach ja: TurboCore hatte/habe ich bei beiden CPUs deaktiviert, da das bei meinen Anwendungen nicht das geringstes bringt (IMO reines Marketing) und nur den Stromverbrauch (und damit Hitze und Lautstärke des PCs) unnötig in die Höhe treibt.

 

[foofoobar]

Das war noch unter LinuxMint: Nach einem reboot hatte sich eine USB-HD "vorgedrängelt" und war sda, wodurch das Systemlaufwerk zu sdb wurde, statt der 2. int. SSD, die ich eigentlich in der VM booten wollte. - Im "Eifer des Gefechts" hatte ich nicht mehr daran gedacht…

Dieses "Vordrängeln" passiert übrigens nur bei Ubuntu und Derivaten: Mit keiner anderen Distribution konnte ich das reproduzieren: Auch nicht mit LMDE!

Das hat also eindeutig Ubuntu vermurkst und nichts daran geändert, da sich das auch mit aktuellen Versionen reproduzieren lässt: Bei allen PCs, auf die ich Zugriff hatte und habe. Also es liegt nicht nur an meinem.

Sich auf nicht garantierte Eigenschaften zu verlassen ist PEBCAK.

Such dir hiervon was aus:

/dev/disk/by-id
/dev/disk/by-partlabel
/dev/disk/by-partuuid
/dev/disk/by-path
/dev/disk/by-uuid

 

[Caramon2]

Sich auf nicht garantierte Eigenschaften zu verlassen ist PEBCAK.

Ich verlasse mich nicht darauf, nur wie geschrieben: "Im "Eifer des Gefechts" hatte ich nicht mehr daran gedacht…"

Von den von dir genannten Alternativen würde übrigens nur das erste funktionieren. Wäre aber viel zu umständlich.

Da mir schon z. B. /dev/sdc auf Dauer zu viel tipperei ist, habe ich das Skript so geschrieben, dass ich stattdessen nur "c" übergeben muss: Das ist effizient.

Gegen "menschliches Versagen" habe ich meine Backups wie gerade erst beschrieben.

 

[Uridium]

Das ist immer noch das aktuelle: NTFS 3.1 – ab Windows XP (NT 5.1)

Das hat nichts damit zu tun, dass chkdsk und seine Methoden weiterentwickelt werden.

Von den von dir genannten Alternativen

Das sind eigentlich keine Alternativen. /dev/sd* sollte man an sich nur manuell im Terminal verwenden, wenn man weiß, dass sie korrekt sind. Ich benutze die meist auch noch, gucke aber mit 'fstab -l' o.ä. vorher noch mal nach.

If your machine has more than one drive sharing a naming scheme, the order in which their corresponding device nodes are added is arbitrary. This may result in block device names (e.g. /dev/sda and /dev/sdb, /dev/nvme0n1 and /dev/nvme1n1, /dev/mmcblk0 and /dev/mmcblk1) switching around on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues.
https://wiki.archlinux.org/title/persistent_block_device_naming

 

[Caramon2]

Ich benutze die meist auch noch, gucke aber mit 'fstab -l' o.ä. vorher noch mal nach.

Ich nutze dazu Gnome-Disks und übernehme es ggfs. per markieren und MMB-Klick-Einfügen.

Wobei sich das während der Laufzeit ja nicht ändert, mir aber nicht mehr bewusst war, dass ich zwischendurch rebootet hatte, wobei Ubuntu und dessen Derivate eben oft (aber nicht immer) wie beschrieben die Geräte würfeln. - Wie Windows es gerne mit den Laufwerksbuchstaben macht… (ich hasse diese Laufwerksbuchstaben!)

Seit über 4 Jahren nutze ich Artix, da passiert sowas nicht, trotzdem sehr ich immer erst nach, welches Gerät was ist, bevor ich etwas kritisches mache. - Außer eben versehentlich, wenn mich anderes zu sehr ablenkt.

Das hat nichts damit zu tun, dass chkdsk und seine Methoden weiterentwickelt werden.

Wie gesagt: ntfs-Laufwerke muss ich ausschließlich für die Satreceiver nutzen und die sind schon 9-14 Jahre alt, als noch zur XP-Zeit.

Bisher konnte es alles reparieren und hat auch keine Probleme mit Windows 10 und 11: Bis auf die übergroßen Cluster ist das offenbar noch voll kompatibel.

Niemals wechsle ein rennendes System.

 

[Caramon2]

chka.cmd:

chkdsk /f d:
chkdsk /f e:
chkdsk /f h:
chkdsk /f k:
chkdsk /f p:
chkdsk /f r:
chkdsk /f s:
chkdsk /f t:
chkdsk /f v:
chkdsk /f w:
chkdsk /f x:
chkdsk /f y:
@Pause

Update:

Ich hatte schon vor einer ganzen Weile "Aria" (die "Browser-KI vom Android-Opera) gefragt, wie man unter Windows auf vorhandene Laufwerksbuchstaben prüft:

Aria:
Hier ist ein Beispiel für eine Windows .cmd-Datei, die überprüft, ob bestimmte Laufwerksbuchstaben vorhanden sind:
@echo off
setlocal

REM Definieren Sie die gewünschten Laufwerksbuchstaben in einer Liste
set "drive_list=C: D: E:"

REM Iterieren Sie über die Laufwerksbuchstaben in der Liste
for %%d in (%drive_list%) do (
REM Überprüfen Sie, ob der Laufwerksbuchstabe vorhanden ist
if exist "%%d\" (
echo Laufwerk %%d ist vorhanden.
) else (
echo Laufwerk %%d ist nicht vorhanden.
)
)
endlocal
Dieses Skript definiert eine Liste von Laufwerksbuchstaben in der Variable drive_list . In diesem Beispiel sind die Buchstaben C, D und E enthalten. Sie können diese Liste an Ihre Bedürfnisse anpassen, indem Sie die Buchstaben hinzufügen oder entfernen.

Das Skript verwendet eine Schleife ( for ) zum Iterieren über jeden Laufwerksbuchstaben in der Liste. Für jeden Buchstaben wird überprüft, ob das Laufwerk existiert ( if exist "%%d\" ). Wenn das Laufwerk vorhanden ist, wird eine entsprechende Meldung ausgegeben, andernfalls wird angezeigt, dass das Laufwerk nicht vorhanden ist.

Sie können dieses Skript entsprechend Ihren Anforderungen anpassen, indem Sie die Liste der Laufwerksbuchstaben ändern und weitere Aktionen ausführen, wenn bestimmte Laufwerke vorhanden sind oder nicht.

Speichern Sie das Skript in einer .cmd-Datei und führen Sie es aus, um die Laufwerksbuchstabenüberprüfung durchzuführen.

Das habe ich angepasst und zusammenfasst:

@echo off
for %%d in (A: B: D: E: F: G: H: I: J: K: L: M: N: O: P: Q: R: S: T: U: V: W: X: Y: Z:) do (
  if exist "%%d\" (
    echo %%d
    chkdsk /f %%d
    echo ________________________________________________________________________________
  )
)
pause

Es werden alle Laufwerksbuchstaben außer C: kontrolliert und nur die existierende per chkdsk geprüft.

Das ist effizienter und übersichtlicher:

Schön, wenn auch mal unter Windows etwas auf Anhieb funktioniert.