Bug 9497

I'm having issues starting networkd that seem related. I see this in the log:

systemd-tmpfiles[123]: [[0;1;31m[/usr/lib/tmpfiles.d/sys
temd.conf:19] Unknown user 'systemd-network'.[[0m


Looks like we need to fix this ASAP.

(In reply to comment #0)
> systemd_229.bb sets /bin/nologin as login command, but the actual file on
> disk is /sbin/nologin. The effect of course is the same, so this is merely
> an oddity.
> 
> meta/recipes-core/systemd/systemd_229.bb:USERADD_PARAM_${PN} +=
> "${@bb.utils.contains('PACKAGECONFIG', 'microhttpd', '--system -d / -M
> --shell /bin/nologin systemd-journal-gateway;', '', d)}"
> meta/recipes-core/systemd/systemd_229.bb:USERADD_PARAM_${PN} +=
> "${@bb.utils.contains('PACKAGECONFIG', 'timesyncd', '--system -d / -M
> --shell /bin/nologin systemd-timesync;', '', d)}"
> 
> However, the recipe seems out of sync with the actual users potentially
> needed by systemd. For example, systemd may also need "systemd-network"
> (from /usr/lib/sysusers.d/systemd.conf when networkd is enabled).
> 
> Presumably the explicit useradd in the recipe was added to ensure that
> /etc/passwd already gets created during image building, to support a
> read-only rootfs.
> 
> I'd like to propose a different solution that I added to Ostro OS: read and
> parse sysusers.d after installation and then do the necessary operations at
> image build time.
> 
> Code is currently here:
> https://github.com/ostroproject/meta-ostro/commits/master/meta-ostro/classes/
> systemd-sysusers.bbclass
> 
> I still need to fix one issue in it, though (must set --shell /sbin/nologin).

From the looks of it, your class only works if the sysusers PACKAGECONFIG is set? I do not see the sysusers.d directory in my build, unless I enable that option.

This also conflicts with the useradd-staticids class. I'm looking into a good fix for this now.

Looks like the reach-only-rootfs systemd functionality is already included here:

http://git.openembedded.org/openembedded-core/tree/meta/classes/rootfs-postcommands.bbclass  

(ln 77)

Is there a reason this isn't being used in Ostro?

I agree with Philip that the sysusers PACKAGECONFIG is required for the sysusers.d directory (and conf files) to be created. So if you do not have sysusers as a config option then you probably will not have a networkd user created.

My guess is that sysusers should be a default config option, but I'll look into that. We could manually (conditionally) add all the required users for systemd in the recipe, but that feels like we are duplicating sysusers functionality.

(In reply to comment #4)
> Looks like the reach-only-rootfs systemd functionality is already included
> here:
> 
> http://git.openembedded.org/openembedded-core/tree/meta/classes/rootfs-
> postcommands.bbclass  
> 
> (ln 77)
> 
> Is there a reason this isn't being used in Ostro?

I wasn't aware that it exists. It is not active in Ostro because we are not building with "read-only-rootfs" in IMAGE_FEATURES. Our goal is similar to read-only-rootfs, but not quite the same.

My comment about "read-only rootfs" was speculation from me about the reason why the systemd recipe adds some users explicitly; turns out that this isn't the reason (or the reason isn't valid anymore).

So given that the code exists, can we make it available also when not building with read-only-rootfs?

IMHO it can even be unconditional. Why do something only at runtime when it can already be done at image build time?

However, beware that the existing code has the same bug as my own initial version ;-) It misses a "--shell /sbin/nologin".

Thanks, I'll fix that issue as well since I'll be reworking that function anyway.

I agree that having this option, regardless of read-only, would be a benefit. Many users will want to boot directly to a working systemd setup, without the need for user creation at runtime.

I'll run this by the team and then make the necessary changes.

With commit 98a4c642444a524f547f5d978a28814d20c12354 I've allowed users to add this functionality by simply adding: ROOTFS_POSTPROCESS_COMMAND += "systemd_create_users".

I've also added YOCTO #9788 to add "-m" flag processing to this function.

Finally, I've added YOCTO #9789 to check the staticids data and apply appropriate ids if needed.