[Please complete the below template with details of the problem reported on your Web-UI. Be as detailed as possible. Community members, including developers, shall try and help. Thanks for your time in reporting this issue! We recommend purchasing commercial support for expedited support directly from the developers.]
Brief description of the problem
After showing up Install Rockstor and Troubleshooting screen, I chose Install Rockstor. Then it showed up Fast TSC calibration failed, and it went so fast that I can’t catch up with other message. Finally it went black and my monitor went to save energy mode immediately, I waited for 5 minutes and nothing went up.
Detailed step by step instructions to reproduce the problem
Use diskutil on macOS Mojave to know the USB sticker and sudo dd if=Rockstor-3.9.1.iso of=/dev/disk2 bs=1m
Sounds like you did all the USB preparation properly, ie dd being the preferred method, but what looks like a clue is the following:
I’d look to custom kernel options, which can be entered at the very early stages of the install, specifically video card related ones. Does the machine you are trying this install on have an AMD / ATI card in by chance?
Hope that helps and if anyone else can chip in here with ideas that would be great. Looks like a sortable issue we just need to track down the correct kernel boot options to sort the video display out, i.e. it’s changing to something not supported by either the monitor or the card itself and this has been seen in linux with AMD/ATI. And to a lesser extend some Nvidia cards. Once the install is done the first reboot establishes the much newer kernel so you should be good there after.
I am using EMB-BT4, a motherboard with J1900. Detailed information can be check here.
I have tried an option in Troubleshooting and it seems that it came up with the ordinary centOS screen, but it finally went black.
And it seems that it parted my new hard disk when it was black without my permission, but it didn’t do any change on my another hard disk which was full of data.
Temporarily I chose Arch linux as my option, I really want to try this convenient system.
@Karl-Han Yes the J1900 is probably a little new for our way old upstream CentOS kernel so the kernel boot options is most likely still the way to go.
Another inheritance from our upstream anaconda installer. We re-badge it and use a kickstart file and only occasionally it will auto select a drive (if blank to start with) and just go ahead with the install. I also don’t like this and have seen it. And we haven’t updated our iso for some time but are in the throws of re-basing on openSUSE anyway so it seem our time is better spend on pushing forward with that so that all new install will be on openSUSE when we get to release that version of Rockstor.
So given it was actually working ‘under the hood’ this again points to a video / monitor issue. If you have a different monitor you could try attaching that. It might be a more amenable work around. Otherwise I’d search CentOS install J1900 blank screen or the like as this is likely shared with our upstream installer.
I’ve installed (though a long time ago now) on an ASUS N3700 here and I also had some graphical issues during install, manly go slow type things, but it didn’t go all out blank.
During a Rockstor system install it’s often advisable, even if just to combat human error let alone software bugs, to remove data disks (ie remove power leads). It’s just too easy to select the wrong disk and wipe your data. So I’d go with having the only drive attached be the to-be system disk every time as then it’s simply safer. All data import (if picking up from a prior Rockstor install for example) is best done with a fully updated system anyway so that can be done first before shutting down and re-attaching the data disks and powering the freshly updated install up and importing the prior Rockstor pools, or command line transferring from a non btrfs volume as required.
Thanks for your patient reply. I am looking forward to the openSUSE version Rockstor.
By the way, I have checked Rockstor’s repo in Github, and I am a little confused by python files, because I don’t understand the relationship between Rockstor and CentOS. And it seems that it can also be moved to Arch.
Could you introduce some materials about this because I am interested in and learning OS? And I will check the Rockstor’s docs later on.
Yes me too. Although of late I’ve had to concentrate on offering better support for our Stable channel subscribers via a planned appliance id management tool. This is by way of a value add to those how are currently helping to keeping afloat our current development path.
This is theoretically possible but is likely very non trivial, especially if you intend to maintain CentOS compatibility, at least for the time being, and current (to-be) openSUSE Leap 15.1 and openSUSE Tumbleweed compatibility also. This is also in the light of our need (this year) to update to Python 3 and then transition to a newer Django; both in themselves non trivial projects. Any pull requests that have not been tested on these last 3 platforms, and the last 2 in the near future, will not be merged. It’s a surprisingly massive task to transition a project of Rockstor’s size but it will hopefully get easier as we go on. I found many CentOS’isms in my current efforts towards the two stated openSUSE distros; detailed in part in:
And the various distros tend to go their own way in how they construct their btrfs offerings. OpenSUSE is, from what I can tell, the only distro that has a default btrfs install and thus has the larges investment in keeping their btrfs eggs in a row. And their sponsors SUSE employ quite a few of the btrfs developers. With SUSE offering enterprise linux support and openSUSE to SLES now assuming the same relationship re binary compatibility / transfer relationship as is the case with CentOS / RHEL, except as I see it openSUSE has more independence: openSUSE is our natural home: and the only distro to back btrfs by default as apposed to RHEL’s previously employing a single btrfs person and then dropping even preliminary support for it in their offerings. Also I see Tumbleweed as a very Arch like distro at least from the community driven, cutting edge point of view; except that their is a possibility to transition to something more stable that also has the SLES angle mentioned above. So given that I cannot help with any Arch development myself however the relevant docs for Rockstor development, should you wish to have a go, are:
And our developer doc re the current team effort to move to openSUSE is:
also note recent user reports on difficulties on compiling against Tumbleweed that I have as yet not managed to reproduce (at least the later elements of @jcdick1 ongoing report anyway). Their earlier reports re compiling difficulties managed to uncover an upstream issue re Tumbleweeds alternatives implementation breaking with regard to expected ‘in path’ links to the postgresql db server offerings:
But know that we have already had another significant breakage in our Leap 15.0 docker compatibility and our current 3 platforms all treat docker differently so even in just that element there are non trivial challenges in our code having to adapt differently in all those cases. I expect Arch will have yet one more ‘take’ on how docker should be handled. We also have the challenge of differing package availability so it’s really quite involved when it comes to it. But with enough informed contributions I don’t see why, in time, Rockstor couldn’t at least work ‘unofficially’ on a number of platforms if the will is their to at least try. I’m afraid though that I don’t have the time required to review anything submitted in the name of Arch. But luckily I’m not the only reviewer so their is hope in the ‘other’ distro support. But my focus is on the openSUSE offering while maintaining CentOS compatibility in the short term.
So in summary I would advise that you first try building from source on our current released platform CentOS and then if interested in contributing code to also familiarise yourself with building on Tumbleweed and Leap 15.1. You may find that our currently progressing Tumbleweed offering fits your requirements for super modern software combined with Rockstor’s user friendly way. Also note that when compiling the code yourself you get the latest code offerings, ie akin to our stable channel subscribers currently: the hope here being that if your are compiling yourself you are also more likely to contribute back to the project in code contributions while our stable channel subscribers assist with Rockstor’s sustainability financially. Due to mainly human resource limitations we have had to drop rpm releases in the testing channel, at least for the time being. See the following thread’s intro section for the background on this move:
Hope that helps. I for one consider Rockstor on an appliance basis and not just a package one installs. Although at it’s heart that is how Rockstor is updated, but that package in turn manages a number of other services, ie docker, making the porting of it a little more tricky due to quite a few inter dependencies.