Jump to content


  • Posts

  • Joined

Recent Profile Visitors

1185 profile views
  1. I receive "No end-user support: built from trunk" at MoTD even though I used a stable and recommended img: Armbian_21.05.4_Odroidn2_buster_current_5.10.43.img. Is that correct given it's a stable build? Furthermore, I've received a kernel panick - not syncing: kernel stack overflow "Insufficient stack space to handle exception!". Are the logs saved a place? Can't find it in journalctl.
  2. This is a minor issue, but I'm hoping to get it solved as I've enjoyed the welcome screen for so long. For whatever reason after running my installation script which I've been using for years, the welcome screen changes when logging in over ssh. This happened some months ago. Any ideas on how or where I should look?
  3. I think I found the root of the issue I had. It seems to be related to resolvconf and particularly resolvconf-pull-resolved where I had systemd-resolved installed and handling resolv.conf with a symlink. Removing the resolvconf package did the trick. I'll let the server run for some days, yet it seems fine some far. I'm going to make sure that I remove resolvconf in my installation script to prevent this mess from happening again... This is something to be aware of as others might be a victim of the issue as well. It's a quite serious one too. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968015 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967906
  4. Thanks again for a great reply! I'll stay put to mainline and use 5.7 until 5.8 has matured. I do not have high expectations or hope for a extremely stable experience with N2, but if it can somewhat give me a decent experience that will be more than enough. I bet I've changed my arm device in a year or two. Out of couriosity, do you have any similar boards you would recommend for NAS usage in the $100-150 price range?
  5. So if you were going to setup N2 as a home NAS, you would rather use 5.7 for some time before jumping to a higher stable kernel (>= 5.9) rather than setup 4.9 and staying there?
  6. Thanks for letting me know! I'll do a new clean install using Armbian_20.08.1_Odroidn2_focal_current_5.8.5 and change kernel to use legacy in armbian-config forwards. I'm looking for a much more stable experience running a home server than what I've encountered the last few months running mainline.
  7. Odroid-N2 using Armbian_20.08.1_Odroidn2_focal_current_5.8.5 I've recently got a "Connection timed out" issue. For instance, I can open files with nano, use htop, armbian-config, update and upgrade packages, but I can't reboot (everything over ssh). I'm having a feeling that the issue started when I tried to figure out if it's possible to get HDMI to work with my 4K TV when the HDMI cable is not plugged in at boot. In that case, I booted several times and chaged boot.ini with setenv display_autodetect "false", setenv hdmimode "1080p60hz" and setenv disablehpd "true" without success. armbianmonitor -u information is attached at the end in my post where this line might be of interest: "[ 0.000000] [Firmware Bug]: Kernel image misaligned at boot, please fix your bootloader!". Conection timed out message: Running armbianmonitor -v: Does armbianmonitor -v give any useful information? It detects corrupted pacakges, but which? The 10-globally-managed-devices.conf does not seem to exist. At least I can't read it with cat or nano. sysctl --system armbianmonitor -u I guess the only way to reboot is to pull the plug? Or could it be done without pulling the plug if I connect to the N2 with UART? I'm thinking about doing a new fresh install, but before that, is it worth trying to use the legacy kernel (4.9)? Thanks for the awesome work with Armbian! It has truly been a blessing since I first discovered it!
  8. What stands trunk for in the filename Armbian_20.05.0-trunk_Arm-64_*? And is there a particular reason for not compiling using latest stable kernel or mainline as 5.5-rc6 is almost a month old?
  9. I've done multiple installations on VIM3 using a clean SD card with both Armbian_19.11.5_Arm-64_buster_current_5.5.0-rc6_20200127 and Armbian_20.02.0-rc1.030_Arm-64_buster_current_5.5.0-rc6_20200129. The color issue appear on both of the images as well as earlier and the simple fix by swapping u-boot files fixes it. My main concern is the following error which I've never seen before and apply to both images. There are thousands of the same error message in journalctl. Update: Running systemctl disable serial-getty@ttyS2.service && systemctl disable serial-getty@ttyS2.service fixed it.
  10. No problem. Then I'll do a clean install later today. Thanks for the incredible work!
  11. I'm getting the following error after normal upgrade with apt from a clean install earlier in January on a VIM3. Never encountered this issue before. I'm thinking about doing a new clean install after overwriting the whole SD card with zeros. @balbes150, are you going to do new builds for kernel 5.5.* in the next 2-3 days for current? Otherwise I'll use Armbian_20.02.0-rc1.030_Arm-64_*_current_5.5.0-rc6_20200129.img. I guess there isn't much of a change between latest rc6 to final. mount: /boot: wrong fs type , bad option , bad superblock, missing codepage or helper program, or other error
  12. @bxm, In both functions, syncToDisk () and syncFromDisk (), it should be "sync /" instead of only "sync" (without the quotes) and the issue is fixed? If that's the case, could you add a PR request on Github for the change? Update I can confirm that changing "sync" to both "sync /" or "sync /var" did not wake up my hdds or trigger any hdd-spinup logging according to "systemctl status hd-idle". Thanks!
  13. Good to know! Choosing "default" worked perfectly and I built kernel 5.3.0 with the latest commit v20190918. I can see from GH source that you did include the patch dwc3/core: xHCI host not responding to stop endpoint command into commit v20190918. Thanks! For meson-g12 users: If you want to upgrade kernel to 5.3.0 with balbes150 v20190918 patches, the .deb files can be downloaded at: Armbian 5.96 and kernel 5.3.0 for meson-g12 devices (v.20190918)
  14. The reason for why I did not choose "default" was that it states: "Vendor provided / legacy". I do not want a vendor kernel, I want to update my 5.3RC6 kernel to 5.3.0. I ask again: Your build Armbian_5.96_Aml-g12_Ubuntu_bionic_dev_5.3.0_20190917 you uploaded fixed the IO errors over USB3.0 interface for g12 devices. Did you actually include the patch i referred to into this build or is it pure kernel 5.3.0?
  15. Yeah, that did the trick! With the build Armbian_5.96_Aml-g12_Ubuntu_bionic_dev_5.3.0_20190917 you uploaded, I'm finally able to copy/move files over the USB3.0 interface without any IO errors. Did you actually include the patch i referred to into this build or is it pure kernel 5.3.0? One more thing. I tried to build the kernel files by following your guide at https://github.com/150balbes/Build-Armbian, but when I was building, I faced an error as seen from the picture attached. I've only followed your guide and selected "U-boot and kernel packages" -> "Do not change the kernel configuration" -> "aml-g12" -> "next". I want to upgrade my current installed build to the latest kernel with the patch. Any ideas why it fails? Let me know if you want the whole output or any logs. Thanks for the great help BTW! It's awesome when someone from the community aid much more support than the actually support team who released the SBC...
  • Create New...