Hi!
Burned todays image of TW raspi 2 XFCE and after first boot updated (some problems with QT5 not available, chose the “keep old version” for all 12 problems). Set up the firewall and wanted to start VNC with Yast, but always get
“Error Enabling service vncmanager has failed”
when trying to finish setup.
I could start the vncserver manually from console/ssh, but would like to have the VNC running on boot automagically…
Any idea how to resolve this?
…are these raspi 2 images meant to be functional at all? Does somebody care? I tried to open PCManFM, nothing happens at all…
I took the JeOS image for Raspi 2 and added the pattern for LXQT, this is functional at first glance 
Will have a further look…
Activated VNC Server in Yast, edited config, reboot. When entering vncviewer <IP> :1
I get on a TW machine:
TigerVNC Viewer 64-bit v1.8.0
Built on: ??-??-?? ??:??
Copyright (C) 1999-2017 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.
Wed Nov 1 15:02:14 2017
DecodeManager: Detected 12 CPU core(s)
DecodeManager: Creating 4 decoder thread(s)
CConn: connected to host 10.0.0.4 port 5901
Wed Nov 1 15:02:15 2017
CConnection: Server supports RFB protocol version 3.8
CConnection: Using RFB protocol version 3.8
CConnection: Choosing security type VeNCrypt(19)
CVeNCrypt: Choosing security type TLSNone (257)
Wed Nov 1 15:02:30 2017
CConn: Using pixel format depth 24 (32bpp) little-endian rgb888
CConn: Using Tight encoding
Wed Nov 1 15:02:35 2017
CConn: End of stream
Window with login-screen opens, but when I try to enter User/Password, the window colapses and the connection is broke (“End of stream in” in log above). What’s going on here?
PS: Tried to login with monitor and keyboard, same effect, so the whole desktop is unstable. Apparently. sigh…
Although I haven’t tested the same image,
Generally speaking,
How are you installing VNC?
Are you simply installing the VNC packages
or
Are you using YaST to install “Remote Administration?”
TSU
Hy!
I went to YaST and enabled
“Allow Remote Administration With Session Management”.
Did you read the PS? Apparently the desktop is unstable, as even the local login fails and the screen turns black…
And btw: It’s now TW JeOS for raspi 2 with LXQT pattern installed…
I don’t recommend adding a Desktop to JeOS (I personally haven’t checked that, and generally on x86 machines it doesn’t work without problems).
Instead, download the LXQt image and burn it to your SDcard.
And, configure YaST > Remote Administration <without> session management at first because it’s simpler, you can enable session management connections later.
TSU
Also,
Verifying that you’re getting your images from links on this page
https://en.opensuse.org/HCL:Raspberry_Pi2
TSU
…yepp. In the past the only functional images (for me) came from the repo of Stefan Bruens, but he discontinued the releases…
…something is wrong with sudo in current TW 64bit KDE (not Raspi…):
sudo xzcat openSUSE-Tumbleweed-ARM-XFCE-raspberrypi2.armv7l-2016.08.20-Build2.2.raw.xz | dd bs=4M of=/dev/sdd iflag=fullblock oflag=direct; sync
dd: failed to open '/dev/sdd': Permission denied
…but after su the same comand works just fine.
I never use sudo for this kind of thing, I elevate all the way to su…
If you really want to troubleshoot your issue, I hope I’m not too obvious by saying it’s a permissions accessing that specific device…
TSU
…not going to do anything about that. It worked flawlessly numerous times in the past with sudo. I avoid su completely.
Hi
If you look at the RPI HCL’s, all operations are to be performed as ‘root’, so your call… suggest you create a bug report if it’s not working, but don’t be surprised if they also ask to switch to root user… and it’s su - to ensure full environment.
Else configure sudo (visudo) to do exactly what your wanting?
It also might not be a sudo problem, it might be something about how the device was detected and mounted…
TSU
Please don’t take it personally, I’m still learning about this linux-thingy, and in my experience, there are always al LOT of diagnoses for a problem. But rarely a solution. No surprise, in my opinion. Yesterday I had a look at this Wayland thing and ended here: https://en.wikipedia.org/wiki/File:The_Linux_Graphics_Stack_and_glamor.svg
UN-BE-LIEV-ABLE. If a car was designed like that, nobody would ever use it more than 2-3 days a year with 2-3 months of preparation (including a tent and a sleeping bag).
Currently I try to debug another TW 64bit KDE, with VNC enabled on boot over systemctl. Working fine for some months, but some months ago the VNCserver started serving a black window (see separate post, with different machine). OK, so I disabled the systemctl service. And enabled the VNCserver in YaST. Same result: today only black window served. I don’t update my other machines with VNCservers, cause they might end up broken also! Because: I disabled the VNCserver in Yast (to start it manually via ssh), but the server is still running after (several) reboot(s) and can’t be killed with vncserver -kill :1 because the file with the PID is not in .vnc folder where it is expected to be. In top I can’t find anything related to VNC.
So the machine is serving an unusable vncserver, no idea how to stop this.
Hi
Can understand your frustration, but please choose your words more carefully 
Why do you need a graphical interface to manage these systems? Can you not just use ssh -X if you need something graphical?
Something will always break on Tumbleweed, sometime for some user… probably more likely with the graphics gpu on RPI’s. Best get on IRC Freenode #opensuse-arm and see if the folks there have some ideas.
Also,
Regarding Wayland, it’s my understanding that it doesn’t support remote X and not likely to do so anytime soon.
So, even if you enable Wayland locally, you still need to deploy an xorg X server for remote X connections (both VNC and X over SSH).
If you install VNC using the YaST Remote Administration module, it’ll install and configure an xorg X server no matter how your local graphical system is configured… and if you install VNC any other way, that’s not guaranteed to happen.
Regarding VNC server issues,
You need to be clear (both for yourself and others) how you’re implementing.
I’ve reviewed the openSUSE documentation for deploying and configuring VNC server and feel it’s the best way although there is another post in these Forums where a User felt very strongly that VNC server can and should be recommended to be deployed “the old way,” how it was usually done for most of the past 20 years or so.
Since both work, both ways are possible.
But, they are so different that you must be clear which way you’re going to do it… And, from your last post you may have switched. You will have to clarify or help will be muddled.
If you believe an update caused your current VNC problems, since the files and settings for VNC server all reside in the root partition, if you’re running BTRFS on that partition, you may be able to roll back your TW update to when your VNC worked.
You should try X over SSH, but it’s my guess that it won’t solve a black screen using VNC.
IMO,
TSU
Hi malcom, without going into details, the use of these “remote” machines (raspi and x64 computers) IS to be the graphic interface to the internet and for some other basic operations for other machines (basically Windows machines without any internet access).
I’m not that advanced with linux, so I need the GUI to handle the “everyday problems” with these machines. I’m practicing ssh/console but not there yet so that I could do the configuration/maintenance work necessary without the GUI. That’s what GUI was invented for, in my opinion…
Hi tsu, I didnt want to “activate” or something this “Wayland” thingy, I simply wanted to understand what it does and why it’s there. To be true: I haven’t got it yet…
My usual way to make VNC on start work is (has been) via a systemd service:
After starting the vncserver manually for the first time, I create a file named
/etc/systemd/system/vncserver@.service
with the content:
[Install]
WantedBy=multi-user.target
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target
[Service]
Type=forking
User=<USERNAME>
PAMName=login
PIDFile=/home/<USERNAME>/.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :%i
ExecStop=/usr/bin/vncserver -kill :%i
and do
sudo systemctl daemon-reload && sudo systemctl enable vncserver@1.service
This worked fine for over a year, until the problems started with serving a black window only, IBUS errors and so on as described in a threat from summer
https://forums.opensuse.org/showthread.php/525794-this-time-they-killed-TigerVNC
As a result I disabled the systemd service and activated VNC in YaST. Afterwards (with some fiddeling in the config) the VNC server was doing fine.
Yesterday I booted a backup machine also with TW 64 bit and the VNCserver (installed as systemd service) served only a black window. OK, I disabled (later masked) the systemd service, deleted the file decribed in detail above and enabled the VNCserver in YaST.
After reboot, VNCserver delivered a black window only, even with the YaST-VNC. I wanted to kill the VNCserver, but it found no PID file in /home//.vnc (as I guess, as this is the usual place to store this file when starting the VNCserver manually). So no way to kill that cat manually. And I don’t see any process in top that could be related to VNCserver:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 217772 8704 6576 S 0.000 0.107 0:02.14 systemd
2 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kworker/0:0
4 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 kworker/0:0H
5 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kworker/u16:0
6 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 mm_percpu_wq
7 root 20 0 0 0 0 S 0.000 0.000 0:00.00 ksoftirqd/0
8 root 20 0 0 0 0 S 0.000 0.000 0:00.01 rcu_preempt
9 root 20 0 0 0 0 S 0.000 0.000 0:00.00 rcu_sched
10 root 20 0 0 0 0 S 0.000 0.000 0:00.00 rcu_bh
11 root rt 0 0 0 0 S 0.000 0.000 0:00.00 migration/0
12 root rt 0 0 0 0 S 0.000 0.000 0:00.00 watchdog/0
13 root 20 0 0 0 0 S 0.000 0.000 0:00.00 cpuhp/0
14 root 20 0 0 0 0 S 0.000 0.000 0:00.00 cpuhp/1
15 root rt 0 0 0 0 S 0.000 0.000 0:00.00 watchdog/1
16 root rt 0 0 0 0 S 0.000 0.000 0:00.00 migration/1
17 root 20 0 0 0 0 S 0.000 0.000 0:00.00 ksoftirqd/1
18 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kworker/1:0
19 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 kworker/1:0H
20 root 20 0 0 0 0 S 0.000 0.000 0:00.00 cpuhp/2
21 root rt 0 0 0 0 S 0.000 0.000 0:00.00 watchdog/2
22 root rt 0 0 0 0 S 0.000 0.000 0:00.00 migration/2
23 root 20 0 0 0 0 S 0.000 0.000 0:00.02 ksoftirqd/2
24 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kworker/2:0
25 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 kworker/2:0H
26 root 20 0 0 0 0 S 0.000 0.000 0:00.00 cpuhp/3
27 root rt 0 0 0 0 S 0.000 0.000 0:00.00 watchdog/3
28 root rt 0 0 0 0 S 0.000 0.000 0:00.00 migration/3
29 root 20 0 0 0 0 S 0.000 0.000 0:00.00 ksoftirqd/3
30 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kworker/3:0
31 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 kworker/3:0H
33 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kdevtmpfs
34 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 netns
35 root 20 0 0 0 0 S 0.000 0.000 0:00.11 kworker/0:1
36 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kworker/2:1
37 root 20 0 0 0 0 S 0.000 0.000 0:00.00 khungtaskd
38 root 20 0 0 0 0 S 0.000 0.000 0:00.00 oom_reaper
39 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 writeback
40 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kcompactd0
41 root 25 5 0 0 0 S 0.000 0.000 0:00.00 ksmd
42 root 39 19 0 0 0 S 0.000 0.000 0:00.01 khugepaged
43 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 crypto
44 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 kintegrityd
45 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 kblockd
46 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 ata_sff
47 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 edac-poller
48 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 devfreq_wq
49 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 watchdogd
And i can’t start VNCserver manually via ssh, as the machine complains there is already a VNCserver running on port :1 and the black window is still served via VNC (port :1), which I don’t want to have on the long run, as this is an “undefined state” for the computer in my opinion.
So how to disable VNCserver when
AND
Many thanks in advance.
PS: latest version of systemd service script that worked in the past:
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target
[Service]
Type=simple
User=<USERNAME>
PAMName=login
PIDFile=/home/<USERNAME>/.vnc/%H:%i.pid
ExecStartPre=/usr/bin/vncserver -kill :%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver :%i -alwaysshared -fg
ExecStop=/usr/bin/vncserver -kill :%i
[Install]
WantedBy=multi-user.target
I found a way to kill the vncserver automatically comming up on boot (but serving only a black window):
Open YaST (via ssh) and choose “network services” -> “remote administration (VNC)”. Although the VNCserver is already set to “disabled” confirm and leave YaST
in the console run
sudo rm /tmp/.X11-unix/X1
Afterwards the vncserver on :1 is gone and can be started manually with
vncserver :1
…which serves a functional VNCserver window.
So apparently after VNCserver has been activated in YaST it cannot be disabled so that the “DISABLED” survives a reboot…
