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?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
