Armbian Ubuntu / Debian

[armbianParticipant]

[ Download ] (preview / beta / WIP image)

https://www.armbian.com/espressobin/

[ minimal server with powerful config and installer ]

[ Configuration ]

armbian-config

– wireless network connect,
– AP (hotspot) in bridged or NAT mode,
– freeze and unfreeze kernel and BSP upgrades,
– edit boot environment, network, FEX, welcome screen items,
– switching between available kernels and nightly builds,
– enabling read only root filesystem (Ubuntu only),
– set display resolution (H3 boards with legacy kernel),

[ Installation ]

– TV headend (IPTV server)
– Syncthing (personal cloud)
– SoftEther VPN server (VPN server)
– Transmission (torrent server)
– ISPConfig (WEB & MAIL server)
– Openmediavault NAS (NAS server)
– PI hole (ad blocker)
– MiniDLNA (media sharing)

[ Built with ]

https://github.com/armbian/build (Espressobin – currently under WIP, EXPERT_MODE=”on”)

[ Follow us on Twitter ]

https://twitter.com/armbian

[tom.iParticipant]

So wifi works without problem as well? Or are there any issues with HW or SW?
Because, I’m now on Ubuntu, and WIFI seems that doesn’t work properly, LAN connection has some small issue after boot, but I would like to use Armbian, but I don’t know, if all is working or not.

[armbianParticipant]

Armbian for this board is also still under development, since kernel is not matured yet. This is second build and I could not get any of my ath9 / ath10 mPCI wireless cards to work. USB ones should work … Hard to say if it’s any better than stock images. Probably it is, since it’s more recent build and configuration is expanded more, but don’t expect much if any difference at this stage. You are welcome to try out and report your findings. This way things got fixed sooner.

[tom.iParticipant]

It’s strange, but I can’t write Armbian IMG file to my SD card. Etcher doesn’t work for my distro(VoidLinux) – some weird message appears, so I’ve tried Etcher CLI, but it writes 1,5GB image in few seconds.

sudo ./etcher index.js -d /dev/sdg -y Armbian_5.32.170626_Espressobin_Ubuntu_xenial_default_4.4.73/Armbian_5.32.170626_Espressobin_Ubuntu_xenial_default_4.4.73.img                                                                                                                    
Flashing [========================] 100% eta 0s                                      
Validating [========================] 100% eta 0s                                    
Your flash is complete!                   
Checksum: 61a8e836

Of course, that it didn’t boot.
So I’ve tried to make 2 partitions. 100MB vfat and 2nd rest with ext4. To the 1st one I’ve put there basic booting files from EspressoBin (Image, armada-3720-community.dtb) and then use “dd” to copy IMG file to 2nd partition.
No luck, same problem no boot at all.
Am I doing this wrongly?

[armbianParticipant]

Image is tested and it boots – the only problem is that you need to alter SPI bootscript – use those commands to boot: https://github.com/armbian/build/blob/master/config/bootscripts/boot-espressobin.cmd

… but you have to get there first.

Alternatively you can use DD to write image, but it does not check writings. SD card failing rate is higher than you can imagine. If you want to save yourself a lot of time: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card

Armbian image has one single ext4 partition.

[tom.iParticipant]

@armbian – I like it, it works perfectly 😛
WIFI, LAN, CPU scaling – these I’ve tried yesterday
Is there any solution how to check sensors? Or have I to install lm-sensors package from repo? Because after start, there are some information from login script, that it shows temps of HDD and so on, so if there is existing program you Armbian guys using there can you tell me the name of it?
I’ve tried to check WIKI, but there are just some information.

And again, thx a lot @armbian for your help 😉

[armbianParticipant]

Thank you for trying out!

The core, kernel, is still considered as development and problems might / will show up. I didn’t catch many of them, but I read people had some unexplained issues with it.

We just started to deal with this board so I am not yet much familiar, but I think temperature sensors are not properly implemented or not implemented at all. Installing some application won’t help, since most likely the data is not in the standard place or not present at all … need to be investigated. Our script check standard locations, like those apps.

I didn’t have luck with my WiFi and this week I’ll proceed also with new kernel (4.12.x) to see how it works …

[armbianParticipant]

Support topic: https://forum.armbian.com/index.php?/topic/4089-espressobin-support-development-efforts/

[armbianParticipant]

https://dl.armbian.com/espressobin/

Added Debian Stretch testing image with kernel 4.4.82, added aufs support

[armbianParticipant]

– Debian Stretch or Ubuntu Xenial base
– possible to rebuild ATF, U-boot and kernel from sources
– updated ATF and u-boot binaries
– full docker support
– few ath9 wireless cards operational
– USB, SD and SATA boot tested
– many small improvements

@GlobalscaleTech @marvellsemi pwrd #EspressoBin #IoT #Docker ready #armbian Stretch testing images are ready 4 dl: https://t.co/q14TMCsomx pic.twitter.com/qYsuVjE2H0

— armbian (@armbian) October 4, 2017

[armbianParticipant]

GlobalscaleTech @marvellsemi pwrd #EspressoBin #IoT #Docker ready #armbian Stretch testing images are ready 4 dl: https://t.co/q14TMCsomx pic.twitter.com/OnDvWDAwqr

— armbian (@armbian) October 4, 2017

[misty-soulParticipant]

I just installed the Armbian distribution to my two EspressoBin boards.
After one or two hours tinkering with it, everything seems OK.

I have however one problem. I have two boards that are intended to be
on the same network with an existing router running LeDe that serves
DHCP. Despite the two boards have different MAC addresses for their
eth0 interfaces, they have exactly the same MAC address for their
br0 interface and it is this interface that gets the address from
the DHCP server. Since the server is configured to distribute
specific IP addresses based on the MAC address, I cannot recognize
which is which and set the correct IP for both boards.

I don’t know much about bridged interfaces, up to now I only had
to deal with single interface computers, so I did expect the eth0
MAC would be used and would get an IP.

How could I solve the confusion? Is it possible to specify a different
MAC for the br0 interface? I did not see anything relevant running
printenv in the uboot environment. I did see the setting of ethaddr,
but nothing else.

[misty-soulParticipant]

I forgot to say I used the nightly build: Debian server legacy kernel (Debian stretch).

[armbianParticipant]

I am sure MAC can be set for a bridge somehow but I would need to read about. We only have systemd defined network in Espressobin … Google for systemd related network settings … In any case, it’s up to you how you will define your network. Our (free) support ends here.

[misty-soulParticipant]

I read in the front page of the armbian.com page:
Become a part of our vibrant community, contribute ideas and have fun!

So I thought this was driven by community, open and helpful. Obviously, I was mistaken. Sorry for having asked a question.

Anyway, in case someone else faces the same problem, here is how I finally managed to solve it. It may
at least help someone else.

The bridge network configuration is split in two files used by systemd: /etc/systemd/network/10-br0.netdev
and /etc/systemd/network/10-br0.network. The first one could have a MACAddress= entry in a [NETDEV] section,
and the second could have a MACAddress= entry in a [LINK] section. I did not check if spoofing a new MAC
address in these files would work, as I found something that worried me more. The manpage for systemd.netdev
reads, in the part concerning the MACAddress= entry in the [NETDEV] section:

If none is given, one is generated based on the interface name and the machine-id(5)

Looking at the /etc/machine-id file, it appeared this file was present in the image provided by Armbian
and was not regenerated at first install. This file should be generated at first install using the command
systemd-machine-id-setup, which in fact itself starts by looking for a D-Bus machine-id. Then, looking at
/var/lib/dbus/machine-id, this file was also already present in armbian image and contained the exact
same value. So I think all machines using this image share the same id. It is weird for an id
that is supposed to be unique…

Then looking at the manpage for dbus-uuidgen, it says that the D-Bus machine-id should not be changed on
a running machine or as they write: it will probably result in bad things happening. The machine-id
should remain constant at least until next reboot.

So at the end, I had to:

1. remove the SD card from the EspressoBin,
2. mount it on a different Linux system
3. delete /the/mounting/point/var/lib/dbus/machine-id
4. generate a random new machine id using dbus-uuidgen –ensure=/the/mounting/point/var/lib/dbus/machine-id
5. copy /the/mounting/point/var/lib/dbus/machine-id to /the/mounting/point/etc/machine-id
6. put the SD card back to the EspressoBin
7. use serial console to get the newly generated MAC address for br0
8. use this MAC address in the dnsmasq configuration of my LeDe router

Of course, I did this twice, once for each EspressoBin board. Now, I am sure not only the MAC address
are different, but also that the machine-id are also different. I could not set up the dnsmasq
configuration before a first boot of the EspressoBin because I don’t know how the MAC address is
derived from the interface name and the machine-id. So I had to boot once first and just look
at the br0 address.

I consider this to be a bug in the Armbian image.

[Author]

Posts