Jump to content

Z11ntal33r

Members
  • Posts

    56
  • Joined

Everything posted by Z11ntal33r

  1. Is anyone else getting "Input/output error" when transferring data between two external drives? I thought the issues regarding IO errors were fixed in kernel 5.3... I'm on 5.3.0-rc6-aml-g12 so perhaps I should give the final version a try. Update: Changing /sys/class/block/?d?/queue/max_sectors_kb from the value of 1024 to 32 still trigger the error. My setup is as follows: A VIM3 with a ORICO Mini USB 3.0 HUB 4 Port Power Supply OTG with Micro USB Power Interface connected to a Rocketek usb 3.0 multi Smart memory card reader with a mSD card inserted and a Seagate Expansion Desktop. Both the ORICO USB HUB and Seagate HDD are powered with an external power supply. Update 2: This is the patch I need which Amlogic worked out for g12 devices: dwc3/core: xHCI host not responding to stop endpoint command I can't seem to find the patch in Kernel 5.3 patch notes... So I suppose it isn't merged yet. Could you please add the patch to your next build, @balbes150? The patch is groundbreaking as it fixes the IO nightmare g12 devices (especially ODROID-N2) have faced for the past months (as seen here: https://forum.odroid.com/viewtopic.php?f=181&t=35031)...
  2. Which DTB have you tried? meson-gxl-s905x-p212.dtb?
  3. Awesome! Everything is working as expected on VIM3 with latest Android build (VIM3 Android Pie V190907) including increased RAM (from 3451MB to 3696MB) and installation to eMMC. The complete step-by-step guide is as follows: Burn latest Android to eMMC with USB burning tool (full erase of flash and bootloader) by Upgrade via a USB-C cable. * Burn latest Armbian to mSD card / USB with Etcher. Change dtb filename in both /extlinux/extlinux.conf and uEnv.ini to meson-g12b-a311d-khadas-vim3.dtb Insert mSD card / USB and boot into Android. Activate multi-boot by using Log in with root, change root password and add new user. Run sudo ./install.sh with root and shutdown after successful installation to eMMC. Activate multi-boot again by using Keys Mode (see step 5) (Remember to have mSD card / USB inserted). Shutdown, unplug mSD card / USB and power on. You should now be running Armbian from eMMC * If you have preinstalled any other OS than Android on eMMC, wipe eMMC before burning Android on it by running dd if=/dev/zero of=/dev/mmcblk<number_eMMC> from an OS on mSD / USB.
  4. The box is a completely mess. Just read up on different forums about ppl whom have plenty of problems with one thing or the other. In addition, it's an oven with temperatures around 70C without stress testing and it's thermal throttling and reducing cpu frequency in the manner of how often people breath... I'm sad to say that you get what you pay for :/
  5. The only reason I burned Ubuntu and not Android was because the Ubuntu build was newer and I was hoping that the latest u-boot patches was present. For me it doesn't really matter as I'm regardless going to install Armbian to eMMC and never use either Ubuntu or Android. Thanks for the tip btw I'll burn the next Android build when it arrive to see if RAM is increased. How much available RAM do you have with the build you are testing on your VIM3?
  6. I've attached a picture so you can see the issue I faced when I tested Armbian_5.94_Aml-g12_Debian_buster_default_5.2.1_20190821.img. I did a full erase of eMMC and burned latest Ubuntu (VIM3_Ubuntu-server-bionic_Linux-4.9_arm64_EMMC_V20190813) with USB Upgrade Tool before installing Armbian to eMMC the last time. How much RAM do you have with VIM3 with the build you are using?
  7. So the new kernel reserves almost 350 MB of RAM for video? Which means the latest patches for Khadas VIM3 u-boot (which is not present in theirs latest Android og Ubuntu builds) won't increase the amount available RAM if I start over by burning Android/Ubuntu to eMMC with latest u-boot and then install latest version of Armbian (Armbian_5.94_Aml-g12_Debian_buster_dev_5.3.0-rc5_20190825) to eMMC again?
  8. Feedback - VIM3 HDMI problems with Armbian_5.94_Aml-g12_Debian_buster_default_5.2.1_20190821.img as the screen is white and blurry... Armbian_5.94_Aml-g12_Debian_buster_dev_5.3.0-rc5_20190823.img on the other hand is working good so far. The only issue I've encountered is the amount of RAM available, which is 3354MB - far from ≈3700MB which is normal for 4GB RAM. VIM3_Ubuntu-server-bionic_Linux-4.9_arm64_EMMC_V20190813 is showing a little more with 3451MB of available RAM, but it's still much lower than it should be (≈3700MB). What's your take on this @balbes150? I can see from Khadas uboot (Github) that there have been some RAM allocation commits for uboot, but it seems that it only increases available RAM with around 128 MB. Update 1: I had no luck with LibreELEC regarding increasing RAM, but installing CoreELEC and upgrading bootloader fixed this as I now have 3696MB of available RAM Update 2: Obviously install to eMMC is not working with CE's custom bootloader, so installing VIM3_Ubuntu-server-bionic_Linux-4.9_arm64_EMMC_V20190813 to eMMC, Armbian_5.94_Aml-g12_Debian_buster_dev_5.3.0-rc5_20190823.img to mSD and running install to eMMC still gives 3354MB of available RAM... So using Armbian instead of VIM3_Ubuntu* decreases RAM even further - almost 350MB less than with CoreELEC's bootloader.
  9. I don't mind updating kernel manually, so that's fine for me. Since you use "default", "dev" and "Next" when naming your builds, are there any differences except the kernel? Given the g12 support added for kernel 5.3, I assume the user experience is better compared to 5.2 with your latest build Armbian_5.94_Aml-g12_Debian_buster_default_5.2.1_20190821. So, do you advice that I use default Armbian_5.94_Aml-g12_Debian_buster_default_5.2.1_20190821 and update kernel manually to 5.3 RC5 or just use next with Armbian_5.91_Aml-g12_Debian_buster_next_5.3.0-rc5-next-20190820?
  10. I was going to buy an ODROID-N2 to replace my RK3288, but given the mess around USB3 for the N2, which is one of the few important aspects that need to work perfectly, I'm thinking of buying a Vim3 instead. However, the perception that I have is that it will be a significant drawback in stability in regard of software maturity, and it doesn't help that it's neither official or unofficial supported as the N2. I want to use my VIM3 as a headless server with main functionality perfectly working as running OS from eMMC, gigabit ethernet, USB3 interface with several HDDs, HDMI (if I loose ssh connection and need to input commands local) etc, is balbes build running mainline kernel as Armbian_5.94_Aml-g12_Debian_buster_default_5.2.1_20190821 the way you would go? I can't find any status of the current state of what's working and what is not. I don't need a rock solid state, but my VIM3 can't have issues every week either... I'm more passionate about mainline support and especially the recent development of g12 support compared to Khadas' 4.9 kernel, in addition to that I still want to stick with Armbian. I presume that the experience with Armbian using balbes build won't be much of a difference user functionality wise compared to example Armbian_5.94.190822_Tinkerboard_Debian_buster_dev_5.2.9_minimal? (disregarded that minimal has fewer packages installed etc).
  11. I've found the issue. As I did only check hd-idle log to see if the HDD's are spinning or not, it seems to be saying that the HDDs are spinning up when they actually are not. This is likely related to that hd-idle is using /proc/diskstats to read disk statistics and then writes the log to systemd as seen below. The hard drives are not spinning up and everything seems fine, disregarding the wrong logging. Thanks for the great support! Server 1 Server 2
  12. I’ve several other jobs in daily cron, but none of them trigger HDD spin ups. I started to look into this by removing all jobs and adding one by one until HDDs are spun up during daily cron task. So commenting /etc/cron.daily/armbian-ram-logging without removing the file stops my HDDs from spinning up. I’ll look into this later today when I get home. The way you have tested this is by running “/usr/lib/armbian/armbian-ramlog write”, correct?
  13. I rebooted after the changes last time, and tried again now by restarting cron, yet still the same result. All hard drives spin up during daily cron and spin down after 10 minutes. So there seems to be something we are missing.
  14. I know, yet the hard drives spins up... /var/log is on my Micro SD card. My hard drives are mounted with fstab to folders in "/mnt/usb*". Everything else is on my Micro SD card, so I've no clue why armbian-ramlog is still spinning up my hard drives...
  15. I changed /usr/lib/armbian/armbian-ramlog directly given your changes (Bugfix: check LOG_TYPE only at script start #1417), made it executable and rebooted the server, yet it spun up the hard drives when I changed the time for daily cron jobs to trigger etc/cron.daily/armbian-ram-logging. So, we are still not there yet... Please let me know if you want more testing etc
  16. As I was in the middle of the exam period when I posted this thread, I stopped all daily cron jobs as a shortcut, which fixed this issue. I've since found out that the daily cron job etc/cron.daily/armbian-ram-logging is the problem. armbian-ram-logging contains #!/bin/sh /usr/lib/armbian/armbian-ramlog write >/dev/null 2>&1 /usr/lib/armbian/armbian-ramlog contains /etc/default/armbian-ramlog contains So, I'm going to modify the file /etc/default/armbian-ramlog to prevent it from waking up my external hard drives every day. In that regard, it's much appreciated if anyone could point out which lines in the file that might wake up the hard drives. I'm thinking about line: 81 with "... blkid -s TYPE /dev/zram0 ..." which I think wake up all drives. What do you think? 65 with the find command "... find $HDD_LOG ...", yet it should only search for folders in the folder $HDD_LOG (/var/log.hdd/). @Igor, this issue is likely something that others might find interesting as armbian-ramlog currently is spinning up all connected drives, which shouldn't be necessary.
  17. I suspected that "Function not implemented" was related to some kernel configuration, however, I'm looking for an alternative to find processes which are accessing all three HDDs every day at the same time without disabling processes one by one... I've found blktrace which seems to give some relevant information as seen below. So, I'm going to run the following command a minute before the timestamp my HDDs are spinning up $ sudo blktrace -d /dev/sdb -o - | blkparse -i - 8,16 1 1 0.000000000 17 C N [0] 8,16 2 1 1266874889.708500152 888 G N [smartd] 8,16 2 2 1266874889.708505985 888 I N 0 [smartd] 8,16 2 3 1266874889.708510360 888 D N 0 [smartd] 8,16 1 2 5.001279610 17 C N [0] 8,16 1 3 5.002521825 17 C N [65531] 8,16 2 4 5.000177978 888 G N [smartd] 8,16 2 5 5.000184978 888 I N 0 [smartd] 8,16 2 6 5.000188770 888 D N 0 [smartd] 8,16 2 7 5.001649445 30968 G N [kworker/2:2] 8,16 2 8 5.001652070 30968 I N 0 [kworker/2:2] 8,16 2 9 5.001653528 30968 D N 0 [kworker/2:2] I'll also run strace to see if I can get some more information regarding this sudo strace -f -e open -t ls 2>&1 Tracking syscalls with auditctl (Audit framework) is also a possibility I've found and might be possible if kernels CONFIG_AUDIT is enabled. I'll look more into auditctl tomorrow if I don't find some relevant information from blktrace or strace.
  18. Hi, I've two Tinker Board servers running latest Armbian stable Debian GNU/Linux 9 with 4.19.*-rockchip. In that regard, I've connected some HDDs and from the log I see that every day at a specific time all HDDs are spinning up as seen below in the spoiler. This happens for both servers at the same specific time every day.. I've been thinking of using fatrace to trace file access events around the specific time to find which service that spins up my HDDs, however, when I try to use fatrace by running the code below I get the message "Cannot initialize fanotify: Function not implemented". I've come across two bug reports which seems to be related to this issue: some archs/kernels define O_LARGEFILE and Hardcoded KERNEL_O_LARGEFILE does not work on ARM. So, I guess fatrace is not an option given that it's not enabled in the kernel configuration. $ sudo fatrace -o /tmp/trace -s 60 Cannot initialize fanotify: Function not implemented btrace doesn't seem to be working either as seen below. $ sudo btrace /dev/sdb BLKTRACESETUP(2) /dev/sdb failed: 5/Input/output error Neither is iotop as seen below. $ sudo iotop Could not run iotop as some of the requirements are not met: - Linux >= 2.6.20 with - I/O accounting support (CONFIG_TASKSTATS, CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING) Any recommendation for tools that I can use to find out which process that is spinning up my HDDs every day? Thanks in advance!
  19. Untick "Set locale environment variables on startup" in Terminal -> Preferences -> Profiles -> Homebrew (if that is the profile you use) -> Advanced
  20. As I've moved away from apt-pinning since upgrading all my TB boxes to ARMBIAN 5.70 stable Debian GNU/Linux 9 (stretch) 4.19.14-rockchip this thread can be closed. I'll stick with compiling the few packages that I want and need the latest versions of while staying at the stable channel as I've encountered several issues when using apt-pinning or buster/sid deb as kernel panics, lost ethernet connection, logging services failing etc.
  21. Well, it seems that not installing some specific packages from testing deb causes Armbian memory supported logging to fail as installing only the package locales makes it fail. I'm thinking about disabling armbian-ramlog.service as you mentioned, yet I'm not sure the consequences and how it would differentiate from ex. the setup I had with Armbian_5.50_Tinkerboard_Debian_stretch_next_4.14.52. I'll post a full log with armbianmonitor -u in the first post after one more setup.
  22. Hi, I've some issues regarding apt pinning, which I've used for a year now without problems, after doing a clean install to Armbian_5.70_Tinkerboard_Debian_stretch_next_4.19.14. I've figured out that installing only locales from testing (2.28-4) over (2.24-11+deb9u3) kills armbian-ramlog.service as seen below in spoiler 1, which again seems to cause problems for other packages as Nginx. If a do a clean install, add testing sources, apt-pinning and run "sudo apt-get -t testing install locales", armbian-ramlog.service fails. I've tested everything using buster/sid after full apt-get dist-upgrade and it works. So, I've to find out which packages that I need to install in addition to prevent armbian-ramlog.service from failing. So, just pointing out which packages I've to install while using apt pinning to make sure armbian-ramlog.service works is very helpful for me. Running buster/sid instead of stable and apt pinning is not an option, so if apt pinning and Armbian memory supported logging is not possible I would have to compile the latest versions of the packages I want - which I've done before. Stretch backport is neither an option. If you guys think moving to Ubuntu might suit me better, please tell me and I'll try. Spoiler 3 contains the packages locales is dependent on which breaks armbian-ramlog.service. Output from armbianmonitor -u after installing locales from testing deb and rebooting is shown here Thanks in advance!
  23. Hi! I'm currently on ARMBIAN 5.50 testing Debian GNU/Linux 9 (stretch) 4.14.52-rockchip, which works perfectly. However, if I want to use the latest stable version without using nightly automated builds, are there any ways to accomplish this without downloading the latest image (ex Armbian_5.59_Tinkerboard_Debian_stretch_next_4.14.67) and reinstall everything? Cause using update && upgrade or using armbian config with firmware upgrade doesn't install later versions even if they are possible to download as images (I still have a TB on Armbian_5.41_Tinkerboard_Debian_stretch_next_4.14.23 which doesn't find any newer versions.).
  24. Hi guys! The Tinkerboard mainline kernel is running extremely smooth and it's months since I had problems regarding my Tinkerboard. So, hats off to everyone who have contributed to make Tinkerboard so stable and reliable! However, there is a minor thing I've been wondering for the last weeks. After normal apt-get upgrade and dist-upgrade, the armbian config version at startup does not change. So, given the code below, it says that Armbian-config 5.45 is installed, yet it show 5.41 which is the version from when I did setup the TB. Am I actually using the latest version? One more thing: On my last setup one of my three external hard drives which I'm mounting on startup with fstab showed up under "Usage of /:" Now no one of the three show up. Which file do I have to modify to make it possible to add more folders to show disk space at the welcome screen? I know that I receive the information running "df -h" to show disk space for different folders, yet it would be better to show it automatically. The following packages will be upgraded: armbian-config 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 35.2 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://apt.armbian.com stretch/main armhf armbian-config all 5.45 [35.2 kB] Fetched 35.2 kB in 0s (102 kB/s) (Reading database ... 39453 files and directories currently installed.) Preparing to unpack .../armbian-config_5.45_all.deb ... Unpacking armbian-config (5.45) over (5.44) ... Setting up armbian-config (5.45) ... ________________________________________________________________________________ *** REBOOTING SERVER *** ________________________________________________________________________________ *** AN AWESOME TINKERBOARD LOGO *** Welcome to ARMBIAN 5.41 stable Debian GNU/Linux 9 (stretch) 4.14.34-rockchip System load: 0.06 0.11 0.06 Up time: 4 min Memory usage: 8 % of 2005MB IP: <MyIP> CPU temp: 45°C Usage of /: 65% of 58G Update: @TonyMac32, could you help me regarding where I should post the information above to receive an answer from the devs maintaining the armbian-config? Should I post it under "Technical support -> Common issues" or "Development -> Development"?
  25. Update: I didn't figure out why I suddenly lost internet connection after upgrading packages so I've reinstalled and everything seems to be fine at the moment using 5.41 stable Debian GNU/Linux 9 (stretch) 4.14.34-rockchip. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Hi all! I've been using the nightly build for weeks, however, after upgrading today I'm having problems regarding network connection as I can't connect to the internet most of the time. I'm currently on ARMBIAN 5.42.180413 nightly Debian GNU/Linux buster/sid 4.14.35-rockchip, so I'm using a Tinkerboard which have been quite stable lately running headless. I posted an issue some months ago that I had problems with the network adapter going offline after restarting the router etc, yet, I'm not sure if the problem still exists. I can confirm it after solving this issue. Have there been any changes lately which is related to the network adapter or Network Manger? I would be of more help if it wasn't for the exam period I'm currently facing as I'm a student. So I haven't had time to look more into this. The strange thing about the issues are that sometimes I've connection to the internet, but most of the time I don't. I've configured a VPN tunnel for one user which have worked for months so I can't think why that implementation should affect the other users as it is linked to tun0. I've flushed all rules with "sudo iptables -F" just to be sure the firewall rules wasn't the problem. Here is my /etc/network/interfaces file as seen below: After running "nmcli d" it seems that the eth0 connection is unmanaged. Should the state of eth0 normally say "connected" as it does with tun0? I've tried running "sudo nmcli dev set eth0 managed yes", yet it doesn't change the state of eth0. Response running "sudo ip a show eth0" "nmcli -p g" response: I've tried to run "sudo ifconfig eth0 up", yet eth0 doesn't show running "nmcli connection" Syslog after rebooting - I think the line "Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0193] settings-connection[0x1f88950,<MyUUID>]: write: failure to update connection: writing settings not supported" might tell us what the problem is. After changing /etc/NetworkManager/NetworkManager.conf to the line below I now at least have a connection running "nmcli d", yet the connection does not last. After some seconds i loose the connection to internet. [ifupdown] managed=true Here is the complete list of all the packages I upgraded today before I lost the connection. Let me know if you require more information to solve the problem. Regards
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines