Igor

Ubuntu is Debian based, but the main difference is packages selection and their versions. Since we also define the package base, most of the packages are the same but they are certainly not the same version. This means certain application might not work out of the box and you need to solve dependencies on your own. This can be simple or a true nightmare. In this case, it's better to start with a proper base, whether Ubuntu or Debian. One good example is OMV - it does not work at all on Ubuntu - at least not out of the box. Stable version requires Debian Jessie, while current development is based on Stretch. For a board, which might be used as OMV (Helios4), we provide both, Jessie and Stretch and it's up to the user to decide which OMV version he will go for. In the x86 world, a change between releases/distribution is usually also on a kernel branch, while here we don't have this luxury. We have to use what is available and since there is no better working kernel than 3.10.y for this board we simply can't provide Stretch. We could Jessie ... but since we provide a simple and easy to use build tools, this is not that urgent either.

One of the major goals of the project is to achieve universality among big diversity. Which is good. Now, moving more toward IOT use case would be the way to go. IMO a desktop is good enough and doesn't need more attention. At least not from a primary team. If there are folks, who have the intention to tune this up, perhaps even fix some web acceleration within Chromium ... welcome to play around and fix that overbranding mentioned by @zador.blood.stained Perhaps I really went too far with it. People are simply spoiled. The same case is with our "testing group" - only the first time there went through good enough, next time(s) I rather test all images on my own. This is now a serious multi-day task and it's not possible to test all. What happened if testing is not well organized? A lot of time is wasted, critical might completely slip through, frustration and anger build up. Also on the user's side, on those who ware too lazy to help to test. Frustration is usually a good motivator and we should make use of it. How? Be ready to aggressively recruit when releasing an update. Again, this we are a problem - who will take this HR like responsibility? If this is taken over by me or other individual who have not much clue what to do, just more frustration is building up on our side. This way only some problems are discovered. We already have a beta branch which shows us what is going on with a trunk. There are people who are using this and some do report when things broke. Perhaps more systematical approach on the infrastructure which is already there? In any case, we will not find all problems on all boards this way. The idea is marvelous, just how to get it up and rolling? I think we need a moderator/project manager for this section, something like @chwe is doing in this thread. Someone who transforms our ideas and babble into tasks? We are already under heavy load, I tend to be lazy when things jump outside of a primary goal and pessimistic that someone will just take and resolve some task. Let's simply reuse this term and - at the new web - expose this as a non-technical necessity "maintainer wanted" to move from WIP to supported section. On a related issue - yesterday, I received a question from @ebin-deb why we don't move Espressobin among stable and I point him here. Well, there are also some minor technical issues to be solved, but in a technical sense, it is ready.

Opi Prime is crashing for a currently unknown reason. That's why it is still in development/WIP section.

http://ix.io/F4j Mine (8G eMMC) works fine after upgrade from 5.37 (also with the mainline kernel) but I can revert this u-boot back to 5.35 ... We use more or less unchanged u-boot. Please report this incident to Hardkernel as well.

I suggest you to regularly backup your important data, not the whole system.

I also don't have eMMC for K2 but I know that this function is also broken on Odroid C2, which is almost identical to K2. Most eMMC cards don't work ... well, except mine Unfortunately, there is no known quick fix for this problem.

Nightly buildings are disabled since they are broken for A64 at this moment so it's pointless to make them. Use recommended builds at the download page. They are "recommended " for a reason. We don't provide Debian Stretch with older kernel because it lacks needed functionality, while Debian Jessie ... is a bit old and it's better to use an Ubuntu-based image. In any case, there is not any of Ubuntu junk on them. Stable kernel 4.y is months away.

Nope, on older systems, it was set to update the index and download only. https://github.com/armbian/build/commit/c6b065b68d8ac27b6f253bdb672ef4090b913571 With "apt upgrade" you conduct the actual install/upgrade. BananaPi was tested for the last update, but if you are using some very old build, changed system files ... who knows. It can also be a failed SD card ... Can you get a serial console log? Can you attach Banana to your HDMI screen and make a photo with your camera or at least show the content of files in /boot ...

Use apt purge method and remove them. This works out of the box, while default package list is not implemented as a user-defined variable.

That is unfortunately not implemented but should not be a hard job, while we don't store userspace caches online - it is uploading/can be on to the server and later auto synchronized, while the rest we ATM do not have time to work on. Since this might be generally useful and if you do it properly, I don't see a problem to accept PR? @zador.blood.stained

This is what you need to check: https://docs.armbian.com/Developer-Guide_User-Configurations/

If this is not enabled in a kernel you have two options: 1. Add whatever you need to this file https://github.com/armbian/build/blob/master/config/kernel/linux-sunxi-next.config and wait for our beta or general update 2. Recompile a kernel on your own.

The network works perfectly fine: 1. On stock unmodified image 2. When setting fixed IP 3. It fails when setting back to DHCP from within a (beta tool) armbian-config It will be fixed.

Preparing such copy/paste instruction is a nightmare :( You need to be in /mnt/boot/ and there you run mkimage without a path.

typo mkimage -C none -A arm -T script -d boot.cmd boot.scr

Replacing boot script with this one https://github.com/armbian/build/blob/master/config/bootscripts/boot-sunxi.cmd and its recompilation is another/proper solution. In case we forget to add a boot script to next update, the problem might resurface.

Forget about changing u-boot, replace rather boot script. It is more simple and actually the fix for the problem. 1. Boot with SDcard 2. Mount /dev/mmcblk2p1 /mnt # on some cases it will be mmcblk1p1 3. cd /mnt/boot 4. wget https://raw.githubusercontent.com/armbian/build/master/config/bootscripts/boot-sunxi.cmd 5. mv boot-sunxi.cmd boot.cmd 6. mkimage -C none -A arm -T script -d boot.cmd boot.scr 7. power off, 8. remove SD and boot from eMMC

Somewhere between problem was recognized and fixed, yes. When most people will just use this product, drop few pennies and not actively participating in testings, this will not change - we simply have too many different boards and variants. We can cut them down in half but the problem will remain. I recently developed a system for quick repository update, that packages can be quickly fixed in case of such problems, but that is all that I can do on the technical part of the problem. At least you were able to solve this without step by step guides. Of course, it is our my fault for providing this service with having sufficient resources.

If you "just did", it should be o.k. https://github.com/armbian/upload/commit/19a4a27ca2ace9c549400a8eface67c581a4b144

I don't understand your problem. Also provide your armbianmonitor -u

https://docs.armbian.com/Developer-Guide_User-Configurations/

Replacing bootloader on your eMMC Boot from SD card. mkdir tmp cd tmp # replace this URL with the one for your board! This is for Orange pi plus 2e wget http://apt.armbian.com/pool/main/l/linux-u-boot-orangepiplus2e-default/linux-u-boot-orangepiplus2e_5.39_armhf.deb dpkg -x *.deb . root_uuid=$(sed -e 's/^.*root=//' -e 's/ .*$//' < /proc/cmdline) root_partition_device=$(blkid | tr -d '":' | grep ${root_uuid} | awk '{print $1}' | tr -d '"/dev') emmc="/dev/"$(cat /proc/partitions | grep -v ${root_partition::-2} | grep mmcblk | awk '{print $4}' | head -1) # adjust the path accordingly to your board - downloaded file dd if=usr/lib/linux-u-boot-orangepiplus2e_5.35_armhf/u-boot-sunxi-with-spl.bin of=$emmc bs=1024 seek=8 status=noxfer If you want to flash your SD card on external SD card reader: sdcard=/dev/sda # make sure this is SD card and not your hard drive!! dd if=usr/lib/linux-u-boot-orangepiplus2e_5.35_armhf/u-boot-sunxi-with-spl.bin of=$sdcard bs=1024 seek=8 status=noxfer

The problem was there too but different kind of. I switch dev and next which lead to troubles with OMV installations. At least setting this to "yes"? https://github.com/armbian/build/blob/master/config/templates/config-example.conf#L22

Changed back https://github.com/armbian/upload/commit/c68b8c84f9edfdfd55f1579894f05035e637022a And also Odroid XU4 upgrade to NEXT https://github.com/armbian/upload/commit/36437b8a9704a5056fccb6ed154b69778716bed8 At least upstream those problems should be fixed by now.

Remove /etc/network/interfaces and network-manager should pick up the address. And reboot in between.