Jump to content

OpenSUSE switch away from legacy repo


Bloodfire

Recommended Posts

We can't reproduce this in our beta channel. We're going to have a new stable release up by tonight hopefully so please try that once available. Thanks !

Link to comment
Share on other sites

ABotelho

I apologize for the delay in responding. If you are on the old mono-based release and not willing to do a fresh install, then there is already a manual process you can perform to update. 

 

Simply follow the steps listed here in posts #3 and #4:

https://emby.media/community/index.php?/topic/58613-question-about-my-32-bit-upgrade/?p=574032

 

Please make sure to read #4.

 

Also, please be aware that the upcoming Emby Server 3.5 will require mono 5.4+. When that release comes, this may require you to manually update mono as well. A regular 

apt-get update

 may do the trick.

 

Does the new installer put Emby in the same place as the older mono builds?

 

Also, was the mono dependency not removed for the new builds, or is it a combination of Mono and .NET?

Link to comment
Share on other sites

It's in a different place, and yes mono is no longer used in favor of. Net core.

Link to comment
Share on other sites

ABotelho

It's in a different place, and yes mono is no longer used in favor of. Net core.

Ah, alright well that clears things up a bit.

 

If the stable is working I'll simply clean install the .NET builds and move over backups. When the repo is brought back up in the future, should the repo be able to update the .NET builds directly?

Edited by ABotelho
Link to comment
Share on other sites

Hopefully but it is unlikely we will use that very same repo. It will probably be something else.

  • Like 1
Link to comment
Share on other sites

Bloodfire

Hey Luke!

Tested the new stable, installed perfectly on a clean VM. After that, I converted all the old emby and emby-server folders to emby.old and emby-server.old, and then un-installed... After re-install of new version... Worked right out of the box! Re-set it up and so far it's running like a champ! Excellent... I'll let you know if I encounter any issues.

Link to comment
Share on other sites

ABotelho
sudo zypper install https://github.com/MediaBrowser/Emby.Releases/releases/download/3.5.0.0/emby-server-rpm_3.5.0.0_x86_64.rpm
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  emby-server

1 new package to install.
Overall download size: 57.8 MiB. Already cached: 0 B. After the operation, additional 186.9 MiB will be used.

Alright, looks normal. I accept the non-signed package install.

sudo systemctl start emby-server
sudo systemctl status emby-server
● emby-server.service - Emby Server is a personal media server with apps on just about every device.
   Loaded: loaded (/usr/lib/systemd/system/emby-server.service; enabled; vendor preset: disabled)
   Active: failed (Result: core-dump) since Tue 2018-07-17 15:28:24 EDT; 17s ago
  Process: 7450 ExecStart=/opt/emby-server/bin/emby-server (code=dumped, signal=ABRT)
 Main PID: 7450 (code=dumped, signal=ABRT)

Jul 17 15:28:24 BotelhoServer emby-server[7450]: Unhandled Exception: System.UnauthorizedAccessException: Access to the path '/var/lib/emby/logs' is denied. ---> System.IO.IOException: Permission denied
Jul 17 15:28:24 BotelhoServer emby-server[7450]:    --- End of inner exception stack trace ---
Jul 17 15:28:24 BotelhoServer emby-server[7450]:    at System.IO.FileSystem.CreateDirectory(String fullPath)
Jul 17 15:28:24 BotelhoServer emby-server[7450]:    at System.IO.Directory.CreateDirectory(String path)
Jul 17 15:28:24 BotelhoServer emby-server[7450]:    at Emby.Server.Implementations.Logging.FileLogger..ctor(String path)
Jul 17 15:28:24 BotelhoServer emby-server[7450]:    at Emby.Server.Implementations.Logging.SimpleLogManager.ReloadLogger(LogSeverity severity, CancellationToken cancellationToken)
Jul 17 15:28:24 BotelhoServer emby-server[7450]:    at EmbyServer.Program.Main(String[] args)
Jul 17 15:28:24 BotelhoServer emby-server[7450]:    at EmbyServer.Program.<Main>(String[] args)
Jul 17 15:28:24 BotelhoServer systemd[1]: emby-server.service: Main process exited, code=dumped, status=6/ABRT
Jul 17 15:28:24 BotelhoServer systemd[1]: emby-server.service: Failed with result 'core-dump'.

Alright can't access /var/lib/emby/logs...?

cd /var/lib/emby
-bash: cd: /var/lib/emby: No such file or directory

...right.

 

Edit: I had to manually create /var/lib/emby and reintstall Emby to get it to start.

Edited by ABotelho
Link to comment
Share on other sites

ABotelho

Does it just not have write access?

/var/lib/emby didn't exist at all.

Edited by ABotelho
Link to comment
Share on other sites

Right but the command we're using will create the whole tree if needed, that's why I'm suggesting write access as preventing that.

Link to comment
Share on other sites

ABotelho

Correct, yes.

Hmm, alright well I'm not entirely sure how this all works if the installer would have been run as sudo and should have had write permissions at that time. Giving emby write permissions to /var/lib doesn't make me feel all that great. Maybe have the installer create the directory instead of having Emby create it afterwards? I don't know enough about the specifics of how Emby installs itself.

Edited by ABotelho
Link to comment
Share on other sites

You're right, it doesn't make any sense, but as we can see based on others experiences, this is not something that everyone is running into. So i guess the question is why, what wrinkle is there in your environment that we haven't thought of.

Link to comment
Share on other sites

ABotelho

You're right, it doesn't make any sense, but as we can see based on others experiences, this is not something that everyone is running into. So i guess the question is why, what wrinkle is there in your environment that we haven't thought of.

I can confirm it's something that only happens on systems with removed/old Emby installs.

 

I fired up an Ubuntu VM to try and restore my 3.3.1 config, upgrade and backup it up as a 3.5 config. The new 3.5 config doesn't work in OpenSUSE Emby 3.5, says "Invalid Date".

 

Anyway, during a clean remove of 3.3 on the Ubuntu VM (dpkg -r emby-server, rm -R /var/lib/emby, rm -R /opt/emby-server), reinstall Emby after that caused the same permission issue in Ubuntu that I saw in OpenSUSE. I suspect you'll probably start seeing it more as people move from legacy to the current builds.

 

Edit: Have you guys considered a snap package? Considering you package in ffmpeg and .net/mono all together anyway, it certainly sounds to me like it would deal with the problem of having a million Linux distros to support.

Edited by ABotelho
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...