hook Posted July 5, 2017 Share Posted July 5, 2017 I have two Olimex Lime 2 eMMC boards, both set up the same way – same HDDs, same batteries, same power supplies, etc. Both run: - Armbian 5.31 (although one was updated to it, and the other was freshly installed with that version) - Debian 9 “stretch“ (same issue when they were both on Debian 8 “wheezy” though) - Linux kernel 4.8.14-sunxi Yet, one shows the CPU temperature, and the other doesn’t. A (the fresh-installed one): cat /sys/class/thermal/thermal_zone0/temp 41800 B (the one updated to 5.31 from a previous 5.x version): cat /sys/class/thermal/thermal_zone0/temp cat: /sys/class/thermal/thermal_zone0/temp: Invalid argument Any idea how that came to be and how to fix it? My plan is to use the GPIO pins to regulate the power of an 5V fan to provide cooling only when needed. If there is interest, I’m happy to share a HowTo, if I succeed Link to comment Share on other sites More sharing options...
Igor Posted July 5, 2017 Share Posted July 5, 2017 apt-update / apt-upgrade + reboot Kernel will be upgraded to 4.11.5 and temperature will be back. In version you are using we had a problem with some patch resulting in failed temperature readings. Link to comment Share on other sites More sharing options...
hook Posted July 5, 2017 Author Share Posted July 5, 2017 I just did and unfortunately this didn’t help. Link to comment Share on other sites More sharing options...
Igor Posted July 5, 2017 Share Posted July 5, 2017 Hmm. Spoiler _ _ ____ | | (_)_ __ ___ ___ |___ \ | | | | '_ ` _ \ / _ \ __) | | |___| | | | | | | __/ / __/ |_____|_|_| |_| |_|\___| |_____| Welcome to ARMBIAN 5.31 stable Ubuntu 16.04.2 LTS 4.11.5-sunxi System load: 0.19 0.10 0.05 Up time: 15 days Memory usage: 18 % of 1001MB IP: CPU temp: 38°C Usage of /: 50% of 117G Battery: 98% charging [ 0 security updates available, 1 updates total: apt upgrade ] Last check: 2017-07-05 00:00 [ General system configuration: armbian-config ] Last login: Wed Jul 5 12:52:36 2017 from root@lime2:~# This is Lime in front of me. Perhaps you have frozen kernel packages to prevent their upgrade? Link to comment Share on other sites More sharing options...
hook Posted July 5, 2017 Author Share Posted July 5, 2017 Hm, you are right. Server A is on 4.11.6-sunxi; while Server B is on 4.8.14-sunxi Although in both cases `apt search` shows the 4.11.6 kernel as installed: linux-image-next-sunxi/jessie,now 5.32 armhf [installed] Linux kernel, version 4.11.6-sunxi Where would I have to check if the package is indeed frozen (and how to unfreeze it)? I honestly don’t remember doing it myself. Link to comment Share on other sites More sharing options...
Igor Posted July 5, 2017 Share Posted July 5, 2017 16 minutes ago, hook said: Hm, you are right. Server A is on 4.11.6-sunxi; while Server B is on 4.11.6-sunxi Where would I have to check if the package is indeed frozen (and how to unfreeze it)? I honestly don’t remember doing it myself. Now I am confused. 4.11.6 should have temperature readings fixed, at least kernel from our repository ... if you are using your own build, rebuild it, install, reboot. BTW: Freezing / unfreezing can be simply done in armbian-config Link to comment Share on other sites More sharing options...
hook Posted July 5, 2017 Author Share Posted July 5, 2017 2 minutes ago, Igor said: Now I am confused. 4.11.6 should have temperature readings fixed, at least kernel from our repository ... if you are using your own build, rebuild it, install, reboot. Yeah, sorry, wrong copy-paste. Fixed now with more info. 2 minutes ago, Igor said: BTW: Freezing / unfreezing can be simply done in armbian-config Got it. I *might* have done that without realising what it does 1 Link to comment Share on other sites More sharing options...
hook Posted July 5, 2017 Author Share Posted July 5, 2017 Odd, I now cancelled the hold/freeze (if it was on before at all), did `apt update; apt upgrade`, rebooted. Then repeated this procedure, just in case. And the results are: uname -a Linux juno 4.8.14-sunxi #1 SMP Sun Dec 11 15:20:01 CET 2016 armv7l GNU/Linux but on the other hand: ls /boot/ bin.old/ dtb@ dtb.old@ script.bin@ uInitrd@ vmlinuz-4.11.6-sunxi* config-4.11.6-sunxi dtb-4.11.6-sunxi/ initrd.img-4.11.6-sunxi System.map-4.11.6-sunxi uInitrd-4.11.6-sunxi zImage@ Colour me confused … Link to comment Share on other sites More sharing options...
Igor Posted July 5, 2017 Share Posted July 5, 2017 armbianmonitor -u Link to comment Share on other sites More sharing options...
hook Posted July 5, 2017 Author Share Posted July 5, 2017 http://sprunge.us/ibXh Link to comment Share on other sites More sharing options...
Igor Posted July 5, 2017 Share Posted July 5, 2017 When you install kernel your actual boot must be mounted under /boot ... which is not your case. Did you alter anything or our installer failed to do this job? Edit: mount eMMC somewhere and bind mount it's /boot under /boot Link to comment Share on other sites More sharing options...
hook Posted July 5, 2017 Author Share Posted July 5, 2017 Both are possible, as the board with the 4.8 kernel, is the one used to test the Lime 2 eMMC installer/images for. That’s odd though. On both boards it should be eMMC as /boot/ and the HDD for the rest. The other board has it that way. Is there an official way how to fix this or should I just copy the /etc/fstab entries for /boot and /media/mmcboot and from the other board and simply change the UUID accordingly? Good thing that it seems that the 5.31 installer seems to have worked fine on the other board Link to comment Share on other sites More sharing options...
Igor Posted July 5, 2017 Share Posted July 5, 2017 Check this, before mounting emmc under /boot copy content from hdd /boot to emmc /boot ... than it will be all fine. 1 Link to comment Share on other sites More sharing options...
hook Posted July 5, 2017 Author Share Posted July 5, 2017 On it, thanks Oddly enough, the eMMC seems to include a full 1.5 GiB system and not just the /boot/ dir ls /media/mmcboot/ bin/ dev/ home/ lost+found/ mnt/ proc/ run/ selinux/ sys/ usr/ boot/ etc/ lib/ media/ opt/ root/ sbin/ srv/ tmp/ var/ Link to comment Share on other sites More sharing options...
Igor Posted July 5, 2017 Share Posted July 5, 2017 This is normal. First you need to mount whole eMMC's (first partition) / and then bind mount it's /boot to your system's /boot Link to comment Share on other sites More sharing options...
hook Posted July 5, 2017 Author Share Posted July 5, 2017 OK, just found it odd. But I can see the logic behind it, as a fail-safe if the HDD fails, right? Link to comment Share on other sites More sharing options...
hook Posted July 5, 2017 Author Share Posted July 5, 2017 Yay! Works now Thanks Igor, again I owe you a cuppa tea. Link to comment Share on other sites More sharing options...
Recommended Posts