Sign In
Create Account
Back to top
 |
Chirurgia endoscopică a hipofizei
"Standardul de aur" în chirurgia hipofizară îl reprezintă endoscopia transnazală transsfenoidală. Echipa NeuroHope este antrenată în unul din cele mai mari centre de chirurgie a hipofizei din Europa, Spitalul Foch din Paris, centrul în care a fost introdus pentru prima dată endoscopul în chirurgia transnazală a hipofizei, de către neurochirurgul francez Guiot. Pe lângă tumorile cu origine hipofizară, prin tehnicile endoscopice transnazale pot fi abordate numeroase alte patologii neurochirurgicale. www.neurohope.ro |
Linux Open Suse Leap 15 Tumbleweed KDE - la zi, X Graphic server issues
Last Updated: Aug 22 2019 18:58, Started by
pinguinul666
, Aug 20 2019 19:56
·
0
0
#1
Posted 20 August 2019 - 19:56
|
sal
Se da un PC cu placa grafica Radeon RX470 g gb DDR5, si OpenSUSE Tumbleweed la zi, mediu KDE pana azi, a functionat flawless! i-am facut ultimul update, la azi si la reboot, s-a oprit doar la command line! nu a mai pornit X Graphical Server! Am incercat systemctl isolate graphical.target dar...imi returneaza eroarea din atasament! Am incercat systemctl status display-manager.service (asa cum sugera), sa vad ce si cum...dar admit ca nu inteleg eroarea! Voi ce ziceti? Multumesc Attached Files
Edited by pinguinul666, 20 August 2019 - 19:56. |
#2
Posted 20 August 2019 - 20:06
|
Zice clar in mesajul de eroare. Fisierul .service contine o referinta catre o cale care probabil este inexistenta. Reporneste sistemul in consola si porneste manual X-ul cu startkde sau startx si vezi ce zice. Sau rulezi manual SDDM.
|
#3
Posted 20 August 2019 - 21:08
|
Zice clar in mesajul de eroare. Fisierul .service contine o referinta catre o cale care probabil este inexistenta. Reporneste sistemul in consola si porneste manual X-ul cu startkde sau startx si vezi ce zice. Sau rulezi manual SDDM. SDDM ? Multumesc
Zice clar in mesajul de eroare. Fisierul .service contine o referinta catre o cale care probabil este inexistenta. Reporneste sistemul in consola si porneste manual X-ul cu startkde sau startx si vezi ce zice. Sau rulezi manual SDDM. Uite rezultatul comenzilor startx si startkde... Multumesc Attached Files
Edited by pinguinul666, 20 August 2019 - 21:08. |
#4
Posted 20 August 2019 - 22:28
|
Vad ca eroarea initiala indica si locul unde e problema, linia 12 din /etc/systemd/system/display-manager.service care este un symlink catre /usr/lib/systemd/system/sddm.service. Intra in fisier si vezi ce e pe linia aia (12). Pe Arch linia 12 este aliasul pentru acest service file:
1 [Unit] 2 Description=Simple Desktop Display Manager 3 Documentation=man:sddm(1) man:sddm.conf(5) 4 [email protected] 5 After=systemd-user-sessions.service [email protected] plymouth-quit.service systemd-logind.service 6 7 [Service] 8 ExecStart=/usr/bin/sddm 9 Restart=always 10 11 [Install] 12 Alias=display-manager.servicePoate in suzeta e ceva diferit la acest service file si asta duce la problema intampinata. LE: As expected, vezi linia 12 dupa cum am spus, incepe cu PIDFile si indica catre o locatie inexistenta sau in care nu se poate scrie de si sddm ruleaza cu drepturi de root si ar trebui sa poata scrie cam pe oriunde. Comentezi linia aia sau corectezi calea si rebootezi. Iti va functiona. Edited by MembruAnonim, 20 August 2019 - 22:32. |
#5
Posted 21 August 2019 - 08:27
|
Vad ca eroarea initiala indica si locul unde e problema, linia 12 din /etc/systemd/system/display-manager.service care este un symlink catre /usr/lib/systemd/system/sddm.service. Intra in fisier si vezi ce e pe linia aia (12). Pe Arch linia 12 este aliasul pentru acest service file: 1 [Unit] 2 Description=Simple Desktop Display Manager 3 Documentation=man:sddm(1) man:sddm.conf(5) 4 [email protected] 5 After=systemd-user-sessions.service [email protected] plymouth-quit.service systemd-logind.service 6 7 [Service] 8 ExecStart=/usr/bin/sddm 9 Restart=always 10 11 [Install] 12 Alias=display-manager.servicePoate in suzeta e ceva diferit la acest service file si asta duce la problema intampinata. LE: As expected, vezi linia 12 dupa cum am spus, incepe cu PIDFile si indica catre o locatie inexistenta sau in care nu se poate scrie de si sddm ruleaza cu drepturi de root si ar trebui sa poata scrie cam pe oriunde. Comentezi linia aia sau corectezi calea si rebootezi. Iti va functiona. Multe multumiri! Imediat ce ajung acasa, e primul lucru care il fac Sincer, sunt uimit ca astfel de lucruri se pot intampla! |
#6
Posted 21 August 2019 - 11:05
|
Pai suzeta a fost tot timpul cunoscuta pentru belelele pe care le produce. Asta e si motivul pentru care de la versiunea 9 sau 11 (anul 2005) nu m-am mai atins de ea.
|
#7
Posted 21 August 2019 - 17:50
|
Daca dai
systemctl get-default Ce iti zice? Edited by NeuralShock, 21 August 2019 - 17:51. |
#10
Posted 22 August 2019 - 12:52
 Eram sigur doar ca in poza omului in postul initial se vede o eroare care apare de mai multe ori si care izoleaza problema la SDDM si mai specific la fisierul de tip service asociat cu SDDM. Deci acel systemctl get-default este useless in cazul de fata deoarece initiatorul stie deja ca targetul default este graphical.target. El are de rezolvat prima data eroarea returnata la boot de sddm.service (display-manager.service) apoi vedem daca rezolvarea acelei erori rezolva toata situatia sau e doar un pas spre rezolvarea completa a acestei situatii.Plus in primul post initiatorul specifica ca a rulat comanda systemctl isolate graphical.target, comanda specificata de altfel in link-ul dat de tine mai sus. Sub systemd pui enable la display-manager.service pentru a intra in mod grafic si disable daca vrei sa pornesti in consola. Cel putin asta e ce fac eu pe Arch / CentOS / Fedora. Ultimile 2 am boala de a le instala folosind netinstall / minimal install si a construi mai apoi sistemul. Edited by MembruAnonim, 22 August 2019 - 12:59. |
|
#11
Posted 22 August 2019 - 15:16
|
Quote Sub systemd pui enable la display-manager.service pentru a intra in mod grafic si disable daca vrei sa pornesti in consola. De acord dar poate acel update pe care l-a facut ultima oara i-o fi schimbat acel symlink din targetul standard, adica default.target, care ar trebui sa duca la graphical.target, cu altceva. E doar o ipoteza ce merita testata mai inainte de a edita fisiere. E un play-safe inainte de a te apuca sa mesteresti concret cu surubelnita. Quote Plus in primul post initiatorul specifica ca a rulat comanda systemctl isolate graphical.target Asta nu reiese din poza. Daca te vei uita cu atentie, initiatorul a introdus comanda systemctl status display-manager.service. Si zice ca-i returneaza eroarea din atasament. Desi el zice ca a dat systemctl isolate graphical.target. Intrebarea fireasca este, i-a dat mai intai un systemctl get-default iar rezultatul NU a fost graphical.target ? Altfel nu vad de ce a incercat direct comanda systemctl isolate graphical.target. Sunt niste etape pe care fie le-a sarit, neintelegand utilitatea lor, fie le-a omis din povestea pe care ne-a prezentat-o aici. In orice caz, asteptam detalii de la pinguin
|
#12
Posted 22 August 2019 - 18:58
|
SDDM / display-manager nu porneste in multi-user.target. Chiar daca sistemul pornea in multi-user.target, initiatorul, nu avea ce cauta sa verifice display-manager.service. Bine daca initiatorul nu stie ca DM-ul porneste doar in mediul grafic, in cazul systemd vorbit de graphical. target, atunci folosirea comenzii de mai sus, systemctl get-default, se explica. In orice caz tot are o problema, parerea mea, cu fisierul serviciu pentru SDDM.
Vedem cand revine si ne spune ce a rezolvat. 
|
Anunturi
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
-
- Change Theme
- English
- Mark Community Read
- Termene & conditii
- Confidentialitate
- Consimtamant
- Cookies
- Help
© 2001-2024 Softpedia. All rights reserved. Softpedia® and the Softpedia logo are registered trademarks of SoftNews Net SRL.
Ora implicita a Forumului Softpedia este ora standard a Romaniei (GMT+2). Mai multe informatii →
⚠ Postarile afisate pe Forumul Softpedia reprezinta o opinie subiectiva a membrilor care le-au publicat si nu a SoftNews Net SRL.