noVNC stopped working after manually upgrading to buster

1

Hello folks,

I used this guide to manually upgrade stretch to buster and it ended up breaking a couple of things.

  • First of all, apache stopped serving php, so the landing page stopped working. I was able to fix it (ended up having to delete /etc/apache2/mods-enabled/php7.0.* because 7.3.0 was the new version)

  • noNVC stopped working.

I am still not able to fix the second problem - it looks like vncserver@1.service is somehow failing to start although Xtightvnc is happily running.

I was poking around Raspbian_For_Robots/VNC at master · DexterInd/Raspbian_For_Robots · GitHub for inspiration but not quite sure what is wrong.

I am seeing things like this in the logs:

Mar 11 02:07:26 dex systemd[1]: vncserver@1.service: New main PID 882 does not belong to service, and PID file is not owned by root. Refusing.

But /home/pi/.vnc/dex:1.pid doesn’t exit (I tried creating it but while it helped with “/usr/bin/vncserver -kill :1” I am still not able to get the service up and running.

I am feeling I’m off by some tiny thing but not quite sure what - any suggestions would be appreciated.

1 Like
2

I never, never, NEVER “upgrade” across major versions, as I have NEVER had it work smoothly.

  • Fedora
  • Ubuntu
  • Mint
  • Raspbian
     

I don’t know why, but it has never, ever worked for me, to the point that, (IMHO), I consider it the fast boat to a borked system.  There are just too many ways for it to go wrong, and when it does - you have a system that has gone all pear-shaped for no apparent reason.

Supposedly, people do it, and do it successfully.  Me?  I avoid it like the plague and many others on the web, wiser than either one of us, recommend strongly against it too.

IMHO, the best way to “fix” this is to roll-back to a recent backup, install fresh to new media, migrate settings and files, and move forward from there.

Another thing I just thought of. . .
Later versions of Raspbian Buster, (and the newer Raspberry Pi O/S), has been a bit wonky and strange lately in ways that are unpredictably odd.

Note:
I have NOT tested subsequent versions of Raspberry Pi O/S and as a consequence I CANNOT talk about them. - Your mileage may vary.

There are other postings about later images of Raspbian/Raspberry Pi O/S, that illustrate this:

Bottom line:
If at all possible stick with trusted and tested releases of R4R, and avoid major version updates at all cost.

Please let us know if there is anything else we can help with.

3

This is a fair point, but I’m willing to take the risk - the upgrade actually mostly went well (regarding IPv6 - I suspect I was having some issues even prior to the upgrade - at least the python http server was a bit flaky).

I would like to stick with Buster for a little while unless it proves absolutely untenable. Even the noVNC problem is not a huge deal breaker - I can VNC directly over port 5901 and I can start noVNC by hand to boot, I was just hoping to remove a little bit of friction and wasn’t quite sure why it wasn’t working properly, so any bit of help would be appreciated.

2 Likes
4

Dave,

Are you working on a Dexter/MR 'bot?

If you don’t need something absolutely from Mars, or don’t mind a simple curl or apt-get, you should try downloading the Raspbian for Robots, Buster image that already exists, is thoroughly tested, and is known working.

Why break your head?  The hard work has already been done.

5

I’m actually just using this as a spare Pi (I used to tinker with the Mindstorms servos/sensors but for now I turned it into an alarm clock).

I tried running “curl -kL dexterindustries.com/update_brickpi3 | bash” but it didn’t do much since I already had all the Buster packages.

I did more research and it looks like the issue is most probably caused by a systemd bug (this thread has some info: centos 7 - VNC Server Error: New main PID <PID> does not belong to service - Super User).

Ultimately, I was able to fix the problem by patching /etc/systemd/system/vncserver@.service:

[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=forking
User=pi
# PAMName=login
PIDFile=/home/pi/.vnc/%H:%i.pid
WorkingDirectory=/home/pi
ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x768 :%i
ExecStop=/usr/bin/vncserver -kill :%i

[Install]
WantedBy=multi-user.target

Now when I am connecting via VNC for the first time (since last boot), I get an on-screen error “No session for pid NNN” but this appears harmless so I think this is good enough for me.

All good now!

1 Like
6

Note: this is the link to the vncsever@.service config:

1 Like
7

Pardon me for asking an obvious question:  What are you using as your base operating system?

8 
cat /etc/os-release

PRETTY_NAME=“Raspbian GNU/Linux 10 (buster)”

1 Like
9

Any reason why you cannot use Raspbian for Robots, (Buster)?  All the integration work has already been done, it’s known working, and it’s only a mater of load, lock, aim, fire! - and you’re done.

10

Not sure I understand. I had originally installed Raspbian for Robots when I got my BrickPi3, I essentially just ran “sudo apt-get full-upgrade -y” to upgrade to the latest Raspbian. Maybe it’s not a correct way to update, but it (mostly) worked and I would rather not reimage unless there is an explicit need.

1 Like
11

Like the preacher said in Blazing Saddles: “Son, you’re on your own. . .”

I cannot, nor will I, speak to your requirements aside from asking why re-imaging is so difficult?  I am sure there are good and valid reasons.  I am just curious so that I can understand the problem better.

 
If I understand rightly, “full_upgrade” should not cross a major version boundary in Raspbian, and if it does so, the results are unpredictable.

One thing I have learned is to NEVER upgrade in-place to a new distribution crossing a major revision boundary as there is always SOMETHING that goes wrong and, (to be honest), I don’t have the skill to delve that deeply into a system and fix the kind of details that this entails.

I hope you cloned your original SD before upgrading.

All I can suggest is to download and install the latest R4R, (Buster), on a new SD card, configure it to your liking, and copy your data across.

I honestly don’t think there’s anyone here who has done that.  Additionally, even with a stock version of Raspbian, “upgrading” across a major version boundary is never pretty - and most people advise strongly against it unless you are a God-level Linux sysadmin.

I have a brother who works at Epic in Wisconsin.  They have very deep pockets and - especially for their server teams - only hire the absolute best of the best.  These people ARE “God level” Linux sysadmins and, (according to my brother), they NEVER upgrade across a major revision boundary - there are just too many things that can go wrong.  And these are the people who spend insane amounts of money for the Full-Monty, Super-Duper, Diamond Encrusted Platinum-Level, God-like support from Red Hat - and they still won’t do it.

IMHO, if they won’t touch it, I damn-sure won’t either.

There’s not much more I can suggest than that.  Perhaps the Raspberry Pi forums can help, though I still think you’re fighting a loosing battle.

Maybe @mitch.kremm or @cleoqc can help, but I wouldn’t hold my breath.

1 Like
12

Stretch and Jessie Raspbian for Robots used tightvncserver as the server. With Buster, we moved to RealVNC
We also moved to the normal default port (5900, I think, but this is from memory) while before that the server was running on 5901 .

All reasons why noVNC would stop working.

2 Likes
13

I ended up hammering noVNC into submission per my previous posts so my franken-Buster is actually doing quite well, but I might eventually re-image per jimrh’s suggestion.

2 Likes