<div dir="auto"><div>Yes you are right, I overlooked the existing exception, it is indeed probably the setup which causes it. I had rebooted the box previously and tested only the clearing service.</div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto">Axel</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Op di 5 dec. 2023 00:38 schreef Michael Biebl <<a href="mailto:biebl@debian.org">biebl@debian.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 04.12.23 um 23:09 schrieb Michael Biebl:<br>
> The code to exclude lost+found appears to be still there:<br>
> <a href="https://github.com/systemd/systemd/blob/main/src/tmpfiles/tmpfiles.c#L720" rel="noreferrer noreferrer" target="_blank">https://github.com/systemd/systemd/blob/main/src/tmpfiles/tmpfiles.c#L720</a><br>
> <br>
> Can you create a lost+found directory and then run<br>
> SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --prefix /tmp<br>
> <br>
> ?<br>
<br>
I haven't really debugged this fully, but from a cursory glance it <br>
appears that systemd-tmpfiles-setup.service is responsible for nuking <br>
/tmp/lost+found<br>
<br>
systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev<br>
doesn't preserve /tmp/lost+found which looks like a regression.<br>
</blockquote></div></div></div>