Vastlopende X bij switchen vanuit Windows 10 naar virtuele Linux Mint 20.3

[daniel37]

Hallo eenieder. Ik post mijn probleem eerst in het Nederlandstalige gedeelte, misschien heeft iemand het al eerder gezien / meegemaakt. Zo niet, dan moet ik naar de Engelstalige secties van dit forum.

Ik heb een probleem met mijn gevirtualiseerde Linux Mint 20.3 Xfce-installatie. Deze installatie draait onder VMPlayer 16.2.3 op een Windows 10-machine (een Thinkpad T15p, om precies te zijn). Ik heb recent besloten te upgraden van Linux Mint 18 naar Linux Mint 20.3: onder v18 had ik van het nu te beschrijven probleem niks geen last. Sterker nog, de hele VM had ik gewoon overgekopiëerd van een 10 jaar oude laptop zonder dat het geheel één kik had gegeven. Maar helaas slaat de softwareduivel nu toe .

Het probleem: als ik vanuit VMPlayer even terugschakel naar de Windows-omgeving (CTRL-Alt, en dan Alt-Tab om naar een willekeurige applicatie te gaan) en dan weer terugga naar VMPlayer, houdt de X-server er in ongeveer 1 op de 10 gevallen mee op. Ik krijg dan in het venster van VMPlayer helemaal niets te zien, alleen maar zwart. In eerste instantie dacht ik aan een volledige vastloper totdat ik mij van lang geleden herinnerde dat wellicht gewone tekstterminals actief zouden kunnen zijn. Dat bleek inderdaad het geval; ik kon ze ook via VMPlayer benaderen. Na inloggen en het zenden van een SIGHUP naar het Xorg-proces startte de X-server gewoon weer op en krijg ik de standaard Xfce-GUI weer te zien.

Of ik SIGHUP had moeten gebruiken; en of ik het signaal überhaupt naar Xorg had moeten sturen laat ik voor nu even in het midden. Het is verschrikkelijk lang geleden dat ik überhaupt met Linux in de weer ben geweest dus 'roestige kennis' is waarschijnlijk al te veel eer voor wat ik me nog herinner. Maar ik vind het wel een irritant probleem, juist omdat ik me had voorgenomen in de zomervakantie weer wat actiever ermee te worden. Vastlopende X'en kan ik daarbij niet gebruiken.

Iemand een idee waaraan dit ligt en/of hoe ik preciezer kan vaststellen in welke softwarecomponent het probleem ligt?

[Pjotr]

Moeilijk te zeggen.... Kan aan Linux liggen, maar ook aan VMPlayer of zelfs aan Windows. Virtualisatie blijft altijd een wat lastige oplossing, met sowieso sterk verminderde prestaties.

[daniel37]

Het systeem is in een seconde of 4 gereed. Dat wil dus zeggen: volkomen koude start tot bruikbare GUI. Misschien dat dat nog 'te langzaam' is voor native installs, maar eerlijk gezegd heb ik 25 jaar geleden nog meegemaakt dat het ruim een minuut duurde. Als je geluk had en de drivers er niet uitvlogen.

Prestaties ben ik op dit moment absoluut niet in geïnteresseerd: voor wat ik ermee wil is het meer dan snel genoeg.

Hoe dan ook, ik ga eens buurten bij het Engelstalige gedeelte, 'ns zien wat men ervan denkt.

[daniel37]

Ik denk dat ik het 'probleem' heb gevonden: de screen saver die na tig minuten het scherm uitschakelt en daarnaast de GUI op slot zet. Ik had Cinnamon geïnstalleerd en zag toen na letterlijk een half uur het Linux-gedeelte te zijn vergeten dat lock screen waar ik mijn wachtwoord kon invullen. Ik realiseerde me toen ineens dat het wel eens een stroombesparingsding kon zijn. Na terug te zijn gegaan naar Xfce heb ik de screen saver uitgezet: dat leidde ertoe dat ik voor het eerst met deze window manager het lock screen zag; en toen ik daarna ook het lock screen uitschakelde leek het probleem te zijn verdwenen.

Dat gezegd, het probleem ís er natuurlijk nog wel omdat het scherm weer aan hoort te gaan als het gast OS hernieuwde focus krijgt. Blijkbaar komt dat signaal niet goed door, hetgeen wijst op een hele subtiele bug ergens diep in X, de drivers of VMWare zelf. Maar aangezien ik noch de screen saver, noch het lockscreen nodig heb, is dit een acceptabele workaround.

[Pjotr]

Als het niet kan zoals het moet, dan moet het maar zoals het kan. Noodoplossingen zijn ook oplossingen....