Hi
i’ve been trying to set up raid1 for my rockstor setup but when i go into the Troubleshooting shell i get alot of dracut-initqueue errors (see image here for more details) and i can’t perform the next steps in the guide (mkfs.btrfs fails)
i’m using the 3.9.1 image and i get this booth on bare metal and in virtuelbox.
@HBDK Hello again.
I’m assuming you are following the Mirroring Rockstor OS using Linux Raid howto in the docs. In which case I think I know what’s going wrong.
Please see my following in a potentially related thread:
ie I suspect we have a label mismatch in our 3.9.1 iso which is noted in the following issue:
https://github.com/rockstor/rockstor-iso/issues/22
Let us know if this sorts your problem.
Hope that helps.
Hi it worked but now when i run “cat /proc/mdstat” the list is empty.
if i run “fdisk -l” it will list (img1 img2) both drives and say that they are a member of a linux raid.
Yes, I’ve just confirmed the same behaviour, something must have changed in our installer since that howto was written.
Anyway it seems that what is needed is the following command to scan and assemble all arrays:
mdadm --assemble --scan
I have created an issue in our rockstor-doc repo to address this:
Thanks for your feedback on this one. It would be good to get this one sorted: fancy having a go at a doc pull request.
Let us know if the rest of that doc works out for your.
Hope that helps.
OK I will go trough the rest of it on my VM tomorrow and and if every thing works out try to reinstall my server. and if that all works out then i’ll try to update the documentation.
i’m guessing you plan to fix these things later so i should it state that these steps are fixes for the 3.9.1 installer?
HMM it will not make the Root subvolume now.
it fails and when i click for details it says “not enough free space”.
Great, the Contributing to Rockstor documentation section of the docs should be useful on this one.
the additional command requirement may just be down to upstream changes in the installer as since that doc was written we have inherited changes after rebasing on a newer version of CentOS for our iso. Our installer is essentially a re-branded CentOS installer and we have made no other changes that I can see would have affected this auto start of mdraid or not behaviour. But we do have that label issue which should be fixed so it’s possible that could be upsetting something. You could add a small note on the label issue if that was what you were thinking, ie point to the GitHub issue as then once it is resolved then it would be noted as such in the issue itself.
No, that additional command is harmless so might as well just pop it in.
That is not my experience having just gone through the install as per the howto but with our discovered caveats; ie the label change (bug work around) to use the rescue system and the additional command once in there to activate the mdraid arrays (suspected changes upstream on defaults). There after I was able to follow the directions as written there after and the install completed successfully.
Could it be that you have forgotten to tick the “reformat” where indicated?
It’s a pretty round about way to do things but it allows us to circumvent the installers inability to do this install without a ‘double take’ approach such as the howto details.
It’s getting late here so I’ve got to dash but I would say that although my install went as described the first boot resulted in an emergency mode so we are not there yet. Looks on quick inspection to be some issue with the /home subvolume:
BTRFS error (device md125): subvol 'home' does not match subvolid 5
Oh well, I thought we had nailed this one. I’ll try and put some more time into this to see if it’s still possible to install this way. Otherwise it might be that we have to wait until the next iso is rolled out and see how it goes with that one.
Hope that helps and let us know if you run into this and manage to sort it. I may have missed something myself or it may just be an artefact of me having to break off during the install process earlier and then restart it. I’ll update if / when I find out.
Otherwise you options are to try installing using the 3.9.0 iso where this method presumably still works and then update once installed.
i found out why i got the “not enough space” error.
i didn’t change the “new mount points will use the following partitioning scheme” dropdown menu from LVM to BTRFS
and i got the same error.
i looked at the fstab in my current install and compared it to the one on the failed raid1 install and found that my current setup doesn’t have any subvolid in the fstab, so i removed it from the / and /home volumes in the raid1 setup and reboot and now it seems to boot just fine.
@HBDK That’s great news, and a nice find. Well done re:
And given subvolid of 5 is ‘special’ and references only the top-level volume that looks like an upstream installer bug where they are using parent volume id rather the sub volumes own id when constructing the fstab:
btrfs subvolume list /
ID 257 gen 78539 top level 5 path home
ID 258 gen 81102 top level 5 path root
ID 260 gen 78538 top level 258 path var/lib/machines
so home=257 and root=258
and from the btrfs SysadminGuide we have the following:
“The top-level subvolume (with Btrfs id 5) (which one can think of as the root of the volume) can be mounted, and the full filesystem structure will be seen at the mount point; alternatively any other subvolume can be mounted (with the mount options subvol or subvolid, for example subvol=subvol_a) and only anything below that subvolume … will be visible at the mount point.”
my “…” and bolding in the above.
But this bug only shows up when installing to an existing btrfs volume, such as we created during rescue mode by the looks of it as a regular Rockstor install, as you say, doesn’t have these subvolid’s specified:
I’ve confirmed your subvolid removal fix here by the way. Thanks for working through this one, it’s good to have this install option available again for the 3.9.1.iso.
Maybe this subvolid issue could be added as a note/caveat within that howto if the emergency prompt is displayed. If you fancy you could open another issue in the docs repo, linking back to this thread, that addresses this additional caveat with the newer installer. Here’s hoping the same is not in the next iso rebase we do.
Cheers and thanks for your contribution here.
yeah it had quit a lot of small bumps.
i think i’ll try to make a pull request for what we have found so far. and maybe try recovering from disk failure as well to ensure that it still holds (i suspect there might be one small thing missing in it.)
That would be great, and much appreciated. We could also make a point of double checking the resulting howto after the next iso release to check for any further regression.
Cheers.
yeah i might be a good idea.
i’m just about about ready to attempt to make the pull request now.
i have included the error messages in great detail so i hope they will come up if someone tries to google this issue and rockstor.
