Heisath

I missed the meeting, sorry. Nothing to add from mvebu side though. I've been busy with the armbian-testing boards.

Well thanks for the (late) reply. I fixed this in between, somehow my apt got detached and did not update the rootfs package.

Anyway, next steps to save time are: - completely remove NetworkManager (you need to do your network config the classic way then). - remove armbian zram and ramlog (which can be done via apt remove or just disable the services) - make sure your device does not run a fsck on every boot - remove u-boot 'prompt timeout' (the time the bootloader waits for user input before booting the system, I guess thats 3s default on armbian) Btw. no guarantee that your system works perfectly after above steps - there's a reason for every service running.

@Userlab If you need to get bigger M.2 cards in there I can suggest using an adapter with extension cable like this: https://www.amazon.com/Sintech-M-Key-Extention-Cable-20CMS/dp/B07DZCCGJN/ You can break the device side to any length you need it. And attach larger and wider cards at the other end.

You could also disable the "NetworkManager-wait-online.service" service. This normally waits a few seconds until some network connection has been established. Use "systemctl disable NetworkManager-wait-online.service" to disable it.

Also you can (as always) download the current versions directly from armbian. https://www.armbian.com/helios4/ https://dl.armbian.com/helios4/

The information you linked indicating there is 2.5Gbps mode is always only for the chip (Armada 3700) used on the espressobin. This Marvell chip does have the 2.5Gbps interface. That is also the reason it is explained on Marvell github. The espressobin itself has all 3 ethernet ports wired through one switch with only RGMII going in. As can be seen here: http://wiki.espressobin.net/tiki-index.php?page=Block+diagram As only one RGMII is feeding all 3 ports I dont think 2.5Gbps will be possible on any of them.

Yeah measuring 3.3V failure or higher frequency is hard(er) do find. But you could atleast measure 5V and 12V while the board with hdds is running. If all looks fine there we can investigate further, but maybe the supply brick is broken. Check this post on where/howto measure:

Into the blue: Another failing power supply? Have you / can you measure the voltages on the molex connector while the device with disks is running? Picture on howto has been posted by gprovost earlier in this thread.

Can you tell us which image you installed? MOTD really does seem weird.

What @guidol is saying is that without internet connectivity you won't be able to NTP sync your clock (as NTP = network time protocol). The fact that 'armbianmonitor -u' is unable to upload you debug info indicates there's a problem with your network. Please use 'armbianmonitor -U' (notice capital U, see also note given in your output) and upload the results manually or post them here (try using a codebox). If this does not work for you atleast try something like 'ping google.com' to make sure your board can even connect to the internet. Otherwise NTP will not work.

For AP+STA at the same time you'd probably need a chip with multiple transceiver modules. The MT7615 might work, although drivers for that are pretty bad atm. http://wiki.banana-pi.org/BPI-MT7615_802.11_ac_wifi_4x4_dual-band_module

If this works consider to contribute (https://docs.armbian.com/Process_Contribute/) and maybe add a PR with your changes to the Github https://github.com/armbian/build We are always looking for helping hands, especially espressobin since this has currently no real maintainer (that I'm aware of).

Build configuration for Espressobin with Armbian Tools can be found here: https://github.com/armbian/build/blob/master/config/sources/families/mvebu64.conf After a quick look I'd say it is using the Marvell Version, Branch u-boot-2018.03-armada-18.12. BOOTSOURCE='https://github.com/MarvellEmbeddedProcessors/u-boot-marvell.git' BOOTBRANCH='branch:u-boot-2018.03-armada-18.12' But have a look at the config yourself.

@tuxd3v yes, 5.4 LTS kernel for all mvebu boards (including helios4) will be released with Armbian 20.05, coming in May. Keep an eye on this thread for more info: Once there are Release Candidates you can help us with testing them.

I meant create an issue for displaying a general warning before writing. Like "WARNING: This will erase all existing data on drive X". The detection can probably not be made entirely perfect & foolproof

Yeah it seems to protect only your system drive in Windows. A general warning before writing would also be nice. Maybe someone add an issue on gitlab?

I have used USBImager for the last few sd card writes. Works well.

SolidRun's ClearfogBase might also fit. Gigabit Ethernet x2 Small Size Good Armbian Support Marvell Armada 388 (2x 1.6Ghz don't know how this compares to Allwinner H2+...) 1Gb RAM GPIO is possible with some I²C IO Extender (it has Pins for I²C, UART, SPI, not lots of direct gpio / no standard header). POE is available via breakout pins and some POE Adapter (like the one linked by Igor above; http://wiki.banana-pi.org/BPI-9600_IEEE_802.3af_PoE_module) Check schematics for more info: https://developer.solid-run.com/download/clearfog-base-schematics/

Yeah that might work. Keep in mind though that this module will still output 3.3V if the input is lower than 5V. Checking the datasheet http://www.advanced-monolithic.com/pdf/ds1117.pdf it seems like this regulator has a dropout voltage of about 1.2V. So 4.5V input would still allow this module to output 3.3V signaling to your SBC that everything is OK while at 4.5V input to your SBC it will probably fail. This is obviously not ideal! EDIT: Easiest way to do it would be to instead of the converter just use a potentiometer (10k or something like that). Connect the ends to 5V and GND, and adjust it until the slider is at about 3V (measure with multimeter). Then attach the slider pin to some GPIO and check GPIO state. Keep turning down the voltage just until the GPIO reads as LOW. Turn back up a bit until it is HIGH. Then once the input drops below 5V the poti output will also drop slightly causing the GPIO to go LOW -> use this as shutdown. This is also not perfect, beware: never turn the poti to high (watch out for anything >3.3V on your GPIO) also you might have to experiment 'till you have a good setting. Minor power fluctuations should not cause a shutdown.

No it does not get mirrored automatically. What you did is create a PR from your robstroess-patch-1_bond-uptime branch to your master branch. What you need to do is go here: https://github.com/armbian/build/pulls And create a PR from your robstroess-patch-1_bond-uptime branch to our master. So robstroess:robstroess-patch-1_bond-uptime to armbian:master. Hope this helps, don't give up, Github is one complicated beast but Igor is right, once you know it a bit it is really helpful. For reference: Robs PR: https://github.com/robstroess/build/pull/1 Cheers Count-Doku

You don't seem to have enough understanding for building an image yourself. Why don't you just download a pre-built one? Find your board here https://www.armbian.com/download/ Choose either Debian or Ubuntu, burn to sd card with etcher, insert it into your board and you're done.

Is this not easily possible by using LIBTAG parameter? Or does it not work anymore? Apart from the final release confusion I'd also totally agree with JMCC this release process was way better than older ones.

Suggestion for future releases: On the release date / once it's released make a topic in Announcements telling people of the new release. Or is Twitter now the main way to communicate such things?

I was not expecting you to put more time into it. It was more directed at the original poster, to address the issues pointed out by you. And to give him an idea what he could do to make it work with a powerbank...