<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 31, 2019 at 4:34 PM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Di, 08.10.19 16:57, Martin Townsend (<a href="mailto:mtownsend1973@gmail.com" target="_blank">mtownsend1973@gmail.com</a>) wrote:<br>
<br>
> Thanks for your help.  In the end I just created a symlink from<br>
> /etc/machine-id to /data/etc/machine-id.  It complains really early on<br>
> boot with<br>
> Cannot open /etc/machine-id: No such file or directory<br>
><br>
> So I guess it's trying to read /etc/machine-id for something before<br>
> fstab has been processed and the data partition is ready.<br>
><br>
> But the journal seems to be working ok and --list-boots is fine.  The<br>
> initramfs would definitely be more elegant solution to ensure<br>
> /etc/machine-id is ready.<br>
><br>
> I don't suppose you know what requires /etc/machine-id so early in the boot?<br>
<br>
PID 1 does.<br>
<br>
You have to have a valid /etc/machine-id really, everything else is<br>
not supported. And it needs to be available when PID 1 initializes.<br>
<br>
You basically have three options:<br>
<br>
1. Make it read-only at boot, initialize persistently on OS install<br>
<br>
2. Make it read-only, initialize it to an empty file on OS install, in<br>
   which case systemd (i.e. PID 1) overmounts it with a random one<br>
   during early boot. In this mode the system will come up with a new<br>
   identity on each boot, and thus journal files from previous boots<br>
   will be considered to belong to different systems.<br>
<br>
2b. (Same as 2, but mount / writable during later boot, at which time<br>
    the machine ID is commited to disk automatically)<br>
<br>
3. Make it writable during early boot, and initialize it originally to<br>
   an empty file. In this case PID 1 will generate a random one and<br>
   persist it to disk right away.<br>
<br>
Also see:<br>
<br>
<a href="https://www.freedesktop.org/software/systemd/man/machine-id.html" rel="noreferrer" target="_blank">https://www.freedesktop.org/software/systemd/man/machine-id.html</a><br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br></blockquote><div><br></div><div>Hi Lennart,</div><div><br></div><div>Thank you for the information it was very useful.  Reading the link on machine-id gives my another option and that is to pass the machine-id via U-Boot to the kernel via its bootargs.  As some background this is for an embedded system that is using systemd and Mender which seems to becoming fairly popular so hopefully this may help someone else who stumbles across this post with the same problem.  Mender provides image updates on an A/B root filesystem, so having /etc/machine-id within the root filesystem isn't really feasible but with Mender you get a persistent data partition that both root filesystems share, hence why have opted for a symlink to the persistent partition. So for embedded systems using Mender that want a persistent machine-id I see two options now:</div><div><br></div><div>1) Use an initramdisk to mount the persistent mender data partition and store machine-id in here with /etc/machine-id a symlink</div><div>2) and thanks to your link I think we could store the machine-id in the U-Boot environment and pass it in as the systemd.machine_id= kernel command line parameter.  </div><div><br></div><div>Out of interest what does PID 1 need /etc/machine-id for before it has processed fstab (and hence the persistent data partition would be ready to read the /etc/machine-id symlink)?  We haven't implemented either of the above so I wouldn't mind knowing what the impact would be.</div><div><br></div><div>Cheers,</div><div>Martin.</div><div><br></div><div><br></div></div></div>