Installer seems to dislike new hardware

So, my (now multiple day) installation fiasco has finally come to an end, and I’ve concluded that Rockstor’s installer doesn’t seem to like installing on any system built with recent hardware.

My first installation attempt was admittedly on something not yet fully supported:

Ryzen 5 1600
MSI B350M Mortar Arctic
Samsung 950 Pro 250Gb M2 NVMe SSD.

I was surprised to see that the installer screenshots from the ISOLINUX bootloader didn’t match my own, there was no logo, and the installation options stated to install CentOS, not Rockstor.
This failed shortly after selecting to boot the system, with the dreaded:

dracut-initqueue[271]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut-initqueue[642]: Warning: /dev/root does not exist

I cannot remember the initial message at the moment, I’ll try and find it again later.

After this installation failure, I noted from various reports that Ryzen doesn’t work from the installer (though boots fine after install and update), and that it doesn’t like recent video cards.
I them attempted on my personal desktop, after swapping out the M2 SSD for the one I wanted as an install target, and removing the GTX970 graphics card:

Intel Core I7 6700K
MSI Z170 Krait Gaming
Samsung 950 Pro NVMe SSD (same drive as before)

This installation failed again, /dev/root does not exist. I’m guessing at this point that it doesn’t like systems with NVMe slots.

I attempted the same on my Laptop, with a SATA SSD attached, however this failed with a new error:

nouveau E[     DRM] Pointer to flat panel table invalid

After some table flipping, and unfortunately targeting my anger in some harsh words to the missus, I decided to attempt the installation on something vastly more dated, a HP Gen8 Microserver, with the SATA SSD attached.
Lo and Behold, the ISOLINUX screen showed the Rockstor logo, and correct OS name.

This installation was entirely successful. I was able to install and update the OS, then re-attach the SATA SSD to the Ryzen with no further issues.

Unfortunately, I forgot to select BTRFS for the partitioning scheme, and it told me to go away.
I’m on my

Next, I intend to DD the installed Rockstor from the SATA SDD to the NVMe SSD on the Ryzen. I wonder what surprises lie in store for me here…

@Haioken Welcome to the Rockstor community and thanks for relaying / sharing your install experiences.

Yes we do suffer somewhat from the rather old kernel used by upstream CenOS install iso’s that Rockstor is based off, although there are plans to update to at least the latest version as we are still using a 1511 base:

And in that issue there are forum links to some who have had better results on newer hardware with 1611 and there is soon to be a 1708 which I’m hoping will be our next iso base as it is due our shortly. Just checked again and as yet not released. That issue also details a number of other forum threads indicating woes related to the older image base. I’ve just added this one to the list :slight_smile:.

Well done for persevering.

That should have been automatic (via our kickstart config), best to go with the defaults really as there is little actual customising of the installer as we assume a default install that is then ‘adjusted’ by the Rockstor programs once they take effect upon first install and reboot: ie we don’t deal with custom partitioning and assume the default presented by the installer as is. Not ideal and definitely work to be done there: starting most likely with the re-basing on the newest iso from CentOS.

If the dd transfers the partitions correctly and those partitions are ‘as default btrfs via installer’ then it may work (sort of) as forum member @snafu in the following forum thread:

helped with highlighting and testing the ‘strange’ partition naming used by nvme devices. But note the quote from the pull request that resulted:

https://github.com/rockstor/rockstor-core/pull/1399

“Please note that this patch does not address outstanding serial retrieval issues for nvme devices however @Snafu in the above referenced thread has developed a working set of udev rules towards the end of that thread.”

So as yet far from ideal but looks possible if you have enough camomile tea on hand.

As a result of the outstanding complexities of an nvme system disk install I’d consider defaulting to something simpler and easier to transfer from machine to machine (given your requirement for that given the install problems) such as a SanDisk Extreme USB 3.0 (now going up in price) or what looks like it’s successor (untested by me) “SanDisk Extreme Go USB 3.1” which in the former model’s case at least is essentially an SSD on a stick (with build in usb-sata bridge).

Thanks again for the feedback and maybe you would be best advised to take a work around for the time being and try our updated installer once it’s in place.

@phillxnet

First, I’d like to commend you and your team on your involvement with the project community. I was not honestly expecting a response to my recount of experience (Read: whinge).

That’s great to hear, and while I look forward to the newer installer for a reinstall long down the track, for now I think I’ll stick to the tried and tested method.

I wanted something better than OMV, and I wanted good BTRFS support. I’m willing to hack my way through a few issues to get it.

Probably was ;o)
I’ve never trusted default partitioning, because I typically want a large root, and no seperation for home and var, which CentOS seems to default to. I had thought (incorrectly as evidenced) that I would need to override this.

Low on tea, but coffee and beer on hand.

I think I’m going to try and make NVMe happy. I’ve got some python, udev and general *nix experience, so maybe I’ll get be able to piece together something workable. I’ll keep an image of the SATA ssd I already have working on hand just in case though.
I’m hoping that by the time I need to install again, these problems will be largely resolved, but for now, hold my beer, I’m going in.

1 Like