Rockstor 4 Pi build first observations

1

First thing to say is I am new to Rockstor and here, so bear with me please.

I’ve spent some time with the build process for a Pi4 target, and wanted to report back my non-expert findings to the community.

I used a Pi4 to build the installer, and the process in the instructions went without hitch: a .raw file (5.2GB size) was successfully created.

However, I could not get a successful boot from either SDCard or USB SSD using this image. After a bit of head-scratching, and an enlightening discussion with @phillxnet on here, I was about to run through the build process again with some additional advice re potentially missing dependancies. Before that, I thought I’d try one last thing with the original .raw file - use a different image writing tool.
Indeed, it seems the built-in tool in my laptop distro was the culprit: I went back to Balena Etcher with success. And yes, I know I should probably be using dd.

I believe the installer build itself to be pretty solid: it built a working .raw image without fuss.

So now I can get a booting Pi4. Well, within reason…

Pi4 boots from SD Card perfectly every time, with or without additional USB drives (ie for data) attached. Rockstor 4 Webgui is accessible, and very responsive, from Chrome on my laptop.

Pi4 will boot from USB SSD, but NOT if additional USB drives are attached at boot time.
Also noted that SDHCI errors were repeatedly generated (I assume complaining of no SD Card in slot). The system still booted successfully and the Rockstor WebGui accessed in the usual manner from my laptop browser, but the screen attached to the Pi for initial setup shows continuously looping SDHCI errors. Simply placing a formatted SD Card in the slot stopped the errors, as the OS could now see something there. This is definitely OS related, and could probably be avoided by blacklisting SDHCI modules - I need to try this, as I don’t know what the knock-on effect of doing this might be. As the Pi would be used headless, these errors would not be visible anyway but I’d rather not have them.

None of the above issues are related to Rockstor itself, but rather the underlying OS. I’m not an expert in SUSEland so will need to try my best mate (Google) and this forum to get some pointers.

Once booted however (I stuck with SDCard boot), Rockstor starts up fine and works like a champ. It was extremely satisfying to log in to Rockstor 4 on a Pi, select Testing channel, and watch it do the update to 4.0.2-0.

I worked through the usual steps of setting up drives, pools, shares, users, SAMBA, NFS etc and it all seemed to go without hitch to be honest.

I found the Pi4 to be extremely responsive to anything I tried in the GUI. Shares were accessed easily, with good read/write speeds using my typical laptop/AC WiFi/Access Point/Gigabit LAN chain.
I’ve not tried Rockons yet, and I know one has to be careful to check they work with ARM64 beforehand.

A couple of functional issues I noted:

  1. I did experience a strange thing where one of my Shares could not be resized from the default 1.00GB size, but this went away without me doing anything apart from a reboot. I know Share sizes are irrelevant with that part of BTRFS not ready yet, but I wanted to test the usual suspects.

  2. Selecting ‘Shutdown’ but then clicking on ‘Cancel’ on the dialog clears the webgui from browser, and then brings up the dialog again in a loop.

When I get some more time hopefully later this week, I will investigate the issues I see with USB SSD booting. Any pointers gratefully received, of course.

Cheers

Geoff

2 Likes
2

@GeoffA Hello again, and thanks for an excellent report. I can chip in with some elements of this.

This is a known upstream issue, see:

And the solution in short is to add the following to /boot/config.txt (may be in another location on live system) to configure the Pi4 on boot to avoid this log spam.

# Disable polling for SD-card
dtparam=sd_poll_once=on

I’m not sure of the consequences of doing this automatically within our installer thought. But we could.

This is non Pi4 specific. I’ve had this also on recent regular x86_64 builds. The browser url gets ‘stuck’. Visiting any other page frees it up I believe.

Curios. I’ve not actually tried this. The Pi4 I have here for building Arm64 installer profiles (Pi4 and ARM64EFI) and Arm64 rpms, has only a single USB-to-SATA adapter in uasp mode with SSD attached.

Yes, super annoying and makes it hard to diagnose anything else. Apply the above fix and then things will calm down considerable so one can see the logs then. These messages got to log and standard out. Let us know if this works for you also and if your end up find out the consequences let us know here. Pretty sure we can just edit this in with the installer if it’s safe to do so.

Yes, I was quite chuffed to finally see that for myself here, could hardly believe it when I first saw it :slight_smile: .

I was surprised as the responsiveness myself. And works much better from an SSD with a descent uasp compatible (and working as some have flaky drivers) adapter.

OK, strange but if this was directly after first install boot, although Rockstor does work directly after install, I have my doubts as to it’s full function. So this may have been directly after initial install. Otherwise no idea currently.

That would be great. As to pointers, given you Pi4 obviously has had it’s EEPROM updated but in the Pi4 world this has to, ideally, be kept in sync with the rest of the boot system with lives in the firmware files. Try overwriting the start4* and fixup4* files on the installed Rockstor disk with those found in a fully updated (on your Pi4 so it also updates your EEPROM boot bit) Raspberry Pi OS. The default ones in openSUSE Leap 15.2 are I believe matched with an older pre USB boot Pi4 EEPROM. I think I had assumed not updating these files would render USB boot completely disfunctional and so I may have just done this quick as I needed to get our Arm64 build system up quickly. And have unfortunately had little time there after to test our resulting installers pre/post firmware file updates etc.

Thanks for getting the ball rolling on the Pi4 testing. Much appreciated. Bit in the middle of things currently hence the vague dir location re firmware files but given your Pi4 familiarity you will likely find them just fine. Really depends on if you are booting into the image in question or mounting say the sdcard on another linux system to make the changes there.

Incidentally in our build setup for the arm side of things I’ve used KVM on the Pi4 and it’s working a treat, bar some version drift between my various machines. I was chuffed to find this worked without issue. Although I’ve heard otherwise on a podcast and it was just not my experience. This was where the host OS was JeOS Leap 15.2 image, same as what Rockstor 4 is based on.

Hope that helps and thanks again for sharing your findings re the Pi4 installer. Much appreciated.

1 Like
3

@phillxnet really appreciate your comments above.

Having followed up on what you said and implemented the SDHCI fix, the only remaining oddity I have is inability to boot from SSD when other USB drives are attached. It is really strange.
I have several UASP adaptors which work fine with my Pi4. I also have a dual bay USB dock - bay one can hold the system drive, with a data drive in bay two. Debian (well, RaspiOS) has no problem booting like that, It has to be something with the boot files in the EFI partition somehow. I will do further investigation and testing.

I might even redo the installer build, so I’,m starting from scratch again.

I will let you know.

As for the oddity when trying to Cancel a Shutdown through the GUI - I tried that on my Stable channel x86_64 install, and yes it does the same as you say. Obviously I’ve never gone through those steps on that box.

Cheers

Geoff

2 Likes
4

Ok, so I’ve spent more time with this, without success. I have rebuilt the installer image, copied the fixup4* and start4* files across from a fully updated and working raspbian boot (there are 4 of each type of file). Still the USB boot does not work if other USB drives are attached to the Pi4 at the same time. This is using known good UASP adapters.
Debian (Raspbian) has no problem with this arrangement.

The same USB SSD attached alone to the Pi4 (without any other data drives attached to the Pi) boots Rockstor 4 perfectly. I can then re-attach the data drives without problem, although hardly the best solution long-term.

Its probably something very obvious that I’ve stupidly overlooked, or something beyond my current skill level :slightly_smiling_face:

Cheers

Geoff

2 Likes
5

@GeoffA Just a head up:
Re:

As of just now post the following merged change:

for issue:

means a fresh build of our installer should now create a new file in the EFI partition, mounted at /boot/efi by the name of: extraconfig.txt. This is in turn sourced from the config.txt file in the same location. And I’ve popped in this
“dtparam=sd_poll_once=on” option.

Hope that helps.

2 Likes