When I started, I had setup Rockstor on a USB drive. It worked great, but I decided recently to move over to an SSD for the OS.
I probably did this wrong, but what I did was do a DD of the USB drive to the SSD. Then I booted up with the SSD. Rockstor booted up fine, and everything is great. Except, the old USB drive shows as detached, and I can’t seem to get rid of it from the interface.
Here is the old USB detached disk on the Disk pane:
I get that modifications to the OS disk are not a good idea, and this is a good way to protect the user. However, in my circumstance, I’m not sure how to “fix” things. In the end, it is really just an annoyance, everything works just fine. I just was trying to clean up things after switching drives.
Doing a ‘btrfs fi show /’ I only see the one drive:
[root@rocknas ~]# btrfs fi show /
Label: ‘rockstor_rockstor’ uuid: 9041aeee-40ef-4c54-a53c-c71f3c0e492f
Total devices 1 FS bytes used 6.71GiB
devid 1 size 25.29GiB used 19.06GiB path /dev/sds3
So my guess is that this is just something in the database that could be cleaned up? But before I started poking around, I wanted to see if I was going about this the wrong way, or if there was even a recommended way to transition the OS across disks.
The Rockstor code currently has a general bug with regard to removing detached drives, and an image clone from one disk, with one serial, to another disk, with a different serial means that our bottom-up stuff is working as intended, the new device is identified as a root pool member, but out top down clean up stuff fails to remove, or allow removal of the detached disk. The manual intervention method suggested should just allow this. I’m hoping to get to this anomaly, or rather it’s more common counterpart of removing detached disks soon though and I’m pretty sure how to go about it as I’ve put some time into this problem already. But I can’t, just yet, prioritise this as it’s, as you say, cosmetic mainly. But irritating never-the-less. It’s essentially down to an over-site on my part when I had to re-jig the pool member removal stuff this there after worked much better in all cases except detached disks.
Yes that’s pretty much it actually, but we want to be able to track such events but just allow the removal when requested, and in some cases we just block or fail to follow through with the db tidy. It’s very much a case of two, or more hopefullly, steps forward and one back. We use to remove detached disks just fine but would also fail to track btrfs disk removals and simply time-out on the web-UI. Now we are able to successfully report disk removal progress through-out but fail on the ‘cosmetic’ removal of detached disks. I’m keen to get to this buggy behaviour pretty soon but given it’s mostly cosmetic I’m prioritising the base function bugs ready for our ‘Built on openSUSE’ stable release endeavour.
Forum member @Azzazel in the following forum thread has another nice reproducer of some related buggy behaviour:
Essentially there process swaps out all drive serials from under Rockstor during a VM backup restore process and the same thing that you see is seen across all drives. Again all functions as expected but with the annoying ‘stuck’ detached disks. It’s been bugging me for ages actually. Especially given it’s fairly easy to reproduce but is harmless, yet the prior arrangements bug was far more tricky to reproduce, often needing real hardware and real Pool recovery scenarious to fail under, and so was noticed far less often except when folks really needed their systems not to fail. This was covered and subsequently sorted by way of the pool management re-vamp against the following issue:
Not really, bar a re-install. We just need to address this detached disk buggy behaviour and you should then just be able to remove the rouge prior detached disk. We have to track drive-to-pool association and so this is working as intended but we should then allow for a tidy up which in this and a few other cases we just don’t. But we have to tread carefully as it’s important to keep the device-to-pool tracking intact as it can be a major help with diagnosing disk missing events.
Hope that helps, at least with a little history and current state and I’ve now added your reproducer report here to the first issue I referenced. Thanks again for the report, does give us another wrinkle re the system drive to keep in mind on this removing detached disks bug.
