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. 

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?

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.
   
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
    

• 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
  

As previously mentioned here: https://forum.pine64.org/showthread.php?...ght=soedge

It seems like USB3 will not be available on older but otherwise compatible (?) hardware like the clusterboard.

Any chance there could also be an undated clusterboard to more fully utilize this module and or maybe also prepare for a sopine2 module?

Armbian install by way of Diet Pi.

I was really looking forward to moving our self-hosted services to a more capable SBC.  I need a solid ethernet connection that the H64b doesn't seem to want to provide.  I'm going to check with Manjaro build, but arch isn't my flavour and I'm not looking to manage a single non-debian based distro.

Am I sending this thing back to Pine?  What was the purpose of the h64 if it's barely supported by anything?

I've pre-ordered the Manjaro CE, seeing as there was no option to buy the PMOS CE when I found out about the PP (or rather when I remembered it existed and looked into it properly ). Ever since then I've been diligently checking the PINE64 RSS feed, forums and even the store page for any updates on the next batch. To my surprise, I've discovered today that the standard, non-convergence PMOS CE is back on the store page, labeled as EU-only.


I'm considering snagging one up so I wonder, is this unsold stock? If so, why is it in the Polish warehouse and not still in China? Why did it show up only now? Or are they devices returned by the customers? Could we get some clarification by PINE64 on the origin of these phones and the reason why they showed up only now with no announcement or explanation on what they are? Also, if I were to purchase this one, I wouldn't be interested in the Manjaro CE one I pre-ordered anymore (as long as they're the same board revision, which is what I understood from the forums and wiki), how can I request a refund, if at all? Any info on this would be appreciated.
Oh and thanks for reading my first post!

I've tried two screen tilers based on using Spectacle on mac: https://github.com/pkkid/pygrid && https://github.com/kwin-scripts/kwin-tiling. I was able to get both of them installed but neither of them actually move the windows the way they are supposed to.

The first runs but does absolutely nothing. The second partially works, it slots the windows into the free space, but the key-commands to move the windows do nothing, and these are what I need the most. Can anyone recommend an application like this that will work in Plasma/Manjaro?

Anyone know where I can download Arch for the Pinephone?
Thanks.

The PP image is now updated to 3.4 so the info below is out of date.
------------------------------------------------------------------------------------------
You can update the sfos version on the pinephone by running the following commands:

devel-su
ssu re 3.4.0.24
ssu ur
zypper ref
zypper dup

NB this can take 3hours+ on sdcard, about 40 mins on emmc.
This build feel a bit faster. Patchmanager doesn't work.

Hi,

on the postmarketos website there are only builds from september available? Where I can get more recent builds?

Or have I to build them on my computer with pmbootstrap? Edge or stable then?

I'm aware that chances of meeting Japanese users here is very small, but one unfortunate thing about Japanese providers is that you must not only change to a completely different SIM card upon switching to a different phone, you also have to provide them the IMEI of the phone in advance, or the SIM card won't work with that phone at all.

I don't have the PinePhone yet, seems like it's going to be shipped in early November if I order now, the US elections/covid19 will be over from then on, so whether it can be shipped is not a problem.

But my question is, once I get the PinePhone, is there a way to know the IMEI?
Like a menu option? Or written inside the battery cover?

Thank you.

alright so my phone was in its box for a month while I focused on other things.. Now I ran a whole apt upgrade, fixed some broken packages (hopefully fixed), and rebooted my pinephone only to be greeted with no boot splash screen, no lock screen, just  blank. When I press the power button to turn the screen on, instead of the lock screen I see a sad face and a message:

"Oh no! Something has gone wrong. A problem has occured and the system can't revoer. Please log out and try again"

Pressing the log out button however blanks the screen again and no other user interaction can bring anything on the screen.

Thankfully I still have ssh access...