Been using Rockstor now for about 9 months - Loving every minute of it!
In an effort to free up a sata port on the NAS, I purchased an m2. 128 GB SSD and used clonezilla to copy the original installation from the samsung 128gb ssd to the new m.2 unit.
Everything went suprisingly smoothly, I rebooted the system and checked things out, the shares were all still working.
It wasn’t until a couple days later I went to use sabnzbd and found the rockon service didn’t start. It seems it can’t start now.
Above is a screenshot of the UI showing what’s happened. I cannot delete the old disk, and this has caused the system to have 2 drives in the pool somehow. the only reason i noticed was that I was going to try putting a VM virtual disk on this ssd.
Any help with where the system stores it’s list of remembered drives? Perhaps I can just remove the offending lines.
@Tony_Stark Hello again. Glad it’s been going ‘mostly’ ok for your.
Am I right in thinking that your issue is the removal of the disk which now has the long ‘fake’ name with the bin / trash can by it (serial beginning S1). In which case you may well have the same problem as experienced and addressed in the following forum post:
It may be that you first just need to press the Rescan button shortly before using the bin / trash icon. Let us know if this works for you. If so then at least that will be the drive listing part sorted. Further details later on in the above referenced forum thread link to an open issue on this behaviour (my fault I’m afraid).
Let us know if that works as far as removing that entry. As a quick note it’s often easier if you copy any errors your see into the forum post if you can, of course I’m assuming there was an error displayed.
By the way when there is a trash icon by the name the drive is categorised as no longer being attached so this may well have no effect on your sabnzbd problem which may actually be unrelated to the detached drive listing. Ie from that screen shot there is only one (attached) disk that is a member of the rockstor_rockstor pool. Hopefully clicking on the rockstor_rockstor pool name should then list only one drive member. Or we have an undiscovered bug which would of course be great to know about. That is we may have a bug in removing a prior rockstor_rockstor disk in the scenario you detailed.
Hope that helps and let us know how you get on, and any error messages you receive if the above Rescan then bin / trash opperation doesn’t sort the drive removal for you.
Disk: f5e30f9c85ce40039e79e7076e9a29c4 does not exist
If you need more help on this issue, email us at support@rockstor.com with the following information:
The error message: Disk: f5e30f9c85ce40039e79e7076e9a29c4 does not exist
A step by step description of the actions leading up to the error.
Download the tarred and zipped server logs by clicking here, and attach it to the email.
Also, I noticed that after pressing the rescan button, the fake name changes. Every time i press the rescan, the fake name changes.
As to the Sabnzbd not working, it was that which caused me to look - plex is dead and so is deluge, the rockstor service is totally broken:
Error!
Unknown internal error doing a POST to /api/sm/services/docker/start
If you need more help on this issue, email us at support@rockstor.com with the following information:
The error message: Unknown internal error doing a POST to /api/sm/services/docker/start
A step by step description of the actions leading up to the error.
Download the tarred and zipped server logs by clicking here, and attach it to the email.
I saved the logs but I can’t seem to post them here.
@Tony_Stark OK, that looks like what I expected and the name is expected to change each time as it goes, hence the requirement to use the Rescan button. Apart from actually working of course.
On the disk removal front, did you make sure to press the Rescan button and then, withing a few seconds, try the bin icon; timing is the issue I’m afraid. If you wait too long then the name will change again ‘under the hood’ but not in the UI, hence the ‘does not exist’ message. Sorry to come back with the same thing but there really is very little reason, that occurs to me anyway, why this drive will not remove and the error is an indication of this very issue, ie name changing under the hood stopping the drive removal. The UI will send the displayed name as a request yet the innards have in the mean time re-named the device. It’s currently understood to be a relatively harmless issue but rather irritating of course.
Please report on if timing helps in your case. Otherwise we may have a different issue; but it very much looks like what I suspect given the “Disk does not exist” error.
@Tony_Stark Well done and sorry to have put you through that little juggle but this behaviour is a side effect of a fix way back and we just need to clean this last element up. However if your Rock-ons are now working as expected and not previously then we may have a new side effect, all be it rather a specific one (origin of imaged system drive as the detached disk).
Chuffed you are on the go again and thanks for reporting back, I have added a note to the outstanding issue to update this thread with any significant development in that area.
