@KarstenV Having slept on it I have another more specific idea which I think you should try first. A frequent forum contributor @sirhcjw in a recent post improved their instability problems by adding the kernel parameter acpi=off. They were also on older hardware. Please read their and my comment on that post for context. As I read their snippet of logs it would seem interrupts were not properly configured and a knockon of this was that the kernel was failing to communicate reliably with the drive controller (and potentially many other things hence my recommendation there after to simply their system) as a result the kernel was continually resetting the drive controller to try to rectify the problem which would in turn result in the drive subsystem intermittently becoming unresponsive / unavailable. Now during install this may well have been happening (the install log would have evidence of this) but may not have caused enough disruption to fail the majority of the install. The majority of the install is simple rpm execution. However if this happened during the grub install then we are dealing with grubs own install timeouts rather than the more generic and I suspect more lenient rpm timeouts. Also note that in the snippet of logs on the referenced post there are repeated:-
lines. The regular rpm subsystem doesn’t work at this level and will just wait for things to settle and access the filesystem when it finally re-appears. But the Grub installer specifically accesses the drive at a low level, and in fact wants to access (among other areas) sector 0 or there abouts. So to me this looks promising and worth a try, especially since it’s quick and has parallels to your circumstance.
To implement you need to:-
- Press the "Tab" key on initial install screen.
- Add to the white text that appears at the bottom of the screen the following:-
- acpi=off
- while you are at it you could remove (its one long line word wrapped) the "quiet" entry
Your should then have something like:-
- then just press the enter key and install
Fingers crossed you may be away.
Rockstor uses one of the most current kernels of any linux distribution so that it can track / implement the new technologies of btrfs so the time distance between its kernel and your hardware is likely to be bigger than on any other distribution. Having said that the installer actually uses a much older kernel that is standard to CentOS 7, it is after all a customized CentOS 7 installer / system. Now upon first reboot after install you will hopefully be running a newer kernel that may suffer from the same incompatibility to a varying extend. The acpi=off that you issued to the install kernel will not be issued to the installed systems kernel. For this you will have to follow the directions given in the same forum post as previously referenced and edit your installed /etc/default/grub to include acpi=off. Hopefully your system is stable enough to get this done. A reboot will be required for the edited grub kernel parameters to take effect though.
-
The quiet kernel parameter is to reduce the text output during boot; but it might tell us something hence removing it.
-
acpi incidentally is short for Advance Configuration and Power Interface
Hence if not working properly we have a misconfiguration. Turning it off will force the kernel to use older methods to setup the hardware that in the case of older hardware may be more successful. -
There is of course sometimes no getting round incompatible hardware and if this is the case then you will of course have to use another distro / OS, or use compatible hardware. Many manufacturers for many years paid less heed to standards and more simply to MS OS compatibility; this obviously does not serve well other OS’s, ie searching acpi and freebsd shows multiple references to older hardware requiring Freebsd’s equivalent of “hint.acpi.0.disabled=1”