Igor

Have you read the text? https://www.armbian.com/espressobin/

You can review a kernel config https://github.com/armbian/build/blob/master/config/kernel/linux-sunxi-next.config and submit things which you miss/need. Then grab the latest kernel from a beta repository. This means switching to nightly repository + reboot. Than just update kernel since you are already on a beta repository. If you want to get back to 4.14.y switch to the stable repository with armbian-config. We still have 4.14.y as latest there, but it will be switched to 4.17.y/4.18.y as soon as major functions work on all supported boards.

Try updating to nightly kernels (4.17.y) where also, u-boot is changed to 2018.05 ... this might help. If not it is possible that you will need to slightly downclock memory on your board. For that, you need to rebuild u-boot with new speed parameters. I hope you will not need to go that far.

It is created for Raspbian Jessie which is Debian Jessie with a kernel (hardware features) special for Raspberry Pi. If script is not updated to run on Raspbian Stretch you might have the same problems with Armbian Stretch. We provide Debian Jessie but since it's old technology and officially EOL I don't recommend to use it. VPN is a hardware independent service which can run virtually on any Linux. I recommend you to use DigitalOcen tutorials since they are good quality. And generic. As OpenVPN is. The first hit is installing it on Ubuntu Bionic which is bleeding edge technology with possible problems ... Debian Stretch as a base is a way to go.

Use Debian Stretech based images. Perhaps it also runs on Ubuntu. http://www.pivpn.io/ https://www.digitalocean.com/community/tutorials?q=openvpn You can easily find a distro with far less.

We (actually Rockchip) have big problems with RK3288 legacy kernel at the moment and AFAIK they are not completely solved. Any help is appreciated.

I only merged the working configuration without major changes. Step one.

I doubt rarmbian-config can not make such a mess. Start with a clean image or clean the mess Remove: apt purge linux-image-dev-sunxi64 linux-dtb-dev-sunxi64 linux-xenial-root-dev-orangepipc2 linux-u-boot-orangepipc2-dev and switch back to stable. If you fail ... start with a new image.

You are running an unsupported development kernel and you didn't supply the most important information: armbianmonitor -u to help you get back to the stable builds.

No, there is no support for NAND in the modern kernel. AFAIK you can enable in armbian-config via overlay and access it, but you can't boot from it. Unfortunately, the problem you face is quite common - you have to make compromises. BTW. NAND is slower and less reliable than most modern SD cards.

Try now .

Forget about. Docker needs a newer version. You need to move to NEXT 4.14.y kernel and it will work.

Deboostrap failing at icon-theme(s) hunts me for a long time. I thought I found/fix the problem, but it looks like it was yet another random "fix". Now searching for another workaround ... at Bionic we have also gnome-icon-theme failing, which is stock desktop dependencies ...

Yes, but probably not here since it is not related to Armbian. https://forum.openmediavault.org/index.php/BoardList/?s=3f87de5366dd6cda7384cedb5c1c1d4fe4304744

One option is simply to throw out those numbers since they contain no valuable info. We have armbianmonitor, where we see all those things. BTW. I am ready with general BSP update for all boards. Upgrade worked well on all test subjects ... we could also add replace zram-config to automatically remove this package ... since our ZRAM logging and ZSWAP is not getting in action in case zram-config is in installed.

That would work on stable builds, but 100% won't work on a build @Anatolii Kraskovskiy is using. Overlay support is completely broken there - we just recently fixed this on 4.17.y and I am not sure it is working properly since I haven't test it yet. We are still preparing this kernel.

Observe how console parameter works: https://github.com/armbian/build/blob/master/config/bootscripts/boot-sunxi.cmd#L31-L32 console=display > armbianEnv.txt

Me too and ATM I don't know why they are not present.

You forget to supply the most important data. Not possible to help. Type: armbianmonitor -u

Remove cache/rootfs and try again. (i will try to recreate the problem in the mean time)

You are asking questions which are not covered by free support. If we would have paid support this would also no be covered. We explicitly state where possible, that development builds are not supported. You can ask things but expect nobody will give you an answer. Solving problems, which you think they are simple, can perhaps require 100, 500 or 1000 of engineering hours to solve. Any might not go the way you want. What was developed or what is getting to be developed for Allwinner chips can be found here: https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix Most of the recent stuff is clearly not on the end user level and require deep understanding to fix something. Even the smallest problem. In the meantime, the main developer (who is/will not do this for the end user but for other motives) can fix the problem or completely change the code ...

Have you noticed and read the red warning text at login? You are using some old automated image/kernel combo made for testing/developers only. There is no end-user support for many reasons. One is obvious - why on earth would anyone dig into EOL development kernel, which is full of junk and was never released ... We don't try to fix development versions on the spot. Issues are collecting, prioritizing and they are eventually fixed. We are putting all of our efforts to make 4.17.y / 4.18.y up and running. What is the best for you? Build your own NEXT kernel and hope for the best. Hope. Bugs are present, but perhaps they might not interfere with your use case.

Strange. We need to investigate whether this is our or upstream problem.

1. and 2. Armbian Toolchain downloads and use right compiler version at right time. We use 13 of them to manage all sources. If you need it just for one kernel / u-boot source you might need just one or two. If you will compile only a kernel, it won't took much space ... but we don't divide host dependencies for kernel compilation and making images. If you know which compiler you need, you can DIY. Remember to grab patches and adjusted kernel config from build source for a start ... Why don't you simply use Docker compilation type? This way of building should run on any X64 distro.

Do you have I2S overlays in /boot/dtb/overlay ?