PINE64
openSUSE Tumbleweed - Printable Version

+- PINE64 (https://forum.pine64.org)
+-- Forum: ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=85)
+--- Forum: Linux on Rock64 (https://forum.pine64.org/forumdisplay.php?fid=88)
+--- Thread: openSUSE Tumbleweed (/showthread.php?tid=11880)

openSUSE Tumbleweed - lewellyn - 10-20-2020

I have installed openSUSE Tumbleweed onto a couple of my Rock64 boards, with 16GB MicroSD cards. (Basically) everything seems to work fine for my needs, but there are some things I noticed. I'm not entirely sure why the distro is not currently on the Rock64 wiki, and there hasn't been much on the forum about it, so I thought I'd toss my thoughts out there for anyone else who's grumbling at pointlessly needing yet another distro for yet another SBC.

The Rock64 HCL notes the availability of Leap, though it is not available at the time of this writing. Further, only JeOS is available at this time, though there are (broken) links on the HCL page for E20, XFCE, LXQT, KDE, and X11. I can think of no reason one might reasonably want any of those though, especially with the caveats below.

The HCL lists instructions for writing the xz file to SD card using an existing Linux install. But I can confirm that the usual Windows tools, including Rufus, will write the xz file fine. Cool

Also, HDMI video output works for initial boot, so you do not need a serial port for initial configuration (I cannot confirm how useful a serial connection, so the HCL might be right that you want one). As it's likely to be running headless long-term, it might be easiest to do your initial boot (it might take a couple minutes) and configuration over SSH, by finding the DHCP lease in your DHCP server's database (probably the most recent entry, of course) and SSHing in with the credentials on the HCL page (don't forget to change them immediately!). Why bother hooking it up to a keyboard and monitor for a one-time thing that can be done with your usual tools? Big Grin

Anyhow, the caveats:
  1. Booting takes a while sometimes. I'm not sure why just yet, but there's a 100 second gap in dmesg each cold boot for me (10 seconds on warm boot, which I think are due to installing rng-tools as they need to gather entropy). But ideally you're not rebooting often. Wink
  2. The default btrfs partition at /dev/mmcblk0p3 is only 1.7GB and starts off 1.2GB full with a bit over 400MB free. You can either create a new partition, or you can extend the one that's there (exercise for the reader, but you could probably do worse than yast2 disk). I opted for the latter and btrfs filesystem resize max / once I fixed the partition size was all I needed, myself.
  3. SPIDF/I2S audio doesn't work. This generates some kernel spew and a mostly harmless set of traces. As I'm not using sound, I've done zero investigation. I've also not bothered to blacklist the modules, so I can't help you reduce boot-spew. I do not know if HDMI audio works, though the drivers seem to load without incident.
  4. There is a lot of screen tearing in the console, even if there's no scrolling or other activity, especially if you have more than just VT1 in use. I have not tried X11, but I can't imagine it having useful performance if it can't even draw the text console error-free. This may be related to the following kernel message: rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes
  5. If you're used to using DTBOs with this SBC, you're going to have a bit more challenge than with some of the more widely-used distros. I do not recommend the task for those not extremely comfortable with the idea of a distro which doesn't have /sys/kernel/config/device-tree/overlays available without you having to do your own legwork and doesn't seem to have a way to take the Raspberry Pi approach.
  6. I do not see evidence of eth1 in either dmesg or YaST. As I do not currently have plans to multihome any of my Rock64s running openSUSE, I have not investigated further (including the whole magjack situation which doesn't look like anyone has documented properly, in general).
  7. Blinking the NIC LED doesn't seem to visibly do anything, but it also doesn't generate errors. This is mostly just a note since it's pretty common behavior on ARM SBCs, and since there's only one port, there's no reason to blink it anyhow.
  8. It does not seem that there is yet TrustZone support. For most users, this is probably a non-issue.
  9. Some things seem to perform much worse than I'd expect, quite notably YaST2. Since performance hasn't shown itself to be an issue with my workload, I've not investigated. It may just be due to the fact that I'm not using an eMMC.
  10. Again, this is a JeOS image. Lots of things are going to be missing compared to even a minimal standard install. Be prepared to use zypper a bit, or to hit the Install button in YaST when you set up things like NTP sync.
  11. openSUSE's aarch64 support isn't quite first class in my opinion. Be aware you're gonna probably need to add some stuff from openSUSE:Factory:ARM
This is almost certainly not suitable for desktop use, or even general-purpose use. But if you already package stuff for yourself using OBS and are otherwise embedded (hah!) within the openSUSE ecosystem, this is definitely a viable option for your SBC.

Links:
  • openSUSE HCL: Rock64
  • devel:ARM:Factory:Contrib:Rockchip images - You'll want the one with a filename like openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-XXXX.XX.XX-BuildX.X.raw.xz (where the X values change, depending on date/build)
    (Note that the download repository has images for other SBCs, as well. Currently the list is fireflyrk3288, rock64, rockpi, and tinker. I have not used any of the other images. I cannot likely assist with issues related to SBCs that I do not own.)
  • openSUSE:ARM distribution howto - This page has how to use osc on ARM (I did mention you'll probably want to already be familiar with OBS right?)
  • Portal:ARM - The jumping off point for openSUSE-on-ARM documentation
[Image: rock64-tumbleweed.png]
(1G Rock64, with kdump enabled, so only 776M available)

Note that this post is adapted from a blog post, so I apologize if I messed up the formatting here. I just figured it was better for posterity and people searching for openSUSE support if I put the whole post contents here rather than just a link.

RE: openSUSE Tumbleweed - tllim - 10-20-2020

(10-20-2020, 04:32 PM)lewellyn Wrote: Links:
  • openSUSE HCL: Rock64
  • devel:ARM:Factory:Contrib:Rockchip images - You'll want the one with a filename like openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-XXXX.XX.XX-BuildX.X.raw.xz (where the X values change, depending on date/build)
    (Note that the download repository has images for other SBCs, as well. Currently the list is fireflyrk3288, rock64, rockpi, and tinker. I have not used any of the other images. I cannot likely assist with issues related to SBCs that I do not own.)
  • openSUSE:ARM distribution howto - This page has how to use osc on ARM (I did mention you'll probably want to already be familiar with OBS right?)
  • Portal:ARM - The jumping off point for openSUSE-on-ARM documentation
[Image: rock64-tumbleweed.png]
(1G Rock64, with kdump enabled, so only 776M available)

Note that this post is adapted from a blog post, so I apologize if I messed up the formatting here. I just figured it was better for posterity and people searching for openSUSE support if I put the whole post contents here rather than just a link.


Thanks on the write up and sorry that wiki site missing this openSUSE build. Please help to include this build to wiki and reference to this thread.

RE: openSUSE Tumbleweed - lewellyn - 10-21-2020

(10-20-2020, 11:29 PM)tllim Wrote: Thanks on the write up and sorry that wiki site missing this openSUSE build. Please help to include this build to wiki and reference to this thread.

I would update the wiki, but changing my skin in my preferences has locked me out with an HTTP 500 error. So I can't even view any pages if I log in now, nevermind editing. Undecided

Also, one thing I left out of my writeup that I probably should have noted: I have only tested MicroSD installs, as I do not have a suitable eMMC (I just have a bunch of SD cards, sorry). I, however, believe it would work perfectly on the eMMC based on how the image is constructed (for the insanely curious, take a look at https://build.opensuse.org/package/show/openSUSE:Factory:ARM/JeOS an especially Images.kiwi.in within that package) and the results others have had with other distros. If anyone with an eMMC tries it out and has trouble, please let me know and I'll do my best to help even if that means buying myself an eMMC and submitting changes to the OBS project to fix the image. Smile

And, speaking of images, it appears openSUSE additionally builds images for pine a64, pinephone, and rockpi4... And they have instructions for manually bootstrapping on pine h64. So I might need to find myself additional hardware to keep occupied during the ongoing crisis and see how it runs and what might need fixing on other devices... Running a PinePhone as a server might be an interesting way to have a low-power server with always-on data and reliable timekeeping available!

RE: openSUSE Tumbleweed - Rocklobster - 10-22-2020

Nice to see someone is actively working away creating new approaches to the Rock64 SBC. I use the standard Armbian distro for everyday use but it's nice to have as many working alternative Distro installs. A very thorough write up too. Sadly lacking these days. Once again, nice work.

RE: openSUSE Tumbleweed - lewellyn - 10-23-2020

Thanks. I have a personal preference for openSUSE as my default distro as it's RPM based (as are some of the non-Linux things I like to use), has an insane number of packages, and is easy to create repeatable builds of custom packages and installation images (both locally and in the cloud). 

If a package isn't available for the distro variant (such as Tumbleweed aarch64 as used here), it's trivial to fork the upstream package for the flavor you're using. If it builds and operates well, it's again usually trivial to get it packaged with the main package, especially if it's a stock part of the main x64 package set.

While the Debians (including Ubuntu and Armbian) have much more visible ecosystems, it's a lot harder for individuals to make a difference due to the learning curve and the difficulty in making packages available for other testers (while PPAs have fixed this some, it's still a lot of effort).

I'm a huge general fan of having a large toolbox to choose from, to make sure that whatever needs to be done can be done well. Consider this my contribution to the toolbox. While I didn't have a hand in getting the platform running, I felt the least I could do was document the state of affairs to the best of my ability (which means it's limited to how I've used and abused it, of course). This is a community of do-ers, so someone is bound to want to do something that a Debian makes difficult, and CentOS doesn't have packages for, and something like Arch is just too rough-edged for. And, for them, there is now another option! Smile

I would like to fix some of the issues noted, but I'm gonna need to buy a few more Rock64s first. Hopefully the effects of the pandemic upon my life will ease a bit soon, and then I can do so. Notably, I'd love to investigate the cold-boot hang and the spidf log spew. I also would like to investigate the graphics woes since if I *do* need a console over HDMI, I don't want it to jitter at random. Tongue

But if you do try it out, let me know what your experiences are. Just really do remember it's a JeOS image, so there's minimal packages and zero hand holding. It might be worth installing a full desktop version in a VM to play with alongside. Big Grin