Hi,

Just did a fresh 5.49 build, OPi PC, legacy, Ubuntu console/server.

 

Ethernet network is not working (out of the box)

 

It does not get an IPv4 address automatically

 

Tried to and got it enabled via nmtui,

it was showing an 'eth0' as activated and a 'Wired connection 1' as deactivated.

I activated the wired connection1, it automatically removed the eth0  from the list and then it has taken an IP address.

 

Did a reboot, though after reboot it was again not working, it did not retained settings.

NMTUI show again eth0 as activated and 'wired connection' as deactivated.

And no IP address is given to the board.

 

So, am I missing something?

 

 

PS.

with 5.49 legacy, Debian console/server, IPv4 works ok out of the box.

Edited June 28, 20188 yr by Christos
PS

A day later also tested the 5.50, same OPi PC legacy, Ubuntu server/console image build.

Same problem, no IPv4 addressing problem.

 

@Igor @zador.blood.stained

Is there anything I miss or build has a broken networking config in the latest (5.49, 5.50) versions?

Which Ubuntu? If Bionic, I don't care ATM, if Xenial, I will look at what can be wrong.

@Igor

It is for Xenial

 

@Igor

@zador.blood.stained

 

I am a bit buffled.

 

Latest image that I created and works correctly with IPv4 network addressing was (did not test/build after that until now)

Armbian_5.46_Orangepipc_Ubuntu_xenial_default on 11/Jun

I use a 4GB Class10 microSD for all my test builds so far.

Two scenarios are done, a plain client by getting IPv4 addressing and a DHCP server setup with isc-dhcp-server.

 

Now the 5.50 image is built from repo for up/and to commit "Adjusted ZRAM implementation" ( 46d754f909980c37cb56533a5a0b0874f2719480 )

Tested the Xenial console with 3 microSD cards, sizes 4, 8, 16GB all Class10 (same brand). All flashed and verified with Etcher and boot/start ok otherwise.

1. Ethernet client networking/addressing does not work with a 4 GB SD card.

2. Ethernet client with many reboot attempts it occasionally/sometimes works (most of the times though not), with 8 GB SD card,

3. Ethernet client does work always with 16GB SD card.

 

With 4GB it shows 20% space utilization, with 8GB, 10% space utilization so obviously space is not directly related but for some reason card size does play a role..

 

Did also the same test with Debian Jessie legacy console build

1. Ethernet client networking/addressing works ok but DHCP server does not work with a 4 GB SD card.

2. Ethernet client and DHCP server work ok with 8 GB SD card,

3. Ethernet client and DHCP server work ok with 16GB SD card.

 

Dont know if those tests have any meaning at all, but I am buffled as I said.

It looks that there might be problems in 4GB or 8GB cards in Ubuntu and in 4GB in Debian, that is one thing that I understand in the latest Armbian versions.

 

So, is there any rule on microSD card size for Armbian?

Is there something else that somehow is broken (new ZRam maybe?) and gives that effect on network IPv4 addressing?

Is it me that I'm missing something?

 

1 hour ago, Christos said:

Is it me that I'm missing something?

Github was acquired by criminals and our code is ... gone bad?  My first try ended up:

Spoiler

U-Boot SPL 2017.11-armbian (Jun 30 2018 - 18:12:36)
DRAM: 1024 MiB
Trying to boot from MMC1
MMC: no card present
mmc_init: -123, time 2
spl: mmc init failed with error: -123
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

 

 

Perhaps your SD card simply died? I have a stack of broken Samsung EVO around ... 

@Igor

(lol about recent github acquiring..)

 

The 8GB cards are brand new, bought them yesterday just to test and it shows that dhclient in Xenial has problems even with them.

When I flash the same 4GB with the old xenial image (5.46) it works just fine! (and as I said etcher verification reports no issues)

So, although it also crossed my mind that the cards gone bad, it looks that they are ok and something else might lurks underneath in the latest versions..

 

 

You were right, ZRAM changes had effects. Fixed:
https://github.com/armbian/build/commit/908dd71d2d8934666dd6ee3502ccf07a693b27ab

 

Thanks!

 

@Arglebargle

@Igor

I'll test if this could solve the issue.

 

Though, if you read my first post, I started having the issue before the ZRAM (3 *) adjustment, it was there from 5.49, the ZRAM adjustment came after 5.50 bump so I'm not so sure that it could fix things entirely.

I'll perform the tests by having another build now and report back.

 

2 minutes ago, Christos said:

I'll test if this could solve the issue.

Go to /etc/defaults/armbian-zram and armbian-ram-log ... and customize/disable.

 

I couldn't boot the image with *3 Ubuntu Xenial / 3.4.113, made 30 minutes ago from sources ... without everything works/looks normal.

1 minute ago, Igor said:

 without everything works/looks normal.

If you use a 16GB card it is normal/ok as I tested here, the problems start to happen when using 8GB and are evident mainly in 4GB cards.

Thanks for the hint in zram config, I'll try to tweak and see the results.

 

On 6/30/2018 at 2:01 PM, Igor said:

You were right, ZRAM changes had effects. Fixed:
https://github.com/armbian/build/commit/908dd71d2d8934666dd6ee3502ccf07a693b27ab

 

Thanks!

 

@Arglebargle

That is really strange. I'll get out one of my spare boards and see if I can replicate/diagnose. Sorry for the hassle!

 

Quick Q: What's the lowest kernel version that will run this script? My implementation is pretty different since I'm >=4.4 on all of my boards. There's no need to use per cpu zram devices in that case, the kernel allocates 1 stream per core without needing multiple devices these days. I think <3.15 is the cutoff for that feature.

5 hours ago, Arglebargle said:

That is really strange.

Perhaps CMA reservations have something to do with this.

 

5 hours ago, Arglebargle said:

What's the lowest kernel version that will run this script?

We would like to provide this for older kernels as well. Lowest is 3.4.y and I made several tests without a problem. The only problem was detected on Bionic, where ZRAM is failing sometimes. Also with a stock script. Haven't got chance for deep analysis ... Bionic bugs are not exactly a top priority ATM.

Thanks @Arglebargle for the hint

According to wiki "zram was introduced into the mainline Linux kernel in version 3.14"

-> https://en.wikipedia.org/wiki/Zram

 

I would be really interested to see if by reverting this and not including it in a new version, things could come back to normal for the supported legacy.