[systemd-devel] fstab mounts get unmounted during boot (.device unit bouncing?)

Przemyslaw Rudy prudy1 at o2.pl
Wed Feb 11 05:14:45 PST 2015


On 02/11/2015 01:45 PM, Martin Pitt wrote:
> Lennart Poettering [2015-02-11 13:29 +0100]:
>> On Wed, 11.02.15 13:20, Martin Pitt (martin.pitt at ubuntu.com) wrote:
>>
>>> Hello all,
>>>
>>> for a few weeks now (roughly since upgrading to 218) I often end up
>>> with my /home and /srv (from fstab) not mounted after booting, and I
>>> have to run "mount -a" manually.  Initially I attributed this to my
>>> hacked-up laptop, but now I got a report from another user about that
>>> too (https://launchpad.net/bugs/1419623)
>>>
>>> The issue is that home.mount (from systemd-fstab-generator) does seem
>>> to get mounted, but unmounted immediately afterwards:
>>>
>>> The full journal and output of systemctl show/status is at
>>> http://people.canonical.com/~pitti/tmp/debug-fstab-unmount/ but
>>> limiting it to the partition which has /home, and the mount unit
>>> reveals some strange things:
>>>
>>> | $ egrep 'f8653.*device|home.mount' journal.txt
>>> | [    5.629480] donald systemd[1]: home.mount changed dead -> mounted
>>> | [    5.629559] donald systemd[1]: Unit home.mount is bound to
>>> | inactive service. Stopping, too.
>>
>> Which unit precisely is the mount unit bound to?
> 
> That was part of the "show home.mount" output in my initial mail, but
> it's this one:
> 
> | BindsTo=dev-disk-by\x5cx2duuid-f86539b0\x5cx2d3a1b\x5cx2d4372\x5cx2d83b0\x5cx2dacdd029ade68.device
> 
>> Is this the device unit change we recently made?
> 
> No, it's not. I don't have that patch backported to our packages yet.
> But I did try with systemd from current upstream trunk master, and I
> get the same issue.
> 
>> My guess is that the device unit the mount unit is bound to doesn't
>> actually become active... Maybe a different name is used for it or so=
> 
> It does become active, it's the very unit that the log shows right
> before home.mount goes to "dead". The name is AFAICS. Also, this is a
> race condition -- sometimes it works, sometimes not.
> 
> I wasn't able to reproduce that in QEMU with BIOS; I'm using EFI on my
> box which might be a significant difference.
> 
>> The latter two are from a systemd --user instance, see the PIDs...
> 
> Ah right, so that's just noise.
> 
>>
>>> | BindsTo=dev-disk-by\x5cx2duuid-f86539b0\x5cx2d3a1b\x5cx2d4372\x5cx2d83b0\x5cx2dacdd029ade68.device
>>
>> It would be goot to check what this .device unit is up to...
> 
> The systemctl show -l for that device is in the initial mail, I can't
> see anything wrong with it. Also, the After= looks ok too, which
> should force home.mount to only start after the .device goes to
> "plugged". But the journal debug output seems to suggest that it
> actually attemps to start (and gets mounted) before?
> 
> Thanks,
> 
> Martin
> 
Curious - by any chance do you mount these also at initramfs level?


More information about the systemd-devel mailing list