• Content Count

  • Joined

  • Last visited

About raschid

  • Rank
    Elite member

Recent Profile Visitors

875 profile views
  1. @sgjava the current device tree (dev) contains ... &usb_otg { dr_mode = "peripheral"; status = "okay"; }; can you check what the FriendlyElec version says here?
  2. Thermals should work with dev for H2+/H3: see https://github.com/armbian/build/pull/992
  3. You are right ... and out of luck for now: https://github.com/armbian/build/issues/1003#issuecomment-394987272 you could try a recent nightly build: https://dl.armbian.com/orangepizero/ One BananaPi running a recent kernel (Armbian 5.45 / kernel 4.17.0 rc7) has been up and running for 12 days now ...
  4. @gounthar you might try downgrading the kernel: sudo apt install linux-image-next-sunxi=5.31 linux-dtb-next-sunxi=5.31 sudo apt install linux-u-boot-bananapipro-next=5.31
  5. Have a look at this: https://forum.armbian.com/topic/6386-lime2-mainline-kernel-with-debian-9-stretch-becomes-unresponsive-forced-reboot-required/?page=2&tab=comments#comment-55225
  6. Host is Xenial. As recommended here https://docs.armbian.com/Developer-Guide_Build-Preparation/
  7. I have the same issue (with jessie and strech, xenial untried) - encountered the following error during build: Reading state information... hostapd is already the newest version (2:2.6-4~armbian5.38+1). sunxi-tools is already the newest version (1.4.2-2~armbian5.38+1). sunxi-tools set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. [ o.k. ] Calling image customization script [ customize-image.sh ] [ o.k. ] Preparing image file for rootfs [ orangepilite stretch ] [ o.k. ] Current rootfs size [ 801 MiB ] [ o.k. ] Creating blank image for rootfs [ 1096 MiB ] 1.07GiB [ 37MiB/s] [====================================================>] 100% [ o.k. ] Creating partitions [ root: ext4 ] [ .... ] Creating rootfs [ ext4 ] Invalid filesystem option set: ^64bit,^metadata_csum tune2fs: Bad magic number in super-block while trying to open /dev/loop0p1 Couldn't find valid filesystem superblock. mount: wrong fs type, bad option, bad superblock on /dev/loop0p1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. The image of course does not boot.
  8. Thank you - that did it. And you are right: it did not solve my wifi issue
  9. Wifi does not work with dev branch (4.17) on H2+/H3 systems: [ 10.807592] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 10.857239] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 10.916465] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 10.916479] platform regulatory.0: Falling back to user helper [ 11.432051] cfg80211: failed to load regulatory.db any hints?
  10. Hmm, looks like the machine is running out of RAM. Maybe we have some memory leak ... Maybe you could check for decreasing available memory over some time?
  11. Thx for the info @vlad59 - I would not recommend upgrading to more current versions at the moment.
  12. OK, so the BPi M1 is still alive - after 6 days of this full-load zombie state. Two more M1s are currently joining it to test stability: BPi M1 #1: Armbian 5.38 - kernel 4.11.5 BPi M1 #2: same Armbian version - kernel 4.14.18 BPi M1 #3: Armbian 5.45 - kernel 4.17.0 rc7 (to see if stabilty improves) I will post results ...
  13. I have the same issue on a BananaPi M1 with an attached SATA disk. It is running SAMBA, a media server, an iperf server, it monitors and log weather data from an attached weather station and does some home automation. "Freeze" means the system is becoming unresponsive to ssh, cron etc. while still responding to ping and the the reset button. A cpu-load triggered system LED remains solid on. The system ran completely stable on Bananian for nearly three years until I switched to armbian in January. Initially the freezes occured quite infrequently with the systmem running ok for weeks. I installed a daemon to monitor system load and dump "ps aux" is load exceeds 2 - but that never happens: The system becomes unresponsive before the daemon can kick in. After upgrading last Saturday it froze after just 22 hours. I am travelling right now - it's quite unsettling to think of the little bugger running at max overload for the next 5 days. I will downgrade as soon as I am back as @theprosuggests. TL;DR: Current armbians builds on A20 platforms seem to be unstable and have been for some time. Upgrading the current builds seems to make things worse.
  14. Building a dev-kernel currently seems to fail to produce something like "linux-dtb-dev-sunxi_5.41_armhf.deb" in /build/output/debs/ Any idea why?