Comment 4 for bug 1718966

Ok so in systemd-204, in TRUSTY, you will find the following logic to create the mount units:

- manager_loop
  - process-event (WATCH_MOUNT)
    - mount_fd_event
      - mount_load_proc_self_mountinfo
        - mount_add_one (if load_extras == true)
          - mount_add_extras
            - mount_add_device_links

The last function will add: device/mount/socket/swap/path/requires/... dependencies in the mount unit to be created. The first one "device" is handled by "mount_add_device_links" and, according to logic:

        if (p->passno > 0 &&
            UNIT(m)->manager->running_as == SYSTEMD_SYSTEM) {
                char *name;
                Unit *fsck;
                /* Let's add in the fsck service */

                /* aka SPECIAL_FSCK_SERVICE */
                name = unit_name_from_path_instance("systemd-fsck", p->what, ".service");
                if (!name)
                        return -ENOMEM;

If filesystem option passno is 0, it won't have the systemd-fsck unit as a requirement, meaning that no error will be given, allowing the mount unit, created by snappy, to work.

----

Check it out:

1)

## /etc/fstab

LABEL=LVROOT / ext4 errors=remount-ro 0 1
LABEL=LVVAR /var ext4 defaults 0 1
LABEL=TESTE /teste ext4 defaults 0 1

$ sudo snap install hello-world

error: cannot perform the following tasks:
- Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit status 6: Failed to issue method call: Unit systemd-fsck@dev-disk-by\x2dlabel-LVVAR.service failed to load: No such file or directory. See system logs and 'systemctl status systemd-fsck@dev-disk-by\x2dlabel-LVVAR.service' for details.

2)

## /etc/fstab

LABEL=LVROOT / ext4 errors=remount-ro 0 1
LABEL=LVVAR /var ext4 defaults 0 0
LABEL=TESTE /teste ext4 defaults 0 0

$ sudo snap install hello-world
hello-world 6.3 from 'canonical' installed

----

Now I'm checking why debian/rules in systemd-204 didn't include fsck@.service files in the final .deb for "systemd" package. Possibly this wasn't noticed because at the time systemd was running in Trusty, it wasn't imagined that mount units would be managed by systemd (like snappy is doing now). I'll check if adding the units for fsck (plus having systemd-fsck binary, already there) is enough for the mount logic to work.

For now, use the workaround above ^.