I have recently switched NASes, and due to an understandable lack of support for FreeBSD, I am running my roon core inside a VM. The problem is, every time I restart the VM, I need to authorize and log in again.
What can I do to avoid this? The VM is configured to have a static MAC address, which is used by DHCP to assign an IP address.
Where should I look to try and diagnose this?
What kind of OS are you running in the VM is it Windows or something else? A few other questions:
- Does the VM by any chance have a “Deep Freeze” ability where it restarts each time?
- Can you provide the exact local time (ex. 6:14PM) for one or a few of these restarts and Roon asking you to re-login?
- What page are you presented with when the VM boots up again, can you please use these instructions to upload a screenshot here?
Thanks for your reply. Sorry, I have a habit of not giving enough information!
This is a Linux VM running on FreeBSD using bhyve. The VM is a Tiny Core Linux system that I created specifically to run Roon. I am not sure what you mean by a “deep freeze” ability. Like taking a snapshot with VMWare? No, I don’t believe so. The VM is a full shut down and restart.
At 7:49am UTC 14th Feb (6.49pm AEDT) I forced a restart, and see the attached image.
The Linux VM doesn’t shutdown very nicely (it just powers off). Could this contribute to the problem? I can probably figure out a way to send a SIGTERM before shutdown if need be?
EDIT: Hmm, that time it didn’t ask me to login again, I just hit unauthorize and I was back in. I am sure it requested a log in last time.
Thanks for letting me know that information and providing those screenshots.
I have spoken to the team regarding your issue and received confirmation that a few of our team members are able to run Roon in a VM without issues, so this behavior is likely something environmental to your setup.
From the info you provided, it appears that some of Roon directories get erased each time you start up the VM, and while I won’t be able to pinpoint a specific location, our Linux Installation Documentation might help here. I would suggest you start off with:
- Running Roon Server as Root
- Make sure that Roon is able to create directories in /mnt
- The user account is able to write to the RoonServer directory
- The hidden directories inside of $Home have both read and write access
- Possibly move the Roon directory elsewhere on the drive
Again, this is not a complete list but just some of the possible causes and there might be other since we have not tested your flavor of Linux. You also might want to ask over at the Linux Section to see if anyone else has configured Roon for this platform.
Hmm, so you are suggesting there is a permissions problem. Can you please confirm that the only places Roon needs to make persistent writes is $ROON_DATAROOT (and the directory where RoonServer is installed)? Locations outside of this will not persist with this Linux build. I explicitly set ROON_DATAROOT to a persistent writable location, but it seems more might be required?
ROON_DATAROOT=/mnt/sda1/dataroot /mnt/sda1/RoonServer/start.sh 2> /dev/null &
Note that while I am already running Roon as root, I need to explicitly define which locations persist over restarts. I figured ROON_DATAROOT was enough, but perhaps not, so clarification would be much appreciated!
Yes, this does appear to be a permissions issues and it appears that part of your Roon directories are getting wiped each time since they are not set as persistent.
While I can’t comment on where exactly this behavior is happening, you should double check the Linux Install guide to try and find any directories which this will occur at or set your Linux machine to persist on all folders as this is exactly the kind of “Deep Freeze” behavior I specified in my first post,
$ROON_DATAROOT, $ROON_ID_DIR and $HOME are possible places to check but I don’t know how you have configured your environment and how Tiny Core splits up directories. All I can say is that on a properly configured VM with no Deep Freeze ability, Roon runs as expected as verified by members of our team.
Thanks for your reply, this is all I need. I will check those 3 directories and ensure they are both writable and persistent ($HOME isn’t for root, so that will be the first place to check. I assume setting $ROON_DATAROOT would make all IOs happen there, but I guess not).
Thanks for your help,
To aid in trouble shooting, I started with a clean Ubuntu install, albeit using the same manual install used previously. I still have the same issues.
There is something else going on here. I have 3 issues, that are all, I suspect, related:
- Restarting the VM results in requiring a re-authorisation
- Restarting RoonServer results in volume extension configs getting lost, even tho they appear in the dialogue. Changing them to re-save gets them picked up again… sort of.
- After doing #2, I only see volume control, not power control in the extension
Any help would be appreciated, this is quite annoying.
EDIT: Tried fresh, automatic install of RoonServer, albeit using the same dataroot with the same results. Is it possible the data root is bad somehow?
I tried with a clean OS and dataroot, same deal.
AFAICT RoonServer does not work well in a VM.
Thanks for the update here, we appreciate you giving that a try. I’ve passed your latest info along to the team for further feedback.
I spoke to the dev team again regarding this issue. Getting Roon to work in a VM is possible if everything is set up correctly, and your setup here is on the edge of being properly set up but not quite there yet.
While our support team can’t give specific instructions on the best way to configure your VM, based on what you’re describing it sounds like it may be set up more as a container than a VM, since things are not persistent across reboots.
You may also want to confirm:
• That the files in the folders I mentioned do not change after a reboot – the date modified should remain the same for all files in those folders
• Whether your VM’s MAC address changing between reboots
Hopefully you’re able to get things working with the information above. We’re always happy to help when Roon isn’t working as expected, but in this case this doesn’t appear to be a Roon issue and our technical staff is confident that this is related to how the VM is configured, which is outside of the scope of what our support team can help with.
Once you figure out the configuration issue, it would be great if you could update this thread with the details, in case others have similar issues in the future. You may also want to ask the folks in the Linux category for additional help and sorry there isn’t more we can do to help configure this VM.
@noris thanks for the reply, but please note that I have created a new VM using Ubuntu, so while the original install using Tiny Core Linux is very container like, Ubuntu certainly isn’t.
I have a fixed MAC address, as I use DHCP and want the RoonServer to have a consistent IP address, so a fixed MAC address is important. At this point there is nothing at all unusual with the guest OS.
I am a bit frustrated with Roon at this point. Multiple guest OSes, multiple fresh installs, both automated and manual, and it always fails the same way.
You post did make me wonder about modified files and timestamps. So I stopped RoonServer, and run find . -ctime 1 to see the files modified in the last day, and started it and ran the same command. Should show any new files created. The files don’t look particularly interesting, and appear to match the same list as before starting RoonServer.
I then re-configured the volume extension, and re-ran the same command, and got the same list of files. This seems a little odd.
EDIT: I can do better than that. I installed fswatch and got it to monitor the filesystem for any newly created files, or files that got written to.
The full set of created files on a RoonServer startup is:
/mnt/RoonServer/dataroot/RAATServer/Logs/RAATServer_log.01.txt Created MovedTo
/mnt/RoonServer/dataroot/RAATServer/Logs/RAATServer_log.02.txt Created MovedTo
/mnt/RoonServer/dataroot/RAATServer/Logs/RAATServer_log.03.txt Created MovedTo
/mnt/RoonServer/dataroot/RAATServer/Logs/RAATServer_log.04.txt Created MovedTo
/mnt/RoonServer/dataroot/RAATServer/Logs/RAATServer_log.05.txt Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Cache/httpcache_2.db/CURRENT Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Cache/httpcache_2.db/LOG.old Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Cache/httpcache.db/CURRENT Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Cache/httpcache.db/LOG.old Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Cache/qobuz_1.db/CURRENT Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Cache/qobuz_1.db/LOG.old Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Cache/tidal_2.db/CURRENT Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Cache/tidal_2.db/LOG.old Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Database/Core/61606aa8c5344ec2aaa89683eb33884f/broker_2.db/CURRENT Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Database/Core/61606aa8c5344ec2aaa89683eb33884f/broker_2.db/LOG.old Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Database/Core/61606aa8c5344ec2aaa89683eb33884f/clientdata.db/CURRENT Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Database/Core/61606aa8c5344ec2aaa89683eb33884f/clientdata.db/LOG.old Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Database/Orbit/orbitnew.db/CURRENT Created MovedTo
/mnt/RoonServer/dataroot/RoonServer/Database/Orbit/orbitnew.db/LOG.old Created MovedTo
Hopefully that gives some useful info.
I spoke to the team again regarding your case and it still appears that you have your Ubuntu VM running as a container and that some aspects of Roon are not being persisting across reboots. Just to confirm here – you are still being presented with the Authorizations page even when the VM is using Ubuntu?
Have you tried using another VM software to host Roon on? If both TinyCore and Ubuntu displayed this deep freeze functionality, I am wondering if the VM software itself could be causing some of the issues here.
I confirmed with the team that the list you provided is to be expected, but there should be other files created there as well, further indicating that something is not setup quite right in your VM environment.
One of our dev team members has his primary Roon core on a VM and it works as expected for him, so figuring out why this is not working for your VM configuration is an aspect you should look into and making sure that directories persist across reboots would be a worthwhile step.
One other thing you can try to look into is how exactly you are shutting down RoonServer. If you remove RoonServer from the startup script and have it launch manually, does the same behavior occur? By this I mean running a
sudo systemctl disable roonserver and then killing the process, reboot your Core and manually start it up again.
The above information is just some clues in which direction you should look towards, I can’t really guide you a definite solution here but I’m hoping this will help.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.