zador.blood.stained

@berturion
 
 
This doesn't look like PARTUUID unless you are using GPT on your USB drive. Partition UUID will work without initrd, while filesystem UUID won't.
Look at this output of "blkid" for example:
# blkid /dev/sda1: LABEL="share" UUID="25616f82-0842-4af4-aea8-8ee54cf2df9d" TYPE="xfs" PARTUUID="0004cde8-01" /dev/sdb1: LABEL="Red" UUID="4a6e870b-f6f7-4b68-9864-55da3b328a75" TYPE="xfs" PARTLABEL="Red" PARTUUID="dccadf90-01e7-4624-99f9-9858ce11ea8f" /dev/sda is using MBR, /dev/sdb is using GPT.
 
If you are using PARTUUID correctly, please try to get a boot log on serial console and post it here.

- build script: support for Xenial as a build host is 95% ready.
- build script: implemented automatic toolchain selection
step 1: if kernel or u-boot needs specific GCC version, add this requirement in LINUXFAMILY case block in configuration.sh variables KERNEL_NEEDS_GCC and UBOOT_NEEDS_GCC, supported relationships are "<", ">" and "==", GCC version needs to be specified as major.minor.
i.e. 
UBOOT_NEEDS_GCC="< 4.9" step 2: unpack toolchains (i.e. Linaro) in $SRC/toolchains/ For running Linaro 4.8 on x64 build host you need to enable x86 support:
dpkg --add-architecture i386 apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 libtinfo5:i386 zlib1g:i386 step 3: run compilation process and check results. Report discovered bugs here on forum on on GitHub.

You'll need to remove "ramlog" from /etc/init.d/rsyslog LSB header then.

I will be testing R1 b53 switch with latest Armbian updates for kernel 4.5.2
 
edit : the patch for R1 b53 switch is working Lamobo-R1 up and running!
 
edit : Thanks Zador.blood.stain

Let's move this off topic to other:
specific info what we are working on general. open or join topic.  i am following this basic task handling logic I am always open for suggestions to make things different way. I am not saying my approach is the best or most perfect but sometimes I am (we are) just not in a coding mood or I am (we are) simply doing on strategy and can't focus much on tiny things and vice versa.

A20 hardware watchdog is supported by both kernel families and should work if configured correctly.
"dmesg | grep watchdog" on mainline:
[ 3.448805] sunxi-wdt 1c20c90.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0) How to configure it depends on your OS release.

All 4 cards are not new, and since this took quite some time, I collected armbianmonitor link only from 1st run: http://sprunge.us/AQDT
Filesystem is ext4 with default settings.
 
Toshiba, class 4, 16GB
 
 
 
Transcend, class 10 UHS-I, 16GB

 
 
Transcend, class 10, 16GB

 
 
Toshiba, class 10, 8 GB

 

Warning: This whole thread is only about historical information now since it's 2018 and we can buy inexpensive and great performing A1 rated SD cards in the meantime. Buying anything else is a mistake so directly jump to the end of the thread for performance numbers and recommendations.
 
 
 
Edit: See an early 2017 update at the end of the thread regarding new SD specs also covering random IO performance.
 
Edit 2: Some thoughts/observations on lifespan/reliability of SBC storage: http://tech.scargill.net/a-question-of-lifespan/ (see also/especially the comments there)
 
Edit 3: CNX Software picked up recent performance reports (eg. by Andreas Spiess) and other important issues around SD cards: http://www.cnx-software.com/2017/06/13/micro-sd-cards-for-development-boards-classes-tools-benchmarks-reliability-and-tips-tricks/
 
Edit 4: See an early 2018 update testing real world A1 performance class products at the end of the thread.
 
Edit 5: See here and there for some rather boring but very important information about Armbian's tries to prevent SD cards wearing out too fast.
 
 

 
Preparations:
 
I tested 8 different SD/TF cards under identical conditions. I created an Armbian 5.07 image to be used on Banana Pi (A20 SoC with 4.4.6 kernel, ext4 rootfs (Armbian defaults == no journal), 960MHz scaling_max_cpufreq, scaling_governor == performance. All test runs were done using 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' and monitored using 'sudo iostat 5' for anomalies (none detected).
  Kernel version matters (since with Allwinner's 3.4 kernel sequential throughput is limited to ~16MB/s, with mainline kernel we get close to Banana Pi SDIO implementation's max: ~23MB/s) and filesystem settings matter too (enabled journal for example slows down 4K writes a lot).   Sequential speeds:     Random I/O:     The 4 Samsung cards were bought within the last 3 weeks and manufactured between 09/2015 and 12/2015 according to the card's metadata. Interesting observation: I used three of these cards the first time and they all show identical behaviour especially regarding writes with small record sizes: pretty slow in the beginning and getting faster over time (the Samsung Pro for example started with only 1400KB/s 4K writes and 3 runs later the same test showed 3270KB/s -- maybe an indication that some sort of calibration happened. Anyway: I know why I always repeat tests and do not rely on a single test run)   Sequential speed mostly irrelevant / random I/O differs and matters a lot!   The SanDisk Extreme Pro has been bought nearly 3 years ago. This card shows superior sequential read/write performance compared to the three Samsung EVOs. But only when used in combination with a host that can make use of these speeds. My MacBook writes 4 times faster an OS image to the Extreme Pro compared to the EVOs. But this doesn't matter at all since the SDIO implementation of the board in question is limited to ~23MB/s (50MHz @ 4 bit). The same sequential write/read speed limitation applies to most SBCs since to be able to exceed this slow mode the voltage the SD/TF card is fed with would've to be adjusted (default 3.3V, the faster modes require a dynamic switch to 1.8V instead which some/most SoCs can perform but if the SBC vendor doesn't implement this you're limited to ~23MB/s).   Therefore cards labeled as being capable of "up to 90MB/s" do not perform different than those that can only do "up to 20MB/s" as long as we're talking about sequential transfers since the SD card interface is already the bottleneck. But since we're using SD/TF cards not in cameras but as storage media for the rootfs of an SBC something different is more important: Random I/O. And here performance of cards that are labeled identical ('class 10' for example) differs a lot.   All 4 Samsungs outperform the other cards easily in this area. The SanDisk Extreme Pro can not compete regarding random I/O compared to superiour (but mostly irrelevant) sequential transfer speeds. And funnily the 3 other cards show horribly slow random write performance, especially with 16k record size. According to card metadata the 2 Intenso are oemid 0x5048 / manfid: 0x000027 (cheap crap known to die way too early) and I would believe the SanDisk 'class 10' card is a fake or at least uses the same controller as the 2 Intenso since 16K random writes are also way slower than 4K writes.   Detailed results (summary table also available as .ods, .xlsx or .txt):   Samsung Pro 64GB (brand new) http://sprunge.us/DEYd   Samsung EVO+ 64GB (brand new) http://sprunge.us/NLQd   Samsung EVO+ 32GB (brand new) http://sprunge.us/heGL   Samsung EVO 64GB (already used some time) http://sprunge.us/DUOS   SanDisk Extreme Pro 8GB (already used some time) http://sprunge.us/ZPFZ   SanDisk 'Class 10' 8GB (already used some time) http://sprunge.us/OHjT   Intenso 'Class 10' 16GB (already used some time) http://sprunge.us/LUMZ   Intenso 'Class 4' 4GB (already used some time) http://sprunge.us/GbAY   Some updates from Igor (still showing superiour EVO results but the clear winner is ODROID's eMMC module with SD card adapter):   Transcend Premium 300x 16GB (almost new) http://sprunge.us/UcSD  
 
 
Sandisk Extreme Pro 8Gb (almost new) http://sprunge.us/aDJJ
 
 
 
Hardkernel eMMC 8G via SD reader (brand new) http://sprunge.us/SHXF
 
 
 
Sandisk Ultra 8Gb (old and very used) http://sprunge.us/OWZf
 
 
 
Sandisk 8GB (almost new) http://sprunge.us/iViT
 
 
 
Sandisk 8G (new) http://sprunge.us/XHjj
 
 
 
Transcend 8Gb (used) http://sprunge.us/NTRT
 
 
 
Samsung EVO 32Gb (brand new) http://sprunge.us/bTQh
 
 
    Further readings: http://www.bunniestudios.com/blog/?page_id=1022 http://thewirecutter.com/reviews/best-microsd-card/ http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card http://www.bradfordembedded.com/2014/05/flashbenching/ Conclusions:
If the board's SD card interface is the bottleneck since it's not supporting the faster SDIO modes using expensive cards that exceed the interface's maximum sequential bandwidth is useless. An expensive Samsung Pro Plus won't be faster than a way more cheap EVO when it's about sequential transfer speeds since you will stay at ~22MB/s anyway Sequential read and especially write speeds are all the SD association's speed ratings are about (to ensure reliable recording of videos/images in cameras/recorders) When an SD card is used in an SBC sequential speeds aren't that important. It's all about random I/O, especially with small block sizes (reading and writing small random chunks of data from/to the card) No commonly used 'random I/O' speed ratings exist so you have to check the card in question prior to usage or rely on appropriate benchmarks (see the two links directly above). Again: the 'speed class' won't tell you anything. You can get two different 'class 10' cards that differ by 500% or even more regarding real world storage performance (again: random I/O matters). In the example above the Intenso 'class 10' card is 385 slower compared to the EVOs when it's about 16K random writes (good luck if you have a database running that uses this page size) Interestingly more expensive cards are outperformed by cheaper ones (the EVOs show a better overall performance compared to the Samsung Pro since sequential speeds are limited by the interface) One extreme example: Using an identical cloned installation that was somewhat outdated on the small 4GB Intenso card and on the 64GB EVO resulted in the following times for an 'apt-get upgrade' (+200 packages): EVO less than 6 minutes vs. 390 minutes (yes, ~6.5 hours) with the Intenso. The time to finish depends largely on fast random writes. It's easy to test the card in question when running Armbian since we ship with iozone. Therefore simply execute the iozone call from the first paragraph after logging in as a normal user. Starting with Armbian 5.06 a even better method exists that also tests the whole card for errors: armbianmonitor -c will report precisely both performance and health state of your card

More specifically, after editing config file, execute in u-boot sources root directory
git diff configs/A20-OLinuXino-Lime2_defconfig > my_dram_settings.patch and place it in one or both of these paths
userpatches/u-boot/u-boot-default userpatches/u-boot/u-boot-next

This is probably related to udev and depends on base distribution used (jessie, wheezy or trusty) and not on kernel version. Please read this for explanation or just google "udev rename network interface".
 
Edit: It may depend on kernel version, but in any case you should be able to rename your interface by creating an udev rule.

This is probably related to udev and depends on base distribution used (jessie, wheezy or trusty) and not on kernel version. Please read this for explanation or just google "udev rename network interface".
 
Edit: It may depend on kernel version, but in any case you should be able to rename your interface by creating an udev rule.

It's available now
| Symbol: DYNAMIC_FTRACE [=n] | Type : boolean | Prompt: enable/disable function tracing dynamically | Location: | -> Kernel hacking | (1) -> Tracers (FTRACE [=n]) | Defined at kernel/trace/Kconfig:446 | Depends on: TRACING_SUPPORT [=y] && FTRACE [=n] && FUNCTION_TRACER [=n] && HAVE_DYNAMIC_FTRACE [=y]

Looking at symbol names, sysdig probably requires kernel compiled with tracing options enabled.

You can always use config file in /boot, but I would still recommend using build script (documentation), mainly because of additional patches.
 
I'll check description for these options later to see if it's OK to have them on by default.

I felt like I was going insane, because environment and all parameters passed to make didn't contain word "next", but then I found this:
lib\patch\kernel\sunxi-dev\packaging-with-postinstall-scripts.patch(42): +packagename=linux-image-next"$LOCALVERSION" lib\patch\kernel\sunxi-dev\packaging-with-postinstall-scripts.patch(43): +fwpackagename=linux-firmware-image-next"$LOCALVERSION" lib\patch\kernel\sunxi-dev\packaging-with-postinstall-scripts.patch(44): +kernel_headers_packagename=linux-headers-next"$LOCALVERSION" lib\patch\kernel\sunxi-dev\packaging-with-postinstall-scripts.patch(45): +dtb_packagename=linux-dtb-next"$LOCALVERSION" lib\patch\kernel\sunxi-dev\packaging-with-postinstall-scripts.patch(46): +libc_headers_packagename=linux-libc-dev-next"$LOCALVERSION" Edit: fixed
dpkg-deb: building package 'linux-firmware-image-dev-sunxi' in '../linux-firmware-image-dev-sunxi_5.07_armhf.deb'. dpkg-deb: building package 'linux-dtb-dev-sunxi' in '../linux-dtb-dev-sunxi_5.07_armhf.deb'. dpkg-deb: building package 'linux-headers-dev-sunxi' in '../linux-headers-dev-sunxi_5.07_armhf.deb'. dpkg-deb: building package 'linux-image-dev-sunxi' in '../linux-image-dev-sunxi_5.07_armhf.deb'. dpkg-genchanges: warning: package linux-libc-dev-next-sunxi in control file but not in files list

BTW: I fixed packaging script so this "make scripts" is done on headers install and will not be needed any more ... adding later today.

Please try executing
make scripts in your kernel headers directory (/usr/src/linux-headers-4.4.1-sunxi)

Then I'm looking forward to complete H3 support in mainline kernel appearing tomorrow out of thin air.    Maybe then I'll even buy some H3 based Orange device to play with.

Please, please spare us any sort of "auto-configuration" and thank you for keeping Armbian straight and simple! I am currently testing Armbian_5.05 on OrangePiOne using the jessie server version as a basis. Adding needed packages one by one, the restricted ressources should be best used for production use cases.
 
By far the easiest ways to "find" a headless server is to look at the end of the serial console cable attached to it  or ssh to a STATIC IP configured in /etc/network/interfaces.

I don't want to argue with either of you, but I enabled fanotify to sun4i and sun7i legacy kernels, so it should be available in new kernel release. 

Ecryptfs was disabled in kernel config - it will be available in new kernel release.
 
Also I would recommend blacklisting sun4i_ss to prevent data corruption until issue is resolved.

For kernel/u-boot compilation you could use distcc. Debootstrap/image creation process doesn't look cluster-friendly, so having more than one device won't help here.
 
And keep in mind that 10 OPi PC should build kernel faster than one OPi PC if you set up things properly, but it probably won't be faster than more or less modern x86/x64 PC, especially with SSD and ccache.
 
Also keep in mind that you probably want to leave 1 core unused to process network and storage I/O interrupts.

Yes, delete or comment out LC_MESSAGES line.

Check output of command "locale". If it doesn't show something like this
➜ ~ % locale LANG=ru_RU.UTF-8 LANGUAGE=ru_RU.UTF-8 LC_CTYPE=ru_RU.UTF-8 LC_NUMERIC="ru_RU.UTF-8" LC_TIME="ru_RU.UTF-8" LC_COLLATE="ru_RU.UTF-8" LC_MONETARY="ru_RU.UTF-8" LC_MESSAGES="ru_RU.UTF-8" LC_PAPER="ru_RU.UTF-8" LC_NAME="ru_RU.UTF-8" LC_ADDRESS="ru_RU.UTF-8" LC_TELEPHONE="ru_RU.UTF-8" LC_MEASUREMENT="ru_RU.UTF-8" LC_IDENTIFICATION="ru_RU.UTF-8" LC_ALL= you will need to edit "/etc/default/locale" to look like this:
LANGUAGE=ru_RU.UTF-8 LANG=ru_RU.UTF-8 this should be done automatically by "dpkg-reconfigure locales", but manual changes should work too.

I don't think you need any extra packages like console-cyrillic (but it may depend on OS release).
 
ru_RU.UTF8 should be selected and generated later
 
Encoding to use on the console: UTF8
Character set to support: Guess optimal character set
Font for the console: Terminus (should be present by default and supports Cyrillic characters)
 
Keyboard layout: Russian