zador.blood.stained

USB ports are powered through SY6280AAC with current limit set to ~1.1A (one switch for a double USB socket and another switch for a single USB socket), so IMO if something would degrade from peak current of spinning up HDDs it would be these switches.

AFAIK this is only for the cache, and browser cache != browser profile, so settings, bookmarks, extensions and other things still live on persistent storage and only cached web files are on tmpfs.
 
Current log2ram version deals only with 1 hardcoded directory, we need to check if folder2ram is more universal.

Current status of mainline kernel and u-boot on H3 boards (kernel branch orange-pi-4.11 and u-boot version v2017.05)
Not all boards are supported and patches for some boards even were not published yet. That means that future upgrades may temporary break some functionality or may break the system completely (i.e. if Device Tree file names change) Ethernet driver branch that is being used in unsupported/obsolete. This means if there are any issues there are no maintainers that can investigate and fix these issues (and there was a serious issue with the previous Ethernet driver version that was fixed only ~2-3 weeks ago) DVFS and THS are WIP. These means they are not enabled on all boards and future upgrades may temporarily break these features even where they are currently working. Operating points may change too, but it's not an issue to be concerned about. Display - only simplefb is available (which means no Mali driver, no DPMS), also custom resolution and overscan parameters (for HDMI) can't be set. Obviously no HW video decoding USB OTG probably doesn't work as it will be officially added only in 4.12  
Regarding Neo Air:
This board will be officially added only in kernel 4.12, and currently it uses DT for the NanoPi Neo with some patches on top. This means that Air specific functionality (wireless and eMMC) may break with update to kernel 4.12. No idea if Bluetooth works out of the box. Most likely not. DVFS and THS are enabled for this board, so overheating should not be a problem. But for these small boards using a heatsink is highly recommended.  
so TL; DR - mainlie based images can be used, but please mark kernel packages as "hold" to prevent upgrades.

Yes

Hey guys,
 
Awesome news, our Kickstarter campaign is finally live. Be amount the first backers and enjoy our early bird deals :

Our kickstarter page :  Helios4
 
For some specs : Helios4_Specifications.pdf
 


Basic Kit - 1GB (USD$125)
(Save 16% off the $149 Retail - Limited to 50 units)

Full Kit - 1GB (USD$139)
(Save 18% off the $169 Retail - Limited to 130 units)

Full Kit - 2GB (USD$165)
(Save 11% off the $185 Retail - Limited to 70 units)
 
Our kickstarter page :  Helios4
 
Cheers ;-)
 

Mounting by UUID may be a solution for changing mmc device numbers.

OK. This breaks it:
➜ u-boot git:(4943dc2) % git bisect bad 4943dc2f1977cf89297b87f93f96ad4d7f09d24d is the first bad commit commit 4943dc2f1977cf89297b87f93f96ad4d7f09d24d Author: Cédric Schieli <cschieli@gmail.com> Date: Mon Jan 23 16:51:45 2017 +0100 bootz/booti: relocate ramdisk if CONFIG_SYS_BOOT_RAMDISK_HIGH set In commit c2e7e72, the ramdisk relocation code was moved from image_setup_linux to do_bootm, leaving the bootz and booti cases broken. This patch fixes both by adding the BOOTM_STATE_RAMDISK state in their call to do_bootm_states if CONFIG_SYS_BOOT_RAMDISK_HIGH is set. Signed-off-by: Cédric Schieli <cschieli@gmail.com> Reviewed-by: Rick Altherr <raltherr@google.com> Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>  

OK. This breaks it:
➜ u-boot git:(4943dc2) % git bisect bad 4943dc2f1977cf89297b87f93f96ad4d7f09d24d is the first bad commit commit 4943dc2f1977cf89297b87f93f96ad4d7f09d24d Author: Cédric Schieli <cschieli@gmail.com> Date: Mon Jan 23 16:51:45 2017 +0100 bootz/booti: relocate ramdisk if CONFIG_SYS_BOOT_RAMDISK_HIGH set In commit c2e7e72, the ramdisk relocation code was moved from image_setup_linux to do_bootm, leaving the bootz and booti cases broken. This patch fixes both by adding the BOOTM_STATE_RAMDISK state in their call to do_bootm_states if CONFIG_SYS_BOOT_RAMDISK_HIGH is set. Signed-off-by: Cédric Schieli <cschieli@gmail.com> Reviewed-by: Rick Altherr <raltherr@google.com> Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>  

Seems so. Compare this and this. Pick a place to fix it.
 
Please note that TV out is not included in this patch. I will add it when I will have time.
 
P.S.: It looks like this driver will be in next U-Boot release. Unfortunately, I can't say the same for fixes I sent later (they go in through different repo).

I'm in favor of leaving everything as is for now. This Etcher implementation is still in beta, we have enough issues and migrations to deal with, so jumping from one compression format to another IMO is not something urgent.

As it was stated in one of the threads you linked, an untested kernel was pushed to the stable repository by mistake, and since your initial kernel version was 4.10.12, this updated kernel was installed on your device before you tried to downgrade it.
 
For the reference "upgrade.armbian.com" is obsolete and I am surprised that it is still not disabled.

I'm in favor of leaving everything as is for now. This Etcher implementation is still in beta, we have enough issues and migrations to deal with, so jumping from one compression format to another IMO is not something urgent.

Wait (1 week or more) until migration to 4.11 is completed or use a previous nightly image with kernel 4.10

Done.

Depends on what was changed between the builds. Nightlies are made for testing purposes without additional considerations regarding upgrades.
apt upgrade will affect the kernel, DT and board support package, but will not affect boot script changes, default package list changes and some build time tweaks.
 
In the end if you are using nightly images not for testing purposes it's better to not upgrade the kernel and DT unless you need something specific that will only appear in the newer kernel. For example due to ongoing migration to kernel 4.11 DVFS will be broken on H5 boards (including PC2) if you update from earlier kernel.

It would be good to add 2 new features in the future:
enable or disable MOTD scripts (individually) freeze or unfreeze kernel and board support packages (`apt-mark hold`)

It would be good to add 2 new features in the future:
enable or disable MOTD scripts (individually) freeze or unfreeze kernel and board support packages (`apt-mark hold`)

Unless it is confirmed by vendor that DVFS table can be safely extended for all boards, additional operating points should not be added to the shipped DT.
Official Armbian builds are not about providing overclocking with the risk of instability.

@plasta-blaster instead watching oil cooling, how about this, then you know how to fix YOUR Device-Tree-Source. 
I read the document a year ago "Device Tree for Dummies!" http://www.ohwr.org/documents/435

If you are talking about FFmpeg libraries conflict - then it was fixed. If you are unsure - you can always make a full SD backup before trying a new image and revert back if there are any serious issues with the new system.

The OPiZero DT in 4.11 wasn't enabled and didn't have PHY assigned. I added a patch in Armbian builds.
Either you wait for next nightly build, or add this patch and build it yourself :

Why do we waste our time with this board (which will most likely be the same shit show as M2+ was/is -- at least that's the device I lost most time with due to vendor even too stupid to provide correct schematic).
 
Why not spending our time on improving things with other boards or Armbian in general (Wi-Fi firmware situation, refactoring to deal better with more and more boards and installation variants, preparing Debian Stretch and so on)?

Small progress: factory calibration data can be extracted from NAND using NAND update tool (Export Fact button)

@Igor https://groups.google.com/forum/#!topic/linux-sunxi/kztLGFTBgZw
 

... or not. Again, it's a benchmark. It doesn't necessarily hit the bottleneck in the system it was designed to measure, it doesn't tell you where the bottleneck is that is responsible for the numbers you are getting and it doesn't take all the factors into account.
 
Well, results in this thread show some numbers related to the I/O performance, nothing more.
If you wanted to really compare filesystems and not underlying storage, you would need to test a lot of other things:
CPU utilization by the FS driver in different scenarios memory utilization by the FS driver in different scenarios storage space overhead for the internal FS data comparison of available FS tweaks that may affect 3 previous points and for the "scenarios" you may wanted to test
creating a large number of files and directories removing a large number of files and directories renaming or changing metadata for the large number of files and directories appending or removing data in existing files traversing a large directory tree  
So in the end if I/O performance numbers do not differ very much it doesn't mean that filesystems will show similar performance results in different real world scenarios not related to reading or writing files