Igor

You made a typo. That's why id doesn't work. systemctl start NetworkManager.servce systemctl start NetworkManager.service

Yes, but this means you are on your own. We don't try to support boards you find in there. They might work or not. They might become supported (WIP), they will probably never be(CSC) or support ended (EOS).

We certainly don't need to go that much into the details, but how much is enough. I only know that this decision shall be made before we sweep the database and waste time adjusting this. I made this decision based on propositions found in this topic ... I am really not sure what is the best. What should be there? Something between a single download link and a bunch of tags which describe overall experience. Hardware and software wise since its hard to tell what people think is hw and what sw. Even we have this dilemma sometimes. If BT stops working, this is just a bug and disclaimer shall be extended/modified that we are covered. Well. This is not that simple as it might sound. People are welcome to use whatever and we shall not scare them ... for example. A few weeks ago I saw someone wasting time with Espressobin bin stock Ubuntu build which is the one and only build and horribly outdated. I recommended: Hey use Armbian. It is in a much much better state ... and his response was ... oh? Really? I didn't even bother to try it since it was labeled testing. What does this tell us? Our only problem is that we don't want that people bother us with support when things are clearly not done and/or full of bugs. We have to say loud: when some board starts to receive our support is already miles away from a stock build, but it can't be just stable yet. Espressobin bin is a typical example. The main problem with our website is/was bad UX and the key feature of a bad UX are confusions. We have to cut them down and if bigger feature list helps in this matter but with higher maintenance cost, be it. In the end, there shall be a compromise anyway.

Yes. I don't use a heat sink.

Unpacked linux-firmware is around 250Mb, while our custom firmware is 8Mb and it covers onboard + most popular ones. Since we have armbian-config in action: "Install full firmware package" should solve this problem.

It looks like a bug to me or bugfix due to problems related to our dedicated (smaller) armbian-firmware package linux-firmware package is only for Xenial ... I am not sure. Will check a little.

An early preview of the download page. There are some concerns regarding specifications - are there too many of them and is it really hard to keep it updated? (nevertheless its more simple than updating such text) Eg. IMO Bluetooth is ticked only if it's working and not if the board has it, some specs might be kernel related (docker), some are undisputable (RPi size), some came only in full/the best version of the board. Makers logo and SoC data also be aligned below in specifications. Is it correct wording?

Use older version until this is solved.

What do you mean by that? Which clock?

A bug is definitely Debian Stretch related since changing console keyboard works fine on Ubuntu Xenial with the correct command: dpkg-reconfigure keyboard-configuration HDMI out, changed keyboard layout in the middle from German to Slovene. It works. I'll try to find it and resolve.

For now and to be realistic, we can further minimize possibility: - split u-boot package and kernel for updating. - create a bulletproof recovery method: perhaps even auto-revert if booting after update not successful - release one kernel(images) at once

OK. I left dev stuff in by default and only removed vim package, change apt list to compressed one and tweaked image size (overhead from +40% down to +10% for CLI images): [ o.k. ] Preparing image file for rootfs [ tinkerboard stretch ] [ o.k. ] Current rootfs size [ 753 MiB ] [ o.k. ] Creating blank image for rootfs [ 961 MiB ] I am not sure if 10% is enough ... perhaps 15% will be right number.

We need those packages: https://github.com/armbian/build/blob/master/lib/configuration.sh#L121 only here: https://github.com/armbian/build/blob/master/lib/distributions.sh#L112 https://github.com/armbian/build/blob/master/lib/image-helpers.sh#L80 ?

Few more fixes and ... images are rebuilt. Default and next.

... but by observing this patch and doing some search and reading results, one can add new screen resolution on his own.

Mine 1080p display doesn't cause any problems if attached when the machine is up. [ 24.075231] Console: switching to colour frame buffer device 240x67 [ 24.108325] sun4i-drm display-engine: fb0: frame buffer device

Perhaps @Jimmy Belanger can help in this. He already made something similar:

Splendid. Right after my breakfast

I made another test with a different image, different SD card, with a serial console attached and without. No problems. It could be (partially) broken board, lower quality memory chips ... in this case you need to build your own u-boot with lower dram settings. Unlikely, but possible.

Nobody can't tell you if it is good (measure voltage on the board). Just get some other one, change everything but the board. Check also Ubuntu image, which is the one I used for testing - if you haven't already.

There are no problems with our images. Double checked. Make sure you read this and act accordingly. (throw away your PSU, cable or both)

We are trying hard not to break anything since dealing with users is our direct cost. You are asking for my personal time for free, remember this. If you would find a serial console, we might be able to provide you hints for recovery ... some generic you can also find here and you will not waste your time in first place. Armbian is the one if not the only one that provides such updating in a first place. On most others, this is the only way.

It is not exactly a distribution bug if you run out of memory for logs - which is set very low by purpose. You can tweak the size, you can tweak logrotate, flushing or disable entirely. Out of memory is generally a problem. I agree that there is a room for improvement and am happy that someone is prepared to improve those scripts.

Update. CMS backend is fully operational at this stage, tested and actual data is slowly moving there, frontend early WIP, sorting at download selection is not finished, the download page is also in making. Check below if this way is better. Exceptions - like a partially broken or slow SATA can be added as one of the device issues or we only expose known working features and strictly forget about crippled ones? WIFI on Opi Zero, Sata on some Oranges, ... ? Solved. This is how adding a device looks like. This is how editing a kernel looks like: This is copy paste from the internal manual "how to add things". It might trigger valuable questions if backend needs more changes, something important was left out or this how-to is unclear: