Rockstor 4 Installer Recipe - call for beta testers

I am somewhat relieved, and a little surprised, to finally be announcing our new installer recipe. And I would like to call on those interested to ‘check our workings’. We do not yet have a binary download of the resulting installer as we must first ensure we are finalised on what it is we intend to be distributing in binary form in the first place. This new repository release, and this forum threads/request, is all part of that process.

So please visit the above repo and try out the instructions there in the README.md file and see if it builds and installs as expected for your. As noted in that file we have working profiles for the following main targets:

Available tested profiles

  • Leap15.2.x86_64
  • Leap15.2.RaspberryPi4

N.B. by default the resulting installer will only show target drives that are < 500 GB as a safety measure as it is assumed the system drive in most cases will be less than this size and existing data drives will likely be greater than this. A grub boot time intervention can remove this safety feature if required. We should probably add some text on how to ‘undo’ this safety feature. Do feel free to document that by way of a pull request in that repo on the README.md file if you fancy. I’d like to foster as much community participation on this repo as possible as the installer is a key element to our pending re-launch and my experience/knowledge of kiwi-ng is essentially only what was needed to create this config. I had not previously used it.

I would like to thank the intrepid @Flox for their super diligent private alpha/beta testing and help in developing this kiwi-ng based installer. It would not have been at the stage it is now without their continued efforts.

Linking to our new end-user doc entry for how the resulting installer is meant to work:

"Rockstor’s “Built on openSUSE” installer - Beta release"
http://rockstor.com/docs/installer-howto/installer-howto.html

Please take a look at this doc so you know what to expect. It also contains some important upstream acknowledgements that are important as the developers of kiwi-ng were super helpful with regular quick fixes relating to the earlier development of this config. It seems the oem variant I’ve chosen was not all that common at the time but is perfect for the appliance angle we are aiming at.

I would also asks that you do not re-distribute the resulting installer, given it’s beta status, and our in-progress trademark compliance enquiries as we finalise exactly what it is we are to be releasing officially on our download page; and what more might be expected of us in this context; if anything. So strictly a recipe only currently. But the moment we are clear on ‘doing the right thing’ by our upstreams then we will be hosting installers pre-build. If you are in the know in these areas then do please chip in as this is another area I’m having to learn up on. And also, as stated in the readme, pull requests are welcome.

So if you have a moment do please attempt to build, as per the README.md, your own Rockstor 4 installer and report your findings on whatever hardware you can. All reports welcome and we can start to get this new repository off the ground with issues and pull request to move towards the end goal of our pending Rockstor 4 “Built on openSUSE” relaunch. And by the way, openSUSE and SuSE create their own installers using kiwi-ng (python based) and it’s predecessor kiwi (perl based I believe). So we are in good company with regard to technology use.

You may be surprised at just how fast it can be to do a fresh install now. I.e. < 5 mins to Web-UI on > 5 year old hardware. Please also report your timings, i.e. from initial installer grub screen to Web-UI setup screen available. Interestingly Rockstor is then available for use/config without even a reboot. But do also check rebooting obviously, after having visited the Web-UI, as there have been known issues early on in the development where the first boot was OK but subsequent reboots failed. This was fixed in upstream however so is unlikely now to reoccur. Also note that the installer auto resizes to it’s target disk. Do also ensure that this has happened as well. Again it did failed in early development but again was fixed in upstream.

So over to you:

Please build, test, and report on the proposed “Rockstor 4 build on openSUSE installer” so we can finally move to distributing a new installer. My aim here is to get everyone over to Rockstor 4 as easily and as fast as possible, but to do that we need community knowledge of how this installer is build and how it is intended to work, and how it might be improved or tweaked/configured if needed.

A last note on the installer build itself: building an installer is not a light task, it will likely require hundreds of MB of download and will take quite some CPU crunching towards the end so best use your fastest machine for this one, or is you do this in a VM, don’t be too stingy with the VM spec :slight_smile:. As a rough guide, an SSD based Haswell i5 class machine will take around 10 minutes to complete the task. Expect the resulting installer to be around 500 MB.

Enjoy and do please report your findings.

4 Likes

Firstly, I was so pleased to see Rockstor is moving to OpenSUSE. As an employee of SUSE myself, looking for a new NAS OS, it couldn’t be better timing!

I successfully built the installer recipe ISO, however I’ve been unable to actually get it to install on one of my bare metal boxes. It seems after the raw image copy section (after system disk selection) it doesn’t progress to the configuration wizard (which I do get to with the same ISO on a vm on my laptop), and drops out to an emergency shell (see screenshot).
Anyone got any ideas? Not sure if it’s HW specific, but other distributions (including of course OpenSUSE) install successfully.
I’m tempted to try deploying opensuse then Rockstor on top to see how I get on, but happy to help troubleshoot/debug the ISO to ensure it works.

This was done using legacy mode, as when using EFI mode I could never get the server to see the (virtual) cd as a valid boot option.

Thanks in advance for any help!
screen2

EDIT: might be worth mentioning that this server has 2 x NVME drives and 4 x SATA HDDs, using the first 256GB NVME as the system disk.

EDIT2: was successfully able to install using a blank 15.2 + testing repos.

2 Likes

@rssfed23 Hello again, and glad your happy about the openSUSE move. I’m pretty chuffed about it myself actually. It’s taken an absolute age but we are pretty much there now which is great.

So this is a new one. And it looks very much like it’s failing during the partition expansion phase. At a guess I’d say this is a bug in upstream kiwi-ng associated with something about your target system device. I know they are super active and have made some changes I believe in this area recently. Plus they have been very responsive and helpful to what little interaction I’ve had in that repo during the early development of the rockstor-installer wiki.

It may very well be worth approaching the kiwi-ng team on this one as our end of this is fairly standard I believe. And given our

is publicly available you can point to it and indicate the profile you used. I’m assuming you used the Leap15.2.x86_64 profile here as our Tumbleweed one is broken and Leap 15.1 was really only there to lead us into the Leap 15.2 Rockstor 4 re-release phase.

I have successfully installed in both modes myself, but I know some systems are pretty fussy with regard to seeing some boot devices, especially in efi mode. You could try enabling the CSM mode/plugin/option I think it’s called in the bios. That worked for me to see a boot device on a system that otherwise refused to see the boot device I was using. But it was then able to see the efi option on that device and the installer usually presents both efi and non efi options, which is nice.

A quick though. You did ensure that you used the latest kiwi-ng via the instructions. And didn’t use the default one included in Leap 15.2. That’s important as kiwi-ng is super active and I think the default Leap 15.2 one is now too old. I.e. this bit in the docs:

sudo zypper addrepo http://download.opensuse.org/repositories/Virtualization:/Appliances:/Builder/openSUSE_Leap_15.2/ appliance-builder
sudo zypper install python3-kiwi

as then you get their latest.

I did see the following issue just get resolved. Only had a quick look but it’s recent enough that maybe it hasn’t yet been released in the very frequent package form:

It was fixed 5 days ago now so it may well not yet be in their package release. However they did tag 4 days ago at v9.21.9:

Nice. Well done. Would be great if you could keep us updated on future installer attempts though. Although we do now have this as a reference which is great.

Thanks for the report and chuffed you’ve now got a Rockstor 4 instance up and running. Our installer is really not that far from a base Leap15.2 JeOS image.

Hope that helps.

Thanks for the detailed reply @phillxnet.

You’re right; I built on Leap 15.2 earlier today.
Definitely was using Kiwi-NG, but I’ve just checked and the repo isn’t quite yet up to date with their latest released (python3-kiwi-9.21.7-lp152.1.1.x86_64).

I’ll keep an eye out and try again & report back once that fix is in the repos, as reading the ML thread it would make sense given I installed it onto NVMEs and the potential for misalignment.

I’ll be wanting to wipe and use the appliance anyway for the eventual personal production install in a few weeks. Just kicking the wheels so far, and really like what I’m seeing! I’m just kicking myself I didn’t discover Rockstor sooner after I’ve wasted a few weeks time on those BSD based SW NAS’!

2 Likes

@phillxnet going to give this a try. Just built the ISO on a VM on my mac for 15.2 x86_64 and 4.0.2 and will try the install on a HP DL380G8 today.

2 Likes

@magicalyak Thanks, that would be great.

Which installer build method did you use. The top level readme one (raw kiwi-ng command) or the vagrant_env one? And did you end up specifying the rockstor package version to get 4.0.2-0. If so that’s fine as you end up with that pre-installed. I’ve pinned it to 4.0.0-0 by default so folks can test the update once subscribed to testing. But that looks to be working just fine actually, or at least we have had no reports otherwise.

Cheers, and thanks for stepping up to yet more testing. I’ve got an NIS regression fix in the works but other than that it’s looking OK for an RC2.

@magicalyak If you haven’t already, you may want to take a look at our doc entry re the new installer:

Rockstor’s “Built on openSUSE” installer - Beta

http://rockstor.com/docs/installer-howto/installer-howto.html

It is linked in the top readme.

Hope that helps, at least with what to expect. As this installer is very different from our last one.

1 Like

I used kiwi-ng and 4.0.2

1 Like

Getting device not found, I think it’s a dirty drive. I am using Centos7 rescue to wipefs and trying to remember the command to force a clean disk (so btrfs doesn’t think it’s dirty). Can’t remember if it’s a dd command or something else.

I think this works

sudo wipefs --all -t btrfs /dev/sda /dev/sdb
1 Like

@magicalyak Re:

Interesting. I’ve not had that myself. At lest yet. And the command that Rocsktor uses internally to wipe a disk is as follows:

So:

wipefs -a dev-name-with-path-here

That should remove all stuff. However at what point did you get this “device not found”?

Cheers.

1 Like

Right at boot, do you think it’s because it’s skipping devices over 500GB? I was going to use a 4TB drive but I’m thinking I need a smaller one (this seems weird though).

@magicalyak Re:

Are yes, sorry; forgot about that ‘safety’ feature. You can remove it as an option via the grub kernel command line edit intervention. We should add a doc entry for this come to think of it.

We purposefully only show < 500 GB to help folks avoid accidentally installing over their data drives. Trying to play it safe give I’m keen on having this very accessible and mostly folks use a small drive for system and lager than 500 GB for data drives so we have our safety net.

Here is where we build in this option:

So you can just grub edit the command kernel command line and remove the:

rd.kiwi.oem.maxdisk=500G

entry.

Let us know how this goes.

Cheers.

1 Like

@magicalyak

Trying to encourage seperate system and data drives as much as we can, hence say a small ssd for system and big hdds for data.

But we still have feature parity with being able to create subvols on the system drive in our “Built on openSUSE” variant.

1 Like

I modified the command line on the boot menu (pressing e) and that worked. Not sure it makes sense to limit (better to suggest I think?).

2 Likes

@magicalyak Re:

Agreed, but there is not a suggestion option unfortunately. We use a completely vanilla kiwi-ng so have to stick to their capabilities re options available. They may be up for pull requests on this but I’m unlikely to find the time for this myself for quite a while by the looks of things in the Rockstor camp.

Thanks.

I’ll take a look, I think I can make the PR for it.

1 Like

I’ve had a few interactions with the main dev during our development of this installer config and they were both super helpful. Hence my credit to them in the docs. This is the upstream project:

Essentially a re-working in bash/python of the old kiwi (perl I think). And it now pretty much as feature parity bar a few things they just dropped due to lack of use, ie re-partitioning etc.

Hope that helps.