gprovost

@matzman666 Thanks for pointing to your test. It's true OMV default settings are not the best to get the best performance out of Helios4. It's always a trade off between ease of use and expert mode tweaking. Will need to see if we can tweak those settings during OMV install, but not really our priority right now. @Tom3kK Yeah it's on top of our TODO list now to implement WoL. Should be implemented in the next 2-3 weeks.

@matzman666 Very interesting findings and well broke down tests 1. I wasn't aware that with LUKS2 you can define sector size bigger than 512b, therefore decreasing the number of IO operations. 2. I never investigate how RAID perf can be impacted with nowadays HDD that support block size of 4K (Advanced Format). Non-aligned 4K disk can effectively show a significant performance penalty. But I'm still a bit surprise that you see that much perf difference (26%) with and without disk alignment on your tests without encryption. https://raid.wiki.kernel.org/index.php/A_guide_to_mdadm#Blocks.2C_chunks_and_stripes Would you be interested to help us improve our wiki, on the disk alignment part and then on the disk encryption part ? https://wiki.kobol.io/mdadm/ https://wiki.kobol.io/cesa/

@djurny Thanks for the benchmark, very useful number. It reminds me I need to indicate on the wiki the correct cipher to use with cryptsetup (preference for aes-cbc-essiv over aes-cbc-plain*) when people create their LUKS device since on latest version of cryptsetup the default is cipher is aes-xts-plain64. Time to combine both benchmark tests together as suggested by @Koen BTW you don't need to load mv_cesa module. This is an old module which is replaced by marvell_cesa.

@thermalz please PM me and we see from there if we should proceed to a replacement of the board. Just reminder to all, as mentioned on our wiki in several place :

@GeckoX Good to hear you figure it out. Yes OMV is the easiest approach to setup your NAS without the need to be too much Linux savvy. @Koen No there is no microSD card included in the kit. Some users of the 1st batch got a free microSD card but it was a free goodie from the PCBA factory to apology from their repeated delay.

@hatschi1000 Happy to hear all going smoothly.

@lanefu Thanks for the anecdote, always nice to hear some feedback from user. Would be great if you can post a picture of your setup on our FB page or/and our Twitter. Cheers.

Is it the objective to address upgrade from previous bsp package to new bsp++ packages ? If I grasped correctly the new approached, then I guess will need then to replace the current armbian-bsp package by a metapackage pointing to armbian-bsp.deb + family.deb + board.deb. This should address the upgrade path... but might still create some tricky use cases.

@Igor Are you going to define a deadline when all the different board maintainers must have migrate&adapt whatever stuff they have in build/packages/bsp/ into build/config/packages/ ?

I think it would be helpful to list all the u-boot + rootfs location combinations possible. Something like that : Then for each board we define in a definition file what combination is supported. We could use bitmap hex value. For example 0x13 will means the board only support MMC/MMC, MMC/Block Device and Block Device/Block Device. Regarding the utility feature, for example today on Helios4, it takes 2 steps to completely move away from SDcard 1st - Install U-boot in SPI (menu 5 Install the bootloader to SPI Flash) 2nd - Move RootFS to other device than USB (menu 6 Boot from SPI - system on SATA, USB or NVMe) I think it's ok that way, but we could have imagined this to be done in one step, where the user would choose through the interactive menu : U-Boot Location + RootFS Location, then from there the script take care to fulfill the new locations. As you described it, the new script should be designed to address only the generic use cases, any board specific use case should be address via a plug-in / sub-script. I also agree with you, when user choose the partition type for the new rootfs target, he should be able to choose LUKS. However, your point on hardware crypto off-load is off topic and only related to kernel crypto framework, it has nothing to do with u-boot | rootfs migration. I understand the utility name is up to discussion, but if it ends up being just a subset of armbian-config then maybe yes the name doesn't matter. I will still venture to coin a name : uboot-rootfs-manage.sh

@Zykr you could also replace the content /boot with the one you extract from an image. Under linux you can mount .img file with a loop device and browse its content.

@Zykr to complement what I wrote before. You could use following u-boot commands to boot manually on the correct kernel. Then once booted as wrote above, you should fix the wrong symlink in /boot ;-) setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 ubootdev=mmc scandelay loglevel=1" load mmc 0:1 ${fdt_addr} /boot/dtb-4.14.83-mvebu/${fdtfile} load mmc 0:1 ${ramdisk_addr_r} /boot/initrd.img-4.14.83-mvebu load mmc 0:1 ${kernel_addr_r} /boot/vmlinuz-4.14.83-mvebu setenv fdt_high 0xffffffff setenv initrd_high 0xffffffff bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr}

@Zykr It is very strange and not normal that the upgrade installed a 4.4.y instead of a 4.14.y kernel. Did you do apt-get upgrade or did you manually choose the linux-image package ? So it could be something similar that what pointed out Tido above. The ext4ls mmc 0:1 /boot/ command doesn't show the symlink target unfortunately. But based on the load sizes in your uboot log, u-boot is loading the initramfs (uIinitrd) ver 4.14.83 and loading kernel (zImage) ver 4.4.153 which is completely wrong and explain why the boot fails. The easiest would be to mount the microSD Card on your personal computer and check / fix that the following symlinks in /boot are as follow: dtb -> dtb-4.14.83-mvebu uInitrd -> uInitrd-4.14.83-mvebu zImage -> vmlinuz-4.14.83-mvebu @Igor Is it an issue you experienced before ?

@Koen Good point, will do a benchmark one of those days.

@Zykr The fact that you reach "Uncompressing Linux... done, booting kernel" means that u-boot found the boot.src on your boot device (assuming microSD Card) and loaded correctly the kernel, initramfs and the device tree file. So something might be wrong with the kernel rather than u-boot. Could you copy your the boot output here. Do you remember what was your kernel version before upgrade ? Have you try a full port cycle ?

Hi All, I added the following section in our wiki : https://wiki.kobol.io/mdadm/#configure-fault-led to explain how to setup mdadm to report array errors via Red Fault LED (LED2) . This way you can have a visual cue if something wrong happen with your RAID.

Yes it is, we have tested all the use cases. It's why we reverted to use boot-marvell.cmd bootscript for branch next in order to cover tricky use case like u-boot in SPI. BTW will have to update documentation to add the new build option FORCE_BOOTSCRIPT_UPDATE.

@Igor we created PR 1169 to address the issue related to bootscript.

I already looked at the white paper but I don't have much time now to dig further. I'm not sure if CJDNS interfaces with the Kernel Crypto API. Plus anyway the Marvell CESA engines don't support SALSA20 stream encryption... so i don't think CJDNS crypto can be accelerated.

Yes I was thinking of something along those line. We will do a PR.

@Igor We didn't foresee that sorry. I thought u-boot dpkg wasn't supposed anymore to be updated with a apt-get upgrade to avoid those specific cases where for example boot script required to be updated. update: so now looking what would be the best approach from user pov. Quite hard without being able to do something with postinstall script.

@Igor Thanks for checking with us before goign ahead ;-) Yes you can trigger now the rebuild and push out the update. Note: we just added a commit to our u-boot 2018 repo, so in case you already had rebuilt before the last hour, you will need to re-trigger the build. Thanks.

@Caribou No, Helios4 is a pure headless server, there is no video output. The idea is to peer Helios4 with a smartTV or Pi-like board (Raspberry Pi or LePotato) to run Kodi and play the content hosted on Helios4 on your TV.

I don't know much about CJDNS. Does CJDNS supports cryptodev or AF_ALG ?

Finally found the time to finish the CESA page on our Helios4 Wiki. It's not as exhaustive as it should be, but enough to help people experiment. https://wiki.kobol.io/cesa/ For the ones who are interested, please have look... any comment welcome ;-)