Jump to content

Recommended Posts

Posted

Does anyone know, what is causing the following error message?

sdhci_transfer_data: Error detected in status(0x2008000)!                                                             
Error reading cluster                                        
** Unable to read file armada-3720-espressobin.dtb **

 

Posted

Hello,

 

First, thanks for your time in creating and managing armbian :)

 

It will be great if cryptsetup work "out of the box"  (without rebuilding your own kernel) (at least in devel ;)).

At the present time, I can't mount any encrypted partition because some options are missing in the kernel.

I think the kernel option "CONFIG_CRYPTO_USER_API_SKCIPHER" is needed.

The module dm_mod.ko is also needed but I can't find which option(s) creates it (it's the device mapper module).

 

 

It will be also great if we can try the CESA code since the option seems here (CONFIG_CRYPTO_DEV_MARVELL_CESA)  , so we can test it :)

 

I paste below the results of my simple tests.

 

Quote

root@espressobin:~# uname  -a
Linux espressobin 4.16.15-mvebu64 #152 SMP PREEMPT Tue Jun 12 01:48:50 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
root@espressobin:~# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       121362 iterations per second
PBKDF2-sha256      74898 iterations per second
PBKDF2-sha512      68337 iterations per second
PBKDF2-ripemd160  108683 iterations per second
PBKDF2-whirlpool   24380 iterations per second
Required kernel crypto interface not available.
Ensure you have algif_skcipher kernel module loaded.
root@espressobin:~# dd if=/dev/zero of=/run/test bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0315174 s, 333 MB/s
root@espressobin:~# cryptsetup open --type plain /run/test test
Enter passphrase: 
Cannot initialize device-mapper. Is dm_mod kernel module loaded?
root@espressobin:~# cryptsetup luksFormat --type luks2 /run/test

WARNING!
========
This will overwrite data on /run/test irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase: 
Verify passphrase: 
Cannot initialize device-mapper. Is dm_mod kernel module loaded?

 

Posted (edited)
17 hours ago, briaeros said:

First, thanks for your time in creating and managing armbian :)

 

It will be great if cryptsetup work "out of the box"  (without rebuilding your own kernel) (at least in devel ;)).

 

Thank you! But only together we can manage with the complexity :) If any kernel config changes are needed, we urge people to send PR against build engine. You can find Espressobin, kernel family mvebu64, configurations here: https://github.com/armbian/build/tree/master/config/kernel ... and general howto here: https://docs.armbian.com/Process_Contribute/

 

Changes lands to the beta.armbian.com package repository in less than 24h if all kernels building succeeded.

 

Try.

Edited by Igor
typo
Posted
On 6/15/2018 at 8:01 PM, briaeros said:

It will be also great if we can try the CESA code since the option seems here (CONFIG_CRYPTO_DEV_MARVELL_CESA)  , so we can test it :)

 

The 5Gbps Security Engine of the Espressoin is not CESA compatible. It needs a specific driver implemented by Bootlin in kernel 4.16:

 

Quote

The driver currently supports:

Hashes: sha1, hmac(sha1), sha224, sha256.
Ciphers: ecb(aes), cbc(aes).

This allows to offload some IPsec connexions, depending on the
configuration, as these algs can be combined by the crypto layer.

More algs are coming, but there is no schedule for them.

 

Posted
4 hours ago, ebin-dev said:

 

The 5Gbps Security Engine of the Espressoin is not CESA compatible. It needs a specific driver implemented by Bootlin in kernel 4.16:

 

 

Thanks for the correction. I don't remember where I read that it was CESA. An untrustworthy source certainly.

 

safeexecel is already compiled as a module. I will then try to make it works with my espresso ;)

 

Posted

Hi,

 

This read is getting a bit too long and thus it is getting hard to find information in it. Am up for helping on extracting some of the information here and compiling it in a wiki or other type of shared document to help the espressobin community. Anyone else think this is a good idea ? And maybe new threads per subject could be openned ? Does this forum have a habit of using the lock feature on posts that are too long ?

 

By the way, I've asked a question about "[Espressobin] Transparent monitoring switch - ethernet bridge and hardware questions" that might interest some of the espressobin owners.

 

Posted
10 minutes ago, arthurlutz said:

This read is getting a bit too long and thus it is getting hard to find information in it.


It's planned to create a separate forum for Armada powered devices, it's planned to upgrade a kernel for Espresso ... but we extremely lack time/resources for that. If you volunteer to get this forum mess in order by taking moderator duties and move topics into new subforum/in order ... this problem might be already solved. The offer contains editorial rights for this: https://www.armbian.com/espressobin/

Posted

On Armbian_5.50_Espressobin_Debian_stretch_next_4.17.3 (either clean install or upgrade) , there is an issue with the network when both lan ports are connected to the same router. This was not the case in the previous (5.44) image.

Demsg is flooded with:

br0: received packet on lan1 with own address as source address (addr:XX:XX:XX:XX:XX:XX, vlan:0)
br0: received packet on lan0 with own address as source address (addr:XX:XX:XX:XX:XX:XX, vlan:0)

and the bridge does not come up.

By the way, has anyone any working bonding setup for lan0 & lan1?

 

Posted

You're effectively introducing a layer2 switch loop when plugging them both in. It was mostly good fortune when it worked previously.


Unfortunately because of the way the espressobin's onboard switch connects to the cpu (sgmi) peak network io to cpu would be 1 gig.


There's dialog about the espressobin's network limitations earlier in the thread. Its kind of a bummer for sure.

On Armbian_5.50_Espressobin_Debian_stretch_next_4.17.3 (either clean install or upgrade) , there is an issue with the network when both lan ports are connected to the same router. This was not the case in the previous (5.44) image.
Demsg is flooded with:
br0: received packet on lan1 with own address as source address (addr:XX:XX:XX:XX:XX:XX, vlan:0)br0: received packet on lan0 with own address as source address (addr:XX:XX:XX:XX:XX:XX, vlan:0)

and the bridge does not come up.
By the way, has anyone any working bonding setup for lan0 & lan1?
 



Sent from my SM-G950U using Tapatalk

Posted

For those who want to run at 1.2ghz, if you have not noticed you need this:

https://marc.info/?l=linux-arm-kernel&m=152941191324122&w=2

Posted

I've discovered more bugs in the current Armbian build, which, I believe, was inherited from Debian 9 and the network card buggy driver.

1) is related with the segmentation-offload, which is pretty well reproducible :

root@espressobin:~# tcpdump -ni any -s100 -vvv port 53
27.49.62.17.52256 > 212.27.40.240.53: [bad udp cksum 0x5932 -> 0x332d!] 33775+% [1au] DS? akamaiedge.net. ar: . OPT UDPsize=4096 DO (43)

2) was very difficult to figure out, and the solution is not yet clear. It appears, that systemd-network is not properly handling the ipv4 and ipv6 renewals, which results in the wan network access failure periodically on the ISP ip lease renewal. It was very annoying and caused serious argues with the ISP support. The last working hypothesis is that the ipv6 Router Advertisement causes the networkd-[iface] service to fail and therefore the dhcpv4 client is killed too.

3) I also experienced the trouble with the wan interface automatic start up at boot time. Many experience it as well, which also looks to be a systemd-network trouble. It should work out of the box, but at the current state, the end-user has to adjust those setbacks with additional custom-made services or rc.local commads.

 

Posted
On 7/9/2018 at 7:18 PM, Igor said:

For those who want to run at 1.2ghz, if you have not noticed you need this:

https://marc.info/?l=linux-arm-kernel&m=152941191324122&w=2

 apt update & upgrade will also do :)

https://github.com/armbian/upload/commit/553477df85dfdd33810d1536409d62bd3a4cb789

This is quite encouraging to finally get the so much advertised CPU clocking.  Has this patch been implemented to the legacy kernel as well? Should the u-boot flash be updated at the same time?

Posted
7 hours ago, y52 said:

Has this patch been implemented to the legacy kernel as well?


No. I am not sure we want to waste time with that kernel. Feel free to test and submit a patch. I can't.
 

7 hours ago, y52 said:

Should the u-boot flash be updated at the same time?


(correct) U-boot (for your board) should be updated in any case.

Posted
23 minutes ago, Igor said:

>Has this patch been implemented to the legacy kernel as well?

No. I am not sure we want to waste time with that kernel. Feel free to test and submit a patch. I can't.

This is sad.  My board just doesn't stay stable with the "-next" kernel, although I wanted to migrate to it. In my case, the board stability also depends significantly on the .dtb file as well. It appears, that the only stable configuration is the legacy kernel and the 

# DTB submitted by GlobalScaleTech. Stable.
setenv fdt_name_a boot/dtb/marvell/armada-3720-community-v5.dtb
# DTB submitted by Armbian. Unstable.
#setenv fdt_name_a boot/dtb/marvell/armada-3720-community.dtb

 

Anyway, I can still try the "-next" kernel again with the new patch. Should I understand it correctly, that the "1.2ghz" is already implemented in the "next tree" ?

 

Pls confirm the algorithm to migrate from the legacy tree to the  "next tree" under "1.2ghz".

If I understand it, the following procedure should be applied:

1.  apt update & upgrade with the current  legacy 4.4.138-mvebu64 kernel

2.  armbian-config -> system -> switch to alternative kernel -> next

3.  1200 Mhz u-boot flashing

4. reboot with 1200 Mhz CPU clock under the  "next tree" kernel.

Should anything else be done?

Posted
2 minutes ago, y52 said:

This is sad.  My board just doesn't stay stable with the "-next" kernel


I am also sad, but for other reasons. Remember. This is not a professional support service and I need to save our resources to be able to work on things that make us happy.

 

The same you need to do on a legacy kernel: https://github.com/armbian/build/commit/5823d40016d2fd522dba5f75af2ec14bfc6986a3 

But implementation might be different and perhaps you will need to adjust patches. Then you need to build and test. One could lose an hour or a day.  If you are unable to do this, hire someone.
 

8 minutes ago, y52 said:

Should anything else be done?


1 & 2 yes

3 & 4 follow the procedure written at the download page. Flash u-boot with correct numbers. 1200Mhz tells me nothing at this point. Just don't go with higher numbers than what you have now and expect that the board will boot and be stable.

Posted
On 4/15/2018 at 7:11 PM, ebin-dev said:

 

Debian server - mainline kernel - make sure you are on the stable branch and update your system with 'apt-get update && apt-get upgrade'.

Using Ubuntu, I just found out during the last three days that if I do a fresh install of 5.50 on my EspressoBIN and as the first thing issue apt-get update && apt-get upgrade, followed by a reboot, then the network will never come up and I'll have to log in using a serial console.

Posted
1 hour ago, Jens Bauer said:

Using Ubuntu, I just found out during the last three days that if I do a fresh install of 5.50 on my EspressoBIN and as the first thing issue apt-get update && apt-get upgrade, followed by a reboot, then the network will never come up and I'll have to log in using a serial console.

Do you have the same problem with Debian - mainline/stable ?

If not - then the issue is very likely caused by the systemd-networkd implementation chosen by Ubuntu ...

Posted
5 hours ago, ebin-dev said:

Do you have the same problem with Debian - mainline/stable ?

 If not - then the issue is very likely caused by the systemd-networkd implementation chosen by Ubuntu ...

I haven't tried debian - and I do not have much time on my hand, because my server needs to be set up completely within a few days, as I'm going back home. Sadly, it seems the Ubuntu I'm running does not allow me to "reboot" without hanging, so I can't maintain much via SSH from home (because it'll cost me 6 hours to travel each way plus around $200, which I currently cannot afford). -I just thought I'd like to mention this, so that others will have fewer problems and the maintainers may know about it.

Posted
5 hours ago, ebin-dev said:

Do you have the same problem with Debian - mainline/stable ?

 If not - then the issue is very likely caused by the systemd-networkd implementation chosen by Ubuntu ...

 

Yesterday, I recorded the commands and the outputs ...

Spoiler

$ uname -a
Linux espressobin 4.17.3-mvebu64 #7 SMP PREEMPT Thu Jun 28 18:21:11 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
# apt-get update
...
(network is still alive)
...
# reboot
...
(network is still alive)
...
# apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  apt apt-transport-https apt-utils cpp-5 dnsmasq-base g++-5 gcc-5 gcc-5-base libapt-inst2.0 libapt-pkg5.0 libasan2
  libatomic1 libcc1-0 libgcc-5-dev libgomp1 libitm1 libpng12-0 libsoup2.4-1 libstdc++-5-dev libstdc++6 libubsan0
  linux-dtb-next-mvebu64 linux-image-next-mvebu64 linux-libc-dev ntp rfkill
26 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 35.1 MB of archives.
After this operation, 177 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://apt.armbian.com xenial/main arm64 linux-dtb-next-mvebu64 arm64 5.51 [9,844 B]
Get:2 http://ports.ubuntu.com xenial-security/main arm64 libgomp1 arm64 5.4.0-6ubuntu1~16.04.10 [45.9 kB]
Get:3 http://apt.armbian.com xenial/main arm64 linux-image-next-mvebu64 arm64 5.51 [13.8 MB]
Get:4 http://ports.ubuntu.com xenial-security/main arm64 libitm1 arm64 5.4.0-6ubuntu1~16.04.10 [23.9 kB]
Get:5 http://ports.ubuntu.com xenial-security/main arm64 libatomic1 arm64 5.4.0-6ubuntu1~16.04.10 [6,384 B]
Get:6 http://ports.ubuntu.com xenial-security/main arm64 libasan2 arm64 5.4.0-6ubuntu1~16.04.10 [229 kB]
Get:7 http://ports.ubuntu.com xenial-security/main arm64 libubsan0 arm64 5.4.0-6ubuntu1~16.04.10 [84.4 kB]
Get:8 http://ports.ubuntu.com xenial-security/main arm64 g++-5 arm64 5.4.0-6ubuntu1~16.04.10 [4,928 kB]
Get:9 http://ports.ubuntu.com xenial-security/main arm64 gcc-5 arm64 5.4.0-6ubuntu1~16.04.10 [5,278 kB]
Get:10 http://ports.ubuntu.com xenial-security/main arm64 cpp-5 arm64 5.4.0-6ubuntu1~16.04.10 [4,537 kB]
Get:11 http://ports.ubuntu.com xenial-security/main arm64 libcc1-0 arm64 5.4.0-6ubuntu1~16.04.10 [27.2 kB]
Get:12 http://ports.ubuntu.com xenial-security/main arm64 libstdc++-5-dev arm64 5.4.0-6ubuntu1~16.04.10 [1,380 kB]
Get:13 http://ports.ubuntu.com xenial-security/main arm64 libgcc-5-dev arm64 5.4.0-6ubuntu1~16.04.10 [490 kB]
Get:14 http://ports.ubuntu.com xenial-security/main arm64 gcc-5-base arm64 5.4.0-6ubuntu1~16.04.10 [17.4 kB]
Get:15 http://ports.ubuntu.com xenial-security/main arm64 libstdc++6 arm64 5.4.0-6ubuntu1~16.04.10 [362 kB]
Get:16 http://ports.ubuntu.com xenial-updates/main arm64 libapt-pkg5.0 arm64 1.2.27 [652 kB]
Get:17 http://ports.ubuntu.com xenial-updates/main arm64 libapt-inst2.0 arm64 1.2.27 [54.4 kB]
Get:18 http://ports.ubuntu.com xenial-updates/main arm64 apt arm64 1.2.27 [1,017 kB]         
Get:19 http://ports.ubuntu.com xenial-updates/main arm64 apt-utils arm64 1.2.27 [188 kB]
Get:20 http://ports.ubuntu.com xenial-security/main arm64 ntp arm64 1:4.2.8p4+dfsg-3ubuntu5.9 [465 kB]
Get:21 http://ports.ubuntu.com xenial-security/main arm64 libpng12-0 arm64 1.2.54-1ubuntu1.1 [106 kB]
Get:22 http://ports.ubuntu.com xenial-updates/main arm64 apt-transport-https arm64 1.2.27 [24.5 kB]
Get:23 http://ports.ubuntu.com xenial-security/main arm64 dnsmasq-base arm64 2.75-1ubuntu0.16.04.5 [265 kB]
Get:24 http://ports.ubuntu.com xenial-security/main arm64 libsoup2.4-1 arm64 2.52.2-1ubuntu0.3 [224 kB]
Get:25 http://ports.ubuntu.com xenial-security/main arm64 linux-libc-dev arm64 4.4.0-130.156 [838 kB]
Get:26 http://ports.ubuntu.com xenial-updates/main arm64 rfkill arm64 0.5-1ubuntu3.1 [8,374 B]
Fetched 35.1 MB in 3s (9,688 kB/s)                                                    
(Reading database ... 28772 files and directories currently installed.)
Preparing to unpack .../libgomp1_5.4.0-6ubuntu1~16.04.10_arm64.deb ...
Unpacking libgomp1:arm64 (5.4.0-6ubuntu1~16.04.10) over (5.4.0-6ubuntu1~16.04.9) ...
Preparing to unpack .../libitm1_5.4.0-6ubuntu1~16.04.10_arm64.deb ...
Unpacking libitm1:arm64 (5.4.0-6ubuntu1~16.04.10) over (5.4.0-6ubuntu1~16.04.9) ...
Preparing to unpack .../libatomic1_5.4.0-6ubuntu1~16.04.10_arm64.deb ...
Unpacking libatomic1:arm64 (5.4.0-6ubuntu1~16.04.10) over (5.4.0-6ubuntu1~16.04.9) ...
Preparing to unpack .../libasan2_5.4.0-6ubuntu1~16.04.10_arm64.deb ...
Unpacking libasan2:arm64 (5.4.0-6ubuntu1~16.04.10) over (5.4.0-6ubuntu1~16.04.9) ...
Preparing to unpack .../libubsan0_5.4.0-6ubuntu1~16.04.10_arm64.deb ...
Unpacking libubsan0:arm64 (5.4.0-6ubuntu1~16.04.10) over (5.4.0-6ubuntu1~16.04.9) ...
Preparing to unpack .../g++-5_5.4.0-6ubuntu1~16.04.10_arm64.deb ...
Unpacking g++-5 (5.4.0-6ubuntu1~16.04.10) over (5.4.0-6ubuntu1~16.04.9) ...
Preparing to unpack .../gcc-5_5.4.0-6ubuntu1~16.04.10_arm64.deb ...
Unpacking gcc-5 (5.4.0-6ubuntu1~16.04.10) over (5.4.0-6ubuntu1~16.04.9) ...
Preparing to unpack .../cpp-5_5.4.0-6ubuntu1~16.04.10_arm64.deb ...
Unpacking cpp-5 (5.4.0-6ubuntu1~16.04.10) over (5.4.0-6ubuntu1~16.04.9) ...
Preparing to unpack .../libcc1-0_5.4.0-6ubuntu1~16.04.10_arm64.deb ...
Unpacking libcc1-0:arm64 (5.4.0-6ubuntu1~16.04.10) over (5.4.0-6ubuntu1~16.04.9) ...
Preparing to unpack .../libstdc++-5-dev_5.4.0-6ubuntu1~16.04.10_arm64.deb ...
Unpacking libstdc++-5-dev:arm64 (5.4.0-6ubuntu1~16.04.10) over (5.4.0-6ubuntu1~16.04.9) ...
Preparing to unpack .../libgcc-5-dev_5.4.0-6ubuntu1~16.04.10_arm64.deb ...
Unpacking libgcc-5-dev:arm64 (5.4.0-6ubuntu1~16.04.10) over (5.4.0-6ubuntu1~16.04.9) ...
Preparing to unpack .../gcc-5-base_5.4.0-6ubuntu1~16.04.10_arm64.deb ...
Unpacking gcc-5-base:arm64 (5.4.0-6ubuntu1~16.04.10) over (5.4.0-6ubuntu1~16.04.9) ...
Processing triggers for libc-bin (2.23-0ubuntu10) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up gcc-5-base:arm64 (5.4.0-6ubuntu1~16.04.10) ...
(Reading database ... 28772 files and directories currently installed.)
Preparing to unpack .../libstdc++6_5.4.0-6ubuntu1~16.04.10_arm64.deb ...
Unpacking libstdc++6:arm64 (5.4.0-6ubuntu1~16.04.10) over (5.4.0-6ubuntu1~16.04.9) ...
Processing triggers for libc-bin (2.23-0ubuntu10) ...
Setting up libstdc++6:arm64 (5.4.0-6ubuntu1~16.04.10) ...
Processing triggers for libc-bin (2.23-0ubuntu10) ...
(Reading database ... 28772 files and directories currently installed.)
Preparing to unpack .../libapt-pkg5.0_1.2.27_arm64.deb ...
Unpacking libapt-pkg5.0:arm64 (1.2.27) over (1.2.26) ...
Processing triggers for libc-bin (2.23-0ubuntu10) ...
Setting up libapt-pkg5.0:arm64 (1.2.27) ...
Processing triggers for libc-bin (2.23-0ubuntu10) ...
(Reading database ... 28772 files and directories currently installed.)
Preparing to unpack .../libapt-inst2.0_1.2.27_arm64.deb ...
Unpacking libapt-inst2.0:arm64 (1.2.27) over (1.2.26) ...
Preparing to unpack .../archives/apt_1.2.27_arm64.deb ...
Unpacking apt (1.2.27) over (1.2.26) ...
Processing triggers for libc-bin (2.23-0ubuntu10) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up apt (1.2.27) ...
Installing new version of config file /etc/apt/apt.conf.d/01autoremove ...
Processing triggers for libc-bin (2.23-0ubuntu10) ...
(Reading database ... 28772 files and directories currently installed.)
Preparing to unpack .../apt-utils_1.2.27_arm64.deb ...
Unpacking apt-utils (1.2.27) over (1.2.26) ...
Preparing to unpack .../ntp_1%3a4.2.8p4+dfsg-3ubuntu5.9_arm64.deb ...
Unpacking ntp (1:4.2.8p4+dfsg-3ubuntu5.9) over (1:4.2.8p4+dfsg-3ubuntu5.8) ...
Preparing to unpack .../libpng12-0_1.2.54-1ubuntu1.1_arm64.deb ...
Unpacking libpng12-0:arm64 (1.2.54-1ubuntu1.1) over (1.2.54-1ubuntu1) ...
Preparing to unpack .../apt-transport-https_1.2.27_arm64.deb ...
Unpacking apt-transport-https (1.2.27) over (1.2.26) ...
Preparing to unpack .../dnsmasq-base_2.75-1ubuntu0.16.04.5_arm64.deb ...
Unpacking dnsmasq-base (2.75-1ubuntu0.16.04.5) over (2.75-1ubuntu0.16.04.4) ...
Preparing to unpack .../libsoup2.4-1_2.52.2-1ubuntu0.3_arm64.deb ...
Unpacking libsoup2.4-1:arm64 (2.52.2-1ubuntu0.3) over (2.52.2-1ubuntu0.2) ...
Preparing to unpack .../linux-dtb-next-mvebu64_5.51_arm64.deb ...
Unpacking linux-dtb-next-mvebu64 (5.51) over (5.50) ...
Preparing to unpack .../linux-image-next-mvebu64_5.51_arm64.deb ...
update-initramfs: Deleting /boot/initrd.img-4.17.3-mvebu64
Removing obsolete file uInitrd-4.17.3-mvebu64
Unpacking linux-image-next-mvebu64 (5.51) over (5.50) ...
Preparing to unpack .../linux-libc-dev_4.4.0-130.156_arm64.deb ...
Unpacking linux-libc-dev:arm64 (4.4.0-130.156) over (4.4.0-128.154) ...
Preparing to unpack .../rfkill_0.5-1ubuntu3.1_arm64.deb ...
Unpacking rfkill (0.5-1ubuntu3.1) over (0.5-1ubuntu3) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for systemd (229-4ubuntu21.2) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for libc-bin (2.23-0ubuntu10) ...
Processing triggers for dbus (1.10.6-1ubuntu3.3) ...
Setting up libgomp1:arm64 (5.4.0-6ubuntu1~16.04.10) ...
Setting up libitm1:arm64 (5.4.0-6ubuntu1~16.04.10) ...
Setting up libatomic1:arm64 (5.4.0-6ubuntu1~16.04.10) ...
Setting up libasan2:arm64 (5.4.0-6ubuntu1~16.04.10) ...
Setting up libubsan0:arm64 (5.4.0-6ubuntu1~16.04.10) ...
Setting up cpp-5 (5.4.0-6ubuntu1~16.04.10) ...
Setting up libcc1-0:arm64 (5.4.0-6ubuntu1~16.04.10) ...
Setting up libgcc-5-dev:arm64 (5.4.0-6ubuntu1~16.04.10) ...
Setting up gcc-5 (5.4.0-6ubuntu1~16.04.10) ...
Setting up libstdc++-5-dev:arm64 (5.4.0-6ubuntu1~16.04.10) ...
Setting up g++-5 (5.4.0-6ubuntu1~16.04.10) ...
Setting up libapt-inst2.0:arm64 (1.2.27) ...
Setting up apt-utils (1.2.27) ...
Setting up ntp (1:4.2.8p4+dfsg-3ubuntu5.9) ...
Setting up libpng12-0:arm64 (1.2.54-1ubuntu1.1) ...
Setting up apt-transport-https (1.2.27) ...
Setting up dnsmasq-base (2.75-1ubuntu0.16.04.5) ...
Setting up libsoup2.4-1:arm64 (2.52.2-1ubuntu0.3) ...
Setting up linux-dtb-next-mvebu64 (5.51) ...
Setting up linux-image-next-mvebu64 (5.51) ...
update-initramfs: Generating /boot/initrd.img-4.17.5-mvebu64
update-initramfs: Converting to u-boot format
Setting up linux-libc-dev:arm64 (4.4.0-130.156) ...
Setting up rfkill (0.5-1ubuntu3.1) ...
Processing triggers for libc-bin (2.23-0ubuntu10) ...
...
(network is still alive)
...
# ifconfig -a | grep addr
bond0     Link encap:Ethernet  HWaddr 8e:60:4a:5a:7b:5b  
br0       Link encap:Ethernet  HWaddr ca:cb:1d:1d:a2:c3  
          inet addr:10.0.2.202  Bcast:10.0.255.255  Mask:255.255.0.0
          inet6 addr: fe80::c8cb:1dff:fe1d:a2c3/64 Scope:Link
dummy0    Link encap:Ethernet  HWaddr 7a:1f:6e:9b:f7:ef  
eth0      Link encap:Ethernet  HWaddr f0:ad:4e:03:64:7f  
          inet6 addr: fe80::f2ad:4eff:fe03:647f/64 Scope:Link
lan0      Link encap:Ethernet  HWaddr f0:ad:4e:03:64:7f  
lan1      Link encap:Ethernet  HWaddr f0:ad:4e:03:64:7f  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
wan       Link encap:Ethernet  HWaddr f0:ad:4e:03:64:7f  
...
(network is still alive)
...
# reboot
...
(network never comes online, I have to log in via serial console and re-install armbian)
...
$ uname -a
Linux espressobin 4.17.3-mvebu64 #7 SMP PREEMPT Thu Jun 28 18:21:11 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

-All I can see about systemd is 'processing triggers for systemd', so I'm not sure systemd is at fault directly.

I can see a lot of library updates, so I would expect that this could be caused by an updated library that systemd is using.

-only a simple guess, though.

Posted
6 hours ago, Jens Bauer said:

the issue is very likely caused by the systemd-networkd implementation

systemd remains quite buggy. I try finding workarounds for it's different issues.

I suggest modifying as follows the

/lib/systemd/system/systemd-networkd.service

 

[Service]
Type=notify
Restart=on-failure
RestartSec=0
# https://www.toradex.com/community/questions/1144/weird-behavior-when-restarting-networkd.html
ExecStartPre=/sbin/ip addr flush dev wan
ExecStartPre=/sbin/ip link set wan down
ExecStartPre=/sbin/ip link set wan up
ExecStart=!!/lib/systemd/systemd-networkd

 

 

There is also a bad behavior in inability acquiring the DHCPv6 lease when hot restarting the systemd-networkd without rebooting.

Where could kernel configs (for mainline and legacy trees) be found to double check if the following settings are similar as below ?

-# CONFIG_IPV6_MULTIPLE_TABLES is not set
+CONFIG_IPV6_MULTIPLE_TABLES=y
-# CONFIG_IPV6_MROUTE_MULTIPLE_TABLES is not set
+CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y

 

 

 

Posted

Am I missing something?

I tried to install wireguard in the prebuild images but i failed using the linux-headers-next-mvebu64 package.

Today I compiled a mainline image with headers installed but I still fail to install wireguard. Here is the log

Spoiler

root@espressobin:cat /var/lib/dkms/wireguard/0.0.20180708-1/build/make.log
DKMS make.log for wireguard-0.0.20180708-1 for kernel 4.17.7-mvebu64 (aarch64)
Τετ 18 Ιούλ 2018 02:22:32 πμ EEST
make: Entering directory '/usr/src/linux-headers-4.17.7-mvebu64'
Makefile:637: arch//Makefile: No such file or directory
make: *** No rule to make target 'arch//Makefile'.  Stop.
make: Leaving directory '/usr/src/linux-headers-4.17.7-mvebu64'

 

I have read in this that we need to call make scripts. Here is the output

Spoiler

root@espressobin:/usr/src/linux-headers-4.17.7-mvebu64# make scripts
  CHK     scripts/mod/devicetable-offsets.h
root@espressobin:/usr/src/linux-headers-4.17.7-mvebu64# make prepare scripts
  CHK     include/config/kernel.release
  UPD     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  UPD     include/generated/utsrelease.h
scripts/Kbuild.include:103: warning: overriding recipe for target '.cache.mk'
scripts/Kbuild.include:103: warning: ignoring old recipe for target '.cache.mk'
make[1]: *** No rule to make target 'arch/arm64/kernel/vdso/gettimeofday.S', needed by 'arch/arm64/kernel/vdso/gettimeofday.o'.  Stop.
arch/arm64/Makefile:163: recipe for target 'vdso_prepare' failed
make: *** [vdso_prepare] Error 2

 

Edit: Diagnostics

 

Posted
9 hours ago, Igor said:

Try without DKMS.
 

Compilation from source also not working:

Spoiler

dlaptop@espressobin:~/Downloads/WireGuard/src$ make debug
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (                \
echo >&2;                                                       \
echo >&2 "  ERROR: Kernel configuration is invalid.";           \
echo >&2 "         include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it.";

root@espressobin:/usr/src/linux-headers-4.17.7-mvebu64# make oldconfig && make prepare
scripts/kconfig/conf  --oldconfig Kconfig
#
# configuration written to .config
#
scripts/kconfig/conf  --syncconfig Kconfig
  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
scripts/Kbuild.include:103: warning: overriding recipe for target '.cache.mk'
scripts/Kbuild.include:103: warning: ignoring old recipe for target '.cache.mk'
make[1]: *** No rule to make target 'arch/arm64/kernel/vdso/gettimeofday.S', needed by 'arch/arm64/kernel/vdso/gettimeofday.o'.  Stop.
arch/arm64/Makefile:163: recipe for target 'vdso_prepare' failed
make: *** [vdso_prepare] Error 2

 

 

 

Posted

 

3 minutes ago, lampra said:

Compilation from source also not working:


Headers are not source. We pack kernel source but don't upload it to the repository due to space limits.

 

So far I don't see any problem on Armbian side except DKMS might be broken ... but that is not essential to compile a module.

Posted
3 minutes ago, Igor said:

Headers are not source. We pack kernel source but don't upload it to the repository due to space limits.

So far I don't see any problem on Armbian side except DKMS might be broken ... but that is not essential to compile a module.

Well the module is compiled and installation finishes but when I am trying to use wireguard it fails and the output seems to point to wrong or missing kernel headers

# wg-quick up wg0
[#] ip link add wg0 type wireguard
RTNETLINK answers: Operation not supported
Unable to access interface: Protocol not supported

What i noticed is that after installation, a new folder is created in /lib/modules/ where wireguard.ko is placed

$ ls /lib/modules/
4.17.7  4.17.7-mvebu64
$ ls /lib/modules/4.17.7/extra/
wireguard.ko

 

 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines