Igor

At least that is correct Only BSP package was updated and at least most non-cosmetic problems were fixed ... Well, we need yet another mini updated. There are only experimental 4.13.y builds and yes its planned when ready and tested. That is completely normal. SD card content is left as is. We only alter boot environment when SD card is needed for booting. We only fixed bugs inboard support package scripts. There were no kernel updates and this problem need to be investigated. It's nothing critical so you can normally use the board.

done. apt-update & upgrade

Those number might be set higher later when the kernel is well tested and thermal protection working as it should. You don't want to burn your board, do you?

Since the nightly building is still on hold, you need to make one. I'll try to make one later if you can't build it.

Yes, there is a strong reason called "waste of scarce human resources" to gain little on a less important area. There are only a few people working on/supporting/developing a build engine ... which anyway support building withing Docker. This means you can actually build anywhere - at any x64 Linux Docker capable host. In case this bothers you a lot and you want to dedicate your time to this challenge: https://docs.armbian.com/Process_Contribute/

No need to format anything. Check is crucial that's why we suggest Etcher and if you can, try some other SD card. I am not sure exactly for image which you are trying, but this one: https://dl.armbian.com/tinkerboard/nightly/Armbian_5.35.171130_Tinkerboard_Ubuntu_xenial_next_4.14.2_desktop.7z was tested personally and it works this way: 4.14.y is recommended since we are ditching 4.13.y ASAP.

https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card

v.5.36 Are we ready to rebuild repository on Sunday ... and update only BSPs and RPI monitor?

Just check project Github if there was any progress on this. In case of major progress, we mention that in a release log. It can take months, sometimes a year(s) before board is labeled stable. I only have RK3328 based TV box and have to get Rock64 first I'll check what can be done but in any case, this will still be a testing build.

Unfortunately, you hit another (known) Ubuntu Xenial bug. Only Debian Stretch desktop is currently available to build for imx6 based boards. I didn't have time to get to the bottom of the issue so I don't know exactly where is the problem and how to solve it.

Those are logs from image: http://sprunge.us/WUDf where HDMI audio was tested successfully. Board is Opi PC+

Remember. This is open source project running by amateurs and not enterprise-grade service. Go to GitHub and monitor progress. We always write major changes to release documentation. Didn't you notice this? * packaged versions might be slightly older than in this table!

Add this extraargs=net.ifnames=0 to /boot/armbianEnv.txt

I didn't get this far yet. I have system on eMMC now, can boot from it and (only) waiting in the corner Busy with other stuff.

Since image currently doesn't boot properly, somebody needs to find and fix this problem first.

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.