Thanks, Peter. More context below.
> On 3 Sep 2020, at 10:29, Peter Robinson <pbrobinson(a)gmail.com> wrote:
> How are you running this image? Is it a VM image or on a physical
> piece of hardware?
> If a VM you should be able to do this:
It’s a real Pi: I’m packaging up some systemd services for use on real machines. The best approach for ARM vms that I’ve found comes form Resin.io, which I’ve used for Raspbian builds in AWS. But the code that I’m packaging is written in C++ and drives a tty over USB0, so I’d prefer not to have to faff with virtualisation. I know that it works on stock Fedora an x86. [see comment at end for what I think is the best approach and feel free to challenge].
Incidentally, this is my typical usecase (ie driving real external h/w, usually using centralised systemd, to manage service (re)starting and dependencies and logging on the small footprint computer, which I don’t think works well with containers, as there’s a lot of extra wiring for the logging. Systemd didn’t use to work well inside containers.). I’d like to use FIoT for this uc as the rpm-ostree model ought to work better at scale (100k to 10M Pis) for remote updates.
I found this (https://bit.ly/3lQ3zrL), which does in fact extend the image size, creating a binary that does work. I had been using a mechanism from this image: Fedora-IoT-29-20181106.0.aarch64.raw.xz, which I’d wrapped into some rake tasks.
fwiw, the Zezere configuration also works. The key (no pun intended) issue seems to be to put the key in as if it were a line from ~/.ssh/authorized_keys: ie include the type of the key. That may be obvious on reflection, but it didn’t leap out of the documentation. An example would be good.
However, I now cannot layer gcc, nor can I create a toolbox. Toolbox fails thus:
[root@localhost ~]# toolbox -v create
DEBU Running as real user ID 0
DEBU Resolved absolute path to the executable as /usr/bin/toolbox
DEBU Running on a cgroups v2 host
DEBU TOOLBOX_PATH is /usr/bin/toolbox
DEBU Toolbox config directory is /root/.config/toolbox
DEBU Current Podman version is 2.0.4
DEBU Old Podman version is 2.0.4
DEBU Migration not needed: Podman version 2.0.4 is unchanged
DEBU Resolving container and image names
DEBU Container: ''
DEBU Image: ''
DEBU Release: ''
DEBU Resolved container and image names
DEBU Container: 'fedora-toolbox-32'
DEBU Image: 'fedora-toolbox:32'
DEBU Release: '32'
DEBU Checking if container fedora-toolbox-32 already exists
DEBU Looking for image fedora-toolbox:32
DEBU Looking for image localhost/fedora-toolbox:32
DEBU Looking for image registry.fedoraproject.org/f32/fedora-toolbox:32
Image required to create toolbox container.
Download registry.fedoraproject.org/f32/fedora-toolbox:32 (500MB)? [y/N]: y
DEBU Pulling image registry.fedoraproject.org/f32/fedora-toolbox:32
Trying to pull registry.fedoraproject.org/f32/fedora-toolbox:32...
no image found in manifest list for architecture arm64, variant "v8", OS linux
Error: unable to pull registry.fedoraproject.org/f32/fedora-toolbox:32: Error choosing an image from manifest list docker://registry.fedoraproject.org/f32/fedora-toolbox:32: no image found in manifest list for architecture arm64, variant "v8", OS linux
Error: failed to pull image registry.fedoraproject.org/f32/fedora-toolbox:32
Which I suppose means that there’s no ARM support for toolbox.
gcc layering fails like this:
[root@localhost ~]# rpm-ostree install gcc
Checking out tree 8e64da7... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora fedora-modular updates-modular
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2020-03-17T20:10:43Z
Updating metadata for 'updates'... done
rpm-md repo 'updates'; generated: 2020-09-03T16:26:50Z
rpm-md repo 'fedora' (cached); generated: 2020-04-22T22:22:16Z
rpm-md repo 'fedora-modular' (cached); generated: 2020-04-22T20:58:40Z
Updating metadata for 'updates-modular'... done
rpm-md repo 'updates-modular'; generated: 2020-08-28T15:24:00Z
Importing rpm-md... done
Forbidden base package replacements:
libxcrypt 4.4.16-3.fc32 -> 4.4.17-1.fc32 (updates)
This likely means that some of your layered packages have requirements on newer or older versions of some base packages. Doing `rpm-ostree cleanup -m` and `rpm-ostree upgrade` first may help. For moResolving dependencies... done
error: Some base packages would be replaced
which I think is a known issue.
I suppose that I need to package the rpm in a vm on ‘standard’ Fedora for ARM in a qemu emulator, and then install and test the rpm on the pi.
It's been a while since I've spun up fedoraiot, so I thought I'd see where we'd got to, as I've now got a concrete usecase monitoring some solar panels. Unfortunately, when I put Fedora-IoT-32-20200603.0.aarch64.raw.xz onto an SDCard, the pi (3b+) boots and gets to a login prompt, but I cannot login; neither as `root` with no password on the console, nor ssh'ing as `root` after using the Zezere portal. I'm pretty sure that I'm using the right key (although the documentation is a bit light on what a good key content looks like). The `/portal/devices/` page shows that there's an action to upload a key, with a `cancel runrequest` button, but no indication that more is happening.
Any hints or tips / troubleshooting approaches?