Guus Sliepen wrote... > I understand the gravity of this bug, the problem is that it's not > ifupdown's fault. That it was ifupdown itself that kept a network > interface up when it detected a network filesystem still being mounted > was a *hack*.
Agreed, but at least it worked quite well for the past years for the
cases it covered - and as I mentioned there were some more where it did
not, so I'll be glad if there's a way to handle this in a saner way.
Currently however, it's breakage.
> Maybe this bug should be reassigned to aoetools to provide a
> proper systemd.service file?
Wearing the aoetools maintainer's hat, I'll be happy to provide that but
will need help on it.
> Another option is to explicitly add a dependency on the network for a
> given mount point in /etc/fstab, see the systemd.mount manpage.
> Basically, the following should work:
>
> /dev/etherd/... /mountpoint ext4 x-systemd.requires=network-online.target
> 0 2
How about block devices that were mounted manually i.e. are not listed
in /etc/fstag? I doubt they will handled in a sane way during shutdown.
> With a proper aoetools.service, perhaps it should become
> x-systemd.requires=aoetools.service. I see nbd-client has a
> nbd@.service, but it requires you to write your own dev-%i.device
> script. I will duplicate this bug and reassign to aoetools and
> nbd-client. I'll also create a bug report for the kernel bug found.
My gut feeling warns me about a dependency loop in case of more complex
mount setups like local block device mounted somewhere inside a mounted
AoE block device. A check of that situation will be part of the tests.
Regards,
Christoph
signature.asc
Description: Digital signature
