Christos

@Igor @guidol Ooops, in the latest 5.51 it looks we cannot remove only unattended-upgrades, if doing so we also lose the most useful armbian-config amongst others (armbian-config python3-software-properties software-properties-common) So, we cannot remove only unattended-upgrades? If so, if we set to "0" all options in 02-armbian-periodic, is it the same and no unattended upgrade will ever happen? ___ ____ _ ____ ____ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) | _ \ / ___| | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | | |_) | | | |_| | | | (_| | | | | (_| | __/ | __/| | | __/| |___ \___/|_| \__,_|_| |_|\__, |\___| |_| |_| |_| \____| |___/ Welcome to ARMBIAN 5.51 user-built Debian GNU/Linux 8 (jessie) 3.4.113-rt143-sun8i System load: 0.67 0.18 0.06 Up time: 0 min Memory usage: 6 % of 997MB IP: 192.168.1.42 CPU temp: 52°C Usage of /: 24% of 3.6G Last login: Tue Jul 3 13:48:59 2018 root@pisdr:~# apt-get remove unattended-upgrades Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: armbian-config python3-software-properties software-properties-common unattended-upgrades 0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded. After this operation, 721 kB disk space will be freed. Do you want to continue? [Y/n]

Thanks!

@guidol Thanks for the links, already did that though and seen that there is a bit of difference in armbian, there are two files in armbian for periodic config (02periodic and 02-periodic) and since I know that some services might need to always be present (for any reason) in armbian, so I asked the question. The question is actually, can I totally remove the unnatended upgrades package in armbian? or what is the best method in armbian for unattended upgrades Not to run? PS. Using Xenial, legacy

Hi, Need to have unattended upgrades stopped and not run uppon every boot. What is the best way to do this?

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.

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.

@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 (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 @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 It is for Xenial

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?

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.

Hi, Got a Tinker Board and tried the 5.41 Xenial mainline 4.14.23 desktop -> https://www.armbian.com/tinkerboard/#kernels-archive Need to enable the I2S on 40pinheader connector for both playback & capture (192KHz/32bits) but I dont seem to find the info for this. Any help is valuable!

Thanks @Igor , that did it and now it can compile from the development branch. Just one more thing though, can it use the 'dev' kernel? meaning the latest 4.16 and not the 4.14? I see as options only the legacy and next, not dev.

@Igor I tried without manually specifiyng branch at first as I show above but it did not work with the shown log. Where and how exactly should I use the LIB_TAG ? not as an argument in compile.sh ?

@Igor Can you please have a look at this compile.sh output? Trying to do a clean build based on the new development branch. It is a fresh new git clone and use your "LIB_TAG=development" argument, yet upon start it reports that is still using 'master'.. is that ok? Select then to build a OPiPC dev (latest kernel) xenial server image. It also later on, reports that it will generate '5.41' deb and img whereas I guess it should say '5.42' as revision, is that ok? And all generated debs are 5.41 revision. christos@Ubuntu16042VM:~/armbian/build$ git checkout master Already on 'master' Your branch is up-to-date with 'origin/master'. christos@Ubuntu16042VM:~/armbian/build$ ./compile.sh LIB_TAG=development [ o.k. ] Using config file [ config-default.conf ] [ warn ] This script requires root privileges, trying to use sudo [ o.k. ] Using config file [ config-default.conf ] [ o.k. ] This script will try to update Already up-to-date. Already on 'master' Your branch is up-to-date with 'origin/master'. [ o.k. ] Command line: setting LIB_TAG to [ development ] [ o.k. ] Preparing [ host ] [ o.k. ] Build host OS release [ xenial ] [ o.k. ] Syncing clock [ host ] .. [ o.k. ] Building deb [ linux-u-boot-dev-orangepipc_5.41_armhf.deb ] .. [ o.k. ] Done building [ /home/christos/armbian/build/output/images/Armbian_5.41_Orangepipc_Ubuntu_xenial_dev_4.16.0-rc5.img ] christos@Ubuntu16042VM:~/armbian/build/output/debs$ ls -l total 76632 -rw-r--r-- 1 root root 30752 Μάρ 18 15:19 armbian-config_5.41_all.deb -rw-r--r-- 1 root root 2115308 Μάρ 18 15:19 armbian-firmware_5.41_all.deb -rw-r--r-- 1 root root 76109880 Μάρ 18 15:22 armbian-firmware-full_5.41_all.deb -rw-r--r-- 1 root root 11588 Μάρ 18 15:22 armbian-tools-xenial_5.41_armhf.deb drwxrwsr-x 2 root sudo 4096 Μάρ 18 00:43 extra -rw-r--r-- 1 root root 187638 Μάρ 18 15:38 linux-u-boot-dev-orangepipc_5.41_armhf.deb drwxrwsr-x 2 root sudo 4096 Μάρ 18 15:38 xenial christos@Ubuntu16042VM:~/armbian/build/output/debs$ Thus it looks the compile.sh even with the "LIB_TAG=development" eventually used the master branch and not the development. Then I tried to build by first selecting manually the development branch and use your "LIB_TAG=development" argument, yet upon start it reports that is still using 'master' ! Select then to build a OPiPC dev (latest kernel) xenial server image. And again later on, reports that it will generate '5.41' deb and img whereas I guess it should say '5.42' as revision. christos@Ubuntu16042VM:~/armbian/build$ git checkout development Switched to branch 'development' Your branch is up-to-date with 'origin/development'. christos@Ubuntu16042VM:~/armbian/build$ ./compile.sh LIB_TAG=development [ o.k. ] Using config file [ config-default.conf ] [ warn ] This script requires root privileges, trying to use sudo [ o.k. ] Using config file [ config-default.conf ] [ o.k. ] This script will try to update Already up-to-date. Switched to branch 'master' Your branch is up-to-date with 'origin/master'. [ o.k. ] Command line: setting LIB_TAG to [ development ] [ o.k. ] Preparing [ host ] [ o.k. ] Build host OS release [ xenial ] [ o.k. ] Syncing clock [ host ] .. [ o.k. ] Building deb [ linux-u-boot-dev-orangepipc_5.41_armhf.deb ] .. So, tried both ways, either from master branch with "LIB_TAG=development" argument or from manually switching to development executing compile.sh with "LIB_TAG=development" argument and in both tries the compile.sh script reverted to master. Am I making something wrong here?

@Igor Do we need to do git clone with -b "development" from scratch or is it ok/suffice to use LIB_TAG="development" with the current compile.sh from master ? /PS: Tried to git clone -b development but every time compile.sh is started, it always checks out to master (Switched to branch 'master'), how can we compile from the development build branch? christos@Ubuntu16042VM:~/armbian/build$ git checkout development Already on 'development' Your branch is up-to-date with 'origin/development'. christos@Ubuntu16042VM:~/armbian/build$ ./compile.sh LIB_TAG=development [ o.k. ] Using config file [ config-default.conf ] [ warn ] This script requires root privileges, trying to use sudo [ o.k. ] Using config file [ config-default.conf ] [ o.k. ] This script will try to update Already up-to-date. Switched to branch 'master' Your branch is up-to-date with 'origin/master'.

@codekipper I hope if its not too much, can you or someone create a patch for Armbian.

@codekipper @nikkov Hi, Is there any advancement in having 24/32bit, 192KHz, concurently playback and capture with I2S ? Any patch we could give it a try and test in 4.14? Season greetings to all.

Rafaelo's repo provides also some released bl bin files in 'Releases'. As a first step, I just copied the bl bin file from rafaelo and placed it/renamed it in the specified position, then I did a new build and it does boot ok. As it shows, the first I2C errors now gone, it does boot and has the same remaining problems, could be needs changed uboot. Also tried to point the dev branch to checkout (via s5p6818.conf) from his new https://github.com/rafaello7/linux-nanopi-m3-v4.14 but could not make it work, could be the patches, dont know. Obviously someone with better knowledge of how Armbian build tool works, should do it. The bl bin though from 'Releases' in rafaelo's repo works as it is when copy it and rename it in the proper Armbian place you showed.

@Igor It might also be the uboot he uses, in Armbian we build it from sources. How can we use his uboot bin instead of ours? And also the same is for any display blob.

Given a try to create full images from rafaelo with this -> https://github.com/rafaello7/debian-installer-nanopi-m3 did both Debian and Ubuntu it took some time but created images that boot ok, work and give desktop without the problems mentioned earlier. Thus, no problem found to report to him. Attached their complete console bootlogs FYI. As I mentioned in the first post, Armbian a couple of months back was able to create a good m3 image without the boot problems shown above nowadays. From the 5.37 bootlog errors now, they look to me that there is a possibility of some bl1 or uboot bin file or even a display blob for m3 to went wrong in some later commit in Armbian, dont know though, just guessing. Rafaelo's image boots and works ok so it might be a good idea to get his bl1 and uboot bins or display blobs and replace these in Armbian build, if of course that makes sense and got the time to do it. M3_rafaelo_Debian_desktop_Boot.txt M3_rafaelo_Ubuntu_desktop_Boot.txt

Ok @Igor Thank you.

@Igor Ok, I know that, just seen your new post here and some latest mobility from Armbian regarding this board and assumed there is some renewed interest. One question though, if I want to make an image but based on a earlier version of Armbian build tool, is there an easy way to do it? eg to git a specific armbian build version and not perform the automatic git update on build start? That way I'll try to rebuild the proper working image that I had a couple of months ago.

@Igor Also this stacktrace is shown in console bootlog after the initial user is created and rebooted probably when the system tries to start the desktop [ 8.812000] Unable to handle kernel paging request at virtual address 3733323a3039 [ 8.816000] pgd = ffffffc03bb20000 [ 8.820000] [3733323a3039] *pgd=0000000000000000, *pud=0000000000000000 [ 8.824000] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 8.832000] Modules linked in: zram brcmfmac cfg80211 aes_ce_blk rfkill crypto_simd brcmutil cryptd aes_ce_cipher crc32_ce crct10dif_ce nano_videodev nxp_vpu videobuf2_dma_contig videobuf2_memops ghash_ce videobuf2_v4l2 sha2_ce videobuf2_core sha1_ce nanopi_thermistor nx_scaler [ 8.856000] CPU: 1 PID: 582 Comm: Xorg Not tainted 4.11.12-s5p6818 #1 [ 8.860000] Hardware name: nexell soc (DT) [ 8.864000] task: ffffffc03c894180 task.stack: ffffffc03763c000 [ 8.872000] PC is at drm_fb_helper_restore_fbdev_mode_unlocked+0x1c/0x70 [ 8.876000] LR is at nx_drm_lastclose+0x24/0x2c [ 8.876000] pc : [<ffffff80085c51b0>] lr : [<ffffff80085ef5d8>] pstate: 40000145 [ 8.876000] sp : ffffffc03763fd30 [ 8.876000] x29: ffffffc03763fd30 x28: dead000000000200 [ 8.876000] x27: dead000000000100 x26: 0000000000000140 [ 8.876000] x25: ffffffc03b8c1510 x24: ffffffc03e04b000 [ 8.876000] x23: ffffffc03e04fa50 x22: ffffff8008ced000 [ 8.876000] x21: ffffffc03b8c14f0 x20: 00000000ffffffed [ 8.876000] x19: ffffffc03e04f800 x18: 0000007fe9606688 [ 8.876000] x17: 0000007f78d14830 x16: ffffff80081cfa68 [ 8.876000] x15: 0000007f791b3000 x14: 0000000000000000 [ 8.876000] x13: 2f6d72645f79616c x12: 0000000100000000 [ 8.876000] x11: 0000000100000000 x10: 0101010101010101 [ 8.876000] x9 : 00000001745617b0 x8 : 0000000000000039 [ 8.876000] x7 : 0000000000000000 x6 : 0000000000000001 [ 8.876000] x5 : 0000000000000000 x4 : 0000000000000000 [ 8.876000] x3 : 0000000000000000 x2 : ffffff8008b1f4e6 [ 8.876000] x1 : 0000000000000001 x0 : 64003733323a3031 [ 8.876000] [ 8.876000] Process Xorg (pid: 582, stack limit = 0xffffffc03763c000) [ 8.876000] Stack: (0xffffffc03763fd30 to 0xffffffc037640000) [ 8.876000] fd20: ffffffc03763fd60 ffffff80085ef5d8 [ 8.876000] fd40: ffffffc03e04f800 ffffff8008ac3000 ffffffc03b8c14f0 ffffff8008ced000 [ 8.876000] fd60: ffffffc03763fd70 ffffff80085c890c ffffffc03763fda0 ffffff80085c8c34 [ 8.876000] fd80: ffffffc03b8c1400 ffffffc03e04f800 ffffffc03b8c14f0 ffffffc03e04b000 [ 8.876000] fda0: ffffffc03763fe00 ffffff80081d3f38 ffffffc03b809c00 ffffffc03cb75118 [ 8.876000] fdc0: 0000000000000008 ffffffc03b809c10 ffffffc03e0738e0 ffffffc03e464118 [ 8.876000] fde0: ffffffc03cb75118 0000000000000039 ffffff80088a2000 ffffffc03c894180 [ 8.876000] fe00: ffffffc03763fe50 ffffff80081d4058 ffffffc03c894180 ffffff8008ab3150 [ 8.876000] fe20: ffffff8008d54000 0000000000000000 0000000040000000 0000000000000015 [ 8.876000] fe40: 0000000000000124 ffffff8008896a98 ffffffc03763fe60 ffffff80080b0e04 [ 8.876000] fe60: ffffffc03763fe90 ffffff8008086ad0 0000000000000004 ffffffc03c894180 [ 8.876000] fe80: ffffffc03c894180 ffffffc03763fec0 0000000000000000 ffffff8008082618 [ 8.876000] fea0: 0000000000000000 00000040372f6000 ffffffffffffffff 0000007f78d14818 [ 8.876000] fec0: 0000000000000000 0000000000000000 0000007fe96070c8 0000000000000000 [ 8.876000] fee0: 00000000ffffffff 0000007f78d9b9b8 0000000000000000 0000000000000000 [ 8.876000] ff00: 0000000000000039 00000001745617b0 0101010101010101 0000000100000000 [ 8.876000] ff20: 0000000100000000 2f6d72645f79616c 0000000000000000 0000007f791b3000 [ 8.876000] ff40: 0000000000000000 0000007f78d14830 0000007fe9606688 000000013cc61000 [ 8.876000] ff60: 0000000000000008 0000000174562870 0000000000000000 0000000000000000 [ 8.876000] ff80: 00000001745616a0 00000001745617b0 0000000000000000 0000000174562870 [ 8.876000] ffa0: 0000000174562a40 0000007fe96070d0 000000013cb1a09c 0000007fe96070d0 [ 8.876000] ffc0: 0000007f78d14818 0000000040000000 0000000000000008 0000000000000039 [ 8.876000] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff [ 8.876000] Call trace: [ 8.876000] Exception stack(0xffffffc03763fb60 to 0xffffffc03763fc90) [ 8.876000] fb60: ffffffc03e04f800 0000008000000000 ffffffc03763fd30 ffffff80085c51b0 [ 8.876000] fb80: ffffffc03763fba0 ffffff80081e6f00 ffffffc03763fbb0 ffffff80081f0d30 [ 8.876000] fba0: ffffffc03e0738c0 ffffff80081f0d0c ffffffc03763fbe0 ffffff80081f0edc [ 8.876000] fbc0: ffffffc03763fbf0 ffffff80080b931c ffffffc03763fc10 ffffff8008543e1c [ 8.876000] fbe0: ffffff8008c208e0 ffffffc03e800100 ffffffc03e800100 ffffff8008dc6000 [ 8.876000] fc00: 64003733323a3031 0000000000000001 ffffff8008b1f4e6 0000000000000000 [ 8.876000] fc20: 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 8.876000] fc40: 0000000000000039 00000001745617b0 0101010101010101 0000000100000000 [ 8.876000] fc60: 0000000100000000 2f6d72645f79616c 0000000000000000 0000007f791b3000 [ 8.876000] fc80: ffffff80081cfa68 0000007f78d14830 [ 8.876000] [<ffffff80085c51b0>] drm_fb_helper_restore_fbdev_mode_unlocked+0x1c/0x70 [ 8.876000] [<ffffff80085ef5d8>] nx_drm_lastclose+0x24/0x2c [ 8.876000] [<ffffff80085c890c>] drm_lastclose+0x40/0xc8 [ 8.876000] [<ffffff80085c8c34>] drm_release+0x2a0/0x2e4 [ 8.876000] [<ffffff80081d3f38>] __fput+0xfc/0x1c4 [ 8.876000] [<ffffff80081d4058>] ____fput+0xc/0x14 [ 8.876000] [<ffffff80080b0e04>] task_work_run+0xbc/0xe8 [ 8.876000] [<ffffff8008086ad0>] do_notify_resume+0x5c/0x8c [ 8.876000] [<ffffff8008082618>] work_pending+0x8/0x10 [ 8.876000] Code: 39406021 a90153f3 a9025bf5 12800254 (f9400416) [ 8.876000] ---[ end trace 3aa669faf69aaea6 ]--- M3_Armbian_Ubuntu_dev_Boot_stacktrace.txt