Bug#801361: [systemd] attempts to unmount filesystems at end of boot, INCLUDING ROOT

[Antonio Russo]

Martin,

I don't have time to break and fix my system again right this
instant (I can debug this weekend), but things are definitely
unmounted (like /tmp). It occurred close to the closing of the
"root slice." I logged in as root, so it could have been a
_privileged_ pam-systemd/user systemd issue.

Obviously, / was not unmounted, but a whole bunch of other stuff
(like /home, which was not in use) was.

I'll check if not logging in as root is a workaround, but it's
still a serious bug if logging as root causes systemd to try
to unmount everything. As well as getting you a journalctl
output.

Thanks,
Antonio

On 10/08/15 23:52, Martin Pitt wrote:
> Control: tag -1 moreinfo
> 
> Hello Antonio,
> 
> Antonio Russo [2015-10-08 20:52 -0700]:
>> The machine in question has /var, /tmp on ZFS (/tmp is mounted
>> "legacy style"). Because these are needed fairly early in the
>> boot process, I mount the ZFS filesystems very early in the boot
>> process, immediately after systemd-udev-settle.
>>
>> At the end of the boot, systemd decides to unmount lots of things,
>> including the "legacy" mountpoint (/tmp) and zfs-style mountpoint
>> /var. Even more strangely, it attempts to unmount / (and fails).
> 
> I can confirm that the *user* systemd instance (not pid 1) attempts to
> do that when closing a session, and it looks indeed confusing:
> 
> | systemd[1653]: Reached target Default.
> | systemd[1653]: boot.mount: Mount process exited, code=exited status=1
> | systemd[1653]: Failed unmounting /boot.
> | systemd[1653]: run-user-1000.mount: Mount process exited, code=exited status=1
> | systemd[1653]: Failed unmounting /run/user/1000.
> | systemd[1653]: dev-dm\x2d2.swap: Unit entered failed state.
> | systemd[1653]: sys-kernel-debug.mount: Mount process exited, code=exited status=1
> | systemd[1653]: Failed unmounting /sys/kernel/debug.
> | [...]
> | umount[1657]: umount: /boot: umount failed: Operation not permitted
> | umount[1658]: umount: /run/user/1000: umount failed: Operation not permitted
> | swapoff[1659]: swapoff: Not superuser.
> 
> and so on. This is indeed weird, but should mostly be cosmetical as
> the user systemd instance has no privileges to actually do that.
> 
> Do you get the same? Or is it pid 1 in your case, and it actually
> unmounts things? Then this would be something different and quite
> serious.
> 
> If you see something else, please grab "journalctl -b >
> /tmp/journal.txt" (as root) after such a boot, and attach it here.
> 
> Thanks,
> 
> Martin
>