Armbian customization

[chradev]

Hi to All,

 

I found this project extremely useful and start customization process in the following directions:

• customize packet set for deploying into A20-Olinuxino-Lime2-4GB based server box
• use read only Root FS on NAND and SD with overlayfs and USB automount capability
• fully configurable by scripts in userpatches and up-gradable by web interface only
• completely none interactive (no tty1, ttyS0, ssh etc.) and controllable via web interface only

Armbian project usage is a must in later maintenance so the customization has to be done by userpatches only. Final project has to be ready for automated builds.

 

On the first step while trying to remove changing root password and adding user account at the first login a problem was reached adding to customize-image.sh following staff in Jessie case:

    chage -m 0 -M 99999 -I -1 -E -1 root # disable root password change at next login
    rm -f $HOME/.not_logged_in_yet # disable execution of the staff in check_first_login.sh

 

Both actions cannot not be disabled while previous lines for configuring network in hostapd mode works fine. To overcome the problem distributions.sh was changed by commenting corresponding lines which is not acceptable.

 

The other problem reached was at hostname change by adding in lib.config of:

    HOST=newhostname

 

The new name is applied at first boot but it is changed again to board name by firstrun script.

 

How to disable / change above staff without modifying Armbian code base?

 

One more problem was reached at trying to mount final raw SD card image on a loop device. It is failed probably because of shrinking so the inspecting of written staff become harder by using SD mounted on other Linux system.

 

Is it possible to leave final image before shrinking for verification and testing purposes without modifying Armbian code base?

 

Best regards

Chris

[Nick]

You might want to look here http://www.armbian.com/using-armbian-tools/ forvarious options, between lib.config and customize-image.sh you really shouldn't have to touch the Armbian code at all. I've been through the same process as you and learnt that almost everything can be customized.

 

As you can see from the link, running

compile.sh COMPRESS_OUTPUTIMAGE=no 

 will prevent Armbian from shrinking your image.

 

As for disabling change of root password and first login, I do exactly the same with customize-image.sh

#Remove annoying user creation at login
rm -f /root/.not_logged_in_yet
echo -e "password\npassword" | (passwd root)

Note that the above will change the root password to "password"

[zador.blood.stained]

As you can see from the link, running

compile.sh COMPRESS_OUTPUTIMAGE=no 

 will prevent Armbian from shrinking your image.

This will prevent packing raw image into zip archive. To prevent image shrinking, try setting

EXTENDED_DEBOOTSTRAP=yes
FIXED_IMAGE_SIZE=4000

image size is in megabytes; you can even create image that perfectly fits your SD card (you'll need to add

touch /root/.no_rootfs_resize

to customize-image.sh to prevent unneeded FS resize on first boot)

[chradev]

Thank you guys,

 

Removing user creation and root password changing at login works fine.

I will test proposals for disabling image shrinking later on.

 

I have already read all documentation and some forum posts when possible to find related once.

Unfortunately, a new problem comes to my head while trying to customize the configuration of installed packages.

 

As I can see the customization is well designed for u-boot and kernel but for packages I cannot find a way to add and/or patch some configuration files residing them in userpatches space. Using customize-image.sh script for such a purpose is limited because it is executed in chrooted environment and it is convenient for small changes in a few files.

 

Is there a way to put needed files in userpatches place and then copy them to rootfs or use to patch existing once using some kind of hooks (script like customize-distribution.sh) executed at the end of the installation and configuration of the distribution while the SD image is mounted on loop device (from distributions.sh)?

[zador.blood.stained]

Is there a way to put needed files in userpatches place and then copy them to rootfs or use to patch existing once using some kind of hooks (script like customize-distribution.sh) executed at the end of the installation and configuration of the distribution while the SD image is mounted on loop device (from distributions.sh)?

Not right now. As a temporary solution you can pack your needed files into an archive and download & unpack this archive from customize-image.sh (just run a simple http server on localhost or share this file on Dropbox/Google Drive/etc and download via direct link. Alternatively there are ways to make "self-extracting shell script" (attach binary archive to customize-image.sh) or encode archive contents in base64, etc.

[tkaiser]

We could add customisation hooks endlessly so that image creation might end up with every random result you could imagine.

 

But then you could also fork Armbian and adjust the scripts to your needs. Since if we open Pandora's box now so that everyone is able to adjust the list of default packages and every other aspect we run into a support nightmare (already there with a new user base lacking partially both patience and reading skills -- the Orange Pi folks)

 

But I agree that it would be useful to disable some automatic adjustments (firstrun). But we should find a more sane solution than now where most of this stuff is result of quick&dirty hacks (me being responsible for many/most of them ). I would appreciate discussing this topic in an open way without looking for 'fast results'

[Nick]

But I agree that it would be useful to disable some automatic adjustments (firstrun). But we should find a more sane solution than now where most of this stuff is result of quick&dirty hacks (me being responsible for many/most of them ). I would appreciate discussing this topic in an open way without looking for 'fast results'

This may not be the right thread for it, but what in particular would you like to disable if you had the option.

 

I know that my ideal Armbian would be one that creates the absolute minimum stable system with ethernet that I can them customise as I wish. Though Zador and I had a very brief discussion about this in another thread, where he did kindly make a change to the packaging so that it could be customised in lib.config. As Zador mentioned at the time though, one man's slimmed down is another man's bloated.

 

Here is the other thread if you are interested http://forum.armbian.com/index.php/topic/714-armbian-lib-kernel-packaging-absolute-minimum-bootstrap/ for my own purposes as much as anything I have toyed with the idea of forking Armbian, writing my own version, considered suggesting a barebones branch. Some of those may have merit especially if Armbian is heading down an end user rather than dev route (as it appears to be with user creation etc.), but for the moment I'm fairly happy other than with the H3 regression grr 

[zador.blood.stained]

This may not be the right thread for it, but what in particular would you like to disable if you had the option.

If I was trimming down firstrun script (or things happening after first boot in general), I would remove:

• Creation of swap file. Mainline kernel has zram/zswap support; for legacy kernel we could provide documentation on how to add swap file or partition of desired size.
• Updating packages list. Doesn't doo too much apart from loading CPU and delaying reboot after resize FS or autodetect (if reboot is needed).

[Nick]

• Creation of swap file. Mainline kernel has zram/zswap support; for legacy kernel we could provide documentation on how to add swap file or partition of desired size.
• Updating packages list. Doesn't doo too much apart from loading CPU and delaying reboot after resize FS or autodetect (if reboot is needed).

They both sound good to me, I'm not sure that I like the idea of swap files on SD cards anyway, I guess if you have a HDD attached it might be ok. That said, is it a good idea to have a small one as a get out of jail if you do use all of your physical RAM, or is the kernel pretty good at keeping a safe buffer anyway? I've not heard of zram/zswap so you may have to enlighten me there...

 

Again, updating packages list is in my situation at least handled by my code when I need it, so it wouldn't worry me if it came out of first boot.

[zador.blood.stained]

I've not heard of zram/zswap so you may have to enlighten me there...

Here: zram, zswap. TL;DR - instead of storing pages to disk, they can be compressed and stored back in RAM, which is cool and efficient if you don't need big swap space.

[Nick]

Here: zram, zswap. TL;DR - instead of storing pages to disk, they can be compressed and stored back in RAM, which is cool and efficient if you don't need big swap space.

Wow that is very cool, I like that alot!!

[chradev]

Hi guys,

 

You are right about endlessly customization but my needs for now are much close to current Armbian staff as is.

Fortunately or not, it is better to use Armbian code base as is following its mainline process with desired customization.

For me the project fork, copying files via network, script etc. are not options.

 

So let's me explain my fast and dirty solution that help me to continue.

 

In userpatches/customize-image.sh I added some staff like (more will be added):

    jessie)
    # Change network configuration to hostapd
    sed -i 's/DAEMON_CONF=/DAEMON_CONF=\/etc\/hostapd.conf/g' /etc/init.d/hostapd
    sed -i 's/ssid=SSID/ssid=egpr2/g' /etc/hostapd.conf
    ln -sf /etc/network/interfaces.hostapd /etc/network/interfaces
    # Remove annoying user creation at login
    rm -f /root/.not_logged_in_yet
    echo -e "password\npassword" | (passwd root)
    ;;

I added in lib/debootstrap.sh a single line:

source $SRC/userpatches/customize-distro.sh

after:

display_alert "Possible after install." "customize-image.sh" "info"

Next I created new userpatches/customize-distro.sh and put in it some staff like (more will be added):

# Add udev based auto mounting staff
cp $SRC/userpatches/misc/storage-automount.sh $DEST/cache/sdcard/lib/udev/
cp $SRC/userpatches/misc/storage-autounmount.sh $DEST/cache/sdcard/lib/udev/
cp $SRC/userpatches/misc/85-storage-automount.rules $DEST/cache/sdcard/etc/udev/rules.d/

Files to copy I put in userpatches/misc. Maybe later on I will reach some more limitations but it is enough for now.

 

For preserving single hook usage the staff:

cp $SRC/userpatches/customize-image.sh $DEST/cache/sdcard/tmp/customize-image.sh
chmod +x $DEST/cache/sdcard/tmp/customize-image.sh
chroot $DEST/cache/sdcard /bin/bash -c "/tmp/customize-image.sh $RELEASE $FAMILY $BOARD $BUILD_DESKTOP"
chroot $DEST/cache/sdcard /bin/bash -c "sync"

can be moved from lib/debootstrap.sh to new userpatches/customize-distro.sh.

 

About customizing of packet set PACKAGE_LIST_* can be overwritten in lib.config adding / removing needed / unnecessary staff.

 

In my opinion this use case will fit my customization needs tightly following mainline Armbian development process.

 

On the other hand I am definitely agree with "trimming down firstrun script" and leaving this actions to the user decision.

 

And finally, is it possible to rely on a small change (at least 1 additional line) described above about customization?

[Nick]

You are certainly doing something very similar to me.

I can see why you would want to be able to copy and it maybe that your situation requires it, but I thought I would just let you know how I tackled it and why.

 

I have setup my own apt-repo (possibly overkill for your needs, but equally not hard to do) by following this article https://www.debian-administration.org/article/286/Setting_up_your_own_APT_repository_with_upload_support

 

There were a few reasons for setting up the repo:

1. It solves the getting files into armbian problem
2. I have quite a few boards to manage so having one central location that is online 24/7 helps alot
3. apt handles all of the install, upgrading, dependency tracking etc. so whenever I need to upgrade my boards I just run apt update; apt upgrade (which is actually done with a cron script for auto upgrades)

I agree that it is alot of effort and if you only have 1 board, in which case your suggestion of adding customize-distro.sh might be worth it, but as soon as you have multiple boards with different versions of your packages etc. apt may actually be your friend.

 

FWIW I use customize-image.sh to pull in my repo key via wget and to add an extra file to /etc/apt/sources.d/ to include my repo.

[chradev]

Hi candratech,

 

It is good idea in case of having specifics you describe. Choosing Armbian was in competition with Yocto project which is on the other side as complexity and flexibility. It support own repositories for all packages and images built but it is quite complex for my needs.

 

Fortunately or not my use case is slightly different:

• single board (could be more in future but limited as number and close as HW)
• FW update will be based on complete SD image (not on packages)
• Armbian basically fits my needs as staff, configuration and supported boards
• customization needed is mainly in package set and configuration
• a set of data files have to be embedded in final images

That is why I prefer the simplest solution giving me the flexibility to produce final image(s) on demand using only third party packages (from Debian repositories) and produced on place once thanks to Armbian. If I heed of package to compile in future Armbian will make it possible as external one.

 

Of course, if the proposed change is not acceptable a fork is possible as exception but the feature offered is quite general and will make Armbian better as flexibility.

 

Should I issue it as a feature request?

[chradev]

Hi to All,

 

After proposed change for adding ability to add, replace and patch easier SD card files I tested successfully modified version of firstrun script:

• copy lib/scripts/firstrun to userpatches
• modify it (remove swap, package update, hostname change etc.)
• add to customize-distro.sh: cp $SRC/userpatches/firstrun $DEST/cache/sdcard/etc/init.d
• rebuild image, write it to SD and boot

and finally shorted to acceptable time it is needed to modify / deploy / test distribution changes.

[zador.blood.stained]

Anyway now it should be easier to copy files to rootfs: https://github.com/igorpecovnik/lib/commit/f300f20e273ec184809640dfcf7e2d8b889caa9a

[chradev]

Thanks a lot

Anyway now it should be easier to copy files to rootfs: https://github.com/igorpecovnik/lib/commit/f300f20e273ec184809640dfcf7e2d8b889caa9a

[Nick]

That looks good :-)

So am I right in thinking that anything I put into userpatches/overlay on the host will appear in /tmp/overlay inside the chroot therefore allowing customize_image.sh to copy things as required?

[zador.blood.stained]

So am I right in thinking that anything I put into userpatches/overlay on the host will appear in /tmp/overlay inside the chroot therefore allowing customize_image.sh to copy things as required?

Yes, exactly.

[chradev]

Hi to All,

 

Following Tido's tutorial I setup Armbian on Lime2 to work as router with Ethernet (eth0 at 100MB and dhcp) and bridged (br0 static ip) with eth0.2 and wlan0 (as AP). There is DHCP server setup to work over br0. IPtables are setup to forward between both networks.

 

/etc/network/interfeces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
    up /sbin/mii-tool -F 100baseTx-FD eth0
    # pre-up /sbin/mii-tool -F 100baseTx-FD eth0 # cannot get IP from dhcp

auto eth0.2
iface eth0.2 inet manual

auto wlan0
iface wlan0 inet manual

auto br0
iface br0 inet static
    bridge_ports eth0.2 wlan0
    address 192.168.2.1
    network 192.168.2.0
    netmask 255.255.255.0

/etc/iptables/iptables.rules was generated by

iptables -A FORWARD -i br0 -s 192.168.2.0/255.255.255.0 -j ACCEPT
iptables -A FORWARD -i eth0 -d 192.168.2.0/255.255.255.0 -j ACCEPT
iptables -A POSTROUTING -o eth0 -t nat -j MASQUERADE

Everything works fine if Lime2 Ethernet is connected to local network via 100MB switch (local network is connected to Internet via router with GB switch). All clients connected via AP on wlan0 get IP address from Lime2 DHCP and have Internet access.

 

First problem is rising when Lime2 Ethernet is connected directly to GB router's switch. While booting Ethernet starts at 1000MB speed (do not work because of Lime2 has a problem to work at 1000MB) then link goes down and then up at 100MB and finally Lime2 DHCP client succeeded to get IP from local network router.

 

I test different ways to setup Lime2 Ethernet to work at 100MB (using rc.local, init.d scrips) but situation stays the same. Using of pre-up instead of up in /etc/network/interfaces prevent Lime2 DHCP client to get IP at all.

 

Is there a way to setup Lime2 Ethernet to work at 100MB by default (without up / down / up sequence)?

 

Other problem rises if Lime2 Ethernet is connected to PC / Laptop instead of local network. My expectation is that connected on Lime2 Ethernet client will get IP from internal DHCP and will be able to communicate with Armbian on Lime2. Unfortunately, this is not happened even the both sides say the link is OK.

 

What is missing in this use case?

[chradev]

I will test it as soon as possible using all my staff copied in my way

Yes, exactly.

[Jens Bauer]

But I agree that it would be useful to disable some automatic adjustments (firstrun). But we should find a more sane solution than now where most of this stuff is result of quick&dirty hacks (me being responsible for many/most of them ). I would appreciate discussing this topic in an open way without looking for 'fast results'

 

Personally, I don't mind quick-and-dirty hacks. You've gotten a great high-quality distribution up in a very short time, so I can definitely live with those hacks, especially because Armbian (to me) is the most stable ARM based linux distribution I know of.

 

As for myself, I tend to write the image to a card, then I make a script mount and modify the image.

When done, I back up the image, so I can replicate it - not because I have hundreds of boxes, but I am messing with things a 100 times over, before I make the final installation, heh! 

[chradev]

Personally, I don't mind quick-and-dirty hacks. You've gotten a great high-quality distribution up in a very short time, so I can definitely live with those hacks, especially because Armbian (to me) is the most stable ARM based linux distribution I know of.

 

As for myself, I tend to write the image to a card, then I make a script mount and modify the image.

When done, I back up the image, so I can replicate it - not because I have hundreds of boxes, but I am messing with things a 100 times over, before I make the final installation, heh! 

 

It depends on time limitations and requirements for predictable and reproducible results.

 

In my case I get a time to modify, rebuild and boot (incl. first boot) the image less than 5 minutes without package set modification and 30-40 minutes with package set modification.

 

This is very important in case of big amount of modifications and tests.

 

On the other hand added change to customization scripts make it possible to keep track to all changes in a single file and ability to overwrite many files gives the possibility to customize everything easily.

 

Any way the feature is here thanks to zador.blood.stained and it is up to us to use it or not.

I have already take an advantage of using such an approach.

 

Thanks again zador.blood.stained.

[chradev]

Hi to All,

 

I run successfully RPI Monitor on Armbian / Kernel 3.4.110 / Lime 2 with customization for A20 as described in the forum threads.

Unfortunately, I have to install and customize it manually after running the image which is hard because of many builds have to be done.

How to change configuration build scripts for installing of RPI Monitor in Armbian build process?

 

On the other hand there is armbian/lib/scripts/armbianmonitor/ but it looks incomplete to support RPI Monitor.

Are there plans to embed by default in Armbian images RPI Monitor customized for Allwinner based boards?

 

Best regards

Chris

[tkaiser]

Since installation is just 'sudo armbianmonitor -r' in the meantime it should be able to install it as part of the image customisation. We also thought about building an own package and bundle it with Armbian but decided against. Please have a look at the whole thread: http://forum.armbian.com/index.php/topic/604-rfc-integrating-rpi-monitor-in-armbian/

 

The whole idea is to use armbianmonitor to setup monitoring and use armbianmonitor-daemon to collect the data. The latter will be bundled with a set of templates below /etc/armbianmonitor/templates/, uses config files below /etc/armbianmonitor/config/ (eg. disks.conf to configure disk monitoring) and collects data sources below /etc/armbianmonitor/datasources. This will be done by either using symlinks eg.

ln -fs /sys/devices/virtual/thermal/thermal_zone0/temp /etc/armbianmonitor/datasources/soctemp

or in continuous daemon mode. Then armbianmonitor-daemon queries for example the disk with GUID 2A56DAB5-1CA5-4803-910F-483F4646AB46 every minute and writes temperature (Temperature_Celsius), CRC errors (UDMA_CRC_Error_Count) and capacity (df output) to

/etc/armbianmonitor/datasources/2A56DAB5-1CA5-4803-910F-483F4646AB46-temp
/etc/armbianmonitor/datasources/2A56DAB5-1CA5-4803-910F-483F4646AB46-crcerrors
/etc/armbianmonitor/datasources/2A56DAB5-1CA5-4803-910F-483F4646AB46-capacity

In case this is the only disk 3 more symlinks will be created linking to these files: disktemp, diskcrcerrors and diskcapacity. Same with 1-wire thermal sensors for example. They can be queried using sysfs and create output like this:

root@raspberrypi: cat /sys/bus/w1/devices/10-000802cfb15d/w1_slave
33 00 4b 46 ff ff 02 10 f4 : crc=f4 YES
33 00 4b 46 ff ff 02 10 f4 t=25625

When configured to do so armbianmonitor-daemon will search for all slave devices, reads the output periodically (and drops readouts with CRC errors for example) and then creates one file each eg.

/etc/armbianmonitor/datasources/10-000802cfb15d-temp

containing the temperature value (in case only one sensor is present a symlink /etc/armbianmonitor/datasources/ambienttemp will be created). Same with DHT11/DHT22 and so on. Also based on the configuration and availalable data sources based on the templates we ship with below /etc/armbianmonitor/templates/ adopted templates ready to be included in a RPi-Monitor will be created by armbianmonitor-daemon at system start. So you can use them simply by linking RPi-Monitor's data.conf to /etc/armbianmonitor/rpi-monitor.conf or use the included templates individually (since you have setup RPi-Monitor already and only want to include the disk monitoring stuff for example).

 

This is still work in progress and not ready. I want to consolidate templates and configuration in a way that single templates per family (sun7i, sun8i, armada) can be shipped which can be used by RPi-Monitor directly but also contain config stuff for armbianmonitor-daemon already.

 

And BTW: with the most important stuff I haven't even started: SNMP. RPi-Monitor is nice when trying things out but to monitor a fleet of devices SNMP is the far better approach and this is also where the idea for /etc/armbianmonitor/datasources/ originates from: Providing everthing at the same location and being then able to use one single snmpd.conf on every board Armbian runs on. 

[chradev]

Thanks tkaiser,

 

This is very good staff planned to be added to Armbian. I will read carefully again discussions including the thread you point to.

As it is work in progress I suppose RPI Monitor and available customization is the best staff for the moment.

 

I will try to add armbianmonitor to the list of packages to install waiting to install RPI Monitor as dependency. But because armbianmonitor is already installed on the image without RPI Monitor I suppose that command 'armbianmonitor -r' has to be run from firstrun script. Unfortunately, I prefer RPI Monitor to be installed as a part of standard package installation process at image build.

 

Is it possible to add custom apt-get source lists like needed to install RPI Monitor while building the image without modifying Armbian code base?

[tkaiser]

 I suppose that command 'armbianmonitor -r' has to be run from firstrun script

 

Why? Please re-read my post before, think about https://github.com/igorpecovnik/lib/blob/master/documentation/geek-faq.md#user-provided-image-customization-scriptthen test and report back. 

[chradev]

Thanks tkaiser,

 

It will work I suppose. I will test it later after finishing battery test in progress.

[chradev]

Hi tkaiser,

 

Why? Please re-read my post before, think about https://github.com/igorpecovnik/lib/blob/master/documentation/geek-faq.md#user-provided-image-customization-scriptthen test and report back. 

 

Unfortunately, I reach a problem following your advice.

Running command 'armbianmonitor -r' from userpatches/customize-image.sh install RPI Monitor into the host even run it.

I have a filling that running apt-get from chroot is not safe and my test confirm it.

 

So is there a way to add links to apt-get source lists for being able to install RPI Monitor together with other packets?

[tkaiser]

Before I would start to search for the most complicated solution ever I would chdir into Armbian's lib dir on the build host and simply do a

grep apt-get * | grep chroot

to get the idea how to automate the necessary steps that are part of armbianmonitor's InstallRPiMonitor and PatchRPiMonitor_for_sun8i functions.