And why did they pick Jasmin, because the name sounded pretty? The performance has been anything but. Come on, Jasmin, let's jazz this thing up! :-D

Actually, when the system was up a few days ago, the performance was outstanding. I could send two of those 14 Megabyte files at a time every six seconds when that was happening. Of course, being down for a week or more is unacceptable. But that is due to their techical support keeping banker's hours instead of round-the-clock support.

---

Status update. I've uploaded and reported all the delayed tasks from the problem machine. Yesterday, I closed it down so that I could install all the pending security updates, and took the opportunity to upgrade it to Mint 21.1: then I restarted it again to verify that BOINC was still working normally.

I'm currently projecting that I'll reach a convenient clean edge for another shutdown around 11 am tomorrow. First, I'll be able to take a full backup of BOINC's remaining files, and then I'll try out one (or if necessary, more than one) of the suggestions so far. If anyone wants to add any extra relevant suggestions, please post them before 11 am.

Hmmm. I tried the simple method in Number Crunching (message 67873) - move the BOINC data directory to the new drive, and create a symlink in the original location - but it didn't work. After reboot, the symlink in the original location is broken, and SuperUser can't see the new drive. 'richard' (my login handle) can see and mount the new drive. After mounting, the symlink is valid - all BOINC's files are there - but the BOINC systemd service doesn't appear to see them: BOINC Manager can't connect to the client.

Reverting all that (with some difficulty) - deleting the symlink and moving the folder back to the original location - lets it all work again.

So, we're back to the original question: how can I mount the new data drive at boot time so that both SuperUser and BOINC can see it without intervention?

I think I'll take a break away from the problem for a while, and clear my head with a walk. Round 2 later this afternoon!

I've just tried that, and it didn't work. My problem is that neither SuperUser nor BOINC can follow the symlink to the new drive after reboot: if the logged-in user (me) mounts the drive manually, it works for SuperUser, but not BOINC.

When I have completed the tasks currently on this box, I will have a play and see what happens. If you right click on the directory the symlink points to what are the permissions and properties on it?

When I have completed the tasks currently on this box, I will have a play and see what happens. If you right click on the directory the symlink points to what are the permissions and properties on it?

Please continue the conversation in the Linux thread. At the moment, I've reverted to the original drive, and I'm running some quick throughput Einstein GPU tasks to check nothing has been lost in the attempt - I can retry the steps when I get back.

CRACKED IT!!!

The walk obviously worked. It turned out that when I edited fstab, I was using the UUID of the underlying hardware, when I should have been using the UUID of the formatted partition.

Once I realised they were different - Voilà!


The beer will taste good tonight.

The beer will taste good tonight.

Enjoy! You have earned it.

Edit: That all makes sense now.

I was using the UUID of the underlying hardware, when I should have been using the UUID of the formatted partition.

What was the UUID if it wasn't "174E3A15-CC2D-47DE-8C5A-AB698A1E8AAF" ?

I was using the UUID of the underlying hardware, when I should have been using the UUID of the formatted partition.

What was the UUID if it wasn't "174E3A15-CC2D-47DE-8C5A-AB698A1E8AAF" ?

It turned out to be 3c7e468d-07e5-44ac-bb24-b6d776221fc1, as revealed by gparted.