jobenvil

Definitely. Since adduser faced the same problem due to read-only rootfs it exited != 0 and then a reboot occured.
 
 
Also not nice and it doesn't help in such situations either. We must take care of more things, check /etc/mtab for obvious errors and so on.
 
At least we should soon implement logging verbosity by checking /boot/.verbose from u-boot (who will do this?) and should definitely check for r/o filesystem, present a warning and try to deal reasonable with such a situation in the other involved scripts.
 
When I ran into that issue some time ago it wasn't even possible to change the root pwd on 1st login (authentication error without further notification that the reason was r/o rootfs). This seems to be different in jobenvil's case -- see top of thread (maybe jessie acting differently than wheezy?)
 
EDIT: And maybe a bit more error handling in the build process too -- see below

Care to give an example? We tried to eliminate possible illegal characters but maybe this didn't worked out. And then you're in a reboot trap
 
Can you please try to adjust line 8 in lib/scripts/check_first_login.sh with
RealUserName="$(echo "${username}" | tr -d -c '[:alpha:]' | tr '[:upper:]' '[:lower:]')" and try it again using the same username? Or better replace the whole file temporarely with the contents from http://pastebin.com/raw/vdUeXndC then try it again and post /var/log/user-creation.log somewhere? Thx

Yes, if you have a local working copy of kernel repository, you just make necessary adjustments and execute in repository root directory
git diff <path> specifying path for git diff reduces time needed for finding changed files, especially in huge repositories
for example
git diff arch/arm/boot/dts > leds-for-bananapro.patch You can fork and make a pull request for Igor's repo, but some triggers (especially heartbeat) are quite annoying with bright SMD LEDs to have them by default.

I agree. And I would also think about controlling the LEDs by us to provide user feedback at least the 1st time an image is booted. For the H3 boards we implemented it now this way:
red led constant on from the moment when u-boot starts as an 'it works' indicator when firstrun is active then we let the red led blink through sysfs ('there's something going on!' indicator) after the first reboot we do the same with the green led. Let it blink for 30 seconds unless the user logged in at least once, after this it only blinks for 3 seconds to not annoy users that much I had the hope we get some feedback from Orange Pi users (but it seems most of them just download and forget) and wanted to discuss this behaviour internally if the majority of 'user grade' boards feature at least a green and a red led (we won't need that 'led user feedback' stuff for ie. the Clearfog -- there the users should be able able to read documentation and stay patient for at least 3 minutes)

Both bananapi and bananapro dts files are present in mainline kernel git repository. And one of kernel maintainers explains here that they don't like setting default triggers in DT because you can change them via sysfs interface (however this means that LEDs won't work in ealry boot until init script or systemd unit sets LED settings).
 
You can read more about sysfs interface, for example, here.

I can confirm this weird behaviour: "changing "ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb in /boot/boot.cmd" and it made the difference between recognice the SATA or not at the boot time (and after that as well).
 
The prebuilt image (with u-boot 5.0.0 & 5.0.1) doesn't work with SATA until we linked the dtb files with the model "bananapro" and not with bananapi default, which is automatically triggered after every upgrade.
 
Changing boot.cmd from default to "sun7i-a20-bananapro.dtb" will do the magic:
ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb || fatload mmc 0 0x49000000 /dtb/sun7i-a20-bananapro.dtb having this packages installled:
root@bananapi:/boot# dpkg -l|grep next ii  linux-dtb-next-sunxi                5.00                              armhf        Linux DTB, version 4.4.1-sunxi ii  linux-firmware-image-next-sunxi     5.00                              armhf        Linux kernel firmware, version 4.4.1-sunxi ii  linux-headers-next-sunxi            5.00                              armhf        Linux kernel headers for 4.4.1-sunxi on armhf ii  linux-image-next-sunxi              5.00                              armhf        Linux kernel, version 4.4.1-sunxi ii  linux-u-boot-bananapi-next          5.01                              armhf        Uboot loader 2016.01 ii  linux-wheezy-root-next-bananapi     5.00                              armhf        Root file system tweaks for bananapi This starts to be litte tricky; since my first ARMBIAN version (4.0.5 ~  Juli 2015) for Banana Pro I suffered with every ARMBIAN upgrade this collateral damage because banana pi and pro are not properly recogniced.
 
Why this? It is not possible to trigger the scripts to manage both separatedly?
 
 
I tested:
 
1) SATA error manifests with this error on u-boot 5.0.1:
 3.477254] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off CAP_PMP [    3.477317] ahci-sunxi 1c18000.sata: SSS flag set, parallel bus scan disabled [    3.477351] ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode [    3.477367] ahci-sunxi 1c18000.sata: flags: ncq sntf stag pm led clo only pio slum part ccc [    3.478886] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 33 [    3.827349] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [    8.827195] ata1.00: qc timeout (cmd 0xec) [    8.827214] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [    9.177171] ata1: SATA link down (SStatus 0 SControl 300) 2) SATA error manifests with this error on u-boot 5.0.0 (downgrade with apt-get install linux-u-boot-bananapi-next=5.00)
root@bananapi:~# dmesg| grep ata [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [    0.000000] Memory policy: Data cache writealloc [    0.000000] Memory: 1010820K/1046952K available (6822K kernel code, 256K rwdata, 1760K rodata, 328K init, 280K bss, 19748K reserved, 16384K cma-reserved, 244136K highmem) [    0.000000]       .data : 0xc08bc000 - 0xc08fc1a0   ( 257 kB) [    3.205237] libata version 3.00 loaded. [    3.448110] ahci-sunxi 1c18000.sata: PHY power up failed. [    3.448184] ahci-sunxi: probe of 1c18000.sata failed with error -5 In this situation it means that the 5.0.1 U-boot version doesn't work properly, or I'm doing something wrong?. I tested this starting with ARMBIAN 4.0.5 on SD and consecutively upgrading.
 
Fazit: U-boot 5.0 failed like 5.0.1 until the change of the bananapro dtb file, this made the trick.
 
Another different issue: I realized that the banana led lighting only works with bananapi.dtb and not with bananapro.dtb. It is possible to do the same for bananapro.dtb out of the box? I really like that led is lighting according to CPU/IOs -or whatever-.
 
 
Tests were performed with a 2,5" HDD SEAGATE Momentus ST750LX003 750GB which was recogniced before without issues.

linux-u-boot-next-bananapi_5.01_armhf.deb is in repository - compiled with patch, so apt-get upgrade should work now (on SD media)

I'm using Debian testing too with commented Armbian repository, but it should work with jessie-specific config since both jessie and stretch are systemd-based.
➜ ~ % cat /etc/apt/sources.list.d/armbian.list deb http://apt.armbian.com jessie main Downgrading kernel, u-boot and other packages should be possible by manually downloading and installing packages from apt repository, or by specifying package version for apt-get manually (apt-get install <package>=<version>)
You can check available versions using i.e.
apt-cache madison linux-image-next-sunxi  
 
 
BTW, if you are experiencing SATA issues on Banana Pro, please check this topic, it might be u-boot related and may be already fixed in new u-boot release.

"Upgrade script" was created mainly for older distributions that didn't have Armbian apt repository set up. For more or less fresh versions upgrade should be done with apt (apt-get update && apt-get upgrade).
Sometimes though you may need to additionally tweak something manually here or there (like modifying u-boot script or installing fake-hwclock package).
 
For installing self-compiled stuff - kernel and DTB (if kernel requires it) should be installed always in pair; updating headers and firmware may be necessary if you use them (i.e. self-compiled drivers of Wi-Fi modules that require firmware). Updating u-boot is generally not needed unless there were device-specific fixes made for it.
 
DTB deb package may give error with FAT /boot partition (i.e. with rootfs on NAND or devices with older u-boot), deleting old package and removing files in /boot manually should solve this issue.

@jobenvil
On my side, I have unplugged and stored my Odroid-XU4, waiting for a miracle.

I appreciate your answer. What I built until now, doesn't work. I Followed basically the same link for Kernel 4.2 (tobetter) but without succes. I was using gparted to mov ext4 and then expand fat partition because I got a big 26MB uInitrd file. After that fix it with fsck. Unfortunatelly I don't have UART and its like a feeling everytime that start the boot process. At least, due to the tty1 I can see where it stops the boot. I'm also confused with why Igors armbian doesn't use the uInitrd and adress inside the boot.ini. Igor is mountig on /boot the /dev/mmcblk0p1 and here I'm also little bit confused following the compiling guide from ummilddeb. Probably having the Igors base image from 3.10.94  is not working, because some scripts are mounted or depending in this /boot, which in ummilddeb is placed on /media/boot and respecting the /boot of ext4. BTW, I have to read a lot your given inputs.
 
- So, you use default config odroidxu4_defconfig ? or you select other choices inside?
 
- Which boot.ini do you use for 4.*? needs only zImage, dtb file and uInitrd?
 
Thank you in advance
 
PS: Igor, if we need to open a new topic, feel free to advice.

I appreciate your answer. What I built until now, doesn't work. I Followed basically the same link for Kernel 4.2 (tobetter) but without succes. I was using gparted to mov ext4 and then expand fat partition because I got a big 26MB uInitrd file. After that fix it with fsck. Unfortunatelly I don't have UART and its like a feeling everytime that start the boot process. At least, due to the tty1 I can see where it stops the boot. I'm also confused with why Igors armbian doesn't use the uInitrd and adress inside the boot.ini. Igor is mountig on /boot the /dev/mmcblk0p1 and here I'm also little bit confused following the compiling guide from ummilddeb. Probably having the Igors base image from 3.10.94  is not working, because some scripts are mounted or depending in this /boot, which in ummilddeb is placed on /media/boot and respecting the /boot of ext4. BTW, I have to read a lot your given inputs.
 
- So, you use default config odroidxu4_defconfig ? or you select other choices inside?
 
- Which boot.ini do you use for 4.*? needs only zImage, dtb file and uInitrd?
 
Thank you in advance
 
PS: Igor, if we need to open a new topic, feel free to advice.

@wildcats_paris
 
Have you built a "good" 4.2.* kernel? I had many issues with rootfs on USB3 (Igors armbian 3.10.94)  using jMICROn bridge adapter (maybe I should retire it and buy a new one controller). I could not fix it because I didn't know if the problem was at micron controller side (I runned update firmware) or at kernel side https://github.com/hardkernel/linux/issues/120#issuecomment-180874515.
 
BTW is a good feeling to observe 8 CPUS working together
 
https://locky.noip.me/seafile/f/ac1beed0f4/

https://duckduckgo.com/?q=motd+site%3Aforum.armbian.com

I got it, shame on me! thanx, thanx!!
and thanx!
 
this looks like much better now:
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 4.2.3-sunxi (root@production) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #2 SMP S un Oct 11 14:12:18 CEST 2015 [ 0.000000] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine model: LeMaker Banana Pro <=======================THANKS!!=================================== [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] On node 0 totalpages: 262144 [ 0.000000] free_area_init_node: node 0, pgdat c0a2c800, node_mem_map eeef8000

There is one image for all bananas and DTB file is encoded into u-boot.
 
For bananapro you only need to change:
ext4load mmc 0 0x49000000 /boot/dtb/${fdtfile} || fatload mmc 0 0x49000000 /dtb/${fdtfile} to
ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb || fatload mmc 0 0x49000000 /dtb/sun7i-a20-bananapro.dtb and recompile the boot.cmd to boot.scr as stated in file. reboot and you are done.

Sorry, but both dd as well as hdparm aren't benchmark tools. They're abused in this way but the results are simply crap.
 
When you use dd with filesizes too small and without the appropriate flags ('direct' parameter) it always tests partially caches/buffers and sequential throughput seems to be higher than it is in reality. Same applies to 'hdparm -tT'. One parameter just shows RAM throughput and when used together with the other parameter a so called 'correction factor' will be applied to the results shown. In other words: The results given do NOT show what the disk in question is able to deliver.
 
And both pseudo benchmarks only test sequential throughput. Use bonnie++ or iozone (and use always at least twice as much as RAM available for test filesizes) to get a clue how the SD card or disk in question really performs. And both tools are able to show the performance of random I/O with different block/sector sizes.

All A20 based boards seem to be limited to approx. 16,x MB/s when reading/writing sequentially from/to SD card. What really makes a difference when you're frequently accessing files on the SD card will be random I/O. And there some SD cards outperforman others easily and sequential writes (or class xy) do not count any more.
 
In my eyes it depends whether you use an SSD or a HDD on the SATA port. In case it's a spinning disk there might be many situations where it's better to keep the rootfs on SD card (and using Wheezy and Igor's ramlog configuration to minimize writes to SD card) to let the HDD spin down when idle after longer periods. When you're using an SSD IMO it's a no-brainer to move the rootfs to SSD.
 
On my TODO list are experiments with F2FS on SD card (only possible using a different partition scheme than the one Igor's using now since u-boot can not directly read from F2FS at the moment). That might both decrease wear-out of the SD card and increase (random) performance. But I won't have the time to test this the next weeks/months. But if I'm done I'll report back.

Just as a small addendum: Many things one might attribute to "new kernel" are just side effects of different settings.
 
Given the hardware implementation of the GMAC ethernet (everything has to be done by the CPU) clock speeds and cpufreq settings matter. So you should check what you had when running Igor's image with kernel 3.4 (I would assume interactive governor and max. 912 MHz?) and what you've now.
 
If you didn't change anything then kernel 4.0.x with the new cpufreq stuff comes with these defaults:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor = ondemand /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq = 960000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq = 144000 /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy = 0 /sys/devices/system/cpu/cpufreq/ondemand/up_threshold = 95 /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor = 1 And while this might be nice on a tablet or on a machine that's mostly idling around it leads to bad throughput especially when it comes down to NAS useage. By tweaking mostly these settings as well as TCP/IP and CPU affinity settings you can double throughput in one direction and let it max out in the other: http://forum.lemaker.org/forum.php?mod=viewthread&tid=15543&fromuid=33332
 
Which results do you get when you try it with the following settings?
echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 960000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo 528000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy echo 25 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor sysctl -w net/core/rmem_max=8738000 sysctl -w net/core/wmem_max=6553600 sysctl -w net/ipv4/tcp_rmem="8192 873800 8738000" sysctl -w net/ipv4/tcp_wmem="4096 655360 6553600" sysctl -w vm/min_free_kbytes=65536 sysctl -w net.ipv4.tcp_window_scaling=1 sysctl -w net.ipv4.tcp_timestamps=1 sysctl -w net.ipv4.tcp_sack=1 sysctl -w net.ipv4.tcp_no_metrics_save=1 BTW: Solely relying on iperf is wrong judging from my experiences. Real-world performance might differ. So I always double-check with a combined benchmark that checks a couple of different things including disk access (unfortunetaly we have a SATA write limitation where network throughput is faster in this direction and vice versa. When writing from client to Banana Pi disk I/O is the bottleneck and in the other direction it's network when using a SATA disk)