Hallo Jan, TroLuger. Wollte das Thema nochmal aufgreifen um mich noch ein wenig in meinem Ruhm zu sonnen :-) und da mir bislang die Zeit zum Antworten fehlte.
Am Donnerstag, 6. August 2015, 23:57:07 schrieb Jan Grosser: > Hallo Andy! > > > > Ich reihe mich dann mal ein in diejenigen mit Problemen unter Gentoo. > > > Ähnlich wie Thorsten habe ich auch beim Booten Probleme, allerdings beim > > > Booten von virtuellen Gästen in VirtualBox. > > > > > > Ich habe erfolgreich Debian 8 und Mint 17.2 (beides 64Bit-Gäste) > > > installiert. Ich kann auch nach dem Installieren rebooten. Das Problem > > > tritt auf, wenn ich die virtuelle Maschine komplett herunterfahre und > > > anschließend neu starten möchte - dann tut nichts mehr. VirtualBox zeigt > > > ein > > > Fenster "Starting virtual machine ...", und das wars. Dann hilft nur noch > > > ein "killall VirtualBox". iotop zeigt aber rege Festplatten-Aktivität an. > > Übe Dich mehr in Geduld und Du wirst feststellen, das nur wenige Dekaden > > später das System vollständig gebootet hat - wetten. ;-) > > > > > > Die vbox-Datei: https://bpaste.net/show/3d3b1a366945 Die Log-Datei: > > > https://bpaste.net/show/97ce556bc48a Screenshot: > > > https://asgard.selfip.net/owncloud/public.php?service=files&t=f054f07668cea1948250d40bdfdb1c87 > > > > > > Hat jemand einen Tipp für mich? > > Wenn's schneller gehen soll, dann empfehle ich folgendes: Da Du deinen > > Image-Dateien auf einem Btrfs Dateisystem liegen hast, wie ich anhand deines > > Logs sehen kann, gibt es hier mindestens zwei Möglichkeiten für Dich, die > > Dritte willst Du nicht wissen. :-) > > Hätte die Probleme nie allein mit dem Dateisystem btrfs in Verbindung > gebracht! Genau dafür ist ja die Community, die TroLug und diese Mailingliste gedacht, damit nicht Jeder die gleichen Schmerzen erleiden muss. Was meint ihr was ich mir beim ersten mal den Wolf nach der Ursache gesucht habe. Nun konntest Du eben mal von meiner bereits gemachten Erfahrung profitieren, ganz so wie es sein soll. > > > Leider nicht im diesem log enthalten die Frage aller Fragen. Sollte dein > > btrfs mit der mount option autodefrag gemountet sein, dann diese unbedingt > > wieder deaktivieren um diese Problem im Umgang mit jeglichen Disk-Image > > Dateien zu lösen. Gilt also auch für z.B. Qemu. Schau aber nicht nur in der > > fstab nach, sondern ggf. auch in dmesg, falls es in der fstab unerwähnt sein > > sollte. > > Nein, die Option "autodefrag" ist bei mir nicht gesetzt. > > > Sollte das wider erwarten nichts bringen, dann schalte das COW für entweder > > einzelne Dateien, oder besser gleich für das ganze ~/.VirtualBox/Machines/ > > samt rekursiver Unterverzeichnisse ab, so wie es z.B. hier beschrieben > > steht. > > https://wiki.archlinux.org/index.php/Btrfs#Copy-On-Write_.28CoW.29 > > Ja, genau das war des Übels Ursprung. Ein > > $ chattr -R +C ~/.VirtualBox/ > > hat das Problem behoben. Allerdings habe ich zuvor "tabula rasa" gemacht, da > mir > chattr das Attribut für die bestehenden virtuellen Festplatten (*.vdi) nicht > ändern wollte ... Was normal ist und auch dort entsprechend erwähnt wird: Note: nodatacow will only affect newly created files. Copy-on-write may still happen for existing files. Daher wird im dann folgenden dort ja auch beschrieben, wie man das per raus und rein kopieren der Dateien bewerkstelligen kann, nachdem man das COW für z.B. ein Verzeichnis abgeschaltet hat. Daher was das klartürnich nach einem rm aka tabula rasa ebenfalls gefixt. > und auch aus anderen Gründen. Die das womöglich um so mehr rechtfertigten, ansonsten wäre die andere Methode halt einfach nur etwas schneller gewesen. Randbermerkung dazu: Für mich bislang noch einer der wenigen Show stopper bei Btrfs, die es noch auszumerzen gälte, da es dem Normal-User eher nicht zugemutet werden sollte, für bestimmte Dateien eine Sonderbehandlung anzustossen. Natürlich könnte man stattdessen seine Home-Partition auch auf einem anderen Dateisystem ablegen, aber wer will das noch, wenn er einmal diesen Workaround kennt. Das wäre übrigens oben angedeutete dritte Möglichkeit gewesen, nach der hier sich hier bislang keiner traute zu fragen. ;-) Besten Gruß, Andy.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Trolug_trolug.de mailing list [email protected] https://ml01.ispgateway.de/mailman/listinfo/trolug_trolug.de
