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.
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 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
“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:
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.
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.)