zfs with mergerfs equals failed boot

1. offizieller Beitrag

    Good Evenin' Everyone,


    For a variety of reasons i'm running mergerfs over top of zfs. everything works fine with the setup/configuration until the first reboot of OMV. The system then fails to boot as it attempts to mount all fs in /etc/fstab and fails. In my case this is due to zfs not having started and imported its pools yet. If i remove the mergerfs lines from fstab and reboot OMV comes up fine. Then restore the fstab and run mount -a and everything is back to normal.


    Is there anyway to have zfs start first?


    Or is my only option to comment out the lines in fstab as OMV creates them and then create a custom script attached to the end of the init process to run to mount the mergerfs post zfs start?


    Thanks in advance.

    • Offizieller Beitrag

    I've runned into similar issues with mergerfs, systemd cannot parse mergerfs lines and relate them to the path that depends on them.
    What you need is jessie backport systemd (v230) that can parse the fstab-systemd directive x-systemd.requires


    Once you have the bpo systemd working you can use the directive in mergerfs extra options field.


    this is my line for example


    defaults,x-systemd.requires=/media/dev-disk-by-label-ironwolf_3TB_1,x-systemd.requires=/media/dev-disk-by-label-ironwolf_3TB_2,allow_other,func.getattr=newest


    With this i force systemd to mount first the mergerfs devices finally the union point


    Note that i don't use ZFS, but i can clearly see your issue here.


    The problem is systemd tries to mount all entries simultaneously, systemd can parse related paths, like nfs, binds etc so it will generate all dependencies at boot, but since it doesn't know zfs it will try to mount that resulting in failure of mount or pool import probably

    Good Evenin' subzero79,


    Interesting as I've always understood that fstab is parsed and mounted top down. When i'm using mergerfs with ext4 for example OMV puts the mounts for the ext4 partitions first and the mergerfs lines last. This works upon reboot without issue (maybe just by luck based on your information). In the case of zfs its not handled by fstab at all. There is a file at /etc/zfs/zpool.cache which tells the system about known pools upon startup so the system will re-import/mount them.


    Maybe the question should be can we start zfs prior to fstab being processed? I'm not sure how this would work since all the zfs pools mount to a individual per pool folder off of /. We need the final / to be mounted first. Maybe the solution is to do root "/" on zfs as well. That seems a little intrusive to OMV.


    I should mention that commenting out the fstab mergerfs entry that OMV creates and adding a /usr/bin/mergerfs ..... command to rc.local works without issue. Kind of a pain but gets me going while looking for a better solution....

    • Offizieller Beitrag

    That behavior is correct on systems without systemd. That ext4 works for you is just luck. In my case it didn't work, so what happened was mergerfs pool was mounted first then one of member disks, and when this happened mergerfs already wrote to mount path failing the the mount of physical disk since it wasn't empty.
    Is up to you the solution. Is an alternative

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden