this does not look pretty:
@dev could this proposal be acceptable ?
And I watched my first learn PHP in 30 minutes tutorial 
, and came up with this:
@dz00te please comment
1 Like
yes i’ve made same consideration while testing ns7alpha on rpi2, hardcoding model seems the only solution… if i remember correctly i’ve written a little script in python to identify the different version of rpiX
i’ll try to find it somewhere on hd… search in progress give me some time 
i need too a tutorial 
1 Like
First of all, thank you for raising this issue, Mark!
I think it’s better to keep the discussion going on here and open issues on GitHub when things are clear enough. We tried to explain this principle here:
http://docs.nethserver.org/projects/nethserver-devel/en/v7b/development_process.html
I agree with you and @dz00te we need to enhance the Dashboard logic to catch the model name.
Are you sure there isn’t an API similar to /sys/devices/virtual/dmi/id/ on ARM? How would you write the script to identify the board?
If we really need a place where to persist information probed during system-init, I think the esmith DB is a good place too.
1 Like
yes, there is not dmidecode or lshw on rpi and maybe others (no bios)
probably i’ve lost my script when i rewrote my sd yesterday 
for rc1
i’ll do some other search at home…
but searching on internet, i think i started from this
and added a list of version based on
and
http://elinux.org/RPi_HardwareHistory
i it was something like this
obviously, not so well written
btw there are other scripts on github
yes i thought about it, but not knowing how to do in 5 min I thought I’d try it later… then i forgot all
Thank you for the tip!
I’d prefer not to have persistent information. I’d go with the following:
Create an UI helper script with all the arch-dependant logics that fetches the required details and outputs it in a JSON format. The helper script must be fast, of course.
The PHP Dashboard module is completely abstract from the arch. It exec() the helper and parses the json output, placing the information in the right place.
Does anybody want to try? It does not bite! 
The x86_64 part is trivial. We can adapt an existing python script for arm by checking for dmi existence…
I totally agree. note it’s an issue of the (my) nethserver-arm issue-tracker, opened on march 27.
Not on devices with a disk based boot loader, there is no bios/dmi. Centos has not switched (yet) to the device tree structure, it’s after kernel 3.10. therefore it’s not implemented ion deceives with 4.x kernels.
My first thought, why read static values very time the dashboard refreshes. I proposed this instead, to start this discussion, because it has minimal impact.
With device tree overlay’s it would be simple just read it from /proc/devicetree, we wouldn’t we need a script.
Without it its difficult. AFAIK: reduce it from : CPU/SOC information and/or “old fashioned” loaded/available system devices in /sys/devices/platform.
This sounds good, give some time to understand what your are saying. 
lol my exact thought 
maybe this can be useful?
Yes,
we should at least include by centos supported boards, cubbietruck and bananapi come in to mind.
In the end it should be possible to set the value manually (for “hackers” like me) this is the case if it’s stored in e-smith db (if no dmi).
I get it now,
I think we making it complicated, the aspect of the dashboard not working are static values,
Oke the cpu could be upgraded. In a VM the numbers of cores for sure, counting of core’s works well.
The esmith DB would be overwritten by the restore-config procedure. Using a different file that is written once during system-init could work. I’d like the same file for different architectures, it would simplify the Dashboard code.
Just thinking aloud, let’s call it hardware-inventory, updated at every boot… /cc @edoardo_spadoni
@davidep Don’t get me wrong, I like your first suggestion to. Do not want to imply a rewrite of code not being altered since 2014 just because ARM is around. I like it, x86_64 would profit to fast(ter) data collection. 
As far as I can see this and nethserver-mock needs work to merge.
and nethserver-release of course (BTW see no point in to “merge” those)
Hi, there is an amazing tool created by PuppetLabs called Facter that is built-in in puppet-agent package.
The puppet-agent is build for x86_64 architecture at the moment, maybe there is an implementation also for ARM architecture.
After the installation, the command is /opt/puppetlabs/bin/facter -j that outputs the hardware inventory of the machine in JSON format.
It could be interesting using this output to store hardware information that NethGUI uses to show data in hardware widgets.
Here the lists of resources that facter can read: Facter docs
2 Likes
Quick search leans there is a debian package for armv7h (=pi), so source is somewhere on the web.
Ill try to hunt it down’, thanx!
2 Likes
Well the problem is not there are no ARM implementations, all arch’s are listen in the puppetlabs debian apt-repository, it’s there is no ruby for centos-arm.
This makes implementing puppet-agent on Centos arm (as @davidep likes to say it) hard to do…
for sure not a great solution, but the empty space in dashboard /hw info it’s not nice
so i’ve made this silly and un-elegant patch (in case someone is interested…)
create patch file
cat << 'EOF' > patchDash.txt
--- Resources.php<----->2017-01-30 12:45:00.000000000 +0100
+++ Resources_rpi.php<->2017-02-15 12:46:59.876975776 +0100
@@ -91,7 +91,7 @@
$ret++;
}
}
- $tmp = explode(':',$f[4]);
+ $tmp = explode(':',$f[1]);
return array('model' => trim($tmp[1]), 'n' => $ret);
}
@@ -100,7 +100,9 @@
{
if (file_exists("/sys/devices/virtual/dmi/id/$id")) {
return file_get_contents("/sys/devices/virtual/dmi/id/$id");
- } else {
+ } elseif (file_exists("/sys/firmware/devicetree/base/model")) {
+ return file_get_contents("/sys/firmware/devicetree/base/model");
+ } else {
return "-";
}
}
EOF
apply:
patch /usr/share/nethesis/NethServer/Module/Dashboard/SystemStatus/Resources.php < patchDash.txt
and at least i’m happy seeing this
1 Like