Igor

NAND is fading out and probably CHIP is one of the last if not the last one using this technology. It's one of those - yes I would like to see this - but it is a low priority from our perspective. I notice that @zador.blood.stained add overlays for NAND and we have support at least in a modern kernel (I only saw NAND was recognized, but haven't actually tested its functionality), while old legacy is officially EOL and we will ditch it once multimedia functions/video acceleration/MALI works in mainline.

Possible, but it is on you to port the driver. We don't have resources to support even the onboard hardware. I would also like to see KODI on Debian but unfortunately, this is hard to achieve. Even on x86 it usually doesn't just work out of the box. Your problem is solvable with two boards - one for backend running modern kernel and one for running Openelec.

A whole nightly building is on hold until upcoming bugfix release. Since I am currently playing out with Tinkerboard, I will make them and upload probably once during a day. If this is not fast enough, you need to setup build environment. Edit: https://dl.armbian.com/tinkerboard/Ubuntu_xenial_next_desktop_nightly.7z https://dl.armbian.com/tinkerboard/Ubuntu_xenial_next_nightly.7z

No GLES support with this kernel yet. Sorry. Wrote on mobile

Yes. Than Debian stretch with this NEXT 4.13.y could be a perfect choice. Just beware that kernel might have some troubles and we don't support it since we are moving to 4.14.y which will be first stable build. Good news is that you will be able to update your system in no time to this stable build when available. When you download this latest nightly build, freeze the kernel updates in armbian-config and update to the stable repository when kernel 4.14. is out.

Solve simple problems first Dietpi is also selling you bullshit and you don't even notice. There are absolutely no technical advantages/optimisations at least towards Armbian. In fact, Diet runs slower in just about every case and on any hardware. Also on Raspberry Pi plus it is not just about speed or other technical advantages but security, support and trust. I knew that RPi is bad and has bad karma and ofc Google is evil too and they stick together very well. Power corrupts if nothing else.

Both must and do work. It must be something else. But if you are satisfied with the outcome ...

How did you connect to the internet? https://docs.armbian.com/User-Guide_Getting-Started/#how-to-connect-to-wireless

There are only two options. We have a bug or you made some strange/from very old images upgrade. Can you start with a clean image from download?

Tha is Ubuntu install disk, no default password. You create one.

I assume you use identical kernel / armbian version on both?

No. Start to build with build script v2017.11 which has a known working configuration based on U-boot v2017.09

This OTG <> HOST switcher is planned for some time to find a place in armbian-config. It exists only as a 2do list entry for now

Well, if you use some very outdated script ... with a recent image, this for sure won't work. Many things have changed since ... But you should have more recent script on your image, also there is armbian-config and you can call that script from there. Can you provide: armbianmonitor -u just for the record to see which image do you have.

Understand. Just after release, we switched to more recent u-boot and some patches were adjusted ... This is most likely THE problem. Try to use our build script tagged with v2017.11 as mentioned. Thank you!

I had a meeting today and all except last two posts, since not existing at the time, were checked. In general, I was more or less presentation our pain with existing ideas how to solve this and that. Wordpress stays since they are familiar and since the problem is not there. Data will go into temp database (from GitHub config files as it comes now) that any possible search/filtering is possible, used or not. UX redesign has top priority than graphics tuneup and then backstage improvements. Estimated due ... hardly this year. Rather slow and good. Now waiting for the first prototype, then arguing further.

For testing only. https://dl.armbian.com/odroidc2/archive/TEST-Armbian_5.34_Odroidc2_Ubuntu_xenial_next_4.13.9_desktop.7z Currently broken: https://github.com/armbian/build/commit/2d490d3a861e02b89e08950eca3f5af93f56c4ea

Is any of those working for you: https://dl.armbian.com/beelinkx2/nightly/ Docker is supported out of the box. Image building might be broken at the moment. Try building by using latest stable tag: https://github.com/armbian/build/tree/v2017.11

It's not a problem of Armbian but kernel used on those board. Debian Stretch will have troubles with it. You need to switch to modern kernel but that one is still labeled as testing and some features are not yet supported. It depends on your use case.

Than use a simple I2C light sensor https://www.ebay.de/itm/Helligkeitsmesser-Sensor-I2C-Bus-digital-TSL2561-fur-Arduino-Raspberry-Pi-New/272477704018

We need to put new, Stretch adjusted version of RPi monitor into repository. Untested. https://github.com/XavierBerger/RPi-Monitor-deb/blob/master/packages/rpimonitor_2.12-r0_all.deb

You monitor changelog on a daily base. How come that you miss this change, written in release docs for some time ... and is cosmetic anyway? Icon theme was also changed since the old one didn't want to install on Debian Stretch under chroot. Couldn't find why / solution.

Desktop wallpaper Screen #1 and Screen #2 was swapped - Why not?

Added: https://github.com/armbian/build/commit/72b42b5b10495d16562cd87bfbb889a054ced2a1

You need to provide all possible data. How did you do it, where, armbianmonitor -u, ...