berturion

We usually work with/have two kernels. Stock legacy, currently mostly 4.4.y.  and mainline, usually latest LTS or stable, 4.14.y/4.18.y at the time. Legacy is labeled "default", while modern "next" ... or "dev" when attached to the master kernel branch.

Repositories per kernel family are defined here: https://github.com/armbian/build/tree/master/config/sources ... for this particular board family we use the repository from Ayufan which seems to be in the best shape. Another alternative would be kernel.org + a bunch of patches. 
 
 

First, boot from SD as usual and check output of "blkid". If your USB drive with rootfs has PARTUUID that looks like this "0004cde8-01", then insert this to your kernel command line in boot.cmd, recompile it and try booting again.

@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.

The url is here: http://sprunge.us/dFBB
 
I will place this new script in /etc/init.d and report back the behavior.
 
EDIT:
 
For now, with new script re-enabled:
$ sudo systemctl status armhwinfo â— armhwinfo.service - LSB: Armbian gathering informations about hardware    Loaded: loaded (/etc/init.d/armhwinfo)    Active: active (exited) since ven. 2016-03-04 09:12:41 RET; 6s ago   Process: 2854 ExecStart=/etc/init.d/armhwinfo start (code=exited, status=0/SUCCESS) mars 04 09:12:30 xxxxxxxx armhwinfo[2854]: [ ok ] Setting cfg I/O scheduler for sda mars 04 09:12:30 xxxxxxxx armhwinfo[2854]: [ ok ] Setting noop I/O scheduler for mmcblk0 mars 04 09:12:31 xxxxxxxx armhwinfo[2854]: [ ok ] Starting ARM hardware info: Cubieboard mars 04 09:12:41 xxxxxxxx systemd[1]: Started LSB: Armbian gathering informations about hardware.

Hello,
 
So if I sum things up, we have to follow these steps with super user rights:
 
# Disable ramlog
$ service ramlog disable
 
# Install necessary packages for systemd
$ apt-get update && apt-get install fake-hwclock systemd-sysv
 
# Backup old working boot.cmd and boot.scr files
$ cp /boot/boot.cmd /boot/boot.cmd.nosystemd
$ cp /boot/boot.cmd /boot/boot.scr.nosystemd
 
# Edit boot.cmd to insert 'init=/bin/systemd' at the first arg of bootargs
$ nano /boot/boot.cmd
setenv bootargs "init=/bin/systemd console=tty1 (...)"
 
# Recompile boot script
$ mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
 
# Reboot
reboot
 
For me that worked
 
Maybe we could add this in the main docs http://www.armbian.com/documentation/ ?

If you installed systemd-sysv, you don't need to edit boot script (though it doesn't break anything).

I just figured out there is something else ... need to look further. I just built 4.4 for CT and try USB install. It does not work ... CONFIG_CHR_DEV_SG=y  
 
Edit: SATA install works fine.

As already pointed out the problem seems to be that SG support (SG --> 'SCSI generic' that is necessary for some USB implementations) is currently built as a module. Modules are stored on the rootfs below /lib/modules. In case the rootfs is not already mounted and the SG module is needed to access the rootfs you're simply lost.
 
And unfortunately this applies to your USB disk and also to your USB thumb drive situation. Again: Either recompile the kernel with CONFIG_CHR_DEV_SG=y  instead of a module or wait for the next version. 

Hello, I agree with you folks. My NAND also on cubieboard2 is not reliable. I had so many file corruptions and re-installed so many times so many debian on it without being able to have a stable OS. I will never install any OS again on NAND.
SD Card or SATA is a much better choice.