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.

 

[Caramon2]

So sieht es aus, wenn ich mein System sich selbst in KVM booten lasse (habe ich fürs Artix-Forum gebraucht):

Durch "snapshot=on" werden Schreibzugriffe nur im RAM gecached, aber nicht wirklich umgesetzt. Dadurch gibt es keine konkurrierenden Schreibzugriffe und es kann am physischen System nichts kaputt gehen.

Das Skript:

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

 

[Uridium]

es kann am physischen System nichts kaputt gehen.

Das sollte man aber vielleicht nicht allein an der 'snapshot' Funktion von qemu fest machen. Mindestens sollten zusätzlich via OS nur Leserechte auf Blockgeräte bestehen. Das Ding hat Potenzial die ganze Platte zu schrotten und sollte vielleicht auch entsprechend deklariert werden. Das ist ein sehr gefährliches Spielzeug.

 

[Caramon2]

@Uridium: Meinst du mit "ganze Platte zu schrotten" wirklich Hardwaredefekte?

Aber auch wenn du nur Dateisysteme oder Partitionstabellen meinst, wie soll man die mit snapshot=on beschädigen können?

Zusätzlich auch noch readonly zu erzwingen finde ich übertrieben und verursacht höchstens Probleme. Eine Warnung war in dem Beitrag aber schon deswegen unnötig, weil es für sich alleine sowieso nicht funktioniert: Welche Voraussetzungen das braucht, hatte ich hier mehrfach beschrieben und dann auch vor den Gefahren gewarnt.

Ich nutze qemu schon lange oft täglich direkt auf Datenträgern (also ohne Snapshot-Option), z. B. um mit dem VM-XP ntfs prüfen zu lassen, aber auch um Betriebssysteme dort zu installieren: Wie habe ich Windows 11 sonst wohl auf eine USB-SSD installieren können? - Auch die dortigen Testinstallationen aktualisiere ich per VM (Windows bekommt natürlich keinen Internetzugang), weil es ja Quatsch wäre, für jede Installation immer erst den PC zu rebooten.

Solange man (ohne Snapshot-Option) in der VM nichts macht, was auch direkt gebootet schädlich wäre und außerdem darauf achtet dass man auf dem Host keine Partitionen einhängt, die in der VM genutzt werden (konkurrierende Schreibzugriffe), beschädigt man nichts.

Und mit Snapshot-Option schon gar nicht: Egal ob mit "dd", "blkdiscard -f", "rm -rf --no-preserve-root /“ oder sonst was (alles schon ausprobiert ), nicht mal mutwillig als root bekommt man irgendwas am Host kaputt.

 

[Uridium]

Meinst du mit "ganze Platte zu schrotten" wirklich Hardwaredefekte?

Nein, das nicht, "nur" Datenverlust. Man legt aber das Schicksal seiner Daten in ein Programm, dessen Funktionalität nicht unter allen Umständen gewährleistet werden kann. Was, wenn die "snapshot" Funktion mal nicht funktioniert? Dann sollte das OS greifen, z.B. mit /dev/sda auf 664 (statt 666) oder 640 (wenn man in der 'disk' Gruppe ist, was nicht empfehlenswert ist). Das kann man ja temporär setzen, bevor man qemu startet.
Es geht in erster Linie um Selbstschutz, um unerwartete Ereignisse.

 

[Caramon2]

Es geht in erster Linie um Selbstschutz, um unerwartete Ereignisse.

Ich halte es für sehr unwahrscheinlich, dass snapshot=on plötzlich nicht mehr funktioniert. Selbst wenn wie jetzt "-runas" in "-run-with user=“ geändert wird, bekommt man lange vorher schon entsprechende Meldungen und gibt es das alte nicht mehr, starten qemu nicht.

Aber selbst falls doch irgendwas passiert (oder viel wahrscheinlicher: etwas ganz anderes das System zerschießt), stellt man einfach die letzte Datensicherung wiederher und fertig.

Dafür braucht es doch nicht so einen Umstand, mit nicht mehr standardmäßig gesetzten Zugriffsrechten, die bei was anderen vielleicht Probleme machen und wenn der Zusammenhang nicht offensichtlich ist, geht die Sucherei los.

Ne, für mich ist das, als würde man sich selbst Stöcke zwischen die Beine werfen: Wozu sich doppel und dreifach gegen alle Eventualitäten absichern, egal wie unwahrscheinlich sie sind und damit potenzielle Fehlerursachen zu konstruieren, über die man irgendwann den Überblick verliert und für die man u. U. keine Hilfe findet, weil nicht mehr standardmäßig, wenn man einfach nur seine Sicherungen aktuell zu halten braucht, um was auch immer passiert wieder rückgängig machen zu können.

Keep it simple.

 

[Uridium]

Ja, alles gut. Das muss letztlich jeder selbst wissen. Ich dachte auch eher an Anfänger, denen vielleicht nicht bewusst ist, dass sie am offenen Herzen operieren.

Wie nimmst Du dir denn in diesem Fall Zugriff auf /dev/sda? Das hat doch 660 und ist für 'world/normaluser' gesperrt. Du startest das Script doch nicht mit 'sudo', oder?

Edit: Das setzen von Berechtigungen auf /dev/sda hält nur pro Session, da dynamisch von udev erzeugt.

 

[Caramon2]

Ja, alles gut. Das muss letztlich jeder selbst wissen. Ich dachte auch eher an Anfänger, denen vielleicht nicht bewusst ist, dass sie am offenen Herzen operieren.

Nicht mit "snapshot=on".

Wie nimmst Du dir denn in diesem Fall Zugriff auf /dev/sda? Das hat doch 660 und ist für 'world/normaluser' gesperrt.

Schon "immer" so:

das Skript funktionirt nur, wenn man das Gruppe "disk" angehört: Wer nicht weiß, was das bedeutet, lässt besser die Finger davon, da man ansonsten schnell sein System zerschossen haben kann.

Dass es als gefährlich gilt, habe ich erst viel später gelesen. Für mich ist es "normal" da ich auch schon beim C64, div. Amigas, MSDOS und Windows 3.11 bis einschließlich XP (andere habe ich nicht genutzt) einfach so aufs Laufwerk zugreifen konnte.

Dass ich als normaler Nutzer z. B. mit echo > /dev/sda die Partitionstabelle des Laufwerks überschreibe, ist mir bewusst (und hatte ich auch schon mit "snapshot=on" ausprobiert ), aber sowas macht man ja auch nicht.

Deshalb würde ich niemandem zu "disk" hinzufügen, der mangels ausreichender Kenntnissse sowas in der Art wirklich im Terminal ausführen würde, wenn ih{m,r} jemand das "scherzhaft" empfiehlt.

Du startest das Script doch nicht mit 'sudo', oder?

Ich hatte mal mit dem Gedanken gespielt qemu in meinen VM-Skripten mit sudo + "-runas $USER" zu starten und es zu /etc/sudoers hinzuzufügen, damit ich nicht immer das Passwort eingeben muss, aber "disk" erschien mir dann doch als das kleinere Übel.

Es kann ja nicht viel passieren: Im schlimmsten Fall kostet es mich einige Minuten das komplette Systemlaufwerk wiederherzustellen, aber "normalerweise" zerschieße ich mir höchstens die Systempartition *) und die paar GiB sind in knapp 50 Sek. wieder drauf.

*) auch schon absichtlich: btrfs ist sehr viel anfälliger für konkurrierende Zugriffe (das ist sofort irreparabel beschädigt und muss neu formatiert werden) als xfs (beim nächsten Einhängen wird lt. dmesg kurz recovered und fertig). - Sicherheitshalber habe ich es dann aber trotzdem neu formatiert.

 

[Caramon2]

@Uridium: Wenn ich Laufwerke ohne Snapshot-Option einbinde, damit auch drauf schreiben kann (z. B. ntfs mit chkdsk reparieren), habe ich nachdem ich die VM beendet habe, das Problem, dass z. B. der Dateimanager (Xfce/Thunar) alle auf dem Laufwerk enthaltenen Partitionen (unabhängig davon, ob aus der VM heraus darauf zugegriffen wurde, oder nicht) nicht mehr einhängen kann:

Kurz abmelden ändert daran nichts (man müsste schon rebooten), nur per gnome-disks lassen sie sich noch ein- und auch aushängen: Wenn ich sie mit dem Dateimanager aushängen will, kommt die gleiche Meldung.

Mounte ich die Partitionen dagegen manuell per "mount"-Befehl, warte eine Sek. und unmounte sie dann gleich wieder, funktioniert es auch wieder mit dem Dateimanager normal.

Gibt es eine einfachere Möglichkeit D-Bus (damit kenne ich mich nicht aus) wieder über diese Laufwerke zu informieren? - partprobe (s. u.) macht das nicht.

---

Ich habe das momentan so gelöst:

Da ntfs3 immer noch nicht trimmen per fstrim unterstützt, hatte ich mir sowieso ein Skript geschrieben, dass die ntfs-Partitionen mir ntfs-3g mountet, um sie nach der Videobearbeitung mit dem VM-WinXP zu trimmen (der Dateimanager kann sie dadurch dann auch wieder einhängen), das habe ich auf alle Partitionen die es betreffen kann erweitert und da überwiegend auf ext. Laufwerken lasse sie dann auch gleich trimmen.

Im angehängten Video zeige ich den kompletten Ablauf: Ich starte das VM-WinXP mit Win+V, dann mit AltGr+A die "Check All" Verknüpfung, anschließend fahre ich es mit AltGr+X runter und starte das chkclra.sh Skript mit Win+Shift+A

Das Skript, mit dem ich das VM-WinXP starte, bindet nur Laufwerke ein, die fat- und/oder ntfs-Partitionen enthalten:

Anschließend starte ich mein chkclra.sh Skript (die unkenntlich gemachten Passwörter sind für verschlüsselte Partitionen):

"ntfswipe" löscht u. a. die Undelete-Informationen, da nach dem trimmen ja nichts mehr zum undeleten da ist und so bleibt die Ausgabe aufgeräumt, wenn ich wirklich mal etwas versehentlich gelöscht habe.

 

[Uridium]

Vielleicht ausloggen (auf TTY), dbus neu starten und X11 wieder starten. Oder eventuell nur gvfs/udisks2 neu starten. Die sind verantwortlich für die Mountgeschichten in Thunar.

 

[Caramon2]

Vielleicht ausloggen (auf TTY), dbus neu starten und X11 wieder starten.

Sowas möchte ich ja vermeiden: Ich bin mitten in der Videobearbeitung und möchte nichts abbrechen/neu starten müssen. Da D-Bus die betreffenden Laufwerke offenbar vergessen hat, soll er die einfach nur neu scannen. Also das was ich mit sudo partprobe nach beenden des VM-WinXP (s. o.) erreichen wollte.

Allerdings hat sich etwas geändert, oder ich hatte mich vertan: Nachdem ich mich kurz ausgeloggt habe, kann Thunar reproduzierbar die Partitionen wieder öffnen. - Nur wie gesagt, das möchte ich vermeiden.

Oder eventuell nur gvfs/udisks2 neu starten. Die sind verantwortlich für die Mountgeschichten in Thunar.

Die einzige Möglichkeit die ich zu gvfs gefunden habe, war killall gvfsd: Anschließend soll es automatisch neu gestartet werden, wenn es eine Anwendung braucht.

Ich habe alle Dateimanager-Fenster geschlossen, gvfsd getötet + nochmal zur Sicherheit mit sudo, aber da kam schon "gvfsd: Kein Prozess gefunden", also hat es 1. funktioniert und 2. braucht es kein sudo. Dann den Dateimanager gestartet und versucht die Partition zu öffnen, aber es kommt immer noch die obige Meldung bzgl. D-Bus. - Da sich gvfsd wieder töten ließ, hat auch das automatische starten funktioniert.

Also gvfs hat offenbar nichts damit zu tun.

………

Bzgl. udisk2 habe ich udisksctl monitor gefunden und beobachtet was passiert: s. u.

Ich habe dann gleich das VM-WinXP gestartet (beim Monitoring passierte nichts):

qemu-system-x86_64 -nodefaults -enable-kvm -cpu host -smp cores=2 -m 2G -vga none -device qxl-vga,vgamem_mb=8 -display sdl,gl=on,window-close=off -device piix3-usb-uhci -device usb-tablet -audio sdl,model=ac97 -drive file=WinXP.qcow2,if=virtio,aio=io_uring,snapshot=on -drive file=/dev/sdc,if=virtio,aio=io_uring,format=raw

Das ist sdc:

Ohne etwas zu machen habe ich es ca. eine halbe Minute laufen lassen und dann beendet. Dabei kam dann der ganze Rest, wobei das auffällt:

17:54:44.711: Removed /org/freedesktop/UDisks2/block_devices/sdc1
17:54:44.824: Added /org/freedesktop/UDisks2/block_devices/sdc1

Dann habe ich versucht die Partition mit Thunar zu öffnen, aber wieder die D-Bus-Fehlermeldung. Beim Monitoring passiere dabei nichts.

Dann habe ich die Partition mit sudo mount /dev/sdc1 /mnt/ eingehängt:

18:21:55.060: /org/freedesktop/UDisks2/block_devices/sdc1: org.freedesktop.UDisks2.Filesystem: Properties Changed
  MountPoints:          /mnt
18:21:55.060: /org/freedesktop/UDisks2/block_devices/sdc1: org.freedesktop.UDisks2.Filesystem: Properties Changed

** (udisksctl monitor:6954): WARNING **: 18:21:55.060: (udisksctl.c:2811):monitor_on_interface_proxy_properties_changed: runtime check failed: (g_strv_length ((gchar **) invalidated_properties) == 0)

und mit sudo umount /mnt wieder ausgehängt:

18:22:50.798: /org/freedesktop/UDisks2/block_devices/sdc1: org.freedesktop.UDisks2.Filesystem: Properties Changed
  MountPoints:         
18:22:50.799: /org/freedesktop/UDisks2/block_devices/sdc1: org.freedesktop.UDisks2.Filesystem: Properties Changed

** (udisksctl monitor:6954): WARNING **: 18:22:50.799: (udisksctl.c:2811):monitor_on_interface_proxy_properties_changed: runtime check failed: (g_strv_length ((gchar **) invalidated_properties) == 0)
18:22:50.824: /org/freedesktop/UDisks2/block_devices/sdc1: org.freedesktop.UDisks2.Filesystem: Properties Changed

** (udisksctl monitor:6954): WARNING **: 18:22:50.824: (udisksctl.c:2811):monitor_on_interface_proxy_properties_changed: runtime check failed: (g_strv_length ((gchar **) invalidated_properties) == 0)

Anschließend konnte ich sie wieder mit Thunar öffnen:

18:25:02.084: Added /org/freedesktop/UDisks2/jobs/26
  org.freedesktop.UDisks2.Job:
    Bytes:              0
    Cancelable:         true
    ExpectedEndTime:    0
    Objects:            /org/freedesktop/UDisks2/block_devices/sdc1
    Operation:          filesystem-mount
    Progress:           0.0
    ProgressValid:      false
    Rate:               0
    StartTime:          1745943902082533
    StartedByUID:       0
18:25:02.338: /org/freedesktop/UDisks2/jobs/26: org.freedesktop.UDisks2.Job::Completed (true, '')
18:25:02.338: Removed /org/freedesktop/UDisks2/jobs/26
18:25:02.339: /org/freedesktop/UDisks2/block_devices/sdc1: org.freedesktop.UDisks2.Filesystem: Properties Changed
  MountPoints:          /run/media/user/Surefire
18:25:02.339: /org/freedesktop/UDisks2/block_devices/sdc1: org.freedesktop.UDisks2.Filesystem: Properties Changed

** (udisksctl monitor:6954): WARNING **: 18:25:02.339: (udisksctl.c:2811):monitor_on_interface_proxy_properties_changed: runtime check failed: (g_strv_length ((gchar **) invalidated_properties) == 0)
18:25:02.340: /org/freedesktop/UDisks2/block_devices/sdc1: org.freedesktop.UDisks2.Block: Properties Changed
  UserspaceMountOptions:        uhelper=udisks2
18:25:02.341: /org/freedesktop/UDisks2/block_devices/sdc1: org.freedesktop.UDisks2.Filesystem: Properties Changed

** (udisksctl monitor:6954): WARNING **: 18:25:02.341: (udisksctl.c:2811):monitor_on_interface_proxy_properties_changed: runtime check failed: (g_strv_length ((gchar **) invalidated_properties) == 0)
18:25:02.355: /org/freedesktop/UDisks2/block_devices/sdc1: org.freedesktop.UDisks2.Filesystem: Properties Changed

** (udisksctl monitor:6954): WARNING **: 18:25:02.355: (udisksctl.c:2811):monitor_on_interface_proxy_properties_changed: runtime check failed: (g_strv_length ((gchar **) invalidated_properties) == 0)

Kannst du was damit anfangen?

---

Das ist die vollständige Ausgabe bis zum beenden des VM-WinXP:

$ udisksctl monitor
Monitoring the udisks daemon. Press Ctrl+C to exit.
17:54:07.065: The udisks-daemon is running (name-owner :1.27).
17:54:44.711: Removed /org/freedesktop/UDisks2/block_devices/sdc1
17:54:44.810: /org/freedesktop/UDisks2/block_devices/sdc: org.freedesktop.UDisks2.PartitionTable: Properties Changed
  Partitions:           
17:54:44.824: Added /org/freedesktop/UDisks2/block_devices/sdc1
  org.freedesktop.UDisks2.Block:
    Configuration:              []
    CryptoBackingDevice:        '/'
    Device:                     /dev/sdc1
    DeviceNumber:               2081
    Drive:                      '/org/freedesktop/UDisks2/drives/Vi550_S3_SSD_20121123900292'
    HintAuto:                   true
    HintIconName:               
    HintIgnore:                 false
    HintName:                   
    HintPartitionable:          true
    HintSymbolicIconName:       
    HintSystem:                 false
    Id:                         by-id-ata-Vi550_S3_SSD_20121123900292-part1
    IdLabel:                    Surefire
    IdType:                     ntfs
    IdUUID:                     7F4E0A0C41FCF4D8
    IdUsage:                    filesystem
    IdVersion:                 
    MDRaid:                     '/'
    MDRaidMember:               '/'
    PreferredDevice:            /dev/sdc1
    ReadOnly:                   false
    Size:                       429496713216
    Symlinks:                   /dev/disk/by-diskseq/4-part1
                                /dev/disk/by-id/ata-Vi550_S3_SSD_20121123900292-part1
                                /dev/disk/by-id/usb-Verbatim_Portable_Drive_0000AB1234D0-0:0-part1
                                /dev/disk/by-label/Surefire
                                /dev/disk/by-partuuid/f9c3a1c7-01
                                /dev/disk/by-path/pci-0000:02:00.0-usb-0:1.4:1.0-scsi-0:0:0:0-part/by-label/Surefire
                                /dev/disk/by-path/pci-0000:02:00.0-usb-0:1.4:1.0-scsi-0:0:0:0-part/by-partnum/1
                                /dev/disk/by-path/pci-0000:02:00.0-usb-0:1.4:1.0-scsi-0:0:0:0-part/by-partuuid/f9c3a1c7-01
                                /dev/disk/by-path/pci-0000:02:00.0-usb-0:1.4:1.0-scsi-0:0:0:0-part/by-uuid/7F4E0A0C41FCF4D8
                                /dev/disk/by-path/pci-0000:02:00.0-usb-0:1.4:1.0-scsi-0:0:0:0-part1
                                /dev/disk/by-path/pci-0000:02:00.0-usbv3-0:1.4:1.0-scsi-0:0:0:0-part1
                                /dev/disk/by-uuid/7F4E0A0C41FCF4D8
    UserspaceMountOptions:     
  org.freedesktop.UDisks2.Filesystem:
    MountPoints:       
    Size:               0
  org.freedesktop.UDisks2.Partition:
    Flags:              0
    IsContained:        false
    IsContainer:        false
    Name:               
    Number:             1
    Offset:             16384
    Size:               429496713216
    Table:              '/org/freedesktop/UDisks2/block_devices/sdc'
    Type:               0x07
    UUID:               f9c3a1c7-01
17:54:44.825: /org/freedesktop/UDisks2/block_devices/sdc: org.freedesktop.UDisks2.PartitionTable: Properties Changed
  Partitions:           /org/freedesktop/UDisks2/block_devices/sdc1

 

[Uridium]

Was hast Du denn für ein init system, bzw. Servicemanager bei Artix? Systemd ist es ja nicht (eher runit oder OpenRC vermute ich mal). Udisks2 sollte besser darüber neu gestartet werden. Außerdem kann man schauen, ob der d-bus Service noch läuft (neu starten kann man den glaube ich nicht "gracefully". Ich habe mal gelesen, der würde X11 mit runter ziehen).

Schau mal, ob Du herausbekommst, wer genau die d-bus Fehlermeldung liefert. Vielleicht steht was im syslog (was immer das ist bei Artix).

 

[Caramon2]

Was hast Du denn für ein init system, bzw. Servicemanager bei Artix?

Runit.

Systemd ist es ja nicht (eher runit oder OpenRC vermute ich mal). Udisks2 sollte besser darüber neu gestartet werden.

udisk" gibt es dort nicht, nur udev.

Offenbar ist mein Workaround mit dem kurzen Einhängen per mount die praktikabelste: Das funktioniert und ist unproblematisch.

Außerdem kann man schauen, ob der d-bus Service noch läuft (neu starten kann man den glaube ich nicht "gracefully". Ich habe mal gelesen, der würde X11 mit runter ziehen).

Das kann ich bestätigen: nach sudo sv restart dbus kam sofort die Meldung, dass das Startmenü beendet wurde, inkl. Option es neu zu starten. Aber die Meldung kam immer sofort wieder.

Thunar zeigte gar keine andern Partitionen mehr an, rebooten ging mangels Startmenü nicht mehr und auch bei Alt+F4 passierte nicht. Das Terminal in dem ich obigen Befehl ausgeführt habe, war weg und es ließ sich auch kein neues öffnen, nicht mal Strg+Alt-F1 wurde noch angenommen.

Außerdem wurde zuerst alle paar Minuten der Bildschirm kurz schwarz, mit kürzer werdenden Intervallen und bei so einem schwarzen Bildschirm war der PC plötzlich beim POST, als hätte ich die Rest-Tasten gedrückt.

Booten funktionierte, alles schien wieder ok und btrfs scrub fand keine Fehler, aber sicherheitshalber (ich traue btrfs aus div. Erfahrungen nicht) habe ich das SoS gebootet und die letzte Sicherung der Systempartition per rsync wiederherstellt. Dabei gab es keine Auffälligkeiten.