Hello
I have been trying to install rockstor software onto a pc system so we can use it as a NAS server etc
However, I always get the same error over and over again which the switch root folder fails. I have tried many troubleshooting steps to see what the problem is but nothing. I have successfully installed it using a VM on my personal PC but when installing it from a USB i run into issues. such as no rockstor gui and instead asks me to install CentOS7
the system specs are ryzen 3400g, 16GB 2999Mhz ram, msi b450 motherboard, and about 6 drives.
I’m having the same issue. Since new users can only have 1 image or 2 links, I’m just going to link this imgur album, and reference the photos in it. Full part list can be seen as the first image.
My HDDs aren’t connected yet, only the NVME is. I’ve tried installing from a USB set up using both Rawrite32 and Rufus in DD mode. Neither worked. My guess is it has something to do with the NVME drive or the CPU. I saw this thread as well, which mentioned these same messages on similar hardware, but a simple change in usb setup didn’t do it for me like it did for him.
The first screen that I’ve usually seen in the example install videos has the Rockstor logo. This never appears. This expected screen is the second image in the album.
Instead I get a generic one with similar options. I assume that’s also not normal. What I’m seeing is the third image in the album.
After selecting the generic “Install CentOS 7” option and letting it sit for a bit, it eventually drops into emergency mode. Since we can’t actually upload txt files to discourse, I figured a quick would have to do. That’s the fourth image in the album. The rdsosreport.txt file doesn’t really give anything else more helpful anyway.
If anyone can help, that’d be great. I can get any other information needed on request. Thanks in advance.
Hey Def_monk!
I have managed to bypass the installation. Please follow these steps
set up vmware and allow the usb you want to install it on access
mount the iso to the VMware, I recommend you give it 8GB of RAM and 4 cores of your CPU to help speed up the process
make sure the USB you want to install it on has a Serial number less then 128 characters otherwise you will run into a new error, click me to see the new thread I have made
once you have installed rockstor and it tells you to reboot, do so then shutdown the VM.
make sure rockstor is working by removing the ISO and starting the VM
if you are happy put the USB with rockstor into the PC you want to run it off
this should be it, you can find the IP of rockstor by accessing your default gateway or if you have set a static ip use that. but remember it is https://192.168.x.x
This is how far I have gotten on my own so far, hopefully one of the devs can reply and confirm my findings soon!
Hi @Regan! Thanks for the update! That does sound like it would work, but sadly I’m not actually attempting to run Rockstor off the USB drive. I’m aiming to only use it as my install media to install the OS on to the NVMe drive in the tower.
I might be able to do similarly on my main desktop to make the NVMe drive bootable (I think I have an open NVMe there, and could just let vmware have control of it to set it up) and move it back when I’m done. At that point, it’s arguable that the effort to make it work would be the same as just doing the btrfs management myself in another linux distro, and this way I have no guarantee it’s possible with the NVMe drive.
I continued poking around on the forums a bit and found another thread here. Based on the related github issue, it doesn’t seem the issue had been resolved by updating the installer to a more recent version at any point (the issue has been open since 2016). I assume this is likely related.
If there’s anyone lurking who has been keeping up with the development on the project: is this something that’s been ignored due to the move to OpenSUSE? From what I understand, that version isn’t quite ready for general use yet.
I’m sorry it’s under difficult circumstances, however. I’m not an expert with regard to these questions but I’ll try to help.
I believe it is indeed related to the relative old age of our current ISO installer, unfortunately, but I’ve seen this error in the past. I believe you have too, as you mentioned having poked around the forum further. I would point you to a few instances where users had the same error on similar hardware (Ryzen & NVMe drive):
You may have seen them already but maybe they’ll help.
As mentioned above, I’m not expert on this but I too would look into using a separate machine to install Rockstor onto the NVMe and then transfer it into the final machine. @Haioken and @phillxnet will know a lot more about it than I do, but if you have the ability to try that easily it might be worth it.
@phillxnet will, again, be the reference there, but I do believe so, yes. This will, most likely, improve compatibility with new hardware like that immensely.
Yea, I’ve seen those in my searches. The second one (from Haioken) in particular stood out as being very similar. I’ve tried a few methods of creating the install USB and even tried legacy rather than UEFI boot, but neither have worked. I can’t think of much else other than hardware detection/compatibility after exhausting that route.
I’ve seen the solution for installing elsewhere and moving the drive after the fact in a few places. I’d normally have just gone for it and tried it, but don’t have any other non-Ryzen hardware around with NVMe support at the moment.
I saw someone elsewhere do an install to a regular SSD and then copy from there to the NVMe drive using clonezilla. That might be a viable option if I have to go down that route. T̶h̶a̶t̶ ̶w̶o̶n̶’̶t̶ ̶r̶e̶q̶u̶i̶r̶e̶ ̶m̶e̶ ̶t̶e̶a̶r̶i̶n̶g̶ ̶a̶p̶a̶r̶t̶ ̶m̶y̶ ̶w̶o̶r̶k̶s̶t̶a̶t̶i̶o̶n̶ ̶e̶i̶t̶h̶e̶r̶,̶ ̶s̶i̶n̶c̶e̶ ̶I̶ ̶s̶h̶o̶u̶l̶d̶ ̶b̶e̶ ̶a̶b̶l̶e̶ ̶t̶o̶ ̶d̶o̶ ̶i̶t̶ ̶e̶n̶t̶i̶r̶e̶l̶y̶ ̶o̶n̶ ̶t̶h̶e̶ ̶n̶e̶w̶ ̶b̶o̶x̶. (EDIT: Scratch that. Having the regular SSD available didn’t make a difference. It seems to be specifically the platform, and sadly, I don’t have any non-Ryzen hardware atm). If there are other easier/consistent solutions though, I’d definitely be open to them. Lol.
EDIT 2: I’ve been looking at the OpenSUSE rebase offerings as a possible option as well. I can see here and here that things are getting pretty far along, but not quite there. I assume being able to install an updated base of OpenSUSE would likely bypass my issues.
There are several places in those two threads that mention what current issues there are or what isn’t working yet. Is there anywhere that has a more complete & up to date list (there doesn’t seem to be a tag for it on the github tracker) of what needs to be done? I am a developer for my day-job (albeit without any substantial experience on OS-level stuff) so I can definitely try to document/assist (or even contribute if it’s something I’m comfortable with) as needed.
How is the status of the btrfs interactions in the SUSE version? If something goes wrong and I need to reinstall the OS, that’s not a huge deal. As long as it’s still possible to re-mount the drives and import the pool (even if I have to do it command-line myself and have rockstor eventually notice it), I’d be willing to use it for my home NAS in this case. Anything important has cloud backups, so the NAS is mostly for media that would just be a time-consuming pain to re-acquire.
Is this a terrible idea? I understand that no one working on the project would directly recommend this as a solution, so I figured I’d bring the option up. Lol.
I’m fairly familiar, along with @Flox, of Rockstor’s development and your are correct that our installer focus has been completely biased towards the openSUSE front and I hope to have an announcement for the forum on this front soon, just got to clear some legal use stuff with the openSUSE folks first. But given the efforts you have both gone too to try and make the old installer work on the new shiny you both have, maybe it would be less work all around for you to strongly consider jumping on the “alpha testing” openSUSE variant, which for the time being at least starts out with a vanilla openSUSE Leap 15.1 install with a few minor configuration changes from default and then a manual rpm install from our openSUSE testing repository. The following “Announcements” forum post from a month ago details what to expect from it and us:
That would at least mean you are reaching into the future for a solution rather than the past.
Note however that we don’t yet have a stable rpm offering for Leap15.1 yet as given the existing wrinkles it doesn’t yet seem fitting. But your experiments and informed reports of your findings can only help with moving us closer to that situation which would of course be best all around. So yes, early days, but worth a try if you are fairly technical, ‘linux’ aware, and fairly game. Just make sure to read fully all the links from the referenced forum post.
The exact same code in GitHub is used, concurrently, to build our CentOS stable rpm as is used to build our openSUSE Leap15.1 rpms. We just have some kinks to work out where stuff works in CentOS but not in openSUSE. Such as those posts indicate, ie the terminal app within the Web-UI and creating shares on the system drive. Scrub progress reporting is likely broken also but the scrub should still be instigated and should also complete as intended, just the reporting of progress as the command output format changed in one of the btrfs kernel back-ports. So in short the rpms are all rolled from the same GitHub tag.
From this I do think you should give it a try. Just keep in mind that we are ‘in progress’ and are still very much supporting the CentOS variant until the openSUSE offering is ‘on par’ at least. But your informed and active (if patient) involvement can only help here. Plus you’d be running a much much newer btrfs stack as openSUSE back-port a tone of btrfs stuff to their seemingly similarly aged kernel.
I’m working on the project, and with your above caveats, and you having read the various warnings and your obviously ‘game’ attitude then why not. We are building this project in the open via community collaboration so I’m all for folks trying out the openSUSE offering. But as you intimate, nobody wants the early nature of these openSUSE offering to spoil the work we have all put into the project thus far on the CenOS side. But if you understand that it’s not yet at feature parity and are game to chip in to make it so then great. Especially given your rather limited options with regard to our now ageing CentOS installer. We have had a few folks here on the forum running source builds already on openSUSE but that’s really very much only sutable for those developing rockstor. And given the testing rpms are now available that should make for a better testing platform for us moving this whole openSUSE thing along so we can offer a stable variant. Which is the entire point of the testing offering in the first place of course.
So along with my own fairly game attitude on this (with noted caveats) I’d also take into account anything @Flox has to say on the matter rather seriously as he has done a lot of the openSUSE testing to date.
Given Rockstor support is predominantly community based the more folks trying the openSUSE testing branch the better. Just heed the warnings and know that core rockstor developers can only really spend time on informed reports as 20 reports of a documented known issue is frustrating at best.
Hope it work out and keep us updated on your progress. I’ll link here to my “Built on openSUSE” installer announcement once I’ve gotten all the ducks in a row, but there are quite a few ducks.
There is a workaround that i found useful, is to use linux on a vm and follow the command to mount the ISO to a USB. It could just be that windows is being funny with how it mounts to the USB. Although it may not work for all it worked for me and I am not getting any errors at the moment
Ha! Doing the install went swimmingly (other than needing to remember to reboot which runs the initialization and startup after install; glad I remembered reading that somewhere) and I’m currently running 3.9.2-51 on Leap 15.1 (4.12.14-lp151.28.36-default). Thanks a bunch for the help!
I’ll chime in somewhere if I come across any issues. Time to start putting together my pools.
Currently I’m running on the testing channel. One of those threads stated updates should start coming through the UI again soon. I understand in the CentOS version, current updates come on the stable channel. What is the circumstance now that I’m running the SUSE version? I assume it will be ‘as described’ in the update channel documentation?
@def_monk Thanks for the update and Glad it when smoothly.
Yes, just installing the rpm doesn’t kick off the systemd services but it does enable them. Hence the reboot requirement, or manually starting them appropriately.
Yes that is the hope. And 3.9.2-51 had a couple of fixes for updating both non rockstor packages and all packages including rockstor on a “Uses openSUSE” instance:
Check the issues listed there beginning with [openSUSE]. Although we don’t always remember to flag them as such.
You should also subscribe within the Web-UI itself to test the Web-UI offering you updates, and listing the associated changelog features. As of writing 3.9.2-51 is the latest available anyway.
For our openSUSE offering we have returned to the ideal of the testing channel being as described in the docs, ie ahead of stable but for development / active testing only. I haven’t yet announced this openSUSE variant testing channel availability within the docs as I at least wanted to first have some ‘game’ testers such as yourself who were in contact with the likes of me and @Flox here on the forum to get the very roughest edges out of the way first. There after I can change the docs to state this much missed update channel’s relaunch. Your version is only the 3rd published in the repo so it’s very early days. And I’m hoping it’s the first to successfully update itself via the Web-UI. This was a prerequisite for the testing channel re-launch as then testers can, having reported an issue, update to in turn test a published fix. You can report on your experiences of that once we’ve released another version, which should be quite soon hopefully.
So in short: welcome to the wild edge of our “Uses openSUSE” / “Built on openSUSE” endeavour. Enjoy you professionally maintained btrfs backports and boot to snapshot capability, but watch for those Rockstor rough edges.
Well done for persevering and do please be patient on the fix front. But I think we are definitely getting there.
