Latest downloaded Version:
openSUSE Leap Linux: 5.14.21-150400.24.46-default
Prevoiusly I reported issues related to cpu overheating, replacing motherboards, starting a rebuild on a budget In my attempt to provide a temporary solution in order to continue the use of Jellyfin, I installed the Intel Server mb into the existing box (redesign etc is still underway) and started the system which seemed to be fine, a few tweaks required as the router had reallocated the ip address requiring updates on useing devices.
Had to leave it there (as needed to rejoin life in general) and got back to it this morning.
System posted and graphics card installed, os drive recognised etc but wouldnât boot into Rockstor.
(See post for New Build on Budget)
(New Build on a budget)
Decided to reinstall Rockstor and carried out the steps to produce a usb drive.
Couldnât back up anything due to no access. (Should have done it to start with)
Now the only pool I can access is the new pool created during the installation.
If the disks all show up, and if there was a good BTRFS pool installed using them, then there should be a little carrot thingy next to the Name in the Name column. Maybe even 2 symbol/carrot/dowitchy thingys next to the disk name.
One of those symbol/carrot/thingys you click on should allow you to Import the pool.
If disks donât show up or show errors, make sure in the MB BIOS that AHCI mode (or whatever mode) is selected to be the same as with the old MB and try again.
Cheers @Tex1954
Back onto the job in hand, i have a log covering the reinstall from start on the 17th to reboot this morning if needed, not too sure how to upload a non-jpg file as the uploader seems to only recognise jpgâs.
Possibly a private message might do it?
I have searched the documentation for possible solutions but nothing has "popped up " to say this is what you need to do, but that doesnât mean it isnât there .
Thanks for all your help in this issue.
The system cannot import a pool if one by the same name exists. Not sure why one with the same name should already exist on a new install however.
When trying to preserve and import a new pool, it is best done from a clean install. Never re-create a pool, only import it. Re-creating a pool will wipe the old one (with warnings) or if it was recreated on different members (drives) then it will block the import of the old one due to the name clash thing:
(Master-Pool) already exists.
We need to improve our search on this front.
Take a look at the re-install pool import sections, i.e.:
The first link covers a re-install and import as it covers moving from V3 (CentOS) to V4 (openSUSE) so there is not update in place option. It should help similarly though with any re-install - import scenario.
My appologies for chasing along after your various messages here. Main think to keep in mind with a new install (existing data pools) is not to re-create any pools at all. That will not be need. You import existing pools via any one of their disk members: so the second link above.
Thanks @phillxnet
As I recall the basic procedure was:
The procedure outlined in the guidance was followed.
Data disks were not connected during the installation
No pools were created manually.
Discs were only imported when the system appeared to be running correctly.
Am I correct in thinking there is no way forward with the current installation so i need to re-install having removed the OS disc and format it as fat32 i.e useing a caddy?
(The installer did warn of deleting the entire contents ???)
Apply any update through the web UI
Try the import procedure.
Or has the wrong end of a very long stick found its way into my grasp. (Very possible)
Well, If he had created a pool with the same name, which drive did he use? In my Linux ignorant mind, doing everything with the GUI, how in the heck can that be done? He wouldnât have been able to use the disks if they already had a BTRFS pool on them to import in the first place!
On the other hand, he could have created a SHARE with the same name using âsome other poolâ and that would cause a hickup, at least it has with me.
I have imported my old stuff many times and made so many mistakes itâs hilarious! But every time I couldnât import a disk set, it was because I made some elementary booboo of this sort. Maybe he accidentally created a share of the same name on the boot drive.
In any case, I think deleting a share or all shares as a first step should certainly not cause a problem.
On the other hand, how could he have accidentally created a pool of the same name on the disks that already have a pool assigned??? That is so contradictory to how BTRFS works that it would be really impossible wouldnât it? I am speaking of using the GUI in all instances⊠I have no idea if CLI commands could do such a thing.
In any case, starting from scratch, the only way I have been able to always successfully import a pool using ONLY the GUI, no CLI stuff is:
Install new rockstor stuff.
check storage disks and make sure the system can see everything.
import the pool already on the drives. (It either works or it doesnât)
3a) If doesnât work and there is more than one drive, reboot & try importing off a different drive)
3b) Repeat 3a until you decide to pull your hair out
3c) have a drink and get some sleep
3d) Scream for help to @phillxnet !!!
reboot, make sure everything is okay.
edit the pool attributes for whatever you want.
reboot, add the shares, edit attributes etcâŠ
if everything else okay, reboot one final time and away you go.
Okay, Mike-B posted before I did and we crossed paths.
Hmmm, new knowledge of happenings nowâŠ
Mike-B, Phillxnet is the expert/developer. I bow to him in about everything.
I would say that a reinstall from scratch with data disk disconnected and all the Rockstor updates done would be a good start. Once you have the system up again and the GUI works, you can of course screen-save pics to upload etc.
Donât give up hope! You might even try the testing update channel with 5.0.8 running. As of now, the latest test version seems to be running perfectly for me (sans a couple GUI specific weirdnesses).
@Mike-B Thanks for the clarification, and my appologies for potentially complicating this chat.
Re:
That sounds ideal, easiest: starting with a clean system to import an existing data pool into has the least variables. But note there is no need for the following step:
As you say the
The install basically raw writes an entire image over the chosen OS disk.
I know, I did wonder about this myself! But we know now. Folks do often re-create a pool rather than import: sometimes using a member of the old pool (wiped first). We have heard of this: in an attempt to get the old one back. I was just checking to see if this had happened: which would lead to a need to mount the remaining old pool members with special options to recover that pool if it was redundant enough to suffer the loss of an entire member.
Yes, good thinking. This is another entirely possible scenario. And Iâd have to check if the error message would indicate this share (not pool) name clash.
Agreed again. Our import has now undergone a goodly number of field tests and is now, bar name clashes, quite robust. But bugs are unfortunately always lurking to surprise us in all non-trivial code.
Again, I find this to be risky as general advise. You are now fairly experience so usually end up seeing more than some: so we have to take care with any delete advise. And we know know the following:
@Mike-B But no mention of shares: likely safe assumption this is not shares created also.
Bit of a puzzle this one.
We do stand aside from btrfs a little here. It is possible to have labels duplicated in btrfs. But we currently treat them as canonical. We are moving to treat the pool uuid as canonical but arnât there just yet: but nearly. This is part of our effort to have pool and share renaming capability. An unfortunate lack in our current code. Iâve moved most share mounts over to id a few years ago now though.
Import list is good: and entertaining, but for:
That would be the exports, the shares (btrfs subvols) are imported along with the pool/cloneâs etc. I realise you know this but just in case folks read this and end up adding yet more shares (of the same name ) before a successful import is accomplished.
I like this approach overall. Easy to rush a disk selection: or have a senior moment! And the the hole just gets deeper !! So a simple disconnection takes all the stress out as you are only doing a clean install to the only disk there. And can check all that stuff has taken before messing with the more concerning import.
Good to hear, and exactly: 5.0.8-0 isnât released as stable, but it is a Release Candidate 3 (RC3) for the next stable. But we do still have some lurking Py2.7 to Py3.11 issues cropping up.
My apologies all around for potentially confusing things here. The linked docs in my last post do rather mention all this already. But we have to update our Reinstalling Rockstor section as it is now way out of date; relating to V3 !!!
When I mention SHARES, I need to be more specific for sure. I was talking about (SAMBA/NFS) EXPORT shares as a first removal try. However, I have also had to remove associated Rockstor pool shares to fix import glitchesâŠ
My vernacular ignorance showing⊠(red faced cringing embarrassment)
In any case, I agree with the boss, try again from scratch and before anything else is done, please send a picture of the System Disks page after you reconnect the drives and rebootâŠ
All went very well with the install up to the update, initiated from the web UI so the username and password used were correct. After the 5 minuites or so it takes to update a new log in screen appeared and guess what
.
) before a successful import is accomplished.
