Add artifact information to rootfs.

mkdir -p "${LXD_ROOTFS}/etc/mender/"
echo "artifact_name=${ARTIFACT_NAME}" > "${LXD_ROOTFS}/etc/mender/artifact_info"

Should be moved to plugins/playbooks/board_support/roles/mender/tasks/main.yml

The edi-resize-rootfs script automatically resizes partition 3 and adds partition 4.
When preparing the migration to gpt I found out that partition 4 does not get properly aligned to 1MiB boundaries as recommended e.g. here. This could result in reduced performance.

The alignment can be checked as follows:

compulab@iot-gate-imx8:/$ sudo parted /dev/mmcblk2 align-check optimal 3
3 aligned
compulab@iot-gate-imx8:/$ sudo parted /dev/mmcblk2 align-check optimal 4
4 not aligned

This integration can be added to https://hub.mender.io as an additional board integration.

Hello Matthias,

there is (at least) one thing left which I do not understand: How are the services which I install by copying the service unit files to /lib/systemd/system/ enabled? I recognised that the are enabled by default. How can prevent them for being enabled?

For example this ansible play:

• name: Copy start-vpn-client service file.
  copy:
  src: start-vpn-client.service
  dest: /lib/systemd/system/
  mode: 0644
  owner: root
  group: root

leads to this one after first boot:

/etc/systemd/system/multi-user.target.wants/start-vpn-client.service -> /lib/systemd/system/start-vpn-client.service

How can I prevent edi from adding those links?

Thanks in advance!

Nils

Hello Matthias,

I have an issue configuratind the ufw rules for my comulab gateway. Maybe you can point me to the right direction.

I added a role "ufw"

When executing the playbook I get the following error:

TASK [ufw : Reset UFW and deny everything] *********************************************************************************** fatal: [edi-2ebded6f-a5c2baac]: FAILED! => {"changed": false, "commands": ["/usr/sbin/ufw status verbose"], "msg": "ERROR: Couldn't determine iptables version\n"}

I checked if I can read the version of iptables on the gateway:

compulab@iot-gate-imx8-0001c034e69b:~$ sudo iptables --version iptables v1.8.9 (nf_tables)

Maybe it is not the right way of setting the rules? Should I copy a script which runs on first boot?

Additional question: Is it possible to test such a new role seperately without building the complete image?

Thanks for your help!

Cheers Nils

This should also fix the iwlwifi issue reported here:
https://hub.mender.io/t/unable-to-boot-properly-with-edi-cl-built-image-on-compulab-iot-gate-imx8/2951

Hi Matthias,

edi-cl is a huge help to build our system-images.

Context:
With the newest release r3.2.1 from compulab we need to update the firmware of our devices as the new kernel won't work correctly (missing can device besides other issues). Building the new firmware is easy and it works well after flashing

Issue:
It's not feasable to manually copy and flash the firmware to all our devices. Is is possible to embed the new firmware in the mender image created by edi-cl?

Thanks in advance.

First of all thanks for this great framework. This is exactly what i was looking for!

I had success building the image for the iot gateway and booting it. Unfortunately the resize script was failing on first boot because the command sfdisk was missing. I tried adding fdisk to the "playbook" but had no success with it. After installing it "by hand" on the device and executing the script the resize was successfull. What do I have to di to get fdisk installed during the image build process?
Thanks!
Nils

To get rid of some legacy it could make sense to switch from the dos partition table to the gpt partition table.

Things to consider:

• gpt has a secondary partition table at the end of the disk.
• edi-resize-rootfs and rootfs2image need to take this into account.
• sfdisk needs to be replaced by sgdisk.
• An old edi-resize-rootfs script might throw errors when trying to resize a gpt disk. Therefore a new image type might make sense.

In order to keep the digital twin LXD container as close as possible to the real hardware it would make sense to switch the network management from ifup to NetworkManager also within the LXD container.

For this the package network-manager needs to be installed during bootstrapping. After this there is no need to separately configure eth0 as the default NetworkManager config is DHCP for wired network interfaces.

The switch to NetworkManager within the LXD container could lead to temporary incompatibilities and special care needs to be taken if an existing LXD container gets switched over to NetworkManager. Maybe the container should get re-created from scratch or as a new configuration.

As suggested in https://hub.mender.io/t/unable-to-boot-properly-with-edi-cl-built-image-on-compulab-iot-gate-imx8/2951 it would make sense to integrate ModemManager and NetworkManager into the edi-cl image.

Any existing NetworkManager connection should then be persisted during an upgrade. A Mender state script could be used to backup and restore the connections.

edi-imx uses {{ imx_timestamp }} while edi-pi uses {{rpi_timestamp}
The prefix could be more generic such that we don't have to modify the files in instances of EDI.

Proposal:
imx_timestamp -> postprocess_timestamp_output
imx_mender_artifact -> postprocess_mender_output

This might help move it upstream into EDI in the future...

See http://variwiki.com/index.php?title=VAR-SOM-6UL for ideas.

The edi_ namespace is "reserved", and conflicts with "edi_boot_shim". Maybe edibootshim - or ebs - could be used as "edi" is part of that scripts name.

Would "base" simply be good enough? It looks decent enough when I actually rename it.

Problem Description

Despite the deletion of /etc/machine-id during the image build it was observed that the machine-id is identical on multiple device instances.

Root Cause

There is a "redundant" copy of /etc/machine-id in /var/lib/dbus/machine-id. During the first boot /etc/machine-id gets derived from /var/lib/dbus/machine-id.

Solution

Also delete /var/lib/dbus/machine-id during image build.