I thought I understood Docker, but maybe not. I'm running ayufan's Ubuntu on my ROCK64; uname identifies it as aarch64. When I run Docker (via Kubernetes) and ask for a multi-architecture image, I get this error:

    no matching manifest for linux/arm/v8 in the manifest list entries

But Docker Hub lists the image (rook/ceph:v1.1.2) as built for both amd64 and arm64 architectures. I thought aarch64 and arm64 meant the same thing, with userland calling the architecture aarch64 and kernel calling it arm64. Is that not true? How are these names related to linux/arm/v8?

If this machine pulled an arm64 image, would it be able to run it? Maybe my Docker is just misconfigured so it doesn't recognize what it can run.

SBC:    Rockpro64 v2.1 4Gb
OS:     ubuntu 18.04 minimal w / Mate' DE     
        Linux rockpro64 4.4.190-1233-rockchip-ayufan-gd3f1be0ed310 #1 SMP Wed Aug 28 08:59:34 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux

While performing an apt update && apt upgrade, the following messages occur:

W: http://ppa.launchpad.net/ayufan/rock64-0.../InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ayufan.key.chroot.gpg are ignored as the file has an unsupported filetype.
W: http://ports.ubuntu.com/ubuntu-ports/dis.../InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ayufan.key.chroot.gpg are ignored as the file has an unsupported filetype.
W: http://ppa.launchpad.net/ayufan/rock64-0.../InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ayufan.key.chroot.gpg are ignored as the file has an unsupported filetype.
W: http://ports.ubuntu.com/ubuntu-ports/dis.../InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ayufan.key.chroot.gpg are ignored as the file has an unsupported filetype.
W: http://ports.ubuntu.com/ubuntu-ports/dis.../InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ayufan.key.chroot.gpg are ignored as the file has an unsupported filetype.
W: http://deb.ayufan.eu/orgs/ayufan-rock64/.../InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ayufan.key.chroot.gpg are ignored as the file has an unsupported filetype.

Any explainations? Concerns?

TIA,
/Faradn
~ Rockpro64 ~ Odroid N2 ~ Odroid XU4 ~ Pi 3B ~

Yesterday I tried to install the Spotify plugin in Kodi but somehow it is not installing? Anyone got it working on their RockPro?

I am wondering if a year or two years in the future the Pine book Pro will have a replacement motherboard that will run the solid-state NVMe drive as easily as the current one runs the EMMc drive.?

  I will definitely purchase that motherboard  !

 Meanwhile I will be happy with the one I purchased.

Hi, a short question. Will the PineTime have a switch to kill the bluetooth? I imagine the use case when it can be used as Morning alarm and it would be kept in the bedroom close to the body. Thanks

We having been discussing uboot on SPI as a way to get bootable PCIe NVMe drives. Yet the consensus is that the SPI is for a version of uboot, (or other firmware), that is quite stable.

But, we can also do some interesting things for recovery. If uboot is not that big, perhaps we can have 2 versions, with a tiny bit of code to select the most current, unless a special key is held down. Then it uses the prior release. That may help prevent some of the bricking of the PBP that has been disscused for new, but faulty firmware.

This could apply to both eMMC and SPI., though eMMC is an easier un-brick than SPI.

Just an idea.

Some users and me have experienced time drift in some sopine modules. This manifests as a date jumping randomly in the future, for example around the year 2114.

Some system output:

I have grouped header mapping between SOPine Clusterboard prototype and Baseboard, focusing on GPIO. I hope it also helps you guys.


ATTENTION: Please verify this BEFORE use, and help to improve this mapping's reliability for all the community.

Attached Files

  SOPine_Clusterboard_Pin_Mapping_v0.4.pdf (Size: 180.96 KB / Downloads: 2499)

My RockPro64 arrived at last, and I've been testing it for the last 2 days. I installed LibreElec and I must say that so far it's working pretty well, but I have a couple of issues that I'd like a little help, if possible.

Firstly the fan. I connected mine on the connector 4 of the diagram on the Pine64 site (the one equivalent to "PWM controlled fan header "), but it just doesn't work at all. Not that bad for now, since I still don't have a case and I also got a 20mm heatsink (the maximum temperature I got was 50°C), but I really would like it to work properly, because as soon as I get a case I'm sure it will heat a lot. I've seen a couple of other threads in which people say that it's necessary to recompile the image and apply a couple of patches in order to make it work properly. Is that still the case or there are any other way?

The other thing that has got me worried is the behavior of the leds. Once the board is up and running the red led keeps blinking all the time (2 short blinks) and the white led is off. As I've read on the Pine64 site the expected behaviour would be the white led to stay on and the red one being a sort of "DIY" whose behaviour would depend on what each developer programmed to his image. Is that constant blinking of the red led the expected behaviour on LibreElec running on RP64?

I'm using my TV remote (through its HDMI-CEC feature) in order to control Kodi. It's working and all, but what I want is to turn it on as I turn the TV on, and off as I turn the TV off. The TV is correctly configured and I revised all related configurations on Kodi, and it still doesn't work. If I use the remote to turn on the TV the RP64 doesn't turn on, and if it's already on and I use the remote to turn off the tv nothing happens on the RP64 (no matter which option I configure on Kodi). Am I missing something?

Any help would be much appreciated.

I get a bit lost with architecture, I can't find image for pinebook pro.

You know if you can install a devuan. You know freedom software

Without systemd 8=]

a greeting