Bad thinking or bug?...and a warning to other Linux users

Yesterday I updated the Linux distribution on which I run Roon Server (it’s a rolling update so no reinstall is required). On rebooting the server it entered UEFI BIOS instead of booting Linux. I powered down the server and disconnected the directly attached drives containing music (a precaution to ensure I cannot inadvertently write to a music drive whilst recovering the boot drive). I then booted the server using a USB stick containing a liveboot instance of Linux so I could check the SSD’s function, partitions, filesystem etc. for integrity to find the issue.

A little online digging led me to understand that changes had been made to the EFI Boot Stub causing any forward slashes in the EFI Boot Stub string to stop working as before. After using Linux tooling to rewrite the BIOS’ EFI Boot Stub without the forward slashes I restarted the server, checking to see if it would now boot from the SSD that houses the server’s Linux OS and Roon Server + database. The server booted correctly and apart from the timeout messages regarding inability to mount the disconnected drives everything appeared normal, or so I thought.

I shut down the server, reconnected the power supply to each of the music drives and restarted the server. It booted and mounted the music drives without a hitch. All seemed well until I tried to run a Roon client and I was presented with a sign-in prompt a brand new virgin install would encounter - enter username and email address. Roon had effectively trashed the existing database for no apparent reason other than it on a single occasion encountered no content in the folders it looks to for content …

It’s hard to see this as anything other than poor software design. There was no reason to throw the baby out with the bathwater - a simple prompt to say “Your music folder(s) are empty, shall I expunge the existing Roon database or shut down and give you a chance to investigate?” would have completely avoided the need to rebuild or restore the database.

Lesson for Linux users: if your server hosting Roon plays up make sure you disable Roon Server before doing any troubleshooting. Roon is a rather blunt instrument!

1 Like

Hope your library was backed up.

Not quite the same as I run a Rock, but I have often restarted without my NAS drive being switched on with no problems. Roon simply says the drive is unavailable but otherwise all is OK.

It sounds as though Roon thought it was a new machine. At that login prompt did you see a Restore a Backup option in the lower left corner? See the migration KB article for example.

As @Slim_Fishguttz says, I hope you had a backup.

The key difference (I think) is that in your case your system would be mounting a network share using SMB, whereas in my setup it was a local filesystem mount. It’s possible Roon understands when a SMB share is inaccessible but have not anticipated a local drive not being mounted in a Linux filesystem - the mount point would simply appear to be empty.

Roon would have shut down knowing there is content. On starting up again the content is gone. Time to enter limp mode and ask the user whether to start over or to check whether a drive or something else has failed. If it discards the database under these conditions I suspect it’ll do exactly the same thing for a failed NFS mount, because on the surface it’ll all look the same.

Let’s see if @support has any input.

If what you say is true, a warning isn’t good enough and Roon should be involved.

1 Like

hi, what linux distribution do you use?

Hi @gduffield,

Even if your music files are available, Roon should not start with a fresh database. It seems like the RoonServer directory was unavailable or removed. As long as the database directory is still available there should be no change, regardless of watched folder availability.

Has your team tried to reproduce the issue or just assumed I don’t know what I’m doing?