It’s pretty simple. A usb hdd failed completely, and now the pools and disk cannot be removed. It is no raid, single drive. It seems I can’t delete it because it is not mounted?
Detailed step by step instructions to reproduce the problem
I tried to remove/resize within the pool (as suggested in help bubble)
Traceback (most recent call last):
File “/opt/rockstor/eggs/gunicorn-19.7.1-py2.7.egg/gunicorn/workers/sync.py”, line 68, in run_for_one
self.accept(listener)
File “/opt/rockstor/eggs/gunicorn-19.7.1-py2.7.egg/gunicorn/workers/sync.py”, line 27, in accept
client, addr = listener.accept()
File “/usr/lib64/python2.7/socket.py”, line 202, in accept
sock, addr = self._sock.accept()
error: [Errno 11] Resource temporarily unavailable
I also tried some btrfs command I found on github
[root@rockstor by-uuid]# btrfs dev delete missing /mnt2/TemporaryBackup
ERROR: error removing device 'missing': no missing devices found to remove
It says there are no missing devices. I tries some other variants of delete, but honestly I have no idea what I am doing or how to mount or identify the missing disk.
Also cannot delete the shares as
Traceback (most recent call last):
File “/opt/rockstor/src/rockstor/storageadmin/views/share.py”, line 337, in delete
force=force)
File “/opt/rockstor/src/rockstor/fs/btrfs.py”, line 787, in remove_share
root_pool_mnt = mount_root(pool)
File “/opt/rockstor/src/rockstor/fs/btrfs.py”, line 438, in mount_root
‘Command used %s’ % (pool.name, mnt_cmd))
Exception: Failed to mount Pool(TemporaryBackup) due to an unknown reason. Command used [‘/usr/bin/mount’, u’/dev/disk/by-label/TemporaryBackup’, u’/mnt2/TemporaryBackup’]
@Zonk Hello again and thanks for the details report.
Re:
I’m pretty sure this is a bug in Rockstor’s code. But it’s only cosmetic, as long as you don’t use the same pool or share name while this situation persists.
It’s not a btrfs thing. It’s where Rockstor ‘remembers’ this disk / pool as one it is supposed to be managing. That way were you to re-attache the device it would know to manage it (as it remembers it). But in this situation it finds itself in a corner and is being overly pedantic (read broken) about the actual removal.
Not really a linux or btrfs thing. It’s a broken corner case in Rockstor code.
I’ve seen a variant of this myself I think but have yet to make an issue for it so I have now done so:
So thanks again for the report and I am due to work in that area of the code again in the near future so will take a look at this particular case. Especially since it’s a fairly simple re-producer that you have described. I strongly suspect it is a ‘side effect’ of some more major changes I had to make to address a more egregious issue we had outstanding for Rockstor’s entire history so we are whittling this one down; and nearly there.
I’m assuming here that you are running the latest 3.9.2-50 Stable channel release?
Hope that helps to at least narrow down the nature of the problem, and I hope to get around to fixing this in the not too distant future.
I’m running [ROCKSTOR 3.9.2-48] and it says its the latest stable version… .50 is maybe the test version?
Okay, thanks for the explanation. I thought I should be able fix that somehow…
I’ll just leave it as is. It is not pretty, but I just recreated the shares with different names.
If 3.9.2-50 is not showing up as available it could be that your stable updates subscription has expired. You can always check on it’s status via our new ‘self service’ Appman Web facility:
The Changelog for current Stable channel is available in the following forum thread:
It’s not been properly announced here on the forum just yet and was created to address some inconveniences that we had outstanding. Contact me via PM here on the forum if their is an issue with your subscription as their have been some known issues with our move to Appman. In a Private Message we can freely discuss you Appliance ID and activation code if required and so more easily get things sorted.
Take a look at Appman and check your subscription is still running and that for each subscription the associated ‘computer’ has the correct Appliance ID (you can change it yourself in Appman if not). We can continue the Appman / subscription discussion in a PM if you end up not being able to get that update for whatever reason.
Hope that helps and lets carry on the update issue in a PM if you find your subscription and Appliance ID all look to be OK in Appman.
Yes we have some work to do in that direction for sure. Appman is a part of that work however, as is our move to openSUSE where zypper handles this a lot better than YUM as well. All bit by bit unfortunately but at least we have Appman now.
Let me know via PM if you need any help getting the subscription re-instated; if that is the direction you end up taking.
Their are ‘easy’ links within Appman to re-establish your subscription via the shop, See the Computer page “Renew” or “Extend” links against “Subscription End Date:” depending of if the subscription has expired or not.
