All of lore.kernel.org
 help / color / mirror / Atom feed
From: hasse@hagenjohansen.dk
To: Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org
Subject: Re: Subvolumes cannot be mounted after raid1 conversion
Date: Tue, 3 May 2016 20:38:14 +0200	[thread overview]
Message-ID: <e0f52464-e153-9961-57df-b45c3513ccf8@hagenjohansen.dk> (raw)
In-Reply-To: <2a657997-6da8-a190-6057-7b5dcb5d70b1@hagenjohansen.dk>

Den 03/05/16 kl. 20:31 skrev hasse@hagenjohansen.dk:
> Den 03/05/16 kl. 18:30 skrev Duncan:
>> Hugo Mills posted on Tue, 03 May 2016 10:27:46 +0000 as excerpted:
>>
>>> Given those symptoms (mount doesn't report errors, but no mount
>>> happens), I would guess that your problem is with systemd. It has a bug
>>> where it sometimes unmounts things immediately after you've mounted
>>> them.
>>
>> FWIW, I have some personal experience with that "bug" myself.  But I 
>> suspect the systemd devs might call it a "feature", not a bug.  Based on 
>> my own experience and understanding...
.
.
.

> Thanks for the very extensive explanation. I did find out systemd did
> the umount by looking in /var/log/syslog. Now I wil try to fixup systemd
> unit files and I will try not boot in either rescue or emergency mode. I
> believe it is fixable without it. It seems systemd thinks it is my old
> LVM setup(which now are moved to btrfs) which should be used and
> immediately unmounts the filesystem again because it cannot find the
> "LVM device". But I must say I find it a little bit stupid that systemd
> doesn't monitor /etc/fstab now that it behind the users back are
> generating its own unit files (I have actually seen the mount.xxx units
> etc when looking at running units...but have never looked into how it
> works...so I would now have to study that)
>
I have found the easy solution. From
https://bbs.archlinux.org/viewtopic.php?id=192991

    First:

    # systemctl daemon-reload

    followed by:

    # systemctl restart remote-fs.target

    or

    # systemctl restart local-fs.target

    depending on filesystem type

I still think it is pretty stupid that systemd doesn't monitor
/etc/fstab (when choosing to create it own secret files) :)

  reply	other threads:[~2016-05-03 18:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-03  8:52 Subvolumes cannot be mounted after raid1 conversion Hasse Hagen Johansen
2016-05-03  9:55 ` Hugo Mills
2016-05-03 10:24   ` Hasse Hagen Johansen
2016-05-03 10:27     ` Hugo Mills
2016-05-03 11:13       ` Hasse Hagen Johansen
2016-05-03 18:06         ` hasse
2016-05-03 16:30       ` Duncan
2016-05-03 18:31         ` hasse
2016-05-03 18:38           ` hasse [this message]
2016-05-04  9:54             ` Duncan
2016-05-04 18:12     ` Chris Murphy
2016-05-04 19:00       ` Hasse Hagen Johansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e0f52464-e153-9961-57df-b45c3513ccf8@hagenjohansen.dk \
    --to=hasse@hagenjohansen.dk \
    --cc=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.