Category Archives: Linux

Xenserver: VDI löschen geht nicht – was tun?

Posted on by

Moin,

heute widmen wir uns eines kleinen Problems, daß auftreten kann, wenn beim Xenserver was richtig schlief läuft:

Beim Transfer einer VM von einem Server zum Anderen ( Stichwort: vm-import ) brach der Transfer zusammen und die importierte VM war defekt. Zu dem Zeitpunkt lies sich weder der Import abbrechen, noch störte das den zweiten Versuch. Erst beim Aufräumen der VM und Festplatten, die beim Import automatisch angelegt werden, kam es zum Problem:

Error: „This Operation Cannot be Performed Because a VDI is in Use by Some Other Operation“

Ja, ok. Und nu? Die zu löschende VM ( vm-destroy ) lies sich noch löschen, aber die daran angehängten Festplatten ( VDI ) nicht mehr. Diese wurden noch vom hängenden Import Prozess blockiert, der an der Dom0 hängt.

Hinweis: Die UUID hier sind die von meinem Server, Ihr habt andere! Die Befehle einfach so in die Konsole hauen, wird schlimmstenfalls Sachen löschen, die Ihr nicht löschen wolltet oder es passiert gar nichts 😀

Da muß man jetzt die Zähne zusammenbeißen und ein paar unfreundliche Anweisungen manuell in die Konsole hauen:

1. Damit wird der hängende Importtask endgültig terminiert:

xe-toolstack-restart

Für sich betrachtet ist der Befehl allerdings harmlos, damit geht noch nichts kaputt 😉

2. Damit sucht man sich die UUID der Festplatte raus, die man löschen will.

xe vdi-list

3. Jetzt müssen wir die VBD ( Virtual Block Device ) zu der VDI finden:

xe vbd-list vdi-uuid=bc83886b-5723-4dfe-9d5b-feebb2917d0f

Da kommt in etwa sowas raus:

uuid ( RO) : d16248e4-2c24-fa3a-1364-dcb43f5f6858
vm-uuid ( RO): 253c1fde-78d4-3719-ede6-8d0bd223b873
vm-name-label ( RO): Control domain on host: xen1
vdi-uuid ( RO): bc83886b-5723-4dfe-9d5b-feebb2917d0f
empty ( RO): false

4. Jetzt die Augen zu und durch: die VBD abziehen und löschen

xe vbd-unplug uuid=d16248e4-2c24-fa3a-1364-dcb43f5f6858
xe vbd-destroy uuid=d16248e4-2c24-fa3a-1364-dcb43f5f6858

5. und jetzt weg mit der VDI:

xe vdi-destory uuid=611441f9-20c7-6775-716a-37c78b6d672e

6. Jetzt empfehle ich noch das Storage Repository ( SR ) neu zu scannen:

xe sr-list
xe sr-scan uuid=655e2297-b012-d722-1c5f-c2814226a942

Damit wird die Liste der virtuellen Festplatten aktualisiert.

Netflix, Firefox und die 1080p – Teil 3

Posted on by

Endlich! Das aktuelle Firefoxproblem mit der 1080p Wiedergabe von Netflix ist gelöst.

Nachdem im Truedread Build die nötigen Anpassungen bereits vor einigen Tagen gemacht wurden, konnte endlich der Pull-Request bei Vladikoffs FireFox Version eingebaut werden.

Netflix, Firefox und die 1080p

Nun müßte man das nur noch eingebaut bekommen und da haperts gerade! Es ist etwas Handarbeit nötig um das im Firefox zu installieren. Ich habe für Euch aus den Sourcen einen AddOn-Build gebaut. Damit Firefox das unsignierte Addon schluckt, muß zuerst die Signaturprüfung abgeschaltet werden.

Dazu gebt Ihr in die Addresszeile vom Firefox „about:config“ ein und sucht nach „xpinstall.signatures.required“ und ändert es auf „false“ ( einfach „true“ Doppelklicken ).

Danach könnt Ihr dann netflix_1080p-1.9.xpi ohne Probleme installieren und habt wieder 1080p Wiedergabe im Firefox. Das File heißt noch 1.9 um es mit dem aktuellen Masterstand in Übereinstimmung zu halten, aber vermutlich wird auch Vladikoff auffallen, daß er vergessen hat die Versionnummer anzuheben 🙂

Ich vermute mal, daß es in den nächsten Tagen auch einen signierten Build geben wird. Allerdings muß man dazu bei Mozilla im DevNetzwerk angemeldet sein und da habe ich keine Lust zu 🙂

Tablet: Kernel 5.6.8+ behebt USB Problem

Posted on by

Wer ein Surface Tablet mit Linux hat, kennt das Problem seit Kernel 5.5.8: Das Typecover konnte man nicht abziehen, weil es nicht wieder erkannt wurde, wenn man es dransteckte.

Tablet: Kernel 5.6.8+ behebt USB Problem

Ein Kernelfix in 5.6.8+ behebt das TypeCoverproblem für Linux, wie ich heute mit 5.6.11 nachweisen konnte:

Damit dürften auch andere, verwandte USB Probleme, die u.a. im Bugtracker von Redhat aufgelaufen sind, endgültig behoben sein: https://bugzilla.redhat.com/show_bug.cgi?id=1813530

Da hatten sich sogar Leute von ArchLinux gemeldet, weil Google das so schnell im RedHat Bugtracker gefunden hatte 🙂

Wie wir diesem Kommentar entnehmen können, scheint „The Big Boss“ nicht ganz unbeteiligt gewesen zu sein:

If I assume that this issue has been appeared on 5.4.23 and fixed on 5.6.8, the candidate related commits are:

  • issue introduced by commit
    torvalds/linux@8099f58
    („USB: hub: Don’t record a connect-change event during reset-resume“)
  • and fixed by commit
    torvalds/linux@9f952e2
    („USB: hub: Fix handling of connect changes during sleep“)

Wenn ich den ersten Commit richtig interpretiere, hatte da wohl beim Abschalten jemand nicht geprüft, ob er wirklich im Sleep war. Wenn man dann natürlich Geräte abzieht und das ignoriert wird, muß man sich nicht wundern, wenn man die dann nicht mehr benutzen kann. Was ich mich aber wirklich frage ist, wieso der Fix soooooo lange gebraucht hat, bis es gefixt wurde. Das ist ja schliesslich nicht nur bei Exotenhardware wie Linux-Surface-Tablets aufgefallen.

Siehe auch: https://github.com/linux-surface/linux-surface/issues/119#issuecomment-628598029