Igor

Try this. Switch to beta, update and enable audio codec (armbian-config -> system -> hardware configuration) Note that switching to beta repository might break the system - its untested area.

Now it is. I asked for serial console output to rule out possible board hardware troubles. We have seen that some boards failed to initialize with a modern u-boot which is used in just about every build. But since you rather waste my time than buying a serial console for 2USD this tells me that it's no use to help you. 1. This image: https://dl.armbian.com/orangepione/Ubuntu_xenial_default.7z 2. Boot this way: Good luck with distributions that works

Do you have a link to display hardware specs, just to tell which display this is? To mention that here: https://github.com/armbian/documentation/blob/master/docs/Release_Changelog.md You mean this locking could be Stretch related? Huh. Will pay more attention - my testings are very quick these days ... click here and there and fixing things

Can you check/see I2C devices with i2cdetect?

https://docs.armbian.com/User-Guide_Getting-Started/#what-are-testing-images At the present situation, we are happy that sound works and little less happy to find out for yet another (small) issue

We are not clairvoyant or mind readers Please describe your setup as best as possible so we know what your operating environment is like. Name of your board: Name of the image you installed: Logs, when you can boot the board: armbianmonitor -u (paste URL to your forum post) If your board does not boot, provide a log from serial console (UART) or at least make and attach a picture, where it stops. Describe the problem the best you can and provide all necessary info that we can reproduce the problem.

It is possible that there are no drivers for this in a modern kernel yet. This is common for all boards. Check around if there are some patches for or prepare to port this driver. We don't have resources for such task.

Thank you for cheer up. Well, it is perspective biased. We have many different kernels which are in various states, we have userspace (CLI and desktop), utilities, documentation, website. To have them all in a perfect state at once is mission impossible no matter how hard and smart we work. If we wait for all this to be perfectly aligned, the release date will never come. We need another approach to this problem. I am seeking consent/approval and sharing responsibility - shell I put a current sunxi-next to the main repository or not, shell I rebuild at least A10/A20/imx6/rk3288/mvebu/xu4 (more precisely which combination to skip?) boards and with Stretch and why not?

Basic hardware features are operational - but all mainline kernels for H3/H5/A64 boards remain labeled testing (also after next major release) since things are not well tested, not fine-tuned (thermal protection) and there is nothing we can do to speed up. In the testing period we don't make all possible images, so you have to make your own (Debian Stretch) image or wait ...

Let's sum up major concerns/problems and unify/create a plan of actions. We already decided to wait with mainline H3-H5-A64 ... which means old stable/legacy kernels/a10-20-xu4 (what else?) mainline should be rebuilt and what remains goes under nightly? Images can be made one board at the time, they can be made in exactly 4 days or not. Perhaps I should emphasize "approximately" more? Or remove this date since it only creates an extra pressure? Or is it ok? This should be fun. For me, most of the time is even sometimes days are wasted and frustration or stress builds up to insane levels. We know which kernels are not done and there is nothing we can do in a week(s)/month, so let's focus now only on userspace and kernels which are labeled stable ... and what shall be removed from /download and dl. ? Since we don't go out with mainline H3-H5-A64 major testing is not that critical, but things are rolling in that direction. With a delay. I am aware we are not organized perfectly. It's also WIP

To me, the main problem was attitude: double demand from anonymous to fix his problem. In 24h. By amateurs. Sometimes pleads (this was not a plead but demand) can be done over the line but generally, this is not possible and we should tell this. Now, let's stop wasting time on this - it will be fixed when possible.

https://github.com/armbian/build If you don't know how to fix this, hire someone.

Yes. Exactly as written.

4.13.11 autodetect resolution. This means it asks your TV for it. Check TV settings first before you want to explore advanced settings (note that changes will come into action after second boot) at armbian. And you are in a development area which means things might not be developed, they certainly are not well tested and 100% not aligned with documentation. Bottom line. Not for end users. You still are welcome to explore but expect problems.

Kernel 4.11 is deprecated / end of life. We moved to 4.13 but images are not yet out ... but you can build one - choose NEXT kernel.

1st possible dirty workaround: cp $SRC/packages/blobs/desktop/vibrancy-colors_2.7~xenial~Noobslab.com_all.deb $SDCARD/root/ chroot $SDCARD /bin/bash -c "dpkg -x /root/vibrancy-colors_2.7~xenial~Noobslab.com_all.deb /" rm $SDCARD/root/vibrancy-colors_2.7~xenial~Noobslab.com_all.deb

Please provide detailed information what you did, logs if possible, a picture where it stops, ... without I can't imagine what is wrong.

And where you put that kernel? To Armbian or somewhere else?

Yes. Even set the same, no impact

https://docs.armbian.com/Developer-Guide_Build-Preparation/

I wasted hours on this problem today and no success. - I repacked package with no compression, xz, gzip, ... you name it. - I tried changing max open files inside a chroot https://lists.debian.org/debian-user/2010/09/msg01318.html - deb package has little more than 25000 files with links. If I repack it with just "a little file" ... it works. - it looks its related to a number of files since the same file size .deb pack installs normally Any clue?

Have you try those perhaps:

It doesn't. But it also doesn't work if I revert URL rewrite. Forum has to have at least one bug

@zador.blood.stained Any idea why deboostrap is failing? target is Jessie. apt-catcher issue? It does not configure packages.

If you have a classroom with a lot of clients, yes. I have this 512GB 2242 in my server for about a year. Still working flawlessly. Its probably the best what you can get in this form factor but it's not NvME. I am not sure that such exists ATM. I don't know if there will be any gain with NvME drive. Don't have any spare at the moment to see. I attached some generic I2C display without a problem. Same should go for SPI. No need to use exactly clickboard products. Don't have any experiences with them but they should work. It's not rocket science. Kernel has build in drivers for many small displays https://github.com/notro/fbtft/ I would say it should work. Rather use M2 slot for fast SSD