$ grep gentoo /etc/fstab /var/cache/portage/gentoo.sqfs /var/cache/portage/gentoo squashfs defaults,noatime,nodev,noexec,nosuid,noauto 0 0 $ sudo mount -vvv /var/cache/portage/gentoo mount: /dev/loop0 mounted on /var/cache/portage/gentoo. $ mount | grep gentoo <no output> Meanwhile journald logs: sudo[14328]: USER : TTY=pts/3 ; PWD=/home/USER ; USER=root ; COMMAND=/bin/mount -vvv /var/cache/portage/gentoo sudo[14328]: pam_unix(sudo:session): session opened for user root by (uid=0) sudo[14328]: pam_unix(sudo:session): session closed for user root systemd[1]: Unit var-cache-portage-gentoo.mount is bound to inactive unit. Stopping, too. systemd[1]: Unmounting /var/cache/portage/gentoo... systemd[1]: Unmounted /var/cache/portage/gentoo. It seems as if systemd would immediately unmount manually mounted directories. I can however trick it to not do that, by mounting a tmpfs in the same location prior to mounting the squashfs: $ sudo mount -t tmpfs none /var/cache/portage/gentoo $ sudo mount /var/cache/portage/gentoo.sqfs /var/cache/portage/gentoo $ mount | grep gentoo none on /var/cache/portage/gentoo type tmpfs (rw,relatime) /var/cache/portage/gentoo.sqfs on /var/cache/portage/gentoo type squashfs (ro,relatime) journald logs: sudo[17270]: USER : TTY=pts/3 ; PWD=/home/USER ; USER=root ; COMMAND=/bin/mount -t tmpfs none /var/cache/portage/gentoo sudo[17270]: pam_unix(sudo:session): session opened for user root by (uid=0) sudo[17270]: pam_unix(sudo:session): session closed for user root sudo[17283]: USER : TTY=pts/3 ; PWD=/home/USER ; USER=root ; COMMAND=/bin/mount /var/cache/portage/gentoo.sqfs /var/cache/portage/gentoo sudo[17283]: pam_unix(sudo:session): session opened for user root by (uid=0) sudo[17283]: pam_unix(sudo:session): session closed for user root
The problem is that "mount" triggers systemd apparently to start an internal unit, see also: https://forums.gentoo.org/viewtopic-t-998456-highlight-.html It seems to me that these attempts of systemd to take full control over all calls of "mount" is conceptually broken: This is nothing an init-system should interfere, to start with.
BTW, the fact that the "workaround" works is due to another conceptual brokenness of systemd: That mount-units *must* be named after path, and so systemd shoots itself into the foot when two mounts occur for the same path - systemd is not able to distinguish them internally. In other words: Its intentional breakage of user mounts breaks due to its own bugs.
From what I read this not only affects loop mounts. Changing summary.
I saw some chatter about this on systemd-devel; I think upstream is aware of the issue.
*** Bug 544704 has been marked as a duplicate of this bug. ***
hit a bug of systemd : https://bugs.freedesktop.org/show_bug.cgi?id=89383 downgrade or and you can find a patch there: https://abf.io/openmandriva/systemd/blob/master/0001-Revert-core-mount-add-dependencies-to-dynamically-mo.patch
(In reply to Druggo Yang from comment #6) > hit a bug of systemd : https://bugs.freedesktop.org/show_bug.cgi?id=89383 > > downgrade or and you can find a patch there: > https://abf.io/openmandriva/systemd/blob/master/0001-Revert-core-mount-add- > dependencies-to-dynamically-mo.patch Patch works fine. Unfortunately I had to create a local ebuild as the systemd ebuild has no epatch_user entry.
(In reply to Chris Smith from comment #7) > Unfortunately I had to create a local ebuild as the systemd ebuild has no > epatch_user entry. Sure it does: It calls autotools-utils_src_prepare, which in turn calls epatch_user.
(In reply to Mike Gilbert from comment #8) > (In reply to Chris Smith from comment #7) > > Unfortunately I had to create a local ebuild as the systemd ebuild has no > > epatch_user entry. > > Sure it does: It calls autotools-utils_src_prepare, which in turn calls > epatch_user. Just another refinement I missed. Thanks!
*** Bug 546900 has been marked as a duplicate of this bug. ***
Please give systemd-219_p112 a try. +*systemd-219_p112 (26 Apr 2015) + + 26 Apr 2015; Mike Gilbert <floppym@gentoo.org> +systemd-219_p112.ebuild: + Add a snapshot from the v219-stable branch upstream.
Mounting of loop devices works again.