Missing CPU temperature sensor output on (one of my) Olimex Lime 2 eMMC

[hook]

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

[Igor]

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.

[hook]

I just did and unfortunately this didn’t help.

[Igor]

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?

[hook]

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.

[Igor]

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

[hook]

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

[hook]

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 …

[Igor]

armbianmonitor -u

[hook]

http://sprunge.us/ibXh

[Igor]

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

[hook]

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

[Igor]

Check this, before mounting emmc under /boot copy content from hdd /boot to emmc /boot ... than it will be all fine.

[hook]

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/

 

[Igor]

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

[hook]

OK, just found it odd. But I can see the logic behind it, as a fail-safe if the HDD fails, right?

[hook]

Yay! Works now

 

Thanks Igor, again I owe you a cuppa tea.