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.
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.
$ 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.
Ok so in systemd-204, in TRUSTY, you will find the following logic to create the mount units:
- manager_loop proc_self_ mountinfo device_ links
- process-event (WATCH_MOUNT)
- mount_fd_event
- mount_load_
- mount_add_one (if load_extras == true)
- mount_add_extras
- mount_add_
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");
return -ENOMEM;
if (!name)
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: 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.
- Mount snap "core" (2898) ([start snap-core-
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 ^.