Igor

What about https://support.ipconfigure.com/hc/en-us/articles/213384266-Install-Oracle-JRE-on-Debian-Linux-including-ARM-architectures-

Merged into master since few weeks.

It is possible that there are no bits in the device tree ... so we need another patch for the kernel. Edit: I can prepare another image later on.

It is enabled since u-boot2018/05, kernel 4.17.y ... and I can't double check atm. Edit: switched + added text that you need to use nightly images for Core. CTRL R?

But I guess it's better to merge it with Neo (now eMMC support is enabled by default and this should not affect normal Neo functionality), as I did it now since it also has ethernet while Air doesn't. At least on this shield. @guidol Check download https://www.armbian.com/nanopi-neo/ ... if nightly images are exposed and named properly?

Try this image: https://dl.armbian.com/nanopineo/Debian_stretch_next_nightly.7z

Check: https://dl.armbian.com/micro/archive/ Hardware troubles would explain strange errors ...

That is something different. We might have some troubles here. Can you provide a link to the download page. I am not sure which image you are using. If you run the board, type armbianmonitor -u

Updating OMV from 3 to 4? P.S. I temporally disable u-boot updating on C2.

Those are build system areas. You copy linux-sunxi-next.config to build/userpatches/ and edit there ... the same goes with patches, copy to userpatches/kernel/sunxi-next (in this case) and rename to .patch ... those .disabled are for our internal needs. Sure it is. https://docs.armbian.com/Developer-Guide_User-Configurations/ Add: KERNELBRANCH='tag:v4.14.52' to build/userpatches/lib.config

Unfortunately, it is a necessity due to source diversity. Packaging script from kernel 3.4.y is very different from the one from 4.17.y. Then there are small changes in between. If someone would dig into and clean up this mess, we could end up probably with 4 different patches + a patch that differentiate our DEV and NEXT kernel branch naming. Since all this mess works, upstream changes in this sections are extremely rare ... we don't touch it.

eMMC is a different technology than NAND and yes, that is better than SD card. eMMC act as another/second (fixed) SD card ... you only need to boot from SD card and use nand-sata-install utility and transfer the system to eMMC, power off when it's done, remove SD card and boot from eMMC should work. Olimex Lime 2 is one of the few boards that comes with NAND, eMMC or without. The rest is the same.

OK, than rather this way.

Dietpi is a bash script (that break Debian into something strange) on top of Armbian. It's our kernel and our u-boot but without end user support. They don't add nor change anything in this regard. That's why this is strange and I want to know why it is not working ... serial console cost 2USD shipped and saves a lot. We both could do something else at this moment. At least edit card on some linux and change verbosity to 10 and console=display in /boot/armbianEnv.txt, save, boot and make a picture where it hangs.

Images are tested and they work. All H5 images/kernels are still marked as development/testing. For a reason. Most of the other images use stock Allwinner u-boot/kernel which has it own bugs, except Dietpi, which used to use our image + their Debian cripling script on the top. Now they dropped "support" since they only create BASH scripts ... Since you don't provide any exact data and think it is all our fault, we can't help. I am out of office and can't help much anyway. We need serial console boot logs to debug. (or change console to tty1 and alter verbosity to 10)

If you have some bad SD card 3 minutes might not be enough ... Under the same condition? Same SD card and power supply? Are you sure?

@tkaiser Shall we rework this to set MIN, MAX and governor with armbian-hardware-optimization and our variables go to /etc/defaults/armbian-cpu-config?

I am not sure we can help anything in this topic. We don't have kernel 3.4.79 from Linksprite. We never had it. But A20 is very well supported in mainline kernel so you can try to use that instead. I don't have this particular board nor we support it, so some specifical things might make you troubles ... Get last mainline build (or better, build one. You need to use EXPERT="yes" switch for building unsupported images), switch to beta, upgrade and run armbian-config -> system -> hardware and see if you can manipulate any settings.

This means you have the wrong image (without eMMC support) for your board. We actually don't know which board you have ... make a picture of it, both sides to make sure.

that is normal ... how long did you wait? do you have a serial console perhaps to see what's going on there?

Average SD card is better than NAND. We use memory for /var/log by default ... NAND works only with old 3.4.y kernel ... which is kind of old. There is no magic ... nand-sata-install ... if it doesn't work, we need to see serial console log to debug.

Implemented.

True, I missed that. Thanks! Well, this has to be completely changed. I'll disable this nightly until its solved.

It doesn't say stable anywhere, but there is a label "supported" while it should not be (fixing it) ... it said "nightly mainline kernel" and at login, you should saw many warnings that this is a test build ... anyway, it might work but rather use Debian Stretch based build with 4.14.y, first download link. 4.17.y is still in the oven ... not ready yet. Ubuntu Bionic is buggy by default/upstream, regardless of the kernel you start with. They (Canonical corporation) still need to fix many bugs. We wanted to ... but there are many of them and our resources are too tiny for such operation.

We don't know that You upgraded to unsupported/beta/development build, where things might not work at all. Try armbian-config -> system -> hardware and enable UARTs ...