Olimage – Mainline Linux images building script for all of our OLinuXino and SOM boards


DEBIANubuntu_904

We work for more than 6 month on our own Linux building script and now we are ready with it’s initial release, which is now on GitHub .

Why do we need it? The number of our boards with all variant hit over 70 pcs when you add to them the different LCD combinations and other peripherials the support and test of these images became little hell. Our latest Armbian based image was released 3-4 months ago as we didn’t manage to properly test all board features in the newer images.

So we first made universal images for all our groups of boards (based on the SOC used) and EEPROM where we store info so uboot and kernel to may recognize the board and configure properly the parameters at boot time.

Then we decided to make one-for-all build script which will automatically build images with recent kernel and uboot automatically.

We had to leave Armbian as we wanted things to be more under our control and decision. Also we wanted everything to be 100% tested when released. Armbian official builds are not tested at hardware level other than to see board boots, so many boards are with peripheral conflicts and we had to apply our patched on Armbian anyway to adjust the images for our boards.

Our official images now are at http://images.olimex.com.

There is release folder where we have minimal and basic images for Debian and Ubuntu and testing folder where new uboot and kernel images will be built and kept until properly tested. For instance Ubuntu 20.04 LTS and kernel 5.6 images will be put there in the next couple of weeks.

The Olimage script and repositories are developed in our internal Gitlab and will be only push to Github when everything is properly tested and images moved to release folder. Also we push all our patches upstream.

With the current kernel and uboot users can easily generate any Linux distribution as it’s matter of building rootfs.

Moving to the next release would be possible simple by

sudo apt-get update && apt-get dist-upgrade

then re-boot of the board, so when we release new images all you have to do is to run the above commands and you will have the latest images.

For the moments the builder has A10, A13, A20, A64.

iMX233 and RK3188 SOCs are obsolete and not produced anymore by Rockchip and NXP, so they will be not included in the script. We still produce and sell these boards, but they will be discontinued when we use our existing SOC stock.

AM3352-SOM and AM3359-SOM will be included in the script, but we have no fixed date when, as we have to put earlier S3-OLinuXino and STMP1-OLinuXino-LIME2 which are with higher priority.

32 Comments (+add yours?)

  1. tibor
    Apr 21, 2020 @ 19:35:25

    hi,
    can you please add checksums and signatures to that images?
    thx!

    Reply

  2. Philip
    Apr 22, 2020 @ 13:54:17

    Thanks for the images, that’s great!
    Unfortunately USB is not working on my A64-Olinuxino-1Ge4GW Rev. D, see https://www.olimex.com/forum/index.php?topic=7286.msg28527#msg28527 for reference.

    Reply

  3. binutzu
    Apr 22, 2020 @ 21:39:41

    That’s awesome and another proof of commitment to your customers.
    Would it be possible to add also Teres-1 to the list of boards?

    Reply

  4. Silvano
    May 05, 2020 @ 18:49:28

    Well done, you did well to make your own distribution. I’m testing it on Lime A10 and Lime A20. How can you copy to cards with 4GB NAND? How can SPIDEV be activated on the card with A10? “olinuxino-overlay” not working. (The sun4i-a10 SoC family is not supported. Exiting.) Anyway great job.

    Reply

  5. Neil Davey
    May 06, 2020 @ 07:21:53

    Hi,
    Stumbled across this and have put buster on my old A13 (rev C). Awesome work..
    Are there instruction for DIY building of images?

    Reply

  6. Mossroy
    May 08, 2020 @ 12:59:23

    Is it supposed to work on A64-OLinuXino-2Ge8G-IND boards too?
    I did not manage to make it start on mine. See https://www.olimex.com/forum/index.php?topic=7663.0

    Reply

    • Lub
      May 08, 2020 @ 13:12:27

      Thanks for the feedback, we are investigating the performance on the A64 boards with 2GB RAM. It seems there might be some software issue.

      Reply

  7. Mossroy
    May 16, 2020 @ 14:27:15

    When will a new image be provided, that works for the A64 boards with 2GB RAM?

    Reply

  8. Mossroy
    Jun 01, 2020 @ 19:29:14

    Thanks.

    The testing images A64-OLinuXino-buster-base-20200523-231345.img and A64-OLinuXino-buster-minimal-20200522-193443.img both boot correctly on my A64-OLinuXino-2Ge8G-IND board.

    But there are still many issues with them :
    – there is a hard-coded DNS resolver in /etc/resolv.conf (only in “base” image) : 192.168.0.1
    – the MAC address is hard-coded and cannot be overridden with /boot/uEnv.txt. Workaround : set it in /etc/network/interfaces.d/eth0
    – any DNS lookup fails, with errors like “Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found” (only in “base” image?). Workaround : sudo systemctl start systemd-resolved.service
    – I suppose there are other networking issues, as any ping command ran by a regular user (without sudo) gives an error : “ping: socket: Operation not permitted”. Looks similar to https://github.com/MichaIng/DietPi/issues/1012
    – some kernel modules fail to load on startup, only on “base” image : “Failed to find module” on lp, ppdev and parport_pc
    – 2 other services fail to start : haveged (only on “base” image) and olinuxino-bluetooth (on both images)
    – I suppose the maximum CPU frequency is lower than on armbian because the performance is 25 to 30% slower (tested with cryptsetup benchmark)

    On the other hand, there does not seem to be any CPU overheating with this image. I did not manage to make /sys/class/thermal/thermal_zone0/temp exceed 65°C, which is good and avoids board restarts at 110°C like in some other images. And this image properly detects USB devices (where armbian images currently have issues on that)

    Reply

    • OLIMEX Ltd
      Jul 13, 2020 @ 10:47:44

      I will reply here as our developers are too busy 🙂
      “– there is a hard-coded DNS resolver in /etc/resolv.conf (only in “base” image) : 192.168.0.1”

      this is not a problem if your DNS server works, we can put here anything like 8.8.8.8 as some customers has bad configured network and their board never got DNS IP, so in these cases they will have access through some pre-defined DNS, otherwise hundreds of emails my board can’t connect to internet will flood us.

      “– the MAC address is hard-coded and cannot be overridden with /boot/uEnv.txt. Workaround : set it in /etc/network/interfaces.d/eth0”

      yes, this board has the MAC hardcoded, what is the issue with this?

      “– I suppose there are other networking issues, as any ping command ran by a regular user (without sudo) gives an error : “ping: socket: Operation not permitted”. Looks similar to https://github.com/MichaIng/DietPi/issues/1012

      our developers work on this, there will be fix soon

      “– some kernel modules fail to load on startup, only on “base” image : “Failed to find module” on lp, ppdev and parport_pc
      – 2 other services fail to start : haveged (only on “base” image) and olinuxino-bluetooth (on both images)”

      these packages are required by Debian but are useless and we do not compiled them, the “fail” to load is not a problem and expected

      “– I suppose the maximum CPU frequency is lower than on armbian because the performance is 25 to 30% slower (tested with cryptsetup benchmark)”

      indeed as we value more stability than the performance, you figured it out yourself in your last sentence, than with this image processor overheating is not observed

      Reply

      • Mossroy
        Jul 13, 2020 @ 22:51:27

        Thanks for your answer.
        Regarding the hard-coded DNS address, I disagree. 192.168.0.1 is not always the address of a DNS server. It’s common for some home network configurations, but fails in many other network configurations (like my home, where DNS clearly works).
        By applying this workaround for some badly-configured networks, you break DNS for many correctly-configured networks (like most corporate ones). 8.8.8.8 is the DNS of Google, which is not always reachable (if you work behind a firewall + corporate HTTP proxy for example) and is the worst in terms in privacy.
        I understand your willingness to simplify your support. But, IMHO, the image should let DHCP set the DNS address (if available).
        The issue with a hardcoded MAC address is that you can not connect several boards on the same ethernet network (which is what I need to do).
        There must be an easy way to override this MAC address in this case.
        uboot can handle this, by reading and applying line “ethaddr=…” in /boot/uEnv.txt. To me, it would be the most generic way to let us do that, but it’s currently rejected by uboot. It looks like adding CONFIG_OVERWRITE_ETHADDR_ONCE option when compiling uboot should allow that (I did not test). Source : https://github.com/linux-sunxi/u-boot-sunxi
        Regarding the CPU performance, I also prefer stability over performance. But a 25 to 30% performance decrease seems a lot to me. Could you provide us an official way to choose if we want to underclock the CPU or not?
        Finally, you forgot to answer the “hard links” issue I reported last month (for which rkhunter complains) : https://olimex.wordpress.com/2020/04/21/olimage-mainline-linux-images-building-script-for-all-of-our-olinuxino-and-som-boards/#comment-41622

      • OLIMEX Ltd
        Jul 14, 2020 @ 11:43:22

        I just grab A64-OLinuXino from our stock and burned Debian buster base image from images.olimex.com to check what you write above:

        1. hardcoded DNS does no any problems, I intentionally edited it to 9.9.9.9 and reboot the board, after the board got connected to the WiFi router the DNS server was set correctly , and I can ping any web site

        2. The hardcoded MAC addresses are not with SAME MAC addresses, Olimex has MAC address range and during the functional test each board has assigned UNIQUE MAC address which is also used in the board Serial number and allow tracebility in production.

        3. Regarding the CPU performance, we bet on industrial use and stability if kids want to play with overclocking they can do it with the Armbian image (hint check our forums for overheating boards with Armbian image).

        4 . we can’t comment about rkhunter as I asked our developers and none of them has used this tool, neither we understand the tool creator concerns about these “hard links” and how they affect board security. Perhaps you can share your concerns? why these hard links are dangerous and how to rectify this “problem”?

        We appreciate your feedback!

      • Mossroy
        Jul 19, 2020 @ 01:29:53

        Thanks for your tests. Here are some answers for the 4 topics you mentioned :

        1. DNS resolution was definitely not working when I tested the “base” image on my board. It got fixed by modifying the /etc/resolv.conf AND starting systemd-resolved.service. I unfortunately can’t test again easily as I don’t have any spare board (and I switched to the minimal image, which better suits my need, and does not have the DNS issues). My local network is not on 192.168.0.*

        2. The 3 boards I bought from you have the same MAC address 02:ba:7b:d5:c6:6f, at least using Armbian_5.79.1_Olinuxino-a64_Debian_stretch_next_5.0.8 (it was somehow fixed in Armbian_5.87.1_Olinuxino-a64_Debian_stretch_next_5.1.4 by assigning a random MAC on each boot). I checked again on one board (running with A64-OLinuXino-buster-minimal-20200522-193443 image) : if I don’t manually set the MAC address in /etc/network/interfaces.d/eth0, it comes back to the dreaded 02:ba:7b:d5:c6:6f

        3. Regarding CPU performance, the problem is that this mainline image seems slower than the very old ubuntu image (https://www.olimex.com/wiki/images/4/43/A64olinuxino_ubuntu_16.04.3_20180523_rel5.torrent). I’m not 100% sure, but the aes-xts performance test of “cryptsetup benchmark” gives a better score with the old ubuntu. I did not test much, though, so I might be wrong?
        My wish is not to overclock, but to avoid a potentially excessive underclocking

        4. After searching a bit more about the hard links (like /usr/bin/which), it looks like it’s a false-positive of rkhunter (and/or its configuration on debian), that has been recently fixed upstream : https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1747321.html . Sorry, I thought you had manually modified the file structure, for some reason I was not understanding.

        NB : I also appreciate your feedback 🙂

  9. Mossroy
    Jun 07, 2020 @ 23:17:45

    There’s another strange issue.
    rkhunter complains about some files in /usr/bin :
    Warning: The command ‘/usr/bin/egrep’ has been replaced by a script: /usr/bin/egrep: POSIX shell script, ASCII text executable
    Warning: The command ‘/usr/bin/fgrep’ has been replaced by a script: /usr/bin/fgrep: POSIX shell script, ASCII text executable
    Warning: The command ‘/usr/bin/which’ has been replaced by a script: /usr/bin/which: POSIX shell script, ASCII text executable

    In the other Debian Buster machines I have, /usr/bin/which is a symbolic link to /bin/which.
    In this testing image, /usr/bin/which and /bin/which both point to the same inode (“ls -i” gives the same inode number for both paths, like the result of hard link)

    Is it done on purpose, or a mistake?

    Reply

  10. Mossroy
    Jun 27, 2020 @ 15:18:19

    Today I tested http://images.olimex.com/release/a64/A64-OLinuXino-buster-minimal-20200601-131837.img.7z on a A64-OLinuXino-2Ge8G-IND
    It has the same issues I mentioned in my last two posts above (about A64-OLinuXino-buster-minimal-20200522-193443.img).
    In particular the performance decrease, the ping issues, and the hard links for some /usr/bin utilities

    Reply

  11. Dave Kibble
    Jul 04, 2020 @ 19:57:06

    Hi – Great work, been battling Armbian for the A13 for weeks without any luck, but these images worked first time. However, I need to implement a custom LCD so want to rebuild using your oImage. When I run “./run.sh -v image A20-OLinuXino buster minimal” I get an error from docker;

    docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused “process_linux.go:402: container init caused \”rootfs_linux.go:58: mounting \\\”/proc\\\” to rootfs \\\”/var/lib/docker/aufs/mnt/0afdaa3294277f59ec3ed74ca61d034f46d9110ba5100406a7dd0417f2abeb25\\\” at \\\”/proc\\\” caused \\\”\\\\\\\”/var/lib/docker/aufs/mnt/0afdaa3294277f59ec3ed74ca61d034f46d9110ba5100406a7dd0417f2abeb25/proc\\\\\\\” cannot be mounted because it is located inside \\\\\\\”/proc\\\\\\\”\\\”\””: unknown.

    There’s not much info on the GitHub page to help. What am I doing wrong?

    Many thanks.

    Reply

    • Dave Kibble
      Jul 14, 2020 @ 18:56:48

      Hi – please can someone point me in the direction of how to use the oLimage tools? Stuck with the docker error above.

      Thanks

      Reply

      • OLIMEX Ltd
        Jul 14, 2020 @ 19:05:34

        Should be some misconfiguration with docker. You never say what OS do you use. Everything works fine here on Ubuntu 18.04

      • Dave Kibble
        Jul 15, 2020 @ 11:20:46

        Apologies – should have said, I’m running Debian 8.11 with Docker CE18.06.3. I’ve certainly not had any other issues with Docker on the machine. I have noticed a “mount.sh” script included in oLimage, does this perform any required setup? It appears to attempt to mount several system directories to a given path.

      • Dave Kibble
        Jul 15, 2020 @ 17:39:16

        In case anyone else has this issue, it is indeed caused by Debian 8.1. Upgraded to Debian 10 (Buster) and the build now works fine. Thanks for the pointer.

      • OLIMEX Ltd
        Jul 15, 2020 @ 18:09:32

        great to hear that the problem is solved

  12. Mossroy
    Jul 10, 2020 @ 23:15:03

    Today I quickly tested http://images.olimex.com/release/a64/A64-OLinuXino-buster-minimal-20200701-182059.img.7z on a A64-OLinuXino-2Ge8G-IND

    It still has the same issues I mentioned above.

    Reply

  13. Dimitri
    Jul 17, 2020 @ 13:47:46

    Hi, did anybody get read-only filesystem working with these images using the overlayroot package? I’ve tried with focal_minimal_20200701, bionic_minimal_20200701 and bionic_base_20200701 but I can not get it to work.

    I installed overlayroot: apt-get install overlayroot
    and added overlayroot=”tmpfs” to /etc/overlayroot.conf

    From what I can see this is what the armbian-config script does to enable this in the Armbian_5.92.4_Olinuxino-a20_Ubuntu_bionic_next_5.2.21_desktop image

    Reply

  14. Dan
    Sep 15, 2020 @ 13:14:54

    Will there be new images for the A33-OLinuXino board too?

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: