laibsch

So I have two boards, and two images, both built with armbian-build. I built `current` on March 24th 2025 and HDMI and everything works great
 
I built one this week and there is no HDMI output.
 
Logs of the non-working one:
 
Apr 07 18:36:09 radxa-zero3 kernel: mmc2: new UHS-I speed SDR104 SDIO card at address 390b Apr 07 18:36:09 radxa-zero3 kernel: rk808-rtc rk808-rtc.4.auto: registered as rtc0 Apr 07 18:36:09 radxa-zero3 kernel: rk808-rtc rk808-rtc.4.auto: setting system clock to 2017-08-05T09:00:10 UTC (1501923610) Apr 07 18:36:09 radxa-zero3 kernel: rockchip-vop2 fe040000.vop: Adding to iommu group 0 Apr 07 18:36:09 radxa-zero3 kernel: rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_component_ops [rockchipdrm]) Apr 07 18:36:09 radxa-zero3 kernel: dwhdmi-rockchip fe0a0000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY) Apr 07 18:36:09 radxa-zero3 kernel: dwhdmi-rockchip fe0a0000.hdmi: registered DesignWare HDMI I2C bus driver Apr 07 18:36:09 radxa-zero3 kernel: rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops dw_hdmi_rockchip_ops [rockchipdrm]) Apr 07 18:36:09 radxa-zero3 kernel: [drm] Initialized rockchip 1.0.0 for display-subsystem on minor 0 Apr 07 18:36:09 radxa-zero3 kernel: rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes Apr 07 18:36:09 radxa-zero3 kernel: rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes  
Logs of the working one:
Mar 24 21:17:04 radxa-zero3 kernel: mmc_host mmc2: Bus speed (slot 0) = 150000000Hz (slot req 150000000Hz, actual 150000000HZ div = 0) Mar 24 21:17:04 radxa-zero3 kernel: dwmmc_rockchip fe2c0000.mmc: Successfully tuned phase to 150 Mar 24 21:17:04 radxa-zero3 kernel: mmc2: new ultra high speed SDR104 SDIO card at address 390b Mar 24 21:17:04 radxa-zero3 kernel: rockchip-vop2 fe040000.vop: Adding to iommu group 0 Mar 24 21:17:04 radxa-zero3 kernel: rk808-rtc rk808-rtc.4.auto: registered as rtc0 Mar 24 21:17:04 radxa-zero3 kernel: rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_component_ops [rockchipdrm]) Mar 24 21:17:04 radxa-zero3 kernel: rk808-rtc rk808-rtc.4.auto: setting system clock to 2017-08-05T09:00:10 UTC (1501923610) Mar 24 21:17:04 radxa-zero3 kernel: dwhdmi-rockchip fe0a0000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY) Mar 24 21:17:04 radxa-zero3 kernel: dwhdmi-rockchip fe0a0000.hdmi: registered DesignWare HDMI I2C bus driver Mar 24 21:17:04 radxa-zero3 kernel: rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops dw_hdmi_rockchip_ops [rockchipdrm]) Mar 24 21:17:04 radxa-zero3 kernel: [drm] Initialized rockchip 1.0.0 for display-subsystem on minor 0 Mar 24 21:17:04 radxa-zero3 kernel: Console: switching to colour frame buffer device 240x67 Mar 24 21:17:04 radxa-zero3 kernel: rockchip-drm display-subsystem: [drm] fb0: rockchipdrmfb frame buffer device  
On the non-working one, I've tried both the same kernel version (6.12.20) as well as the most recent `current` (6.12.21), and edge (6.14.1).
 
Buildling a vendor image on bookworm works fine. Given I have two systems where one works and one doesn't, what can I check between them (deb package versions maybe? DTB files?) to help debug this?

I know Ext4 and 1st boot resize is used, but I have manually recreated rootfs to be Btrfs. On NanoPi-R6C it is u-boot code in first 16M of SD or eMMC, then a 256M FAT32 partition with Image uInitrd DTB overlays. I made an extra script for update-iniitramfs to copy those for a certain kernel version to the FAT partition.
 
In a qemu VM, I use a custom enhanced u-boot that has Btrfs support, so no bootFAT needed anymore.  This should also work on real HW,
 
The advantage of Btrfs for root is that you can move the rootfs from SD to eMMC (or NVME) I a live running system (btrfs replace start ...) At finish, only dd with u-boot loader to eMMC is needed. Then take out SD-card and done, no reboot needed, same rootfs UUID. Creating partition on eMMC is still needed of course, but can be just max of eMMC. Btrfs can always be shrunk later on in live system. So that is what I did several times also to install other OS variants in other partitions of the eMMC (and mostly NVME as that is much faster).
 
I haven't looked in armbiam-installer. I know when selecting Btrfs as rootfs in builder, you get Ext4 for boot and Btrfs for root. This is what I use on NanoPi-NEO and BananaPi-M1 (created manually long time ago). Those don't have eMMC or SPI-flash and it works fine. But tempting to write a Btrfs enabled u-boot to the proper place at the beginning of the SD-card and merge Ext4 /boot into rootfs.
I am a bit unsure about building 32-bit u-boot but i think i can temporary used systemd-nspawn of a 32-biit rootfs on RK3588 so fast building.
 

Until only you, me and those few people that will read this thread knows about this .... doesn't make any sense. Our current download logic and UX is very bad at this state, almost as bad as Debian  It is very difficult to know that such image exists, what are their advantages (this part I have some draft and will be sent to the docs eventually), then telling them that they can choose between .xz .qcow2 .xz.qcow2 ... while ISO (what people understand) is nowhere to be found.

Enabling a feature at build framework. This is trivial and I think it's even supported with a switch already "KEEP_UNCOMPRESSED_IMAGE" or similar, but its not supported at CDN. When compressed qcow2 was replaced with uncompressed, redirection followed as it doesn't carry file extensions https://dl.armbian.com/uefi-arm64/Noble_cloud_minimal-qcow2 which means we don't have support for .xz at this moment. Changing this? Chain of command and execution is slow, I can't deal with everything, and people are busy. I still wait that https://dl.armbian.com/uefi-arm64/Noble_cloud_minimal-hyperv.zip (HyperV Azure) started to work. As you can see, compressed is even bigger then qcow2 image and apparently it has to be zip (don't know that yet). Once re-director is extended, now hard coded values goes out of the code, so its small refactoring - easier job for the future. When re-director is fixed, we need to adjust (already messy) web page. Which is now half broken, those cloud images are mixed with minimal / IOT. You don't know until you click on the link.
 


 

That cloud kernel supports features required to run Docker. Something like this:
 
curl https://raw.githubusercontent.com/docker/docker/master/contrib/check-config.sh | bash  
 
Already have some draft ready, but wanted to do more tests before. On some clouds.

Yes. Cloud providers, those that accept direct qcow2 images loading, expect uncompressed variant. It is handy if you can just pass URL or upload image without any additional handling.
 
 
This should address the problem.
https://github.com/armbian/build/pull/8046

shrink-backup is a bash script for backing up your SBC:s into an img file
Version 1.2
Info updated: 20 Oct, 2024.
shrink-backup
 
I made this script because I wanted a universal method of backing up my SBC:s into img files as fast as possible (with rsync), no matter what os is in use.
 
Supports backing up root & boot (if existing) partitions. Data from other partitions will be written to root if not excluded (exception for btrfs, all existing subvolumes in /etc/fstab will be created).
Please see Info section.
 
Autoexpansion tested on Raspberry Pi os (bookworm and older), Armbian, Manjaro-arm, DietPi and ArchLinuxARM for rpi with ext4 or f2fs root partition.
(Now also experimental btrfs functionality, please read further down)
Full support for usage inside webmin (including "custom command" button).
 
Latest release: shrink-backup.v1.2
Testing branch if you want to have the absolute latest version. There might be bugs.
 
Very fast restore thanks to minimal size of img file.

Can back up any device as long as root is ext4 or f2fs (experimental btrfs)
Default device that will be backed up is determined by scanning what disk-device root resides on.
This means that if boot is a partition, that partition must be on the same device and before the root partition.

Backing up/restoring, to/from: usb-stick /dev/sdX with Raspberry pi os has been tested and works. Ie, writing an sd-card img to a usb-stick and vice versa works.

Ultra-fast incremental backups to existing img files.

See wiki for information about installation methods, usage and examples.
Ideas and feedback is always appreciated, whether it's positive or negative. Please just keep it civil.
If you find a bug or think something is missing in the script, please file a Bug report or Feature request

Don't forget to ensure the script is executable.

To restore a backup, simply "burn" the img file to a device using your favorite method.
When booting up a restored image with autoresize active, wait until the the reboot sequence has occured. The login prompt may very well become visible before the autoresize function has rebooted.
 
Usage:
shrink-backup -h Script for creating an .img file and subsequently keeing it updated (-U), autoexpansion is enabled by default Directory where .img file is created is automatically excluded in backup ######################################################################## Usage: sudo shrink-backup [-Uatyelhz] [--fix] [--loop] [--f2fs] imagefile.img [extra space (MiB)] -U Update existing img file (rsync to existing img) Optional [extra space] extends img size of root partition -a Autoresize root partition (extra space is ignored) When used in combination with -U: Expand if partition is >=256MiB smaller than resize2fs recommended minimum Shrink if partition is >=512MiB bigger than resize2fs recommended minimum -t Use exclude.txt in same folder as script to set excluded directories One directory per line: "/dir" or "/dir/*" to only exclude contents -y Disable prompts in script (please use this option with care!) -e DO NOT expand filesystem when image is booted -l Write debug messages to logfile shrink-backup.log located in same directory as script -z Make script zoom at light-speed, only question prompts might slow it down Can be combined with -y for UNSAFE ultra mega superduper speed --fix Try to fix the img file if -a fails with a "broken pipe" error --loop [img] Loop img file and exit, works in combination with -l & -z If optional [extra space] is defined, the img file will be extended with the amount before looping NOTE that only the file gets truncated, no partitions Useful if you for example want to manually manage the partitions --f2fs Convert root filesystem on img from ext4 to f2fs Only works on new img file, not in combination with -U Will make backups of fstab & cmdline.txt to: fstab.shrink-backup.bak & cmdline.txt.shrink-backup.bak Then change ext4 to f2fs in both files and add discard to options on root partition in fstab --version Print version and exit -h --help Show this help snippet ######################################################################## Examples: sudo shrink-backup -a /path/to/backup.img (create img, resize2fs calcualtes size) sudo shrink-backup -e -y /path/to/backup.img 1024 (create img, ignore prompts, do not autoexpand, add 1024MiB extra space) sudo shrink-backup -Utl /path/to/backup.img (update img backup, use exclude.txt and write log to shrink-backup.log) sudo shrink-backup -U /path/to/backup.img 1024 (update img backup, expand img size/root partition with 1024MiB) sudo shrink-backup -Ua /path/to/backup.img (update img backup, resize2fs calculates and resizes img file if needed) sudo shrink-backup -Ua --fix /path/to/backup.img 1024 (update img backup, automatically resizes img file if needed, fix img free space) sudo shrink-backup -l --loop /path/to/backup.img 1024 (write to log file, expand IMG FILE (not partition) by 1024MiB and loop)  
-t (exclude.txt)
The folder where the img file is created will ALWAYS be excluded in the backup.
If -t option is selected, exclude.txt MUST exist (but can be empty) within the directory where the script is located or the script will exit with an error.
 
Use one directory per line in exclude.txt.
/directory/* = create directory but exclude content. /directory = exclude the directory completely.  
If -t is NOT selected the following folders will be excluded:
/lost+found /proc/* /sys/* /dev/* /tmp/* /run/* /mnt/* /media/* /var/swap Please see info section further down.
 
-l (Log file)
 
Use -l to write debug info into shrink-backup.log file in the same directory as the script.
 
 
-z (Zoom speed)

The -z "zoom" option simply removes the one second sleep at each prompt to give the user time to read.
By using the option, you save 15-25s when running the script.
When used in combination with -y warnings will also be bypassed! PLEASE use with care!


--fix (Broken pipe)

Add --fix to your options if a backup fails during rsync with a "broken pipe" error. You can also manually add [extra space] instead of using -a to solve this.

Example:
sudo shrink-backup -Ua --fix /path/to/backup.img
The reason it happens is because rsync normally deletes files during the backup, not creating a file-list > removing files from img before starting to copy.
So if you have removed and added new data on the system you backup from, there is a risk rsync tries to copy the new data before deleting data from the img, hence completely filling the img.

Using --fix makes rsync create a file-list and delete data before starting to transfer new data. This also means the backup takes a little longer.
Having a "broken pipe" error during backup has in my experience never broken an img backup after either using --fix (can be used in combination with -a) or adding [extra space] while updating the backup with -U.


--loop (Loop img file)

Use --loop to loop an img file to your /dev.

Example:
sudo shrink-backup --loop /path/to/backup.img
If used in combination with [extra space] the amount in MiB will be added to the IMG FILE NOT any partition.
With this you can run for example run: sudo gparted /dev/loop0 (if you have a graphical interface) to manually manage the img partitions in a graphical interface with gparted.
If you added [extra space] this will then show up as unpartitioned space at the end of the device where you can create partition(s) and manually copy data to by mounting the new loop partition that will become visible in lsblk.
If you do this, don't forget to create or update the img with -e (disable autoexpansion) first. Autoexpansion will not work since the space will be occupied by your manually managed partition.

Example:
sudo shrink-backup --loop /path/to/backup.img 1024
This functionality works on any linux system, just use the script on any img file anywhere available to the computer.

To remove the loop: sudo losetup -d /dev/loop0, change loop0 to the correct dev it got looped to.
To remind yourself: lsblk /dev/loop* (if you forgot the location after using --mount)


--f2fs (Convert ext4 into f2fs on img file)

ONLY use this for CONVERTING filesystem into img file, if you already have f2fs on your root, do not use this option.
The script will detect what filesystem is used on root and act accordingly.
Only supported with new backups, not when using -U.

Autoexpansion at boot is not supported for f2fs (there is no way of resizing a mounted f2fs filesystem, unlike with ext4) so resizing root partition have to be made manually after writing img to sd-card.
Resize operations (when updating backup with -U) is not available for f2fs as of now.

The script will make backups of fstab & cmdline.txt into fstab.shrink-backup.bak & cmdline.txt.shrink-backup.bak on the img.
It will then change from ext4 to f2fs in fstab & cmdline.txt and add discard to the options on the root partition in fstab.

Please read information about f2fs further down.
 
 
Info
 
Rsync WILL cross filesystem boundries, so make sure you exclude external drives unless you want them included in the backup. (separate /home for example)

The script will ONLY create boot (if exits) and root partitions on the img file.
The script will ONLY look at your root partition when calculating sizes.
Not excluding other partitions will copy the data to the img root partition, not create more partitions so make sure to manually add [extra space] if you do this.
Experimental btrfs is an exception to this, all subvolumes will be created.
 
Applications used in the script:
fdisk
sfdisk
dd
parted
e2fsck
truncate
mkfs.ext4
rsync
gdisk (sgdisk is needed if the partition table is GPT, the script will inform you)
 
########################################################################
 
Image creation

To create a backup img using recomended size, use the -a option and the path to the img file.

Example:
sudo shrink-backup -a /path/to/backup.img
Theoretically the script should work on any device as long as root filesystem is ext4, f2fs or experimental btrfs.
Since the script uses lsblk to crosscheck with /etc/fstab to figure out where the root resides it does not matter what device it is on.

Even if you forget to disable autoexpansion on a non supported system, the backup will not fail.
 
 
Order of operations - image creation
Reads the block sizes of the partitions Uses dd to create the boot part of the system + a few megabytes to include the filesystem on root (this can be a partition) Removes and recreates the root partition, size depends on options used when starting the script Creates a new ext4 filesystem with the same UUID and LABEL as the system you are backing up from Uses rsync to sync both partitions (if more than one)  
Uses lsblk & /etc/fstab to figure out the correct disk device to back up. Reads the block sizes of the system's root (and boot if it exists) partition. Uses dd to create the boot part of the system + a few megabytes to include the filesystem on root. (this can be a partition) Uses df & resize2fs to calculate sizes by analyzing the system's root partition. (For btrfs: btrfs filesystem du + 192MiB is used instead of resize2fs) Uses truncate to resize img file. Loops the img file. Removes and recreates the root partition on the loop of the img file. Creates the root filesystem on loop of the img file with the same UUID and LABEL as the system you are backing up from. Creates a temp directory and mounts img file root partition from loop. Checks if boot partition exists, if true, checks fstab and creates directory on root and mounts accordingly from loop. Uses rsync to sync filesystems. Tries to create autoresize scripts if not disabled with -e. Unmounts and removes temp directory and file (file created for rsync log output).  
Added space is added on top of df reported “used space”, not the size of the partition. Added space is in MiB, so if you want to add 1GB, add 1024.
 
The script can be instructed to set the img size by requesting recommended minimum size from e2fsck by using the -a option.
This is not the absolute smallest size you can achieve bit is the “safest” way to create a “smallest possible” img file.
If you do not increase the size of the filesystem you are backing up too much, you can most likely keep it updated with the update function (-U) of the script.
 
By using -a in combination with -U the script will resize the img file if needed (not supported on f2fs).
Using combination -Ua on an img that has become overfilled works, if not add --fix and retry.
Please see --fix and image update sections for more information.
 
 
Smallest possible image
 
To get the absolute smallest img file possible, do NOT set -a option and set “extra space” to 0
Example:
sudo shrink-backup /path/to/backup.img 0  
This will instruct the script to get the used space from df and adding 128MB “wiggle room”.

If you are like me, doing a lot of testing, rewriting the sd-card multiple times. The extra time it takes each time will add up pretty fast.
Example:
-rw-r--r-- 1 root root 3.7G Jul 22 21:27 test.img # file created with -a -rw-r--r-- 1 root root 3.3G Jul 22 22:37 test0.img # file created with 0  
Disclaimer:
Because of how filesystems work, df is never a true representation of what will actually fit on a created img file.
Each file, no matter the size, will take up one block of the filesystem, so if you have a LOT of very small files (running docker f.ex) the “0 added space method” might fail during rsync. Increase the 0 a little bit and retry.
 
This also means you have VERY little free space on the img file after creation.
If the filesystem you back up from increases in size, an update (-U) of the img file might fail.
 
By using -a in combination with -U the script will resize the img file if needed (not supported on f2fs).
Using combination -Ua on an img that has become overfilled works, if not add --fix and retry.
Please see --fix and Image update sections for more information.
 
########################################################################
 
Image update

To update an existing img file simply use the -U option and the path to the img file.

Example:
sudo shrink-backup -U /path/to/backup.img  
 
Order or operations - image update
Loops the img file. Probes the loop of the img file for information about partitions. If -a is selected, calculates sizes by comparing root sizes on system and img file by using fdisk & resize2fs. Expands filesystem on img file if needed or if manually added [extra space] is used. Creates temp directory and mounts root partition from loop. Checks if boot partition exists, if true, checks fstab and creates directory on root and mounts accordingly from loop.
Uses rsync to sync filesystems.
Shrinks filesystem on img file if -a was used and conditions were met in point 3.
Tries to create autoresize scripts if not disabled with -e.
Unmounts and removes temp directory and file (file created for rsync log output).
 
 
Resizing img file when updating

If -a is used in combination with -U, the script will compare the root partition on the img file to the size resize2fs recommends as minimum (or du calculations depending on filesystem).

The img file root partition needs to be >=256MB smaller than resize2fs recommended minimum to be expanded.
The img file root partition needs to be >=512MB bigger than resize2fs recommended minimum to be shrunk.
This is to protect from unessesary resizing operations most likely not needed.

If manually added [extra space] is used in combination with -U, the img file's root partition will be expanded by that amount. No checks are being performed to make sure the data you want to back up will actually fit.
Only expansion is possible with this method.

########################################################################

f2fs

The script will detect f2fs on root automatically and act accordingly.
Do NOT USE --f2fs unless you are converting from a ext4 filesystem (on your system) into f2fs on the img file.

Autoexpansion at boot is not possible with f2fs. User will have to manually expand img to cover entire storage media (f.ex sd-card) when restoring.
Resizing of img root partition while updating img (-U) is not possible with f2fs as of now. User will have to create a new backup if img runs out of space.
This is something I am planning to implement further down the line.


btrfs

ALL testing has been done on Manjaro-arm
THIS IS NOT A CLONE, IT IS A BACKUP OF REQUIRED FILES FOR A BOOTABLE BTRFS SYSTEM!

All options in the script should work just as on ext4. The script will detect btrfs and act accordingly.
The script will treat snapshots as nested volumes, so make sure to exclude snapshots if you have any, or directories and nested volumes will be created on the img file. This can be done in exclude.txt, wildcards should work.
When starting the script, the initial report window will tell you what volumes will be created. Make sure these are correct before pressing Y.

As of now, top level subvolumes are checked for in /etc/fstab and mounted accordingly, mount options should be preseved (if you for example changed compression).
Autoresize function works on Manjaro-arm.

----------------------------------------------------------------------------------------------------------------------------------------------------------

Thank you for using my software ❤️
 
A backup is not really a backup until you have restored from it.

We can discuss including this into CLI/desktop images. Not for minimal.

This is more or less expected for current since the HDMI implementation in this LTS version is very basic/incomplete. Features were and still are in development and did not make it into this version. If you need desktop use edge or vendor.

If there are no pre-built version available, use the build framework to create your own: https://docs.armbian.com/Developer-Guide_Build-Preparation/

Also documentation (related to this topic) is now in right state of mind: https://docs.armbian.com/User-Guide_Armbian-Software/#adding-example 
 
It is hard to add software title we never tried, installed and / or know nothing about, then expert user of this software adding it to (armbian-config) installer. We focused to make this task as simple as possible, to encourage you doing that and not opening us tasks (we already have 1000 x too many and won't ever complete).
 
We added popular titles to the system, which have some value for us, while everything else is mocked by more important tasks in other sections. 
 
But mechanism is there - use it, its user / developer friendly. Also its a nice and easy way to contribute to the open source.

Since I listed the history of different BSP kernels and settings a few posts above and have been asked by a fellow what's different between a recent Armbian Xenial desktop build and for example this OS image here based on loboris' build script... I thought: let's give it a try.
 
First big surprise: All the overheating issues we thought would've been resolved are still there in an OS image released a few weeks ago!
 
This image uses the insane overvolting settings from loboris so H3 is all the time fed with at least 1.3V and jumping up to 1.5V (see on the left the Vcore values). This way it's ensured that even when the board is totally idle SoC temperature will be close to 60°C (I've a heatsink applied to my Orange Pi PC Plus I tested with so be prepared that without a heatsink it gets even worse):
 

 
I installed RPi-Monitor and let the thermal fix script do its job to cure the installation:
root@OrangePI:~# wget -q -O - http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-h3.sh | /bin/bash Installing RPi-Monitor. This can take up to 5 minutes. Be patient please [x] done Checking and installing sunxi-tools if not available [x] done Patching RPi-Monitor to deal correctly with H3 [x] done Now you're able to enjoy RPi-Monitor at http://192.168.83.156:8888 root@OrangePI:~# wget -q -O - http://kaiser-edv.de/tmp/H9rWPf/fix-thermal-problems.sh | /bin/bash Trying to fix thermal settings on this board. This might take a few seconds up to 3 minutes. Please be patient. Starting now. Done Successfully repaired broken overvolting/overclocking settings. Reboot necessary for changes to take effect root@OrangePI:~# reboot Afterwards the VDD_CPUX voltage switched fine grained, temperatures looked better but of course this is still far from perfect since in loboris kernel the 1.3 GHz cpufreq step is missing so now with the sane settings maximum cpufreq isn't 1536 MHz but 1200 MHz.
 
I made also quick sysbench runs using 'sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4' (these are the three temperature peaks you see in the graph above):
Insane overvolted settings allowing 1536 MHz max: 116.3053 seconds After applying thermal fixes allowing 1200 MHz max: 117.9727 seconds And finally after rebooting the board into the normal Armbian installation allowing 1296 MHz max: 109.2925 seconds Since I refrain from using an annoying fan both the insane overvolted settings and the sane known as 'bronco settings' perform identical which is absolutely no surprise since with loboris overvolted settings H3 overheats way too early and therefore throttling is more heavy than with sane settings. Running with Armbian performance increases automagically since we optimized also our kernel settings and allow way more cpufreq steps (interested in details? Then read from here on)
 
I wanted to test other stuff (GPU/X11) but unfortunately loboris kernel not only misses the 113 patches we apply to the newer BSP kernel (just a few hundred security fixes still missing between 3.4.39 and 3.4.112) but also essential USB HID drivers eg. for my Apple keyboard and mouse so I wasn't even able to login. I then thought about replacing the old kernel with our latest Armbian kernel:
 
 
 
But to no avail since after converting our kernel image to the uImage the outdated u-boot on all the older OS images expects I rebooted and our kernel paniced since I failed to provide a way to look for the rootfs: http://pastebin.com/ehyk1XhQ
 
Anyway: I won't waste any more time with this since it's just crazy to use an image based on a horribly outdated 3.4.39 kernel lacking so much fixes and features. I could confirm that the most recent version of the GC2035 camera driver we included in Armbian yesterday is way better than the one included in this/loboris image, that thermal/performance settings still suck, no support for Wi-Fi on the new Oranges there, no access to eMMC (though it should work with loboris install_to_emmc script but I haven't tested since I don't want to wipe out my nice Armbian installation on eMMC) and so on.
 
Since I also don't know which real world applications make use of OpenGL ES (apart from irrelevant benchmarks and some games where it seems to be confirmed that Armbian's switch to the new BSP kernel and clocking Mali 400 with 600 MHz increases performance by 30%) I saw also no need to further waste time with testing other images. But as usual: YMMV

Download Armbian with OpenMediaVault (OMV) 
Currently (for testing) only 4 targets were build: rock5-itx, odroid m1, odroid xu4 and x86. Once its confirmed that works well, other targets will be assembled. 

Then boot the image, wait few minutes and login via:

http://ip_address_of_armbian_running_ha
U: admin
P: openmediavault
 
Test setup on Odroid M1:
 
 
Tested on:
Odroid M1 Raspberry PI 4  
DIY

Symptoms:
Board does not boot Armbian from inserted SD card, but may boot other distributions (based on old/legacy u-boot).
Following or similar output can be grabbed from the serial console:
U-Boot SPL 2017.01-armbian (Feb 02 2017 - 03:04:04) DRAM: 2048 MiB Trying to boot from MMC1MMC: no card present spl: mmc init failed with error: -123 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### The key message here is "MMC: no card present"
 
Most likely cause:
Malfunctioning microSD slot card detect switch.
It can be verified either visually (with a magnifying glass) or electronically (with a multimeter) - at least in the slots used on Orange Pi boards and on Pine64 the pin near the switch should be shorted to the ground (i.e. SD slot casing) when card is inserted.
 
Illustration (example) of a working switch:

 
Verification (with a multimeter):
Probe 1 - slot pin near the switch (may be different for different slot types, but at least true for Oranges and Pine64)
Probe 2 - microSD slot casing or other parts connected to GND (not shown on the photo)
No card - circuit is open
Card inserted - circuit is shorted
 
Photos - card is not inseted on the left and is fully inserted on the right:
Orange Pi
 
Pine64 (switch is more visible)
 
Can it be fixed?
Yes if the switch is not broken completely, by carefully adjusting (bending) the stationary contact (left on the pictures and photos, it usually is a part of the SD slot casing) i.e using a needle so it touches the moving contact (mostly hidden inside the slot on the photos) when card is inserted and not touching it when it is not inserted.