Bug#768644: systemd: missing dependency on /var being mounted

David Kozub zub at linux.fjfi.cvut.cz
Sun Nov 9 12:44:06 GMT 2014


On Sun, 9 Nov 2014, Michael Biebl wrote:

> Am 09.11.2014 um 00:21 schrieb Michael Biebl:
> Hm, this might be a result of David adding a custom var.mount unit.
>
> David, could you please undo all local hacks you had: var.mount,
> delay.service etc, then reboot and add systemd.log_level=debug to the
> kernel command line so we get a log from a systemd which exposes the issue.
>
> Then attach the output of "systemd-analyze dump" and "journalctl -alb"

Hi Michael,

You are right. This is the results of my hacks. When I undo my hacks I see 
"After: var.mount" in local-fs.target (in the output of systemd-analyze 
dump).

The original case that made me poke around this was running with readonly 
rootfs on a Raspberry Pi with raspbian. I saw debian-fixup.service failing 
there and concluded it's the order of /var and debian-fixup.service. While 
trying to reproduce this with a clean jessie install my attempts at 
delaying /var caused other issues.

So my original report is nonsense. I apologize for the noise.

With systemd-analyze I think I now understand why does 
debian-fixup.service fail. That part I think is still a valid issue. (I 
think debian-fixup.service can be run before /var is mounted. But unless 
the condition for the service is not met AND rootfs is readonly it doesn't 
show up, so it's not likely many people would see it.)

Is it OK to hijack this bug for that, or should I create a new bug?




More information about the Pkg-systemd-maintainers mailing list