dracut/99setup-root: change owner of /run/log/journal#59
dracut/99setup-root: change owner of /run/log/journal#59tormath1 merged 2 commits intoflatcar-masterfrom
Conversation
|
|
||
| # Give the correct ownernship otherwise the tmpfiles configuration will not | ||
| # apply because of mismatching machine-id - which makes "journalctl --user" to fail. | ||
| chown --recursive root:systemd-journal /run/log/journal/ |
There was a problem hiding this comment.
Wait, this reminds me of flatcar/Flatcar#799
I think the problem could be that systemd-tmpfiles doesn't find the systemd-journal group because it's not part of /sysroot/etc/group but only loaded via the nss-altfiles plugin from our database in baselayout.
I think as long as we don't change systemd-tmpfiles to somehow resolve the nss stuff in the given chroot, we should all systemd-journal as special group to copy like docker: https://github.com/flatcar/baselayout/blob/flatcar-master/scripts/flatcar-tmpfiles#L13
This will also be a workaround for the linked issue (at least for the journal but not for kvm - maybe add that, too? At some point we should fix the tools, though).
There was a problem hiding this comment.
Based on the assumption that this existing tmpfiles rule here would set the group:
/usr/lib/tmpfiles.d/systemd.conf:z /run/log/journal 2755 root systemd-journal - -
/usr/lib/tmpfiles.d/systemd.conf:Z /run/log/journal/%m ~2750 root systemd-journal - -
There was a problem hiding this comment.
Yeah I checked this initially and the issue is not to change the owner in /sysroot/run/log/journal but in /run/log/journal (the one in the initramfs) so I tried with systemd-tmpfiles --create systemd.conf but in the end, I thought it would be overkill so just changed the ownership of the /run/log/journal.
There was a problem hiding this comment.
Ah, ok, right, /sysroot/run isn't mounted and this setup would take place later and not in the call we do here.
If this is about /run/log/journal of the initrd I think it's at the wrong place. Edit: Maybe 99journald-conf?
There was a problem hiding this comment.
I tried it out manually with rd.shell rd.break=cmdline (=pre-mount or =pre-pivot would be too late) on a qemu arm64 VM.
After the VM booted I see this:
core@localhost ~ $ ls -alh /run/log/
total 0
drwxr-xr-x. 3 root root 60 Mar 28 03:10 .
drwxr-xr-x. 30 root root 780 Mar 28 03:16 ..
drwxr-sr-x. 4 root systemd-journal 80 Mar 28 03:15 journal
core@localhost ~ $ ls -alh /run/log/journal/
total 0
drwxr-sr-x. 4 root systemd-journal 80 Mar 28 03:15 .
drwxr-xr-x. 3 root root 60 Mar 28 03:10 ..
drwxr-s---. 2 root systemd-journal 60 Mar 28 03:10 931d6b0b22a24775bbd156cfaf0e98f4
drwxr-s---. 2 root systemd-journal 60 Mar 28 03:15 bd9ce2b134744c6db1aca45238fd9848
core@localhost ~ $ ls -alh /run/log/journal/*
/run/log/journal/931d6b0b22a24775bbd156cfaf0e98f4:
total 2.5M
drwxr-s---. 2 root systemd-journal 60 Mar 28 03:10 .
drwxr-sr-x. 4 root systemd-journal 80 Mar 28 03:15 ..
-rw-r-----. 1 root systemd-journal 2.5M Mar 28 03:14 system.journal
/run/log/journal/bd9ce2b134744c6db1aca45238fd9848:
total 2.5M
drwxr-s---. 2 root systemd-journal 60 Mar 28 03:15 .
drwxr-sr-x. 4 root systemd-journal 80 Mar 28 03:15 ..
-rw-r-----. 1 root systemd-journal 2.5M Mar 28 03:16 system.journal
core@localhost ~ $ ls -alh /run/log/journal/*/*
-rw-r-----. 1 root systemd-journal 2.5M Mar 28 03:14 /run/log/journal/931d6b0b22a24775bbd156cfaf0e98f4/system.journal
-rw-r-----. 1 root systemd-journal 2.5M Mar 28 03:16 /run/log/journal/bd9ce2b134744c6db1aca45238fd9848/system.journal
There was a problem hiding this comment.
(I have no answer for why this happens only on arm64 and why the upstream file wants local-fs - probably more for the real system and not really needed in the initrd, but no idea how to encode this conditionally)
There was a problem hiding this comment.
CI is done. AMD64 is failing too for the very same reason. Ignition's run seems to be the point of failure (as it pass the update test)
Mar 27 19:56:35.796020 systemd[1]: ignition-fetch.service: Found ordering cycle on systemd-resolved.service/start
Mar 27 19:56:35.796028 systemd[1]: ignition-fetch.service: Found dependency on systemd-tmpfiles-setup.service/start
Mar 27 19:56:35.796036 systemd[1]: ignition-fetch.service: Found dependency on local-fs.target/start
Mar 27 19:56:35.796043 systemd[1]: ignition-fetch.service: Found dependency on local-fs-pre.target/start
Mar 27 19:56:35.796051 systemd[1]: ignition-fetch.service: Found dependency on ignition-disks.service/start
Mar 27 19:56:35.796058 systemd[1]: ignition-fetch.service: Found dependency on ignition-fetch.service/start
It looks like we differ from coreos/ignition on this:
# Flatcar:
Wants=systemd-networkd.service
After=systemd-networkd.service
Wants=systemd-resolved.service
After=systemd-resolved.service
Requires=local-fs-pre.target
Before=local-fs-pre.target
(https://github.com/coreos/ignition/blob/main/dracut/30ignition/ignition-fetch.service &
bootengine/dracut/30ignition/ignition-fetch.service
Lines 22 to 32 in 3ba6216
Do you remember why we have this dependency:
Requires=local-fs-pre.target
Before=local-fs-pre.target
?
There was a problem hiding this comment.
It's needed because Ignition can repartition the rootfs (https://github.com/flatcar/bootengine/blob/flatcar-master/dracut/30ignition/ignition-disks.service#L24)
There was a problem hiding this comment.
As said, I think we can tweak the service to run a bit earlier, too. I've moved the comment into a suggestion.
fcd7e86 to
9aceb99
Compare
8d11a68 to
d45435c
Compare
This reverts commit b0b7416.
otherwise it leads to a cyclic dependency with ignition-fetch.service ``` Found ordering cycle on systemd-resolved.service/start Found dependency on systemd-tmpfiles-setup.service/start Found dependency on local-fs.target/start Found dependency on local-fs-pre.target/start Found dependency on ignition-disks.service/start Found dependency on ignition-fetch.service/start ``` Co-authored-by: Kai Lüke <pothos@users.noreply.github.com> Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
d45435c to
66b6dda
Compare
Give the correct ownernship otherwise the tmpfiles configuration will not apply because of mismatching machine-id - which makes "journalctl --user" to fail