Use 4B images for SE?

#1

Do I use the 4B images for Rock SE?

as in this for Ubuntu 20.04 Server LTS (64-bit)
rockpi-4b-ubuntu-focal-server-arm64-20221019-1015-gpt.img.xz

and edit the /system-boot/network-config file to configure my WiFi for headless install?

#2

If you go to our download page you will see 4B images are listed under 4 SE. This is intended as the difference between those 2 is minor. We do plan to release 4 SE specific image in the future.

1 Like
#3

I do see on the download page that there are 4B images listed under SE. Thank you

Q1) BUT I also see that the SE Ubuntu Server 5.1 kernel links to a different image than the “latest” which is listed under the 4B column, so which do I use?

Q2) Is there a reason I would not want the “true latest” image in my original post?

Q3) The install wiki does not include a headless WiFi first-boot method (such as editing network-config file in the RaspberryPi Ubuntu Server). Is only wired headless first-boot possible?

#4

Previously we were basically on a rolling release model, that any time we making a change new images will be created for everything the build tool supports. As we added more products to the build tool the number of the images per release was getting out of hand, and it was not obvious which image is needed. We had a few forum posts about not booting, that turned out to be mismatching system image.

We then split the huge list of images into several product specific release repositories on GitHub. This way the user coming from our Wiki’s Download page, they will only be given valid choices that all could boot (as long as we don’t mess up…). We also limit the image generate frequency in those repositories to once per month. This way we reduced the support variants from tens of different images to a handful, so we can better support known issues and provide workarounds. We can also demote broken builds by marking them as pre-release, so GitHub will use a older but working build as the latest release, and that is what we present on the Download page.

In both models, we haven’t talked about testing, because it was basically non-existent back then. We had no dedicated testing team and the engineers had to do the testing. Testing takes a lot of time especially if you want to detect regression, which obviously didn’t happen when engineers had a lot of other stuffs to work on. The 2nd model was meant to take advantage of community feedback to improve the user experience, without draining a lot of time from engineers.

Now when we launched ROCK 4 SE, things have changed considerably:

  1. We now have a dedicated testing team.
  2. We are working with OKdo, who ended the license agreement with Raspberry Pi after 10 years.

OKdo saw what Raspberry Pi Foundation has done so far, and they are asking for the same thing from us. That means formal release with release note and proper testing. This puts an end to our (semi-)rolling release model. We can still use the existing facility to generate builds, but they are only release candidates now. They become a real release after testing along with the release note, and then we will list this specific version on the Wiki page.

So back to your questions:

Use 4 SE image for your 4 SE.

This or using 4B image as suggested in the last question has the same issue: it makes support more difficult, that there are more software variants we need to acknowledge. Also, while they are supposedly compatible softwares, the exact combinations were not tested by us. With a formal release procedure and quality assurance, we cannot recommend those use cases.

This is something I worked on before. The existing image builder has a lot of limitations, so I made a new one, and better first-boot setup is one of the features of the new system. It was on the back burner for a while and now we are seriously trying to get this released, so this will be something you could use in the future.

But for now there is no easy way. The closest thing is probably mounting the image and adding the Wi-Fi connection file.

1 Like
Rock 4 SE: Benchmarks vs Pi4B?
#5

Please also include disabling ipv6 at first boot. It is so difficult to find the IP of the DHCP assigned new system among the long list of devices on my home routers, and ipv6 makes that even more complicated. Additionally, folks often want to wget software from github, and do not know to use wget -4 when the wget times out due to ipv6 incompatibilities.

Another interesting difference setting up the Rock4SE was the different way various OS treat the imaged Rock uSDcard. On my Mac, after flashing with balenaEtcher, the card does not auto mount when re-inserted to the card reader. (This was disconcerting because I could not tell what was on the card after imaging it.) Using “diskutil list” I was able to see the partitions but without auto mounting I could not write any pre-configuration to the card. Inserting the card to my Linux system, did auto mount several partitions and I could have preconfigured things like the disable ipv6 custom rule I added later, or perhaps have preconfigured WiFi if I had known where to apply my changes. (I had never before used the nmcli dev wifi command, but once I found out what ethernet IP was assigned, I was able to ssh in and configure wifi using the wiki instructions.)

#6

This is how we could never progress and sounds more like router and ISP issues. After all are you going to disable IPv6 on all your home devices that now show up in your router as a long list?

If you have a lot of devices in your home network you can start setting up VLAN to ease management, and build isolated networks. Manually setting known devices an address outside of DHCP pool is another way to do it, and could be done centrally form the router as well. In case of OpenWrt it also splits IPv4 DHCP leases from IPv6 leases, so there is no mixing.

If your ISP doesn’t provide IPv6 try disable IPv6 in your router. Otherwise something is wrong in your network configuration that IPv6 should just work.

1 Like