Heisath

Members
  • Content Count

    105
  • Joined

  • Last visited

About Heisath

  • Rank
    Elite member

Profile Information

  • Gender
    Male
  • Location
    Germany

Recent Profile Visitors

895 profile views
  1. 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.
  2. @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.
  3. 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.
  4. Also you can (as always) download the current versions directly from armbian. https://www.armbian.com/helios4/ https://dl.armbian.com/helios4/
  5. 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.
  6. 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:
  7. 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.
  8. Can you tell us which image you installed? MOTD really does seem weird.
  9. 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.
  10. 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
  11. 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).
  12. 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.
  13. @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.
  14. 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
  15. 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?