Christos Posted June 28, 2018 Posted June 28, 2018 (edited) 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, 2018 by Christos PS
Christos Posted June 28, 2018 Author Posted June 28, 2018 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?
Igor Posted June 29, 2018 Posted June 29, 2018 Which Ubuntu? If Bionic, I don't care ATM, if Xenial, I will look at what can be wrong.
Christos Posted June 30, 2018 Author Posted June 30, 2018 @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?
Igor Posted June 30, 2018 Posted June 30, 2018 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 ...
Christos Posted June 30, 2018 Author Posted June 30, 2018 @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..
Igor Posted June 30, 2018 Posted June 30, 2018 You were right, ZRAM changes had effects. Fixed:https://github.com/armbian/build/commit/908dd71d2d8934666dd6ee3502ccf07a693b27ab Thanks! @Arglebargle
Christos Posted June 30, 2018 Author Posted June 30, 2018 @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.
Igor Posted June 30, 2018 Posted June 30, 2018 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.
Christos Posted June 30, 2018 Author Posted June 30, 2018 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.
Arglebargle Posted July 2, 2018 Posted July 2, 2018 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.
Igor Posted July 2, 2018 Posted July 2, 2018 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.
Christos Posted July 2, 2018 Author Posted July 2, 2018 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.
Recommended Posts