Z11ntal33r

  • Posts

    48
  • Joined

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Everything posted by Z11ntal33r

  1. 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?
  2. 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).
  3. 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
  4. 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?
  5. 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.
  6. 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...
  7. 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
  8. 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.
  9. 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.
  10. 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!
  11. Untick "Set locale environment variables on startup" in Terminal -> Preferences -> Profiles -> Homebrew (if that is the profile you use) -> Advanced
  12. 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.
  13. 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.
  14. 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!
  15. 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.).
  16. 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"?
  17. 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
  18. Haha, I wished, yet it didn't... We have been playing with the RPi in some courses at the university and I've been sitting on the edge for months hoping for a new version. As that never happened, I started looking for other options and the choice felt on the Tinker Board. The main drawbacks of the Tinker Board is of course the community, yet since I want to learn and develop skills there shouldn't be any issue to fill the software gaps by myself. Which I have by compiling latest software versions right from the source as the versions in the repo are outdated by months... I'm so satisfied as I could get! I wasn't thinking that my Tinker Board was able to transcode huge 1080p files, yet it does and from a hardware point of view, compared to the RPi of course, the Tinker Board is marvelous!
  19. Hello! I've been using Armbian on my newly bought Tinker Board for less than two weeks now and I've to say that the work you guys have put into this is incredible! It truly is remarkable and inspires us newcomers which haven't started studying computer science or are currently studying - as myself. So, I will definitely contribute and help others in the future to increase the Armbian community! However, as I'm new to Unix, Tinker Board, everything that's not Windows or Mac OS, I've a deep learning curve ahead! Let's start with my setup: Build: ARMBIAN 5.32.170921 nightly Ubuntu 16.04.3 LTS 4.14.0-rc1-rockchip (I know it's nightly so there are bugs, yet I would like to help to fix them by giving helpful information if needed) My main sudo user is only used to connect to the Tinker Board through ssh and Remote Desktop. The other users have separate tasks, like the vpn user is connected through OpenVPN and runs rTorrent (split tunnel), another user is running Monit, Resilio Sync, Plex Media Server (with Transcoding), NFS File Server and so on. The connection is wired and the main issue occurs when I reboot my router or the power cuts as the Tinker Board won't try to re-establish the connection. All my other devices that are connected through ethernet will, so I assume this is a bug or something I've to configure. The only way to reconnect the Tinker Board is to cut the power as I'm using the Tinker Board as a NAS with no mouse, keyboard and HDMI cable. My syslog has thousands of lines so if there are some specific information you need, please point me in the right direction. Again, thanks for the incredible support and the effort you guys have put into this! I couldn't dream of a better experience with my Tinker Board using Armbian and considering everything I've installed and done so far without facing critical bugs or big problems is almost to good to be true! So keep up the excellent work:)