Machine id service

[mwallnoefer]

This is the error message which I get with the edison-machine-id.service:

root@edison:~# systemctl status edison-machine-id.service
● edison-machine-id.service - Generate unique machine-id
   Loaded: loaded (/lib/systemd/system/edison-machine-id.service; enabled; vend>
   Active: failed (Result: exit-code) since Fri 2020-02-21 07:01:47 UTC; 3min 3>
  Process: 2292 ExecStartPre=/bin/umount /etc/machine-id (code=exited, status=3>

Feb 21 07:01:47 edison systemd[1]: Starting Generate unique machine-id...
Feb 21 07:01:47 edison umount[2292]: umount: /etc/machine-id: not mounted.
Feb 21 07:01:47 edison systemd[1]: edison-machine-id.service: Control process e>
Feb 21 07:01:47 edison systemd[1]: edison-machine-id.service: Failed with resul>
Feb 21 07:01:47 edison systemd[1]: Failed to start Generate unique machine-id.

On my Edison board /etc/machine-id is a plain file, no mountpoint.

[mwallnoefer]

Also the battery-voltage.service may be disabled by default, since it cannot find any battery.

[htot]

Yeah, true. I haven't found the time to look into the machine id. What do you think, should we just remove it? We have:

journalctl -b | grep machine
edison systemd[1]: Starting Generate unique machine-id...
root@edison:~# cat /etc/machine-id 
8036b48979e9460a96d98b58a799ef18

Systemd already takes care of this?

For battery voltage would be nice if it just fails silently. But I have no battery to test if it works at all.

[mwallnoefer]

What do you think, should we just remove it?

It's not clear for me how this machine id was used in the past. So if there do not exist an important dependency we may drop immediately. Otherwise such an unique machine id code could also be generated by bitbake on the host, making this systemd service superfluous?

For battery voltage would be nice if it just fails silently. But I have no battery to test if it works at all.

If you ask me I would deliver this systemd unit disabled by default, since I do not think that the majority of our potential users make use of it.

[mwallnoefer]

Machine id fixed: https://github.com/edison-fw/meta-intel-edison/pull/89

[mwallnoefer]

If I look at the source (battery_voltage.c) it is clear that it won't work without the pmic_ccsm driver:

char path[] = "/sys/devices/platform/pmic_ccsm/battery_level";

So I opened another pull request: #90

[htot]

It may be that currently the machine-id is generated by systemd: https://www.freedesktop.org/software/systemd/man/machine-id.html so that the recipe has become obsolete, but I didn't check that. If so we could drop the whole recipe.

@andy-shev has done a pmic driver, but I'm not sure if we are picking up the battery voltage. If we are we need to rewrite batter_voltage.c a bit.

[andy-shev]

@andy-shev has done a pmic driver, but I'm not sure if we are picking up the battery voltage. If we are we need to rewrite batter_voltage.c a bit.

With battery things are quite complicated. It involves charger chip to be upstreamed first, but nobody continued that work https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1740180.html Any volunteer?

[htot]

So how does that work on edison-arduino? The charger U38 is external. Is there another in the pmic?

[andy-shev]

So how does that work on edison-arduino? The charger U38 is external. Is there another in the pmic?

Hmm... I thought BQ24261 somehow related to this. I'll check the documentation I have next week, possible I'm simple misguided. I have just checked data sheets for SparkFun Edison battery block and Edison/Arduino, and seems they have standalone chargers (no OS involvement needed).

[htot]

But there was also a phone right? Maybe there the situation was different?

[htot]

Just tested: we can drop the recipe as systemd already generates a machine-id. Patch for this will appear initially in https://github.com/htot/meta-intel-edison/tree/zeus (in a few days after I clean up)