Support of Raspberry Pi

[Louis]

Hi Igor,

 

[No apologies necessary for your non-native English. My partner speaks English as a second language but her English is a lot better than my Japanese. I'm the one who has to apologise when we travel.]

 

I agree that Broadcom has a business model that benefits from sales of the Raspberry Pi. The Pi wouldn't exist without that, nor would the community, nor would the ecosystem of vendors around the Pi, some who create really cool stuff, innovations over chips and hardware that they make accessible through carrier boards and supporting software libraries (like Adafruit, Pimoroni, etc.). They're also a business and need to survive and thrive, and like Canonical rely upon the free contributions of their users as well as years and years and layers upon layers of the product of hundreds of open source communities. I'm not an apologist for this arrangement, but I see that at least it works pretty well compared with whatever might be the alternative, which would be an entirely closed model like Apple, who a lot of people love for some reason (very clever marketing and nice-looking, expensive hardware?). I'd hardly call myself an avid capitalist, and I've (like I'm sure you) put in thousands of hours of my life into community endeavours. Sometimes I got sponsored to do it by whoever I was working for, but most of the time not. I don't think many people have any idea how much effort even a small project takes to bring to fruition, or maintain it.

 

On the other hand, expressing anger over the situation with Broadcom or the Raspberry Pi Foundation shouldn't extend to the community of users of those products. They're just people, sometimes children, sometimes students, sometimes hobbyists (beginners to seasoned veterans), sometimes professionals (beginners to seasoned veterans). All sorts of levels of experience with hardware and software, all sorts of levels of experience in communicating in a healthy way within a community. As I said to NicoD, grouping people together and treating them badly because they are women, black, gay, or Raspberry Pi users, is all the same. People are individuals, and some just need a bit of gentle training in how to behave in a community. I find this especially true of younger people who've grown up with their primary social experience being staring into a cell phone. Bad social interactions have real costs: to the recipient, to the person acting badly, and certainly to the community. It's in everyone's best interests to try to smooth that out if possible, and if after trying to explain to someone what are appropriate expectations or behaviour (maybe point them to a web page) they don't behave, then sure, by all means tell them to leave. I do understand the time constraints of trying to be nice, but I can only say it probably takes more time to argue with someone than to explain that they should stop yelling and instead offer to help the community if they want help. In my day job I sometimes deal with people who are under a great deal of stress and that is sometimes erupt right at me -- I have to remember it's (usually) not me they're really angry with.

 

In any case, thank you for replying. I've managed to 'do-release-upgrade' the Armbian on my Orange Pi and things look nice and stable (logs are clean, etc.), so I won't abandon it and go back to the Ubuntu I'd built on a different SD card. The Armbian experience was better and smoother than Ubuntu on the Orange Pi.

 

Thanks very much to you and your community's efforts.

[lanefu]

1 hour ago, Louis said:

The Orange Pi power consumption is almost twice that of a Pi 4 and runs a lot hotter

 

Not too surprising with the OPI4's SoC, it's known for requiring a large heatsink.   You still have some options that might get temps and consumption  a little more under control.   From the armbian-config tool you can make adjustments to the CPU frequency governor.    From there you can set min and max frequency ranges, and pick an alternative governor.   My personal preference is the schedutil governor.  It's responsive, but more granular in adjustment than the on-demand governor.

[Louis]

10 minutes ago, lanefu said:

Not too surprising with the OPI4's SoC, it's known for requiring a large heatsink.   You still have some options that might get temps and consumption  a little more under control.   From the armbian-config tool you can make adjustments to the CPU frequency governor.    From there you can set min and max frequency ranges, and pick an alternative governor.   My personal preference is the schedutil governor.  It's responsive, but more granular in adjustment than the on-demand governor.

Hi lanefu,

 

The heatsink I'm currently using is clearly not big enough. I'm still evaluating whether or not using the Orange Pi is really beneficial for this particular usage as I'm not using the SPR2801S NPU and as my code is in Python I'm not really able to take advantage of the six cores anyway -- coming from a Java background I was sad to see that Python's threading looks just like Java's but doesn't act much like Java's.

 

My current solution is simply a Python class that powers up a cooling fan if the temperature goes over a configured threshold. The tiny brushless fans I got from AliExpress sell for under a dollar, and for the Orange Pi I'd use a heatsink-mounted fan that sells for $1.69 which is double-sided tape mounted right on top of the RK3399. So rather than throttle the CPU I'd just cool it. But thanks, I'm happy to check out the frequency governor, sounds like a good tool to have in my kit. A lot of designing and building robots is trying parts of the system out separately, then realising that firing up everything at once things start to break.

 

I hadn't really looked into the armbian-config that much yet so thanks for the tip.

[TRS-80]

On 3/18/2021 at 3:20 PM, Igor said:

Closed hardware is like a cancer, a slap toward Linux community. IMO, there lies another big part for this conflict. And the reason why bad words has been used.

 

This is why I personally have disdain for RPi / Broadcom.  IMO companies who are riding the current wave of popularity of "open source", whilst being actually nothing of the sort, I just find obnoxious (and actually, sociopathic, even).

 

I also don't like that RPi seem to have become synonymous with SBC, in the mind of many casual users.  You hear RPi being mentioned all the time on the broader Internet (I don't think we should be giving such mindshare / free advertising to such a closed platform).

 

So to me it was actually like a breath of fresh air to find this community, where people weren't "drinking the Kool-Aid" so to speak.

[Irgendeiner]

  

On 3/19/2021 at 11:02 PM, TRS-80 said:

Closed hardware is like a cancer, a slap toward Linux community. ...

So it is, but I must admit that I've fallen in love with the Pi4B 8GB which delivers for $70.- a fully usable desktop computer. I've combined it with a dual sata station  https://www.amazon.de/dp/B076Q8QW1F costing approx. $30.- including a 3A power supply. The built-in 5V converter does also feed the Pi4.

 

So for $100.- I get a powerful desktop system with HDMI output, 1x USB3, 2x USB 2 running Ubuntu like a charm...

[MichaIng]

Is the situation with other SBC manufacturers really so much different, or better? E.g. the closed source Mali driver blob, used by most SBC manufacturers with their hopelessly outdated Linux version images, or their probably open source Linux build, which is based on the latest LTS at the time when development started, and never updated (at least not major/minor version), so that earlier or later one needs to hope that certain features are merged to upstream Linux and can be provided by Armbian (which does an awesome job for providing mainline Linux images!) or other 3rd party distros. Regarding Mali drivers, as far as I understand, Mesa is constantly backwards engineering GPU features without any help from the GPU/SoC manufacturers.

Now with RPi, the closed source blob covers more than GPU acceleration but the bootloader and other firmware parts itself, but at least they provide major kernel upgrades in time so that one can still use RPi 1 with all recent features on modern distro versions. With every other SBC I'm aware of, one either needs to use a hopelessly outdated (at least kernel wise) distro, needs to do own kernel compiling, without much chance to get all features from legacy images, or hope for e.g. Armbian to get most things running with mainline kernel. And with Armbian, there are still often features missing, depending on the SBC/SoC, sometimes still legacy manufacturer provided kernel and/or bootloader used, support for older SBCs dropped so that users at some point can only stop using their hardware wise fully capable and functional SBC which does not work anymore with recent distro versions, etc.

 

I would love to see GPU/SoC/SBC manufacturers making everything open source and contributing all specific features and drivers upstream etc, but that doesn't seem to happen consequently in any case. And even when SBC manufacturers kernel builds are open source, as long as patches and drivers are not provided upstream, earlier or later the outdated Linux sources are useless.

[TRS-80]

32 minutes ago, MichaIng said:

Is the situation with other SBC manufacturers really so much different

 

Yes, it is.

 

There may be blobs (as you correctly point out, later in your post) however what RPi do is just above and beyond.  Completely proprietary bootloader and GPU which totally runs the show, and which no one can do anything about.

 

On other hardware, slowly but surely, blobs get reverse engineered one by one.  Some of these boards can be run completely blobless by now, and others are very close.  I just don't see that even being possible with RPi.

 

Everything else you mention is just a function of RPi having more resources at their disposal.

 

Of course the fundamental debate is functionality/convenience vs freedom.  The vast majority of people pick the former.  However there are a lot of us (myself included) who care enough about the latter to make a principled stance, try and discuss the issue, and also provide material support to the (difficult!) effort towards more freedom.

 

[MichaIng]

vor 13 Minuten schrieb TRS-80:

Everything else you mention is just a function of RPi having more resources at their disposal.

 

Totally right, though their initial agreement with Broadcom may have been one reason why RPi became so successful/popular, starting the era of SBCs in the first place, probably even the only option they had to get the whole project up. I'm not sure whether the RPi Foundation now had the "freedom" to decide going open source (regarding contracts with Broadcom), even when switching to a different SoC manufacturer probably not able to keep the brand "Raspberry Pi" then. So we should be careful where to put blame on (at least when not knowing more about the contract details), considering that without this initial contract with Broadcom and using (forced to) closed source firmware the whole SBC marked may not exist or not to that extant like it does today.

Also, there is development in it, more and more prior firmware features are moved to mainline kernel drivers, like CPU scaling, display driver stack (KMS/DRM/CMA/camera) and others.

But of course, if you want to go full FLOSS, or as much as possible, RPi is not the option. But that's a personal choice and not a reason to blame anyone else for, especially not those which established a marked in the first place where open source simply was not the priority, but getting things up and running sustainable (business wise). The other way round, the whole ARM marked, development and community is benefiting from what RPi established, including all the open source projects addressing the "new" little low power ARM home server or cluster use cases.

[TRS-80]

11 minutes ago, MichaIng said:

But that's a personal choice

 

Certainly, my beliefs are my own.

 

However, this project is also named after Debian.  Which means different things to different people.  To some it means reliability, wide support, lots of packages, etc.  However to very many people it also stands for a certain philosophy, which is strongly in agreement with Free Software principles.

 

A lot of things you say are true re: attention, development, etc.  It's just lamentable that the most popular SBC is also the most locked down.  Historical accident, or?  Personally I am not so keen to cut Broadcom some slack.  Remember, these are the people who nearly had to be sued to release GPL source for wrt54g all those years ago...  They were smarter about controlling their platform this time around...

[MichaIng]

vor 50 Minuten schrieb TRS-80:

However, this project is also named after Debian.

 

It is not. If you mean Raspbian, it is a dedicated project, not related directly to the RPi Foundation, nor maintained by their developers. It is a dedicated small community which simply uses the regular Debian sources and compiles them for armv6hf, required for the RPi 1 and Zero ARM which is simply not supported by Debian. Only where compile or runtime issues occur, small patches are applied. But all the closed source firmware blobs and such are provided not via Raspbian but via the dedicated RPi repository `archive.raspberrypi.org` (in raspi.list) vs `archive.raspbian.org`==`raspbian.raspberrypi.org` (in sources.list). The first can be used with any other Debian or Ubuntu image, the new Raspberry Pi OS 64-bit (announced as stable just yesterday) uses the Debian repository, not Raspbian.
 

vor 50 Minuten schrieb TRS-80:

It's just lamentable that the most popular SBC is also the most locked down.

 

Basically since it, in case of RPi was the first SBC (was it? or like iPhone not the first, but the first popular one?), establishing the definition and marked, also the reason why RPi is used as a synonym for SBCs so widely, vice versa. I'm not happy with this either, but sometimes I'm thinking whether it would have been possible all that years ago to start this purely open source, considering that you need to have a chip manufacturer which provides you with open source chips/hardware for a price which is sufficiently low to attract sufficient attention and acceptance to not remain a niece and/or dying because no one wants to pay so much for something where use cases need to be found first (hence tinker guys as initial potential customers).

But it's of course great that there are so many competitors now, even that it's hard for them. Regarding my earlier post about manufacturer providing outdated images/kernel etc, coincidentally a BeagleBone developer just made me aware of new images based on Debian Bullseye with upstream Linux 5.10, even kernel packages up to 5.17 via APT repository up to Bookworm is all provided. A great example for how it can be:
- https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshots/31280
- https://repos.rcn-ee.com/debian/dists/

[TRS-80]

14 minutes ago, MichaIng said:

It is not.

 

I was referring to Armbian, not Raspbian.

 

/looks around, makes sure we are still in Armbian forums, check 

 

Also thread is about RPi support in Armbian, unless I missed something?

 

 

[MichaIng]

vor 12 Minuten schrieb TRS-80:

I was referring to Armbian, not Raspbian.

 

Ah whoops, got it . I guess I was more reacting to the RPi/Broadcom criticism than to the question whether Armbian should support RPi or not. Regarding the latter, I have the hope that Armbian can be an additional driver to push more RPi features into upstream Linux. Sometimes one can only change the direction of a flow when swimming with the flow, but whether one wants to try it that way or even believe in these words for the actual topic is another question. Anyway, I'm curious how it all develops.

[TRS-80]

Besides freedom reasons, there are user/support and practical (limited) resource ones, too.  But there are 5 pages in this thread about that already (but see first page for some interesting historical perspective however).  We are after all just few guys and RPi have tons of resources already.  There are 100+ other (often more interesting) boards out there not seeing anywhere near that attention.  So we try to give attention to those otherwise orphaned ones.  Maybe we should rename the project to SBC orphanage, or use that as a subtitle.  

 

Competition and diversity are good for keeping corporations on their toes and innovating.

 

In fact, a lot of early criticisms of RPi 2/3 hardware have been fixed by now in newer versions.  Would that have happened if no one else were making and developing other SBC?  I think probably not.  Look at current web browser situation which is a nightmare due to no real competition.  Or places which have only one ISP (cough Comcast cough).  Many examples.

 

44 minutes ago, MichaIng said:

Sometimes one can only change the direction of a flow when swimming with the flow, but whether one wants to try it that way or even believe in these words for the actual topic is another question.

 

I guess it's like the debate between Free Software and 'Open Source' approaches.  I am in favor of the former but some times I wonder.  Hard line stance or 'swim with the flow'?  In fact Debian themselves are somewhere in between (allowing non-free and contrib repos, just not by default).

 

Also as you said above:

 

1 hour ago, MichaIng said:

Basically since it, in case of RPi was the first SBC (was it? or like iPhone not the first, but the first popular one?), establishing the definition and marked, also the reason why RPi is used as a synonym for SBCs so widely, vice versa. I'm not happy with this either, but sometimes I'm thinking whether it would have been possible all that years ago to start this purely open source, considering that you need to have a chip manufacturer which provides you with open source chips/hardware for a price which is sufficiently low to attract sufficient attention and acceptance to not remain a niece and/or dying because no one wants to pay so much for something where use cases need to be found first (hence tinker guys as initial potential customers).

 

Some times I wonder, too.  I guess we will never know?

 

Allwinner is a sort of similar example, those devices became well supported in Linux not because of Allwinner (who were (are still?) famously hostile towards GPL) but they were sold so inexpensively they got into hands of a lot of hackers and ended up with good support in spite of them.  I see a sort of similar thing going on with PinePhone lately (as compared to Librem 5).[0]

 

Anyway, it's Friday afternoon, let's grab a beer. 

 

[0] PINE64 are no where near flaunting GPL like Allwinner, I was just contrasting their 'sell many cheap units but hire no devs' approach to that of Purism's, the latter who more explicitly promote freedom and mainlining as a feature (but at higher cost).

Edited February 4, 2022 by TRS-80
add footnote / disclaimer

[MichaIng]

vor 9 Minuten schrieb TRS-80:

So we try to give attention to those otherwise orphaned ones.

 

True, in many cases I see Armbian's kernel distribution as only real option for many of those, at least ~1 year after release, when the manufacturer provided images start to become too old. When there is a well maintained Debian based image from manufacturer and few or no chances to provide a capable one with higher FLOSS degree, the question indeed is how much benefit an Armbian image has, of course also a question of the actual goal with it.

 

vor 14 Minuten schrieb TRS-80:

In fact Debian themselves are somewhere in between (allowing non-free and contrib repos, just not by default).

 

Some Ethernet and many WiFi chips do not run well or not at all without the non-free driver blobs. The armbian-firmware package ships these as well, btw, reasonably, as otherwise many SBCs couldn't establish a WiFi connection in the first place, causing a bootstrap issue when there is no Ethernet adapter or port nearby.

 

vor 23 Minuten schrieb TRS-80:

Anyway, it's Friday afternoon, let's grab a beer. 

 

Making hamburger for dinner now, fits well with a beer, cheers . Well fed I'll read through the whole topic.

[TRS-80]

On 2/4/2022 at 7:26 PM, MichaIng said:

Some Ethernet and many WiFi chips do not run well or not at all without the non-free driver blobs.

 

Same as on x86.  This being one of main (philosophical) differences between Debian and its many derivatives in fact.  Here again, Debian goal is to promote Free Software, so these non-free repos are disabled by default.  Those of us who come from this perspective consider this a feature (as enabling them is easy enough, and by doing so have an opportunity to educate the user about blobs).    However many downstream distros (and users who care only about convenience) consider this a bug.  And therefore many of these downstream derivatives enable these non-free blobs by default.

 

On 2/4/2022 at 7:26 PM, MichaIng said:

The armbian-firmware package ships these as well, btw, reasonably, as otherwise many SBCs couldn't establish a WiFi connection in the first place, causing a bootstrap issue when there is no Ethernet adapter or port nearby.

 

Besides the practical issue you already addressed, I suppose I always figured this was just one more of the many long list of things we would like to do 'some day' but cannot yet as to lack of resources.

 

Personally it has always been my dream to see some separation along Freedom lines like what mainline Debian do with their repos (main contrib non-free), I am just not sure how practical that is here in SBC world, given the nature and complications of bootloaders, blobs, (large) hardware abstraction differences from x86, etc.

 

 

[gounthar]

Hi there,

 

I needed an aarch64 gitlab-runner asap, so I got rid of HyprioOs (32 bits) and installed Armbian on my Raspberry Pi 3B.
I would have loved to stay with Debian, but went with Ubuntu Focal (as it was the smallest install available).
I have a problem with Docker and `overlay2`.
 

Spoiler

 sudo /usr/bin/dockerd
INFO[2022-02-17T16:58:28.689286518+01:00] Starting up
INFO[2022-02-17T16:58:28.699468486+01:00] parsed scheme: "unix"                         module=grpc
INFO[2022-02-17T16:58:28.700166971+01:00] scheme "unix" not registered, fallback to default scheme  module=grpc
INFO[2022-02-17T16:58:28.700632176+01:00] ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.sock  <nil> 0 <nil>}] <nil> <nil>}  module=grpc
INFO[2022-02-17T16:58:28.701143371+01:00] ClientConn switching balancer to "pick_first"  module=grpc
INFO[2022-02-17T16:58:28.728169297+01:00] parsed scheme: "unix"                         module=grpc
INFO[2022-02-17T16:58:28.728332109+01:00] scheme "unix" not registered, fallback to default scheme  module=grpc
INFO[2022-02-17T16:58:28.728427993+01:00] ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.sock  <nil> 0 <nil>}] <nil> <nil>}  module=grpc
INFO[2022-02-17T16:58:28.728491014+01:00] ClientConn switching balancer to "pick_first"  module=grpc
ERRO[2022-02-17T16:58:28.741652443+01:00] failed to mount overlay: no such device       storage-driver=overlay2
ERRO[2022-02-17T16:58:28.741913379+01:00] exec: "fuse-overlayfs": executable file not found in $PATH  storage-driver=fuse-overlayfs
ERRO[2022-02-17T16:58:28.760037902+01:00] AUFS was not found in /proc/filesystems       storage-driver=aufs
ERRO[2022-02-17T16:58:28.769291698+01:00] failed to mount overlay: no such device       storage-driver=overlay
WARN[2022-02-17T16:58:28.808232811+01:00] Your kernel does not support CPU realtime scheduler
WARN[2022-02-17T16:58:28.808329894+01:00] Your kernel does not support cgroup blkio weight
WARN[2022-02-17T16:58:28.808379633+01:00] Your kernel does not support cgroup blkio weight_device
INFO[2022-02-17T16:58:28.809312127+01:00] Loading containers: start.
WARN[2022-02-17T16:58:28.828738048+01:00] Running modprobe bridge br_netfilter failed with message: modprobe: WARNING: Module bridge not found in directory /lib/modules/5.16.7-bcm2711

 

 

Would anyone know if there is anything I can do on my side to get it to work?
I mean, if that does not imply rebuilding a specific image for me, as I don't have the hardware to do so.
Thanks in advance.

 

 

Edited March 4, 2022 by TRS-80
put long output inside spoiler

[Igor]

3 hours ago, gounthar said:

Would anyone know if there is anything I can do on my side to get it to work?

https://github.com/armbian/build/pull/3502

[gounthar]

Thank you so much.

When that will work for me, I will try with overlay2.

Will a

armbian-config/System/Firmware

be enough to get the corrected kernel, or should I reinstall the complete image?

Armbian monitor

[gounthar]

I think I have my answer, as the kernels are not freezed, they are updated.
When it works.

Spoiler

 sudo apt dist-upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants seront mis à jour :
  armbian-bsp-cli-rpi4b-fkraspi armbian-zsh linux-dtb-edge-bcm2711 linux-image-edge-bcm2711 linux-libc-dev
5 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
5 partiellement installés ou enlevés.
Il est nécessaire de prendre 27,9 Mo dans les archives.
Après cette opération, 20,5 ko d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n]
Réception de :1 https://imola.armbian.com/beta focal/main arm64 linux-image-edge-bcm2711 arm64 22.02.0-trunk.0043 [24,2 MB]
Réception de :2 https://imola.armbian.com/beta focal/main arm64 armbian-bsp-cli-rpi4b-fkraspi arm64 22.02.0-trunk.0044 [129 kB]
Réception de :3 https://imola.armbian.com/beta focal/main arm64 armbian-zsh all 22.02.0-trunk.0044 [2 266 kB]
Réception de :4 https://imola.armbian.com/beta focal/main arm64 linux-dtb-edge-bcm2711 arm64 22.02.0-trunk.0043 [84,1 kB]
Réception de :5 https://imola.armbian.com/beta focal/main arm64 linux-libc-dev arm64 22.02.0-trunk.0044 [1 182 kB]
27,9 Mo réceptionnés en 7s (4 016 ko/s)
(Lecture de la base de données... 41471 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../linux-image-edge-bcm2711_22.02.0-trunk.0043_arm64.deb ...
update-initramfs: Deleting /boot/initrd.img-5.16.9-bcm2711
Dépaquetage de linux-image-edge-bcm2711 (22.02.0-trunk.0043) sur (22.02.0-trunk.0042) ...
Préparation du dépaquetage de .../armbian-bsp-cli-rpi4b-fkraspi_22.02.0-trunk.0044_arm64.deb ...
Dépaquetage de armbian-bsp-cli-rpi4b-fkraspi (22.02.0-trunk.0044) sur (22.02.0-trunk.0042) ...
Préparation du dépaquetage de .../armbian-zsh_22.02.0-trunk.0044_all.deb ...
Dépaquetage de armbian-zsh (22.02.0-trunk.0044) sur (22.02.0-trunk.0042) ...
Préparation du dépaquetage de .../linux-dtb-edge-bcm2711_22.02.0-trunk.0043_arm64.deb ...
Dépaquetage de linux-dtb-edge-bcm2711 (22.02.0-trunk.0043) sur (22.02.0-trunk.0042) ...
Préparation du dépaquetage de .../linux-libc-dev_22.02.0-trunk.0044_arm64.deb ...
Dépaquetage de linux-libc-dev:arm64 (22.02.0-trunk.0044) sur (22.02.0-trunk.0042) ...
Paramétrage de linux-image-edge-bcm2711 (22.02.0-trunk.0043) ...
 * dkms: running auto installation service for kernel 5.16.10-bcm2711                                                                                                                                                                                                   [ OK ]
update-initramfs: Generating /boot/initrd.img-5.16.10-bcm2711
Using DTB: bcm2710-rpi-3-b-plus.dtb
Couldn't find DTB bcm2710-rpi-3-b-plus.dtb on the following paths: /etc/flash-kernel/dtbs /usr/lib/linux-image-5.16.10-bcm2711 /lib/firmware/5.16.10-bcm2711/device-tree/
Installing  into /boot/dtbs/5.16.10-bcm2711/./bcm2710-rpi-3-b-plus.dtb
cp: cannot stat '': No such file or directory
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Using DTB: bcm2710-rpi-3-b-plus.dtb
Couldn't find DTB bcm2710-rpi-3-b-plus.dtb on the following paths: /etc/flash-kernel/dtbs /usr/lib/linux-image-5.16.10-bcm2711 /lib/firmware/5.16.10-bcm2711/device-tree/
Installing  into /boot/dtbs/5.16.10-bcm2711/./bcm2710-rpi-3-b-plus.dtb
cp: cannot stat '': No such file or directory
run-parts: /etc/kernel/postinst.d/zz-flash-kernel exited with return code 1
dpkg: erreur de traitement du paquet linux-image-edge-bcm2711 (--configure) :
 installed linux-image-edge-bcm2711 package post-installation script subprocess returned error exit status 1
Paramétrage de initramfs-tools (0.136ubuntu6.7) ...
update-initramfs: deferring update (trigger activated)
Paramétrage de linux-firmware (1.187.26) ...
update-initramfs: Generating /boot/initrd.img-5.16.10-bcm2711
Using DTB: bcm2710-rpi-3-b-plus.dtb
Couldn't find DTB bcm2710-rpi-3-b-plus.dtb on the following paths: /etc/flash-kernel/dtbs /usr/lib/linux-image-5.16.10-bcm2711 /lib/firmware/5.16.10-bcm2711/device-tree/
Installing  into /boot/dtbs/5.16.10-bcm2711/./bcm2710-rpi-3-b-plus.dtb
cp: cannot stat '': No such file or directory
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
dpkg: erreur de traitement du paquet linux-firmware (--configure) :
 installed linux-firmware package post-installation script subprocess returned error exit status 1
Paramétrage de linux-libc-dev:arm64 (22.02.0-trunk.0044) ...
Paramétrage de docker.io (20.10.7-0ubuntu5~20.04.2) ...
Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service.
Created symlink /etc/systemd/system/sockets.target.wants/docker.socket → /lib/systemd/system/docker.socket.
Job for docker.service failed because the control process exited with error code.
See "systemctl status docker.service" and "journalctl -xe" for details.
invoke-rc.d: initscript docker, action "start" failed.
● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Sat 2022-02-19 21:08:28 CET; 27ms ago
TriggeredBy: ● docker.socket
       Docs: https://docs.docker.com
    Process: 10956 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=1/FAILURE)
   Main PID: 10956 (code=exited, status=1/FAILURE)
Paramétrage de armbian-zsh (22.02.0-trunk.0044) ...
Paramétrage de armbian-bsp-cli-rpi4b-fkraspi (22.02.0-trunk.0044) ...
Recreating boot script
Paramétrage de linux-dtb-edge-bcm2711 (22.02.0-trunk.0043) ...
Paramétrage de flash-kernel (3.103ubuntu1~20.04.3) ...
Using DTB: bcm2710-rpi-3-b-plus.dtb
Couldn't find DTB bcm2710-rpi-3-b-plus.dtb on the following paths: /etc/flash-kernel/dtbs /usr/lib/linux-image-5.16.10-bcm2711 /lib/firmware/5.16.10-bcm2711/device-tree/
Installing  into /boot/dtbs/5.16.10-bcm2711/./bcm2710-rpi-3-b-plus.dtb
cp: cannot stat '': No such file or directory
dpkg: erreur de traitement du paquet flash-kernel (--configure) :
 installed flash-kernel package post-installation script subprocess returned error exit status 1
Traitement des actions différées (« triggers ») pour initramfs-tools (0.136ubuntu6.7) ...
update-initramfs: Generating /boot/initrd.img-5.16.10-bcm2711
Using DTB: bcm2710-rpi-3-b-plus.dtb
Couldn't find DTB bcm2710-rpi-3-b-plus.dtb on the following paths: /etc/flash-kernel/dtbs /usr/lib/linux-image-5.16.10-bcm2711 /lib/firmware/5.16.10-bcm2711/device-tree/
Installing  into /boot/dtbs/5.16.10-bcm2711/./bcm2710-rpi-3-b-plus.dtb
cp: cannot stat '': No such file or directory
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
dpkg: erreur de traitement du paquet initramfs-tools (--configure) :
 installed initramfs-tools package post-installation script subprocess returned error exit status 1
Des erreurs ont été rencontrées pendant l'exécution :
 linux-image-edge-bcm2711
 linux-firmware
 flash-kernel
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

 

 

[gounthar]

The kernel got correctly updated tonight.

 

Welcome to Armbian 22.02.1 Focal with bleeding edge Linux 5.16.10-bcm2711

Docker now works.

Spoiler

 sudo docker run hello-world
[sudo] password for poddingue:
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
93288797bd35: Pull complete
Digest: sha256:97a379f4f88575512824f3b352bc03cd75e239179eea0fecc38e597b2209f49a
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (arm64v8)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

 

Thanks a lot for your work.

[perlian]

I was very happy to realize that the raspberry is now also supported. Many have waited a long time for this.
I immediately wrote an article about it on gnulinux.ch.
Hopefully this will not be a half-hearted project.
I also think it would be an advantage if Armbian would appear as a distribution on the Raspberry download page