WSL 2 / Leap-15.2 mit systemd und dbus - Komme nicht weiter bei meinem Test-Projekt

Hinweis: In dem Thema WSL 2 / Leap-15.2 mit systemd und dbus - Komme nicht weiter bei meinem Test-Projekt gibt es 19 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Ist meine erste Frage hier in diesem Forum. Ich hoffe ich mache alles richtig.

    Leider denke ich, dass ich ein bisschen weiter ausholen muss, um mein(e) Problem(e) zu beschreiben.


    Ich weiss jetzt nicht wie viel Text ich schreiben darf und ob es nicht schläuer wäre von null anzufangen und jedes Problem einzeln anzugehen, weil es Euch sonst zu blöd wird.

    Aber ich denke einen Versuch ist es wert. ;)


    Mein System:

    Microsoft Windows 10 Pro / immer up-to-date

    Intel(R) Core(TM) i7-7800X CPU @ 3.50GHz, 3501 MHz, 6 Cores, 12 Logical Processors

    32 GB RAM

    American Megatrends Inc. 3006, 07.02.2020 (DD.MM.YYYY)

    SMBIOS-Version 3.2

    ASUSTeK COMPUTER INC.

    PRIME X299-A

    Rev 1.xx

    NVIDIA GeForce RTX 2070

    Leap-15.2 per Store installiert


    Warum WSL - warum nicht VM?


    - Es ist (wäre) einfach bequemer.

    - Was ich z.B. toll finde ist die export / import Funktion von WSL.

    - Über das Netzlaufwerk auf die Dateien zugreifen

    - Ich möchte über VS c# etwas entwickeln, wo ich eine openSUSE Distro brauche. Mit dem Konsolen-Switch wäre das echt eine praktische Sache.

    - Es ist eigentlich auch nicht schlecht um mehr über Linux zu lernen.



    Goal 🏆


    - xrdp mit KDE in einer mehr oder weniger "sauberen" Umgebung (sudoers / session und mit systemd)


    Es müsste ja eigentlich nicht unbedingt KDE sein, z.B. LXDE wäre auch ok. Aber ich habe mich irgendwie auf KDE verbissen und entsprechende Pakete installiert.

    Ausserdem scheint "startplasma-x11" einigermassen mit xrdp zu harmonieren. Leider fehlt mir da einiges an Wissen.


    Bei meinem ersten Testlauf habe ich es bis zum KDE Desktop geschafft und dann realisiert, dass ohne systemd mal gar nix geht. Z.B. yast2.



    Aktueller status


    Zuerst einmal habe ich alles weggekickt und bei null angefangen. Dann war mein erstes Ziel systemd zum laufen zu bringen.

    Dabei habe ich mich an diesen guide gehalten wsl2-hacks:


    - dbus-1 per rpm neu installiert

    - policykit-1 per yast installiert

    - daemonize-1.7.8-1-omv4000.x86_64.rpm irgendwo "geklaut" und die bin nach "/usr/sbin/" mit chown root und chmod 700 kopiert


    Dann habe ich mit meinem beschränkten Wissen die "/usr/bin/bash" erstellt und entsprechend versucht diese suse-konform zu machen. Ausserdem habe ich gleichzeitig eine Routine eingefügt für xrdp als fork. Irgendwie wollte xrdp nichts von systemd wissen. Oder ich nicht, wie auch immer.


    /usr/bin/bash:

    Habe noch ein paar Kommentare auf Englisch reingeschrieben. Weiss auch nicht wie Sinnvoll meine Umsetzung eines Timeout ist. Wie auch immer mein "gebastel" scheint soweit zu funktionieren.


    Als xrdp user verwende ich den user "marvin", den ich beim firstboot in yast erstellt habe.


    - Anschliessend xorg-x11, KDE patterns, yast2 patterns via yast installiert (und noch ein paar andere Sachen, macht süchtig ;) )


    - Bei xrdp habe ich mich grundsätzlich an diesen guide gehalten und ihn mit ein paar anderen Seiten kombiniert:

    /home/marvin/.xsession

    /home/marvin/.xclients

    startplasma-x11


    /etc/xrdp/startwm.sh

    Code
    # den rest habe ich so gelassen wie es war...
    pre_start
    #wm_start
    startplasma-x11
    post_start


    Hier fangen schon mal meine Probleme an, da ich irgendwie einfach nicht verstehe, wie eine ordentliche Session aufgebaut werden sollte. Das mit .xsession und .xclients scheint irgendwie total witzlos zu sein. Ich habe das einfach irgendwo aufgeschnappt.


    - Dann habe ich mich via rdp localhost:3390 mit marvin auf der Xorg Session angemeldet.


    Tja und da stecke ich im Moment fest:


    - Wenn ich z.B. yast2 starten will kommt KDE mit kdesu, was ja auch gut so ist, nur leider geht das PW nicht. Also kein typo.


    Also habe ich mal eine wheel gruppe erstellt und marvin hinzugefügt:


    Code
    id marvin
    uid=1000(marvin) gid=100(users) groups=1000(wheel),100(users)


    /etc/sudoers

    https://pastebin.com/NacKGWnR


    /etc/sudoers.d/wheel-users

    Code
    # allow members of group wheel to execute any command
    %wheel ALL=(ALL) ALL


    - Hat nicht funktioniert und scheint von mir aus ein Leerlauf zu sein, da ich ohne systemd auch keinen wheel hatte soweit ich weiss. Ausserdem hat es schon einen ausgeklammerten wheel im template. Scheint wo anders zu liegen?


    Die services haben status failed bei auditd.service und systemd-modules-load.service.


    Code
    service -s

    https://pastebin.com/ZtRaR82U



    - Noch ein paar relevante Konsolen-Befehle:


    - Und schlussendlich noch ein riesen Massaker bei den Logs:


    /var/log/warn


    https://pastebin.com/1FrBn7dM



    /home/marvin/.xorgxrdp.202.log - sieht alles in allem gar nicht so übel aus


    https://pastebin.com/ixSLP0G5



    Z:\home\marvin>dir /O > dir.txt


    https://pastebin.com/sMmQx3sR



    Ich habe keinen Plan wo ich ansetzen soll, oder ob es besser ist, das ganze auf den Müll zu kippen, da es sowieso zum scheitern verurteilt ist oder ob noch Hoffnung besteht.


    Ich bin mir auch am überlegen, ob es eine Möglichkeit gibt, ein minimalist openSUSE auf WSL laufen zu lassen, wo ich alles Schritt für Schritt aufbauen könnte...


    Auf jeden Fall bin ich für jeden Input dankbar. ;)

    Rule 101: Never touch a running system.

    Für den Inhalt des Beitrages 285659 haftet ausdrücklich der jeweilige Autor: Luckylazuli

  • Danke für den link. Du meinst ich sollte xrdp als service starten? Macht das einen Unterschied? Ich meine xrdp funktioniert ja soweit.

    Rule 101: Never touch a running system.

    Für den Inhalt des Beitrages 285664 haftet ausdrücklich der jeweilige Autor: Luckylazuli

  • Habe für dich zwar keine Lösung, aber evtl. eine interessante Info:


    A system in WSL does not actually boot and does not use systemd. A proprietary Microsoft /init binary initializes the system. Therefore service management does not work like in a VM. It rather behaves like an interactive container.


    Quelle:

    https://en.opensuse.org/openSUSE:WSL

    Für den Inhalt des Beitrages 285666 haftet ausdrücklich der jeweilige Autor: sterun

  • Hehe ja. Habe ich auch schon gesehen. Nur leider bringt das reichlich wenig, wenn yast z.B. die config für den dhcp schreiben will. Darum habe ich auch systemd wieder mit dem hack aktiviert. Ich glaub mein Problem ist mehr, dass ich keine ordentliche KDE session mit xrdp aufbaue. Und davon habe ich leider reichlich wenig Ahnung. Oder wieso kdesu mein root PW nicht "schluckt".

    Rule 101: Never touch a running system.

    Für den Inhalt des Beitrages 285669 haftet ausdrücklich der jeweilige Autor: Luckylazuli

  • Funktioniert in der WSL überhaupt ein grafischer Displaymanager für das dort installierte Linux?
    Ich hab mich zu den Anfängen von WSL mal ein bisschen damit beschäftigt und zu dem Zeitpunkt konnte man nur ein Linux (Ubuntu über den M$ App-Shop) ohne grafische Oberfläche installieren und betreiben.

    EDV-Dinosaurier im Ruhestand


    ich bin /root, ich darf das 8)


    Dinos are not dead. They are alive and well and living in data centers all around you. They speak in tongues and work strange magics with computers. Beware the Dino! And just in case you're waiting for the final demise of these Dino’s: remember that Dino’s ruled the world for 155-million years! (Unknown Author)

    Für den Inhalt des Beitrages 285674 haftet ausdrücklich der jeweilige Autor: Igel1954

  • Oder wieso kdesu mein root PW nicht "schluckt".

    Es wird vermutlich noch Jahre dauern, bis WSL "ausgereift" ist.

    Aber versuch doch mal:

    Code
    zypper in -f kde-cli-tools5

    WSL neu starten.

    Geht es dann noch immer nicht, versuch mal:

    Code
    zypper in -f kde-cli-tools5 plasma5-workspace

    Anschl. Neustart.

    Besser?

    Für den Inhalt des Beitrages 285675 haftet ausdrücklich der jeweilige Autor: sterun

  • Funktioniert in der WSL überhaupt ein grafischer Displaymanager für das dort installierte Linux?
    Ich hab mich zu den Anfängen von WSL mal ein bisschen damit beschäftigt und zu dem Zeitpunkt konnte man nur ein Linux (Ubuntu über den M$ App-Shop) ohne grafische Oberfläche installieren und betreiben.

    Ja gibt inzwischen schon Möglichkeiten GUI Apps direkt in Windows zu starten. Mit Remote Desktop verbinde ich einfach auf meinen eigenen PC also localhost. xrdp ist es ziemlich egal von wo man verbindet. Hauptsache ein anderer Port als der standard rdp port. Sonst meckert Windows, weil es denkt man will es veräppeln. ;)


    @sterun werde ich dann morgen ausprobieren. Aber ist echt eine Freude die Community hier. Danke für die Antworten. :thumbup:

    Rule 101: Never touch a running system.

    Für den Inhalt des Beitrages 285678 haftet ausdrücklich der jeweilige Autor: Luckylazuli

  • Ne hat nichts gebracht. Ich versuche imo gerade zu verstehen was und in welcher Reihenfolge geladen wird. Also boot > init > kernel > etc. Wenn ich das kapiert habe kann ich vielleicht eins nach dem anderen eruieren. Kann ja nicht so ein Geheimnis sein. Aber google mag mich nicht. ;)


    Strange ist z.B.

    Code
    systemctl is-enabled display-manager.service
    disabled

    Aber unter

    Code
    service -s

    versucht linux immer noch den zu laden


    - unter normalem user marvin bringt

    Code
    systemctl status --user
    Failed to connect to bus: No such file or directory

    während unter

    Code
    sudo systemctl status --user
    ● XXXX-Win10
    State: running
    Jobs: 0 queued
    Failed: 0 units
    Since: Mon 2020-11-30 03:33:36 CET; 49ms ago
    CGroup: /user.slice/user-0.slice/user@0.service
    └─init.scope
    ├─1200 /usr/lib/systemd/systemd --user
    └─1201 (sd-pam)

    Naja hab wohl noch viel vor.


    Edit: Hab mir mal überlegt ob ich init.d installieren soll. Aber ich glaub dann mach ich alles nur noch schlimmer.

    Der init.d Ordner sieht bei mir so aus:

    Code
    13.12.2019 11:43 <DIR> boot.d
    13.12.2019 11:43 <DIR> rc0.d
    13.12.2019 11:43 <DIR> rc1.d
    13.12.2019 11:43 <DIR> rc2.d
    13.12.2019 11:43 <DIR> rc3.d
    13.12.2019 11:43 <DIR> rc4.d
    13.12.2019 11:43 <DIR> rc5.d
    13.12.2019 11:43 <DIR> rc6.d
    13.12.2019 11:43 <DIR> rcS.d

    KA was das soll. Sind alle leer.


    Und noch so nebenbei: Wie sieht eigentlich /var/run in einer offiziellen leap 15.2 aus? Ist das ein Ordner, ein symlink oder eine Datei?

    Rule 101: Never touch a running system.

    Einmal editiert, zuletzt von Luckylazuli ()

    Für den Inhalt des Beitrages 285720 haftet ausdrücklich der jeweilige Autor: Luckylazuli

  • Hallo nochmals ;)


    Also ich hab mich entschieden mich richtig reinzuhängen. Selbst wenn mein "gewurstel" hier weiter Früchte tragen würde, der Ansatz gefällt mir nicht.

    Das ganze fängt schon beim MS Store an und wenn man da einfach Leap 15.2 reinkickt hat man von Anfang an Pakete und Dateien vorinstalliert und auf diesem Müll aufzubauen ist eine Idiotie.


    Was ich lustig finde, ist, dass es kein "minimalist" linux gibt, oder ich habe keins gefunden. Ich mein wieviel Dateien braucht man zum nur die Konsole laufen zu lassen, vielleicht noch mit sudo? 40? Ist irgendwie die Mentalität über Store linux zu installieren und dann "wow, jetzt habe ich auch linux in Windows, ist das nicht der Wahnsinn?". Mir wäre es lieber ich hätte wirklich nur das minimum vom minimum, mehr kann man immer noch installieren. Ein Paket nach dem anderen eruieren. Egal.


    Ich habe mich jetzt weiter schlau gemacht und herausgefunden, dass SuseStudio (resp. build.opensuse.org) mehr als nur vielversprechend ist. Ironischerweise kann ich dort beim Windows launcher starten, also wirklich bei null, während im Internet sonst fast nur quatsch zu finden ist. Es gibt dort die offiziellen builds für WSL.


    Tja danke für Antworten soweit. Ich werde meinen Fortschritt mal festhalten und falls hier im Forum Interesse besteht (und ich etwas erreicht habe) diesen veröffentlichen.

    Rule 101: Never touch a running system.

    Für den Inhalt des Beitrages 285721 haftet ausdrücklich der jeweilige Autor: Luckylazuli